Durchführung von Emulator-Tests auf GitLab CI

GitLab CI (Continuous Integration) wurde ein grundlegender Teil der Abläufe der F-Droid-Community. Es ist freie Software, auf offenen Standards aufgebaut, und funktioniert gut. Der letzte Teil, der in unserer Testumgebung fehlt, ist eine zuverlässige Durchführung von Tests in wirklichen Android-Emulatoren. Dank Pushes von einer Reihe von Leuten prüft Google nun tatsächlich die Ausführung von Android-Emulatoren in Docker. Und jüngste Freigaben des emulator SDK-Pakets funktionieren tatsächlich ohne sofortigen Absturz! Das ist die vielversprechendste Neuigkeit hinsichtlich der Nutzung freier Software-Emulatoren zur Testung in Android seit langem. Leider läuft noch nicht alles glatt, und die Emulatoren in GitLab CI zum Laufen zu bringen, erfordert immer noch einige Tänze mit magischen Beschwörungsformeln. Unsere Anforderungen sind:

  • Funktioniert auf den von gitlab.com geteilten Standardkanälen.
  • Funktioniert ohne KVM oder irgendwelche Extraprivilegien.
  • Verwendet KVM wenn vorhanden.

Was wir jetzt haben, gibt uns das Fundament, auf dem wir unser Standard fdroidclient CI Setup aufbauen. Zuvor waren wir darauf limitiert, alte armeabi-v7a Emulatoren zu verwenden, die schier unvorstellbar langsam laufen. Dies waren die einzigen Emulator-System-Images, die in Docker ohne KVM-Unterstützung liefen. Selbst mit KVM-Support, erscheint der Emulator ziemlich unzuverlässig. Dies ist besser geworden aber noch immer nicht so, wie es sein sollte.

Die gute Nachricht ist, dass die Ausführung des Emulators in Docker nun stabil genug ist, dass die Leute tatsächlich Dinge damit erledigen können, wie die Ausführung von Emulatoren in GitHub Actions. Da viele Leute die Google-Emulatoren nutzen, sollte Google sich weiter um sie kümmern. Die F-Droid-Emulator-Einrichtung ist freie Software: ein auf Debian basierendes Image, das auf GNU/Linux-Maschinen läuft. Jedes Projekt, das GitLab CI verwendet, kann dieses Setup nutzen, um Emulatoren bei Merge Request usw. auszuführen.

Es ist wichtig eher die Standard als die google_apis System-Images zu verwenden, da sie keine Binär-Blobs aus Google Play und Apps enthalten und weil die Google Apps anscheinend den Boot-Vorgang stark verlangsamen. Auch scheint es so, dass die Systemabbilder von android-22 bis android-27 anscheinend weniger Ressourcen benötigen als die neueren, so viel sodass es bei ihnen unwahrscheinlich ist, dass sie in manchen Projekten überhaupt funktionieren.

Das microg system-image repository ist auch in das Setup von F-Droid eingeschlossen. Es gibt momentan zwei Images:

  • system-images;android-29;microg;x86_64
  • system-images;android-23;microg;x86 - benötigt Emulator v28 oder älter, weil ihm ein „ranchu“-Kernel fehlt.

Syntax

Die fdroiclient -Einrichtung nutzt YAML-Vorlagen (templates), um die Auswahl spezieller Emulator-Einrichtungen zu vereinfachen, insbesondere das test-template, das connected-template und das kvm-template.

Wir verwenden das microg-Image im fdroidclient so:

kvm 29 microg x86_64:
  <<: *kvm-template

no-accel 29 microg x86_64:
  <<: *test-template
  <<: *connected-template
  • Zur Unterstützung bei der Fehlersuche kann das Emulator-Kernel-Startprotokoll im Wurzelverzeichnis des Projekts in kernel.log und die komplette Logcat-Ausgabe in logcat.txt gefunden werden. Diese können in artifacts: eingeschlossen werden, um einfach darauf zuzugreifen.
  • Um die Jobs, die KVM verwenden, auszuführen, muss man zunächst einen GitLab-CI-Kanal haben, der KVM unterstützt und mit fdroid and kvm ausgezeichnet ist. Dann muss man die Variable RUN_KVM_JOBS in denCI/CD-Einstellungen auf true setzen.

Um die Weiterentwicklung der Verwendung von Emulator-Images in GitLab CI weiter voranzutreiben, gibt es eine Wiki-Seite, um Tipps und Tricks, Gotchas sowie neue Entwicklungen zu dokumentieren: