Ce document décrit les AVD pour Test Lab, y compris les avantages et les limites connues. Nous vous fournissons également des recommandations sur la façon de tester votre application tout au long du cycle de développement. Les AVD Test Lab sont similaires aux AVD pour Android Studio, mais sont optimisées pour les performances avec les tests dans le cloud. Il existe donc quelques différences entre les deux.
Les AVD Test Lab avec un suffixe .arm ou (Arm) sont des émulateurs avancés qui offrent les avantages suivants :
Temps d'exécution des tests plus rapide
Tailles et densités d'écran alignées sur les AVD d'Android Studio pour plus de cohérence
Graphiques accélérés compatibles avec le GPU
Le tableau suivant décrit les avantages de l'utilisation d'appareils virtuels :
| Avantage | Description | Cas d'utilisation |
| Haute disponibilité | Vous pouvez exécuter des tests et obtenir des résultats plus rapidement lorsque vous effectuez des tests avec des appareils virtuels. Étant donné que les appareils virtuels sont créés à la demande, vos tests commencent presque immédiatement, ce qui permet de valider rapidement votre application. | Tester de petites mises à jour de votre application ou effectuer des tests de régression |
| Durée des tests plus longue | Les appareils virtuels acceptent une durée de test maximale de 60 minutes. Les tests sur des appareils physiques sont limités à une durée de 45 minutes sur chaque appareil. | Exécution de tests plus longs |
| Réduction des coûts | Les appareils virtuels sont facturés à 1 $ par heure pour chaque appareil virtuel utilisé pour tester votre application. | Tests quotidiens à l'aide de systèmes d'intégration continue ou avant de vérifier le code. Pour en savoir plus, consultez Niveaux d'utilisation, quotas et tarifs pour Test Lab. |
Tester votre application avec des appareils virtuels
Vous pouvez tester votre application avec des appareils virtuels de la même manière que vous le faites avec des appareils physiques. Vous pouvez sélectionner des appareils virtuels pour vos tests lorsque vous configurez une matrice de test. Pour en savoir plus sur l'exécution de tests avec Test Lab, consultez Premiers pas avec les tests Android avec Firebase Test Lab.
Afficher les modèles et les API compatibles
Pour afficher les modèles AVD et les API compatibles avec Test Lab, exécutez la commande suivante :
gcloud firebase test android models list --filter=virtual
Bonnes pratiques pour tester votre application
Les appareils virtuels élargissent votre gamme d'options lorsque vous testez votre application avec Test Lab. Nous vous recommandons de suivre les bonnes pratiques suivantes pour tester votre application tout au long du cycle de développement:
Utiliser l'émulateur Android Studio ou un appareil physique connecté
Lorsque vous développez votre application, utilisez l'émulateur Android Studio ou un appareil physique connecté pour examiner chaque build afin de le valider initialement. Si vous avez des tests d'instrumentation, vous pouvez également les exécuter à partir d'Android Studio sur des appareils physiques ou virtuels fournis par Test Lab.
Utiliser des systèmes CI pour chaque modification de code lorsque vous travaillez sur des projets partagés
Si vous travaillez sur un projet de grande envergure ou si vous contribuez à des projets partagés à l'aide de GitHub ou d'un site similaire, nous vous recommandons d'utiliser des systèmes d'intégration continue (CI). Testez vos applications sur des appareils virtuels chaque fois que le système de CI s'exécute ou avant chaque requête pull. Pour en savoir plus sur l'utilisation de Test Lab avec des systèmes CI, consultez Utiliser Test Lab pour Android avec des systèmes d'intégration continue.
Tester votre application sur des appareils physiques avec Test Lab avant de publier des mises à jour importantes
Avant de publier des mises à jour d'application avec des modifications importantes de l'interface utilisateur et des fonctionnalités, nous vous recommandons d'utiliser Test Lab pour tester votre application sur des appareils physiques. Cela vous aidera à vous assurer que votre application est stable et performante sur un large éventail d'appareils physiques populaires. Les tests sur des appareils physiques garantissent également la couverture des tests pour toute fonctionnalité d'application qui repose sur des fonctionnalités d'appareils physiques qui ne sont pas simulées par des appareils virtuels. Pour en savoir plus sur ces fonctionnalités, consultez la section Limites connues.
Mises à jour des appareils virtuels
Régulièrement, l'équipe Android ajoute de nouvelles images d'appareils virtuels, abandonne les anciennes et met à jour les existantes. Nous appliquons ces mises à jour à nos images d'appareils virtuels pour vous assurer que vous effectuez des tests sur des versions Android à jour qui reflètent l'expérience de vos utilisateurs.
Dans de rares cas, ces mises à jour peuvent entraîner un échec inattendu des tests. En cas de mise à jour connue et potentiellement destructive, Test Lab inclura des informations dans les notes de version. Dans la mesure du possible, nous vous recommandons d'utiliser des frameworks de test (par exemple, Espresso) qui résistent à ces modifications. Si ce n'est pas possible, nous vous recommandons de cibler des appareils virtuels Arm, que vous pouvez mettre à jour moins fréquemment.
Limitations connues
Certaines fonctionnalités d'appareils physiques ne sont pas actuellement simulées par les appareils virtuels ou sont simulées avec certaines limites. Le tableau suivant récapitule les fonctionnalités actuellement indisponibles sur les appareils virtuels ou disponibles avec certaines restrictions:
| Fonctionnalité | Détails |
| Interfaces binaires d'application (ABI) | Tous les appareils ne sont pas compatibles avec toutes les ABI. Si vous développez avec le NDK Android, veillez à générer du code pour les ABI compatibles avec les appareils que vous ciblez (voir Appareils disponibles dans Test Lab). Pour en savoir plus sur la gestion des ABI, consultez la section ABI Android.
Remarque:Si un test de votre matrice de test est marqué comme non valide, cela peut être dû au fait que votre application dépend d'un code natif non compatible avec l'ABI de l'appareil. |
| Performances graphiques | Les appareils virtuels Nexus et Pixel utilisent le rendu graphique logiciel. Les applications gourmandes en graphiques peuvent enregistrer des performances moins élevées. Si votre application utilise une grande quantité de ressources graphiques, envisagez plutôt d'utiliser SmallPhone.arm, MediumPhone.arm ou des appareils physiques. |
| API graphiques | OpenGL ES 3.x n'est pas compatible avec les appareils dont le niveau d'API est inférieur à 29. Les appareils plus récents ne sont pas 100% compatibles avec les API OpenGL/Vulkan. Vous remarquerez peut-être de légères différences au niveau des graphismes. |
| Application Google Play Store | L'application Google Play Store n'est pas compatible avec les appareils virtuels Arm. |
| Fonctionnalité de réalité augmentée (RA) | Le test de la fonctionnalité de réalité augmentée (RA) n'est pas compatible avec les appareils virtuels. |
| Niveaux d'API plus anciens | Test Lab Les appareils virtuels ARM ne sont pas compatibles avec les niveaux d'API inférieurs à 26. |