Éléments d'adaptation système RK3588 : périmètre Android, Linux et OpenHarmony

Guide d'ingénierie

Pour l'acquisition d'une baseline SDK Android pour carte RK3588, vérifiez les entrées, les preuves et les points non résolus ci-dessous avant de choisir une approche. Attribuez des responsables et des méthodes d'acquisition pour les documents manquants ; une démonstration seule ne suffit pas à établir la compatibilité ou les performances.

Ce que les trois directions de projet doivent confirmer

Faites défiler le tableau horizontalement pour afficher toutes les colonnes.

Direction	Entrées principales	Travaux à délimiter séparément
Systèmes Android et applications embarquées	SDK Android du fournisseur, carte, périphériques et APK/SDK	Configuration système, autorisations, interfaces périphériques, services applicatifs, signature et mises à jour.
BSP Linux et applications embarquées	Bootloader, noyau, arbre des périphériques, système de fichiers racine et périphériques cibles	Démarrage, pilotes, interfaces espace utilisateur, services, images et récupération.
Adaptation OpenHarmony par étapes	Code source spécifié, documentation de la carte et cibles de compilation/démarrage	Évaluer le démarrage minimal, les services, les graphiques et le multimédia comme des étapes distinctes.

Il s'agit d'un tableau de répartition des responsabilités projet, et non d'une liste de compatibilité inter-systèmes. Réévaluez la portée des enregistrements de vérification existants lorsque le système d'exploitation, le SDK ou la carte change.

Entrées à préparer avant de demander un devis

• Modèle complet de la carte, révision matérielle, schéma, stockage et connexions de débogage.

• SDK/code source, version ou commit, chaîne d'outils, commandes de compilation et images existantes.

• Modèles des périphériques, interfaces, modes cibles et états de fonctionnement actuels.

• Applications métier, interfaces, autorisations, entrées/sorties de données et dépendances tierces.

• Étapes de reproduction, journaux, fréquence et mesures déjà tentées pour les défaillances existantes.

• Code source, correctifs, images, documentation et responsabilités de maintenance convenus.

Listez les documents indisponibles comme des lacunes et convenez de la manière de les obtenir ou définissez une phase d'évaluation. Ne comblez pas les lacunes avec des versions non vérifiées.

Définir des conditions d'acceptation reproductibles

Remplacez « adaptation système terminée » par des conditions telles que : démarrer la version spécifiée sur la carte spécifiée depuis le support spécifié, puis vérifier les journaux et les services selon des étapes documentées. L'affichage, la caméra, l'audio, le réseau, les applications, les mises à jour et l'endurance nécessitent chacun leurs propres conditions ; un démarrage minimal ne les couvre pas automatiquement.

Pour les tâches NPU, ajoutez le modèle, les échantillons, le prétraitement, le post-traitement et l'environnement cible. Un système qui démarre ne prouve pas que le modèle est déployé.

Utiliser les cas existants pour comprendre les phases du projet

Le cas original chinois OpenHarmony RK3588 Stage-0 documente une étape limitée de démarrage sans interface graphique sur une carte spécifique. Ses méthodes de vérification des journaux et des images illustrent une livraison par étapes ; elles n'établissent pas qu'une certification complète des graphiques, du multimédia ou de la production est acquise.

L'intégration d'applications Android peut être illustrée par le cas original chinois SDK TTS hors ligne, qui doit également être compris dans les limites de son propre système, appareil et environnement de test.

Découper les lots de travaux suivants

Si vous disposez déjà d'un SDK mais que les périphériques ne fonctionnent pas, consultez l'Adaptation Android ou le Service BSP Linux. La conversion de modèles et l'intégration de l'inférence relèvent du Service NPU. Ces liens pointent vers les périmètres originaux en chinois. Préparez la carte, la version, les interfaces et les entrées de test avant d'évaluer le périmètre de développement et les coûts.

Liste de contrôle d'acquisition

Faites défiler le tableau horizontalement pour afficher toutes les colonnes.

Point de contrôle	Entrées et vérifications	Limite de décision
Correspondance des versions	Faire correspondre la révision matérielle de la carte au commit SDK, aux correctifs et à l'image existante	Le même processeur ne garantit pas la compatibilité au niveau de la carte
Accès au code source et à la compilation	Confirmer le périmètre du code source, la chaîne d'outils, l'accès aux dépendances et les droits de compilation	Attribuer des responsables pour les entrées manquantes plutôt que de substituer des versions non vérifiées
Signature et publication	Distinguer les compilations de débogage, les services de signature, les mises à jour et les licences tierces	Les clés privées de production n'ont pas à être remises au développeur ; convenir d'un processus de signature contrôlé

Quelles entrées sont nécessaires avant de commencer ?

Le modèle complet et la révision de la carte, le SDK Android, les instructions de compilation, les images existantes, la liste des périphériques et les journaux série. Vérifiez d'abord les versions et la disponibilité des documents, et conservez les éléments manquants comme entrées non résolues.

Comment définir la livraison et l'acceptation ?

Compiler et démarrer la carte cible dans l'environnement convenu en utilisant la procédure livrée ; vérifier les versions, les journaux et les problèmes, et convenir du traitement des défauts bloquants. Une baseline reproductible n'établit pas la préparation des périphériques, des applications, de l'endurance ou de la production ; délimitez Linux et OpenHarmony séparément.

Les entreprises de Shenzhen, en Chine, peuvent soumettre ces entrées pour une revue à distance. L'intégration de prototypes, l'envoi d'échantillons, le travail sur site et les coûts associés doivent être confirmés pour chaque projet spécifique.

Vérifications supplémentaires pour l'acquisition de cartes cibles Linux

Faites défiler le tableau horizontalement pour afficher toutes les colonnes.

Point de contrôle	Entrées et vérifications	Limite de décision
Carte et support	Vérifier la révision de la carte, la configuration du stockage et la sélection du démarrage	Le même processeur ne prouve pas que la configuration de démarrage est identique
Composants du SDK	Lister les versions du bootloader, du noyau, de l'arbre des périphériques, du système de fichiers racine et de la chaîne d'outils	Distinguer les binaires du fournisseur, le code source modifiable et les droits de redistribution
Débogage et récupération	Confirmer les niveaux série, le câblage, les outils de récupération et l'accès autorisé	Ne pas écraser le support de démarrage original sans disposer d'un chemin de récupération

Ces vérifications supplémentaires s'appliquent également aux revues de baseline Linux pour les entreprises de Tianjin, en Chine. Délimitez Android, Linux et OpenHarmony séparément ; leurs résultats de test ne sont pas interchangeables.

Examinez le périmètre du service et soumettez les éléments d'entrée du projet avant de convenir du développement et de la livraison. Périmètre du service dans le texte original en chinois