RK3588-Systemanpassung: Eingaben für Android, Linux und OpenHarmony

Technischer Leitfaden

Prüfen Sie bei der Beschaffung einer RK3588 Android-Board-SDK-Baseline zunächst die untenstehenden Eingaben, Nachweise und offenen Punkte, bevor Sie einen Ansatz wählen. Weisen Sie Verantwortliche und Beschaffungswege für fehlende Dokumente zu; eine bloße Demonstration belegt weder Kompatibilität noch Leistung.

Was die drei Projektrichtungen bestätigen müssen

Wischen Sie horizontal über die Tabelle, um alle Spalten anzuzeigen.

Richtung	Haupteingaben	Separat abzugrenzende Arbeiten
Android-Systeme und Geräteanwendungen	Hersteller-Android-SDK, Board, Peripheriegeräte sowie APK/SDK	Systemkonfiguration, Berechtigungen, Peripherieschnittstellen, Anwendungsdienste, Signierung und Updates.
Linux-BSP und Geräteanwendungen	Bootloader, Kernel, Device Tree, Root-Dateisystem und Ziel-Peripheriegeräte	Boot-Vorgang, Treiber, Userspace-Schnittstellen, Dienste, Images und Wiederherstellung.
Stufenweise OpenHarmony-Anpassung	Angegebener Quellcode, Board-Dokumentation sowie Build-/Boot-Ziele	Minimalen Boot, Dienste, Grafik und Multimedia als separate Stufen bewerten.

Dies ist eine Tabelle zur Projektzuständigkeit, keine systemübergreifende Kompatibilitätsliste. Bei Wechsel von Betriebssystem, SDK oder Board müssen bestehende Verifizierungsnachweise neu bewertet werden.

Vor der Angebotsanfrage vorzubereitende Eingaben

• Vollständiges Board-Modell, Revision, Schaltplan sowie Speicher- und Debug-Anschlüsse.

• SDK/Quellcode, Version oder Commit, Toolchain, Build-Befehle und vorhandene Images.

• Modelle der Peripheriegeräte, Schnittstellen, Zielmodi und aktueller Funktionsstatus.

• Anwendungen, Schnittstellen, Berechtigungen, Ein-/Ausgaben und Drittanbieter-Abhängigkeiten.

• Reproduktionsschritte, Protokolle, Häufigkeit und bereits versuchte Maßnahmen bei bestehenden Fehlern.

• Vereinbarter Quellcode, Patches, Images, Dokumentation und Wartungsverantwortung.

Nicht verfügbare Dokumente sind als Lücken aufzulisten; vereinbaren Sie deren Beschaffung oder definieren Sie eine Bewertungsphase. Füllen Sie Lücken nicht mit ungeprüften Versionen.

Wiederholbare Abnahmebedingungen festlegen

Ersetzen Sie „Systemanpassung abgeschlossen“ durch Bedingungen wie: Booten der angegebenen Version auf dem angegebenen Board vom angegebenen Medium sowie Prüfung von Protokollen und Diensten gemäß dokumentierter Schritte. Display, Kamera, Audio, Netzwerk, Anwendungen, Updates und Dauerlauf benötigen jeweils eigene Bedingungen; ein minimaler Boot deckt diese nicht automatisch ab.

Für NPU-Aufgaben sind Modell, Samples, Vorverarbeitung, Nachverarbeitung und Zielumgebung separat anzugeben. Ein bootfähiges System belegt nicht die Modellbereitstellung.

Fallbeispiele zur Einordnung der Projektphasen nutzen

Der OpenHarmony RK3588 Stage-0-Fall (Original Chinesisch) dokumentiert eine begrenzte Headless-Boot-Stufe. Die dortigen Protokoll- und Image-Prüfungen veranschaulichen die stufenweise Lieferung; sie belegen keine vollständige Grafik-, Multimedia- oder Produktionszertifizierung.

