Android Store Screenshot Kit

À propos du projet

Les captures du store se périment à chaque changement de l'application, et les faire à la main sur un téléphone est lent et jamais tout à fait identique. Ce kit en fait une étape reproductible : chaque application garde un petit test qui prépare ses propres données et parcourt ses écrans, et le kit s'occupe du reste.

Il compile l'application et son test, les exécute sur l'appareil Firebase Test Lab choisi, suit l'exécution jusqu'au bout, télécharge les captures et les vérifie selon les exigences de Google Play avant de les copier dans le dossier store de l'application.

Comment ça marche

1. Décrire l'exécution. Un court fichier TOML indique l'application, son test, les appareils à utiliser ainsi que le nombre et la taille des captures attendues.
2. Écrire la partie propre à l'application. Partez du test modèle, chargez des données d'exemple fixes et listez les écrans à capturer. Des fonctions communes attendent les écrans, touchent, ferment les boîtes de dialogue système et verrouillent l'orientation.
3. Lancer un appareil. Une seule commande compile les deux APK, les soumet à Firebase Test Lab et suit le test jusqu'à la fin.
4. Récupérer et vérifier. Les captures sont téléchargées, vérifiées en nombre, en taille et en format de couleur, puis enregistrées avec un compte rendu de l'exécution.

Réalisé avec le kit

Voici les captures tablette de Pocket Omaha pour Google Play, prises par le kit sur une vraie Pixel Tablet dans Firebase Test Lab. Le test charge des données enregistrées pour Apple, JPMorgan et Nokia : aucune donnée de marché n'a été récupérée et chaque exécution affiche les mêmes chiffres.

La première exécution a aussi fait apparaître un avertissement de compatibilité Android sur l'alignement de l'une des bibliothèques natives de l'application. Après la mise à jour de la bibliothèque, une deuxième exécution s'est déroulée sans lui.

Fonctionnalités

• Le même résultat à chaque exécution : Chaque application charge ses propres données d'exemple enregistrées au lieu d'appeler des services en ligne, si bien que les captures ne changent pas d'une exécution à l'autre.
• Vérifiées avant usage : Chaque PNG est contrôlé pour le nombre attendu, les dimensions et le format RVB sans transparence que demande Google Play.
• Un compte rendu pour chaque exécution : Chaque exécution a son propre dossier, avec les PNG intacts et un fichier run.json contenant les empreintes des fichiers, l'appareil, le lien vers la Firebase Console et la configuration exacte.
• Prêt pour les appareils à 16 Ko : Une vérification distincte contrôle l'alignement de l'APK et de chaque bibliothèque native qu'il contient, pour les appareils Android à pages mémoire de 16 Ko.
• Pas de facture surprise : Un appareil doit toujours être nommé, pour qu'une exécution ne s'étende jamais à tous les appareils physiques configurés, potentiellement payants.
• Les secrets restent dehors : Les identifiants de projet viennent de variables d'environnement et la connexion de la Google Cloud CLI ; la configuration ne contient aucun identifiant de connexion.
• Facile à adopter : Les fonctions communes ne dépendent que d'AndroidX Test et d'UI Automator ; elles conviennent donc aux applications avec ou sans Jetpack Compose.

Sous le capot

L'outil en ligne de commande est un seul script Python qui ne demande rien d'autre que Python 3.11. Les fonctions communes forment une petite bibliothèque Android écrite en Java : elles n'imposent aucune version de Kotlin aux applications qui les utilisent et fonctionnent avec AGP 8 comme avec AGP 9. En CI, des appareils virtuels peuvent tourner à chaque pull request, les appareils physiques étant réservés aux versions candidates. Le kit est open source sous licence GPL-3.0.