Android Store Screenshot Kit

Über das Projekt

Store-Screenshots veralten mit jeder Änderung an der App, und sie von Hand auf einem Smartphone aufzunehmen ist langsam und nie zweimal gleich. Dieses Kit macht daraus einen wiederholbaren Schritt: Jede App behält einen kleinen Test, der ihre eigenen Daten vorbereitet und durch ihre Bildschirme führt, und das Kit erledigt den Rest.

Es baut die App und ihren Test, führt beide auf einem gewählten Firebase-Test-Lab-Gerät aus, verfolgt den Lauf bis zum Ende, lädt die Screenshots herunter und prüft sie gegen die Anforderungen von Google Play, bevor es sie in den Store-Ordner der App kopiert.

Wie es funktioniert

1. Den Lauf beschreiben. Eine kurze TOML-Datei nennt die App, ihren Test, die zu verwendenden Geräte sowie Anzahl und Größe der erwarteten Screenshots.
2. Den App-Teil schreiben. Beginnen Sie mit dem Vorlagentest, laden Sie feste Beispieldaten und legen Sie die aufzunehmenden Bildschirme fest. Gemeinsame Hilfsfunktionen warten auf Bildschirme, tippen, schließen Systemdialoge und sperren die Ausrichtung.
3. Ein Gerät ausführen. Ein einziger Befehl baut beide APKs, übergibt sie an Firebase Test Lab und verfolgt den Test bis zum Ende.
4. Sammeln und prüfen. Die Screenshots werden heruntergeladen, auf Anzahl, Größe und Farbformat geprüft und zusammen mit einem Protokoll des Laufs gespeichert.

Mit dem Kit erstellt

Das sind die Google-Play-Tablet-Screenshots von Pocket Omaha, aufgenommen vom Kit auf einem echten Pixel Tablet in Firebase Test Lab. Der Test lädt aufgezeichnete Daten zu Apple, JPMorgan und Nokia, sodass keine Marktdaten abgerufen wurden und jeder Lauf dieselben Zahlen zeigt.

Der erste Lauf brachte außerdem eine Android-Kompatibilitätswarnung zur Ausrichtung einer nativen Bibliothek der App zutage. Nach einem Update der Bibliothek lief ein zweiter Lauf ohne sie durch.

Funktionen

• Bei jedem Lauf dasselbe Ergebnis: Jede App lädt ihre eigenen aufgezeichneten Beispieldaten, statt Live-Dienste aufzurufen, sodass sich die Screenshots von Lauf zu Lauf nicht verändern.
• Vor der Verwendung geprüft: Jedes PNG wird auf die erwartete Anzahl, die Abmessungen und das RGB-Format ohne Transparenz geprüft, das Google Play verlangt.
• Ein Protokoll für jeden Lauf: Jeder Lauf erhält einen eigenen Ordner mit den unveränderten PNGs und einer run.json-Datei mit Datei-Hashes, dem Gerät, dem Link zur Firebase Console und der genauen Konfiguration.
• Bereit für 16-KB-Geräte: Eine eigene Prüfung kontrolliert die Ausrichtung des APK und jeder darin enthaltenen nativen Bibliothek, für Android-Geräte mit 16-KB-Speicherseiten.
• Keine bösen Überraschungen bei der Rechnung: Ein Gerät muss immer ausdrücklich angegeben werden, sodass sich ein Lauf nie auf alle konfigurierten, möglicherweise kostenpflichtigen physischen Geräte ausweitet.
• Geheimnisse bleiben draußen: Projekt-IDs kommen aus Umgebungsvariablen und die Anmeldung aus der Google Cloud CLI; in der Konfiguration stehen keine Zugangsdaten.
• Leicht einzubinden: Die Hilfsfunktionen hängen nur von AndroidX Test und UI Automator ab und passen daher zu Apps mit und ohne Jetpack Compose.

Unter der Haube

Das Kommandozeilenwerkzeug ist ein einzelnes Python-Skript, das nichts außer Python 3.11 braucht. Die gemeinsamen Hilfsfunktionen sind eine kleine, in Java geschriebene Android-Bibliothek; sie schreiben den Apps, die sie nutzen, keine Kotlin-Version vor und funktionieren mit AGP 8 und AGP 9. In der CI können virtuelle Geräte bei jedem Pull Request laufen, während physische Geräte für Release Candidates bleiben. Das Kit ist Open Source unter der Lizenz GPL-3.0.