Le projet Android Open Source (AOSP) fournit plusieurs outils et suites de tests pour tester différentes parties de votre implémentation. Avant d'utiliser les pages de cette section, vous devez connaître les termes suivants:
- Appareil compatible avec Android
- Appareil pouvant exécuter n'importe quelle application tierce écrite par des développeurs tiers à l'aide du SDK et du NDK Android. Les appareils compatibles avec Android doivent respecter les exigences du document de définition de compatibilité (CDD) et réussir les tests de la suite de tests de compatibilité (CTS). Les appareils compatibles avec Android peuvent participer à l'écosystème Android, ce qui inclut la licence potentielle de Google Play, la licence potentielle de la suite d'applications et d'API Google Mobile Services (GMS), et l'utilisation de la marque Android. Tout le monde peut utiliser le code source Android, mais pour être considéré comme faisant partie de l'écosystème Android, un appareil doit être compatible avec Android.
- artefact
- Journal lié à la compilation qui permet le dépannage local.
- Document de définition de la compatibilité (CDD)
- Document qui énumère les exigences logicielles et matérielles d'un appareil compatible avec Android.
- La suite de tests de compatibilité
Suite de test sans frais de qualité professionnelle, disponible en téléchargement au format binaire ou source dans AOSP. Le CTS est un ensemble de tests unitaires conçus pour être intégrés à votre workflow quotidien. L'objectif du CTS est de révéler les incompatibilités et de s'assurer que le logiciel reste compatible tout au long du processus de développement.
Les tests CTS et les tests de plate-forme ne s'excluent pas mutuellement. Voici quelques consignes générales:
- Si un test affirme l'exactitude des fonctions ou des comportements de l'API du framework, et que le test doit être appliqué aux partenaires OEM, il doit être dans CTS.
- Si un test vise à détecter des régressions lors du développement de la plate-forme, et qu'il peut nécessiter une autorisation privilégiée pour être effectué, et qu'il 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 Google Mobile (GMS)
Ensemble d'applications et d'API Google pouvant être préinstallées sur des appareils.
- GoogleTest (GTest)
Framework de tests et de simulation C++ Les binaires GTest accèdent généralement aux couches d'abstraction de niveau inférieur ou effectuent l'IPC brute sur divers services système. L'approche de test pour GTest est généralement étroitement liée au service testé. CTS contient le framework GTest.
- test d'instrumentation
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 un contexte d'application de base, et un thread d'instrumentation est lancé dans la machine virtuelle du processus d'application. CTS contient des tests d'instrumentation.- Logcat
Outil de ligne de commande qui crée un journal des messages système, y compris les traces de la pile indiquant quand l'appareil génère une erreur et les messages que vous avez écrits depuis votre application avec la classe
Log
.- journalisation
Utilisation d'un journal pour suivre les événements du système informatique, tels que les erreurs. La journalisation dans Android est complexe en raison de la combinaison des normes utilisées qui sont combinées dans l'outil Logcat.
- test postsubmit
Test Android effectué lorsqu'un nouveau correctif est validé dans une branche de kernel commune. En saisissant
aosp_kernel
comme nom de branche partiel, vous pouvez afficher une liste de branches du kernel avec des résultats disponibles. Par exemple, les résultats pourandroid-mainline
sont disponibles sur https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.- test avant envoi
Test utilisé pour éviter l'introduction de défaillances dans les noyaux communs.
- Fédération du commerce
Également appelé Tradefed, il s'agit d'un framework de test continu conçu pour exécuter des tests sur des appareils Android. Par exemple, Tradefed permet d'exécuter des tests de la suite de tests de compatibilité et de la suite de tests fournisseur.
- Suite de test pour les fournisseurs (VTS)
Ensemble de fonctionnalités étendues pour les tests Android, la promotion d'un processus de développement basé sur les tests et l'automatisation des tests de la couche d'abstraction matérielle (HAL) et du noyau de l'OS.
Types de tests de plate-forme
Un test de plate-forme interagit généralement avec un ou plusieurs des services système Android ou des couches HAL, exécute les fonctionnalités de l'objet testé et vérifie la validité du résultat du test. Un test de plate-forme peut:
- (Type 1) Exercice des API du framework à l'aide du framework Android. Voici des exemples d'API spécifiques que vous pouvez tester :
- API publiques destinées aux applications tierces
- API masquées destinées aux applications privilégiées, à savoir les API système ou les API privées (
@hide
,protected
oupackage private
)
- (Type 2) Appelez directement les services système Android à l'aide de liaisons brutes ou de proxys IPC.
- (Type 3) Interagir directement avec les HAL à l'aide d'API de bas niveau ou d'interfaces IPC.
Les tests de type 1 et 2 sont généralement des tests d'instrumentation, tandis que les tests de type 3 sont généralement des tests G.
Et maintenant ?
Voici une liste de documents que vous pouvez consulter pour en savoir plus:
Si vous n'avez pas étudié l'architecture Android, consultez la section Présentation de l'architecture.
Si vous créez un appareil compatible avec Android, consultez la présentation du programme de compatibilité Android.
Pour intégrer des tests hôtes d'instrumentation, des tests fonctionnels, métriques et JAR dans un service de test continu de plate-forme, consultez la page Workflow de développement de tests.
Pour détecter les failles de vos appareils et les renforcer, consultez Tests de sécurité.
Pour en savoir plus sur le test de vos implémentations de HAL et de kernel, consultez la section Suite de test de fournisseur (VTS) et infrastructure.
Pour les tests d'applications, consultez Principes de base des tests d'applications Android et effectuez le cours Advanced Android in Kotlin 05.1:Testing Basics (Principes de base des tests) à l'aide des exemples fournis.
Découvrez les tests de présoumission de base disponibles via les hooks de dépôt. Ces hooks peuvent être utilisés pour exécuter des analyseurs de code, vérifier la mise en forme et déclencher des tests unitaires avant de continuer, par exemple en important un commit. Ces hooks sont désactivés par défaut. Pour en savoir plus, consultez la section Hooks de préchargement AOSP.
Pour en savoir plus sur la journalisation, consultez Comprendre la journalisation.
Pour comprendre comment déboguer le code Android, consultez Déboguer le code natif de la plate-forme Android.