Tests de la plate-forme Android

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 la Compatibility Test Suite (CTS). Les appareils compatibles avec Android peuvent participer à l'écosystème Android, qui inclut la possibilité d'obtenir une licence pour Google Play, pour la suite d'applications et d'API Google Mobile Services (GMS), et pour 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 de résoudre les problèmes localement.
Document sur les conditions de compatibilité
Document qui énumère les exigences logicielles et matérielles pour un appareil compatible avec Android.
La suite de tests de compatibilité

Suite de tests sans frais et de qualité commerciale, disponible en téléchargement sous forme de binaire ou de 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 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 qu'il doit être appliqué à tous les partenaires OEM, il doit figurer dans le CTS.
  • Si un test est destiné à détecter les régressions lors du développement de la plate-forme, 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 les appareils.

GoogleTest (GTest)

Framework de test et de simulation C++. Les binaires GTest accèdent généralement à des couches d'abstraction de niveau inférieur ou effectuent des IPC bruts sur différents services système. L'approche de test pour GTest est généralement étroitement liée au service testé. Le 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 de l'application cible est redémarré et initialisé avec le contexte de l'application de base, et un thread d'instrumentation est démarré à l'intérieur de la machine virtuelle du processus de l'application. Le 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 enregistrées lorsque l'appareil génère une erreur et les messages que vous avez écrits à partir de 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 du mélange de normes utilisées et combinées dans l'outil Logcat.

postsubmit test

Test Android effectué lorsqu'un nouveau correctif est validé dans une branche de noyau commune. En saisissant aosp_kernel comme nom de branche partiel, vous pouvez afficher la liste des branches du noyau pour lesquelles des résultats sont disponibles. Par exemple, les résultats pour android-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 est utilisé pour exécuter les tests Compatibility Test Suite et Vendor Test Suite.

Vendor Test Suite (VTS)

Un ensemble de fonctionnalités étendues pour les tests Android, favorisant un processus de développement piloté par les tests et automatisant les tests de la couche d'abstraction matérielle (HAL) et du noyau OS.

Types de tests de plate-forme

Un test de plate-forme interagit généralement avec un ou plusieurs services système Android ou couches HAL, exerce les fonctionnalités du sujet testé et affirme l'exactitude du résultat du test. Un test de plate-forme peut :

  • (Type 1) Utilisez les API du framework d'exercice avec le framework Android. Les API spécifiques utilisées peuvent inclure :
    • 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 ou package private)
  • (Type 2) Appelez directement les services système Android à l'aide de proxies binder ou IPC bruts.
  • (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 sont généralement des GTests.

Étapes suivantes

Voici une liste de documents que vous pouvez consulter pour obtenir des informations plus détaillées :