Test de la plateforme Android

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 pour android-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 :