Die Integration von Android-Anwendungen wird im Offline-TTS-SDK-Fall (Original Chinesisch) innerhalb der jeweiligen System-, Geräte- und Testgrenzen des Falls veranschaulicht.

Nachfolgende Arbeitspakete aufteilen

Bei vorhandenem SDK mit nicht funktionierender Peripherie prüfen Sie die Android-Anpassung oder den Linux-BSP-Dienst. Modellkonvertierung und Inferenzintegration gehören zum NPU-Dienst. Diese Links führen zu den originalen chinesischen Leistungsbeschreibungen. Bereiten Sie Board-, Versions-, Schnittstellen- und Testeingaben vor, bevor Sie Entwicklungsumfang und Kosten bewerten.

Beschaffungs-Checkliste

Wischen Sie horizontal über die Tabelle, um alle Spalten anzuzeigen.

Punkt	Eingaben und Prüfungen	Entscheidungsgrenze
Versionsabgleich	Board-Revision mit SDK-Commit, Patches und vorhandenem Image abgleichen	Derselbe Prozessor belegt keine Board-Kompatibilität
Quell- und Build-Zugriff	Quellumfang, Toolchain, Zugriff auf Abhängigkeiten und Build-Rechte bestätigen	Verantwortliche für fehlende Eingaben benennen, statt ungeprüfte Versionen einzusetzen
Signierung und Release	Debug-Builds, Signierungsdienste, Updates und Drittanbieter-Lizenzen trennen	Private Produktionsschlüssel müssen nicht an den Entwickler übergeben werden; kontrollierten Signierungsprozess vereinbaren

Welche Eingaben werden vor Beginn benötigt?

Vollständiges Board-Modell und Revision, Android-SDK, Build-Anleitung, vorhandene Images, Peripherieliste und serielle Protokolle. Prüfen Sie zunächst Dokumentversionen und Verfügbarkeit; fehlende Elemente als offene Eingaben vormerken.

Wie sind Lieferung und Abnahme zu definieren?

Zielboard in der vereinbarten Umgebung nach gelieferter Prozedur bauen und booten; Versionen, Protokolle und Probleme prüfen sowie Umgang mit blockierenden Fehlern vereinbaren. Eine reproduzierbare Baseline belegt keine Bereitschaft von Peripherie, Anwendung, Dauerlauf oder Produktion; Linux und OpenHarmony separat abgrenzen.

Unternehmen in Shenzhen, China, können diese Eingaben für eine Remote-Prüfung einreichen. Prototypenintegration, Musterversand, Vor-Ort-Arbeiten und zugehörige Kosten sind projektspezifisch zu vereinbaren.

Zusätzliche Beschaffungsprüfungen für Linux-Zielboards

Wischen Sie horizontal über die Tabelle, um alle Spalten anzuzeigen.

Punkt	Eingaben und Prüfungen	Entscheidungsgrenze
Board und Medium	Board-Revision, Speicherkonfiguration und Boot-Auswahl prüfen	Derselbe Prozessor belegt keine identische Boot-Konfiguration
SDK-Komponenten	Versionen von Bootloader, Kernel, Device Tree, Root-Dateisystem und Toolchain auflisten	Zwischen Hersteller-Binärdateien, bearbeitbarem Quellcode und Weiterverbreitungsrechten unterscheiden
Debug und Wiederherstellung	Serielle Pegel, Verkabelung, Wiederherstellungstools und autorisierten Zugriff bestätigen	Ursprüngliches Boot-Medium ohne Wiederherstellungspfad nicht überschreiben

Diese zusätzlichen Prüfungen unterstützen Linux-Baseline-Reviews für Unternehmen in Tianjin, China. Android, Linux und OpenHarmony separat abgrenzen; ihre Testergebnisse sind nicht austauschbar.

Prüfen Sie den Leistungsumfang und reichen Sie die Projekteingaben ein, bevor Sie Entwicklung und Lieferung vereinbaren. Leistungsumfang im chinesischen Original