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 ce , vous devez connaître les termes suivants:
- Appareil compatible avec Android
- Un appareil capable d'exécuter n'importe quelle application tierce développée par des développeurs tiers. à l'aide du SDK et du NDK Android. Les appareils compatibles avec Android doivent respecter le les exigences du document de définition de compatibilité (CDD) et transmettez la Compatibility Test Suite (CTS) Compatible avec Android appareils peuvent participer à l'écosystème Android, qui comprend toute licence potentielle de Google Play, ou toute licence potentielle du Suite des services Google Mobile l'application et les API, et l'utilisation de la marque Android. Tout le monde est le bienvenu dans utiliser le code source Android, mais pour être considéré comme faisant partie de l'écosystème Android, l'appareil doit être compatible avec Android.
- artefact
- Journal lié à la compilation qui permet le dépannage local.
- Document de définition de compatibilité (CDD)
- Document qui énumère la configuration logicielle et matérielle requise pour une appareil compatible avec Android.
- La suite de tests de compatibilité
Suite de tests sans frais de qualité commerciale, disponible au téléchargement sous forme binaire ou source dans AOSP. La 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 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 exemples consignes:
- Si un test vérifie l'exactitude des fonctions ou des comportements de l'API Framework, Le test doit être appliqué à tous les partenaires OEM, mais dans CTS.
- Si un test est destiné à détecter les régressions pendant le développement de la plate-forme, et peuvent nécessiter une autorisation privilégiée, et peuvent dépendre sur les détails de l'implémentation (telle que publiée dans AOSP), il doit s'agir d'une plate-forme test.
- Services Google Mobile (GMS)
Ensemble d'applications et d'API Google qui peuvent être préinstallées sur les appareils.
- GoogleTest (GTest)
Framework de tests et de simulation C++ Généralement, les binaires GTest accéder à des couches d'abstraction de niveau inférieur ou effectuer une IPC brute sur différents systèmes services. En général, la méthode de test de Google Testing est étroitement liée service en cours de test. CTS contient le framework GTest.
- test d'instrumentation
Un environnement d'exécution de test spécial lancé par la commande
am instrument
, où le processus d'application ciblé est redémarré et initialisé avec le contexte de base de l'application, ainsi qu'une le thread d'instrumentation est démarré dans l'environnement virtuel du processus d'application machine. CTS contient des tests d'instrumentation.- Logcat
Un outil de ligne de commande qui crée un journal des messages système, y compris les traces de pile indiquant quand l'appareil génère une erreur et les messages que vous avez écrites depuis votre application avec la classe
Log
.- journalisation
L'utilisation d'un journal pour garder une trace des événements du système informatique, tels que en tant qu'erreurs. La journalisation dans Android est complexe, car les normes utilisées sont combinés dans l'outil Logcat.
- test postsubmit
Un test Android effectué lorsqu'un nouveau correctif est appliqué à une branche de noyau commune. En saisissant
aosp_kernel
comme nom de branche partiel, vous peut voir la liste des branches du noyau avec les résultats disponibles. Par exemple, les résultats deandroid-mainline
sont disponibles à l'adresse https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid- test avant envoi
Test utilisé pour empêcher l'introduction de défaillances dans le noyaux courants.
- Fédération commerciale
Également appelé Tradefed, un test continu conçu pour exécuter des tests sur des appareils Android. Par exemple : Tradefed est utilisé pour exécuter les tests de la suite de tests de compatibilité et de la suite de test fournisseur.
- Suite de test pour les fournisseurs (VTS)
Un ensemble de fonctionnalités complètes pour les tests Android, la promotion d'un processus de développement basé sur les tests et l'automatisation la couche d'abstraction matérielle (HAL) et les tests du noyau de l'OS.
Types de tests de plate-forme
Un test de plate-forme interagit généralement avec un ou plusieurs systèmes Android ou couches HAL, applique fonctionnalités du sujet testé, et affirme l'exactitude le résultat du test. Un test de plate-forme peut:
- (Type 1) API du framework d'exercice à l'aide du framework Android Des API spécifiques
peut inclure:
- API publiques destinées aux applications tierces
- Les API cachées destinées aux applications privilégiées, à savoir les API système ou
API privées (
@hide
,protected
,package private
)
- (Type 2) Appeler des services système Android à l'aide d'une liaison brute ou de proxys IPC directement.
- (Type 3) Interagissez 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 généralement des tests G.
Et maintenant ?
Voici une liste de documents que vous pouvez consulter pour obtenir des informations plus détaillées:
Si vous n'avez pas étudié l'architecture Android, consultez Présentation de l'architecture
Si vous créez un appareil compatible avec Android, consultez la présentation du programme de compatibilité Android.
Intégrer des tests hôtes d'instrumentation, des tests fonctionnels, des métriques et des tests JAR sur les hôtes dans un service de test continu de plate-forme, consultez Workflow de développement de tests
Pour détecter les failles et les protéger, consultez la section Tests de sécurité.
Pour en savoir plus sur les tests des implémentations HAL et de noyau, consultez Suite de test pour les fournisseurs (VTS) et infrastructure.
Pour les tests d'applications, consultez Principes de base des tests d'Android applications et mener le cours Advanced Android in Kotlin 05.1:Testing Principes de base à l'aide du exemples fournis.
Découvrez les tests de base avant envoi disponibles via les hooks de dépôt. Ces hooks peuvent être utilisés pour exécuter des lints, vérifier la mise en forme et déclencher une unité avant de continuer, comme l'importation d'un commit. Ces hooks sont désactivés par défaut. Pour en savoir plus, consultez AOSP Preupload Accroches.
Pour en savoir plus sur la journalisation, consultez Comprendre la journalisation.
Pour comprendre comment déboguer du code Android, consultez Déboguer le code natif de la plate-forme Android