Exécuter des tests d'émulateur sur GitLab CI

GitLab CI (Intégration Continue) est devenue une partie essentielle des processus de la communauté F-Droid. C’est un logiciel libre, construit sur des normes ouvertes et ça fonctionne bien. La dernière piece manquante dans notre écosystème de testage est une méthode fiable pour exécuter des tests dans un vrai émulateur Android. Grâce à plusieurs personnes, Google teste maintenant l’exécution des émulateurs Android dans Docker. De plus, les publications récentes du paquet de SDK emulator fonctionne maintenant sans se planter immédiatement ! Ceci est la nouvelle la plus prometteuse à propos de l’utilisation d’émulateurs libres pour le testage sur Android depuis longtemps. Cependant, ce n’est pas complètement prêt et l’exécution des émulateurs dans GitLab CI exige encore un peu de danse avec des incantations magiques. Nos exigences sont :

  • Fonctionne sur les exécuteurs partagés défauts sur gitlab.com.
  • Fonctionne sans KVM ou d’autres privilèges supplémentaires.
  • Utilise KVM quand disponible.

Ce que nous avons maintenant nous donne une fondation sur lequel nous pouvons créer notre installation standard de CI fdroidclient. Avant, nous étions limités à utiliser les vieux émulateurs armeabi-v7a, qui fonctionnent presque inimaginablement lentement. C’étaient les seules images de système d’émulateur qui pouvaient exécuter dans Docker sans support KVM. Même avec support KVM, l’émulateur semblait très fragile. Ceci est devenu mieux, mais nous ne sommes pas rendu au but.

La bonne nouvelle est que l’exécution de l’émulateur dans Docker est maintenant assez stable que des gens sont en traîn de construire des choses autour, comme exécuter des émulateurs dans GitHub Actions. Puisque beaucoup de gens utilisent les émulateurs de Google, la compagnie devrait prendre soin d’eux. L’installation de l’émulateur F-Droid est un logiciel libre : C’est une image de base Debian sur des exécuteurs GNU/Linux. N’importe quel projet qui utilise GitLab CI peut utiliser ceci pour exécuter des émulateurs lors des requêtes de fusion, etc.

C’est important d’utiliser les system-images default plutôt que google_apis puisqu’ils ne contiennent pas les fichiers binaires de Google Play et car les applications Google semblent ralentir beaucoup le processus de démarrage. De plus, il semble que les images android-22 jusqu’à android-27 semblent utiliser moins de ressources que les nouvelles, tellement qu’ils ont très peu de chances de fonctionner pour certains projets.

Le dépôt de system-image microg est aussi inclus dans l’installation F-Droid. Il y a en ce moment deux images :

  • system-images;android-29;microg;x86_64
  • system-images;android-23;microg;x86 exige émulateur v28 ou antérieur car il manque un noyau “ranchu”.

Usage

L’installation fdroidclient utilise des gabarits YAML pour faciliter le choix de plusieurs installations d’émulateur spécifiques, plus précisément le test-template, le connected-template et le kvm-template.

Nous utilisons l’image microg dans fdroidclient comme ceci :

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

no-accel 29 microg x86_64:
  <<: *test-template
  <<: *connected-template
  • Pour aider le débogage, le journal de démarrage du noyau de l’émulateur peut être trouvé dans la racine du projet dans kernel.log et l’entièreté des données de sorties de logcat dans logcat.txt. Ceux-ci peuvent être inclus dans artifacts: pour un accès facile.
  • Pour exécuter les travaux qui utilisent KVM, vous devez en premier avoir un exécuteur GitLab CI qui supporte KVM et qui est marqué avec fdroid et kvm. Ensuite vous devez adjuster la variable RUN_KVM_JOBS à true dans les paramètre CI/CD.

Pour que le développement de l’utilisation d’images d’émulateur dans GitLab CI puisse continuer, il y a une page wiki pour documenter les trucs et astuces, pièges et nouveaux développements :