AOSP fournit plusieurs outils et suites de tests pour tester différentes parties de votre implémentation. Avant de continuer avec cette section, vous devez être familier avec les termes suivants :
- Appareil compatible Android
- Un appareil capable d'exécuter n'importe quelle application tierce écrite par des développeurs tiers à l'aide du SDK et du NDK Android. Les appareils compatibles Android doivent respecter les exigences du document de définition de compatibilité (CDD) et réussir la suite de tests de compatibilité (CTS) . Les appareils compatibles Android sont éligibles pour participer à l'écosystème Android, qui comprend une licence potentielle du Google Play Store, une licence potentielle de la suite d'applications et d'API Google Mobile Services (GMS) et l'utilisation de la marque Android. Tout le monde est invité à utiliser le code source d’Android, mais pour être considéré comme faisant partie de l’écosystème Android, un appareil doit être compatible avec Android.
- artefact
- Les artefacts sont des journaux liés à la construction qui permettent un dépannage local.
- Document de définition de compatibilité (CDD)
- Un document qui énumère les exigences logicielles et matérielles pour un appareil compatible Android.
- Suite de tests de compatibilité (CTS)
Une suite de tests gratuite de qualité commerciale, disponible en téléchargement sous forme binaire ou source dans AOSP. Le CTS est un ensemble de tests unitaires conçus pour être intégrés à votre flux de travail quotidien. L'objectif de CTS est de révéler les incompatibilités et de garantir que le logiciel reste compatible tout au long du processus de développement.
Les tests CTS et plateforme ne s’excluent pas mutuellement. Voici quelques directives générales:
- Si un test vérifie l'exactitude des fonctions ou des comportements de l'API du framework et qu'il doit être appliqué aux partenaires OEM, il doit l'être dans CTS.
- Si un test est destiné à détecter les régressions pendant le développement de la plate-forme et peut nécessiter une autorisation privilégiée pour être exécuté et peut dépendre des détails d'implémentation (tels que publiés dans AOSP), il doit s'agir d'un test de plate-forme.
- Services mobiles Google (GMS)
Un ensemble d'applications et d'API Google pouvant être préinstallées sur les appareils.
- GoogleTest (GTest)
GTest est un framework de test et de moquerie C++. Les binaires GTest accèdent généralement aux couches d'abstraction de niveau inférieur ou effectuent un IPC brut sur divers services système. L'approche de test pour GTest est généralement étroitement associée au service testé. CTS contient le framework GTest.
- essai d'instrumentation
Un test d'instrumentation fournit un environnement d'exécution de test spécial lancé par la commande
am instrument
, dans lequel le processus d'application ciblé est redémarré et initialisé avec le contexte d'application de base, et un thread d'instrumentation est démarré dans la machine virtuelle du processus d'application. CTS contient des tests d'instrumentation.- Logcat
Logcat est un outil de ligne de commande qui crée un journal des messages système, y compris les traces de pile du moment où l'appareil génère une erreur et les messages que vous avez écrits à partir de votre application avec la classe
Log
.- enregistrement
La journalisation fait référence à l'utilisation d'un journal pour suivre les événements du système informatique, tels que les erreurs. La connexion sous Android est complexe en raison de la combinaison de normes utilisées et combinées dans l'outil Logcat.
- test post-soumission
Les tests post-soumission Android sont effectués lorsqu'un nouveau correctif est validé dans une branche commune du noyau. En entrant
aosp_kernel
comme nom de branche partiel, vous pouvez voir une liste des branches du noyau avec les résultats disponibles. Par exemple, les résultats pourandroid-mainline
peuvent être trouvés sur https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid .- test de pré-soumission
Les tests de pré-soumission sont utilisés pour empêcher l'introduction de pannes dans les noyaux communs.
- Fédération du commerce
Trade Federation, également appelé Tradefed, est un framework de test continu conçu pour exécuter des tests sur les appareils Android. Par exemple, Tradefed est utilisé pour exécuter les tests Compatibility Test Suite et Vendor Test Suite.
- Suite de tests des fournisseurs (VTS)
L'Android Vendor Test Suite (VTS) offre des fonctionnalités étendues pour les tests Android, favorise un processus de développement basé sur les tests et automatise les tests du noyau HAL et OS.
Types de tests de plateforme
Un test de plate-forme interagit généralement avec un ou plusieurs services du système Android ou couches de couche d'abstraction matérielle (HAL), exerce les fonctionnalités du sujet testé et affirme l'exactitude du résultat du test. Un test de plateforme pourrait :
- (type 1) Exercer les API du framework à l'aide du framework Android. Les API spécifiques utilisées peuvent inclure :
- API publiques destinées aux applications tierces
- API cachées destinées aux applications privilégiées, à savoir les API système ou les API privées (
@hide
, or
protected,
package private`)
- (type 2) Invoquez directement les services du système Android à l’aide d’un classeur brut ou de proxys IPC.
- (type 3) Interagissez directement avec les HAL à l'aide d'API de bas niveau ou d'interfaces IPC.
Les tests de types 1 et 2 sont généralement des tests d'instrumentation, tandis que les tests de type 3 sont généralement des GTests.
Et après?
Voici une liste des prochains documents que vous pourriez lire :
Si vous n'avez pas étudié l'architecture Android, consultez Présentation de l'architecture .
Si vous créez un appareil compatible Android, consultez la présentation du programme de compatibilité Android .
Pour intégrer des tests d'instrumentation, fonctionnels, de métriques et d'hôte JAR dans un service de test continu de plateforme, consultez Workflow de développement de tests .
Pour détecter et renforcer vos appareils contre les vulnérabilités, consultez Tests de sécurité .
Pour en savoir plus sur les tests de vos implémentations HAL et du noyau, consultez Vendor Test Suite (VTS) et infrastructure .
Pour tester les applications, lisez Principes de base du test des applications Android et effectuez l' Android avancé dans Kotlin 05.1 : Testing Basics à l'aide des exemples fournis.
Découvrez les tests de base de pré-soumission disponibles via les hooks de dépôt. Ces hooks peuvent être utilisés pour exécuter des linters, vérifier le formatage et déclencher des tests unitaires avant de continuer, comme le téléchargement d'un commit. Ces hooks sont désactivés par défaut. Pour plus d’informations, consultez AOSP Preuplaod Hooks .
Pour en savoir plus sur la journalisation, consultez Comprendre la journalisation .
Pour comprendre comment déboguer le code Android, consultez Débogage du code de plateforme natif .