@Olivier's

Faire tourner Docker Android sur un VPS ?

J’ai la chance d’avoir accès à un VPS hosté par BeYs Cloud (merci 💚 à eux) que j’utilise pour héberger un tas de petits conteneurs de tests. Très content du service, j’ai voulu cette fois voir s’il me serait possible d’émuler un smartphone Android via Docker et de le piloter depuis mon mac. Spoiler : c’est possible. Spoiler 2 : c’est vraaaiment pas fait pour ça.

Dans le suite de cet article, nous allons voir comment procéder, les contraintes et astuces nécessaires.

Tout d’abord, se pose la question de faire tourner un emulateur Android sous Docker. Nos téléphones tournent principalement sur des processeurs ARM, mais l’émulateur Android a la bonne idée d’avoir une version x86 qui permet d’exécuter l’Android Runtime, tout en contenant un jeu d’émulation interne pour permettre l’exécution de code ARM pour les apps. Donc au niveau architecture CPU, ça doit passer.

L’émulateur en lui-même nécessite l’accès aux instructions de virtualisation du processeur, via KVM idéalement. C’est important pour ne pas avoir a émuler le processeur x86 lui-même, donc à devoir réinterpréter chacune des instructions. Et là ça coince souvent sur des VPS, non pas parce que ce n’est pas possible, mais souvent parce que ces instructions ne sont pas exposées par le Cloud Provider dans la VM fournie. C’est le cas ici. Donc là encore, rien n’est perdu, mais il va falloir émuler le x86, donc s’attendre a des performances exécrables, en utilisant l’option -no-accel de l’émulateur.

Parlons également de RAM. La préconisation c’est d’avoir un moins 8Go de RAM disponible pour faire tourner l’émulateur normalement. Ma machine ne disposant que de 6Go de RAM, et ne faisant pas que ça, il va falloir croiser les doigts. Dans mon cas, je suis parti sur 2Go de RAM alloué au max, ce qui permet de lancer l’émulateur.

Halim Qarroum maintient le projet open-source docker-android dont l’objectif est justement de faire tourner l’émulateur dans un conteneur Docker. Pas mal d’images buildées ici, pour mes tests je me tourne vers le build api-32 de base, sans les outils Google, mais avec l’émulateur intégré évidemment. L’api-33 est disponible, mais demande trop de RAM à priori. On peut tuner la mémoire du conteneur au lancement, mais cette image ne prévoit pas le fait de passer d’autres paramètres. N’ayant pas très envie de rebuilder l’image, on va hacker la ligne de commande pour faire passer le -no-accel. En regardant le script de l’image au démarrage, je trouve cette solution, pas classe, mais suffisant pour faire un test :

1docker run -it --rm -e MEMORY="2048 -no-accel" -p 5555:5555 halimqarroum/docker-android:api-32

Ok, ça semble démarrer. And so what ? Maintenant, il faut accéder à notre émulateur sur le port 5555. Et on ne va pas le faire depuis le VPS, puisqu’il n’a pas d’interface graphique, on ne va pas non plus exposer le port 5555 au monde entier - même si j’envoie tout mon respect à la personne qui parviendra a faire quelque chose de concret avec l’émulateur dans cet état 😉

Donc pour accéder au port 5555 de la machine depuis mon mac, on va faire une redirection de port local via SSH. Pour faire ça c’est assez simple :

1ssh user@host -L5555:localhost:5555

SSH tourne en tâche de fond, le port 5555 est accessible, donc maintenant tout le reste des commandes se passe en local sur mon mac. On a tout d’abord installé adb et scrcpy.

1brew install android-platform-tools scrcpy

Une fois que c’est fait, il suffit de se connecter via adb à notre emulateur remote via notre redirection de ports, puis de lancer le screen copy dans une résolution pas trop haute pour optimiser les performances :

1adb connect 127.0.0.1:5555
2scrcpy --tcpip=127.0.0.1:5555 -m1024

Si tout se passe bien, pendant quelques (très longues) minutes vous aurez droit au boot de la machine. De mon côté, j’ai probablement 1 image toutes les 3 secondes, donc en termes de réactivité… on s’est compris.

Ecran de chargement de l’émulateur Android

La bonne nouvelle, c’est qu’au bout d’un moment… aléatoire, vous avez votre emulateur fonctionnel, “utilisable” si vous êtes patient. Ça peut être pratique pour exécuter des scripts, mais certainement pas pour une utilisation réelle, sans accelération matériel. Et même là, c’est beaucoup trop énergivore pour pouvoir être conseillé. Reste qu’avec accès aux instructions de virtualisation du processeur, c’est un outil puissant !