Ce document décrit les AVD pour Test Lab, y compris leurs avantages et leurs limites connues. Nous fournissons également des recommandations sur la façon de tester votre application tout au long du cycle de vie du développement. Test Lab Les AVD sont semblables aux AVD pour Android Studio, mais ils sont optimisés pour les performances avec les tests cloud. Il existe donc quelques différences entre les deux.
Test Lab Les AVD avec un suffixe .arm ou (Arm) sont des émulateurs avancés qui offrent les avantages suivants :
Exécution plus rapide des tests
Tailles et densités d'écran alignées sur les AVD d'Android Studio pour plus de cohérence
Graphismes accélérés compatibles avec les GPU
Le tableau suivant décrit les avantages des 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. Comme les appareils virtuels sont créés à la demande, vos tests démarrent 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. |
| Tests plus longs | Les appareils virtuels acceptent une durée de test de 60 minutes maximum. Les tests sur des appareils physiques sont limités à une durée de 45 minutes sur chaque appareil. | Exécuter des 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 l'enregistrement du 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 qu'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 pour Android avec Firebase Test Lab.
Afficher les modèles et les API compatibles
Pour afficher les modèles et les API d'AVD 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 augmentent vos 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 de son 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 associé pour examiner chaque build en vue d'une validation initiale. Si vous disposez de tests d'instrumentation, vous pouvez également les exécuter depuis Android Studio sur des appareils physiques ou virtuels fournis par Test Lab.
Utiliser des systèmes d'intégration continue à 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 d'intégration continue s'exécute ou avant chaque demande d'extraction. Pour en savoir plus sur l'utilisation de Test Lab avec des systèmes d'intégration continue, consultez Utiliser Test Lab pour Android avec des systèmes d'intégration continue.
Testez votre application sur des appareils physiques avec Test Lab avant de publier des mises à jour d'application importantes.
Avant de publier des mises à jour d'application apportant des modifications importantes à l'interface utilisateur et aux 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 permettent également de s'assurer que les tests couvrent toutes les fonctionnalités de l'application qui reposent sur des fonctionnalités d'appareils physiques non simulées par les appareils virtuels. Pour en savoir plus sur ces fonctionnalités, consultez Limites connues.
Mises à jour des appareils virtuels
L'équipe Android ajoute régulièrement de nouvelles images d'appareils virtuels, abandonne les anciennes et met à jour les images existantes. Nous appliquons ces mises à jour à nos images d'appareils virtuels pour vous assurer de tester des versions d'Android à jour qui reflètent l'expérience de vos utilisateurs.
Dans de rares cas, ces mises à jour peuvent entraîner l'échec inattendu des tests. Lorsqu'une mise à jour potentiellement incompatible est connue, Test Lab inclut des informations dans les notes de version. Nous vous recommandons d'utiliser des frameworks de test (par exemple, Espresso) qui sont robustes face à ces modifications, dans la mesure du possible. Lorsque ce n'est pas possible, nous vous recommandons de cibler les appareils virtuels Arm, que vous pouvez mettre à jour moins fréquemment.
Limitations connues
Certaines fonctionnalités des appareils physiques ne sont pas simulées par les appareils virtuels, ou sont simulées avec certaines limites. Le tableau suivant récapitule les fonctionnalités qui ne sont pas disponibles actuellement sur les appareils virtuels ou qui sont disponibles avec certaines limites :
| Fonctionnalité | Détail |
| 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 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 ressources graphiques peuvent présenter des performances inférieures. Si votre application utilise beaucoup de ressources graphiques, envisagez d'utiliser SmallPhone.arm, MediumPhone.arm ou des appareils physiques à la place. |
| 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 entièrement 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és de réalité augmentée (RA) | Le test de la fonctionnalité de réalité augmentée (RA) n'est pas possible sur les appareils virtuels. |
| Anciens niveaux d'API | Test Lab Les appareils virtuels Arm ne sont pas compatibles avec les niveaux d'API inférieurs à 26. |