Uruchamianie testów emulatora na GitLab CI

GitLab CI (Continuous Integration) stał się istotną częścią procesów społeczności F-Droid. Jest to wolne oprogramowanie, zbudowane na otwartych standardach i działa dobrze. Ostatnim elementem, którego brakuje w naszym ekosystemie testowym, jest niezawodny sposób na uruchamianie testów w rzeczywistych emulatorach Androida. Dzięki naciskom wielu osób, Google teraz faktycznie testuje uruchamianie emulatorów Androida w Dockerze. A ostatnie wydania pakietu emulatorów SDK faktycznie działają bez natychmiastowej awarii! Jest to najbardziej obiecująca wiadomość dotycząca używania emulatorów wolnego oprogramowania do testowania Androida od dłuższego czasu. Niestety, nie jest to jeszcze płynne żeglowanie, a uzyskanie emulatorów do uruchomienia w GitLab CI nadal wymaga tańca z magicznymi zaklęciami. Nasze wymagania to:

  • Działa na domyślnych współdzielonych runnerach gitlab.com.
  • Działa bez KVM i dodatkowych uprawnień.
  • Używa KVM, jeśli jest dostępny.

To, co mamy teraz, daje nam podstawę do zbudowania naszego standardu konfiguracja CI fdroidclient. Wcześniej ograniczaliśmy się do używania starych emulatorów armeabi-v7a_, które działają niewyobrażalnie wolno. Były to jedyne obrazy systemu dla emulatora, które są uruchamiane w Dockerze bez obsługi KVM. Nawet z obsługą KVM emulator wydaje się być dość niestabilny. Jest już lepiej, ale wciąż nie jest to tym, czym powinno być.

Dobrą wiadomością jest to, że uruchamianie emulatora w Dockerze jest teraz na tyle stabilne, że ludzie faktycznie budują wokół niego rzeczy, takie jak uruchamianie emulatorów w GitHub Actions. Jak wiele osób korzysta z emulatorów Google, to powinno sprawić, że Google się nimi zajmie. Konfiguracja emulatora F-Droid jest wolnym oprogramowaniem: obraz bazowy Debiana działający na systemach GNU/Linux. Każdy projekt korzystający z GitLab CI może używać tej konfiguracji do uruchamiania emulatorów na żądanie scalenia itp.

Ważne jest, aby używać default, a nie google_apis obrazów systemowych, które nie zawierają Google Play i aplikacji binarnych plam, a ponieważ aplikacje Google wydają się znacznie spowalniać proces rozruchowy. Ponadto, wydaje się, że ` android-22 przez android-27` obrazy systemowe wydają się wymagać mniej zasobów niż te nowsze, tak bardzo, że są mało prawdopodobne, aby pracować w ogóle dla niektórych projektów.

Repozytorium microg system-image jest również dołączone do konfiguracji F-Droid. Obecnie są tam dwa obrazy:

  • system-images;android-29;microg;x86_64
  • system-images;android-23;microg;x86 - wymaga emulatora v28 lub starszego, ponieważ nie posiada jądra “ranchu”.

Zastosowanie

Konfiguracja fdroiclient używa szablonów YAML, aby ułatwić wybór określonych ustawień emulatora, w szczególności szablon-testu, podłączony- szablon oraz kvm-template.

Używamy obrazu microg w fdroidclient w ten sposób:

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

no-accel 29 microg x86_64:
  <<: *test-template
  <<: *connected-template
  • Aby ułatwić debugowanie, log startowy jądra emulatora można znaleźć w katalogu głównym projektu w kernel.log, a pełne dane wyjściowe logcat w logcat.txt. Mogą one być dołączone do artefaktów: dla łatwego dostępu.
  • Aby uruchomić zadania korzystające z KVM, najpierw musisz mieć runnera GitLab CI, który obsługuje KVM i jest oznaczony tagami fdroid i kvm. Następnie należy ustawić zmienną RUN_KVM_JOBS w ustawieniach CI/CD na true.

Aby utrzymać postęp w rozwoju używania obrazów emulatorów w GitLab CI, istnieje strona wiki, która dokumentuje wskazówki i sztuczki, problemy i nowe rozwiązania: