Modulführer
Bei einer Android SDK-Lieferung sollten die Bibliothek, die Beispiel-App, die Schnittstellendokumentation und die Build-Datensätze auf einer Versionsbasislinie platziert werden. AAR beschreibt die gepackte Bibliothek, die Beispiel-App zeigt die Integration, die Dokumentation definiert Aufrufeinschränkungen und Build-Datensätze verfolgen das Artefakt bis zu seiner Quelle.
Was der AAR und die Beispiel-App bieten
AAR ist ein Android-Bibliotheksarchiv, das Code, Ressourcen, ein Manifest und konfigurierte native Bibliotheken enthalten kann. APK ist ein installierbares Anwendungsartefakt. Geben Sie an, welche Abhängigkeiten gepackt sind und welche das Clientprojekt bereitstellen muss. In der Bibliotheksdokumentation Android werden die Unterscheidung zwischen Bibliothek und Anwendung sowie die Handhabung von Abhängigkeiten erläutert.
Android-Bibliotheksdokumentation
ABI steht für „Application Binary Interface“ und identifiziert native Code-Anforderungen für die Ziellaufzeit. Überprüfen Sie es zusammen mit der Systemversion, externen Bibliotheken, Modelldateien und Ressourcenpfaden.
Wischen Sie horizontal über die Tabelle, um alle Spalten anzuzeigen.
| Artefakt | Inhalt und Zweck | Bedingungen zur Bestätigung |
|---|---|---|
| AAR-Bibliothek | Öffentliche Schnittstellen, Ressourcen und enthaltene native Dateien | ABI, Systemversion, Abhängigkeiten und Ressourcenbelastung |
| Demo Beispiel-App | Initialisierung, Eingabe, Rückrufe und grundlegende Interaktion | Berechtigungen, Threading, Lebenszyklus und Laufzeit |
| Schnittstellendokumentation | Parameter, Callbacks, Fehler, Abbruch und Ressourcenfreigabe | Übereinstimmung zwischen Dokumentation und Code |
| Erstellen Sie Datensätze | Quellrevision, Toolchain, Einstellungen, Schritte und Artefakt-Hash | Rückverfolgbarkeit, Reproduktionsbedingungen und Wartung |
Eine Checkliste für den Lieferindex
Ordnen Sie das Material nach Zweck. Vereinbaren Sie die tatsächlichen Verzeichnisnamen und den Quellbereich innerhalb des Projekts.
Wischen Sie horizontal über die Tabelle, um alle Spalten anzuzeigen.
| Material | Zu definierende Inhalte |
|---|---|
| Bibliothek und Version | AAR-Datei, Versionsidentität und Hash |
| Integrationsbeispiel | Demo-Projekt, Ausführungsschritte und erforderliche Berechtigungen |
| Abhängigkeiten und Ressourcen | Externe Abhängigkeiten, native ABI, Modelle und Ressourcenplatzierung |
| Schnittstellen und Ausfälle | Parameter, Threads, Fehlercodes, Abbruch und Ressourcenfreigabe |
| Bauen und testen | Toolchain, Build-Schritte, Geräte, Fälle und bekannte Grenzen |
| Lizenzierung und Veröffentlichung | Bedingungen Dritter, Vertriebsumfang und Verantwortung für die Signatur von Beispiel-Apps |
Akzeptanz in der ersten Phase
Halten Sie das Gerät, die Android-Version, ABI, die Coderevision und die Aufrufmethode während der gesamten Prüfungen konsistent. Überprüfen Sie Initialisierung, wiederholte Aufrufe, Abbruch, Fehlerreaktionen und Freigabe. Überprüfen Sie für Kamera- oder Audiofunktionen den Pufferbesitz und die asynchrone Lebensdauer. Definieren Sie Langtextgrenzen nur für SDK-Aufgaben, die tatsächlich Sprache oder Text verarbeiten.
Geben Sie für Leistung und Dauerbetrieb Belastung, Dauer und Aufzeichnungsmethode an. Vereinbaren Sie die Produktionssignatur, die Store-Einreichung und die Client-App-Veröffentlichung separat. Durch das Vervollständigen eines Bibliothekspakets wird die Annahme der Anwendungsfreigabe nicht abgeschlossen.
Vorhandene SDK Material- und Verpackungseingaben
Das RK3588-S Offline-Projekt TTS SDK und das Projekt RK3588 Vision SDK bieten Referenzen zu verschiedenen Funktionen, Geräten und Testbedingungen. Lesen Sie deren Leistung und Umfang separat. Stellen Sie Code, ABI, Schnittstellen, Abhängigkeiten und Lieferziele über den Anpassungsdienst RK3588 Android bereit, um Softwarepaketierung, Integration und Prüfungen zu definieren.
RK3588-S offline TTS SDK Projekt, auf Chinesisch · RK3588 Vision SDK-Projektbeispiel, auf Chinesisch · RK3588 Android Anpassungsservice, auf Chinesisch
Online
Telefon
WeChat
zurück nach oben