docker-android : des émulateurs Android accélérés par KVM en conteneur, avec MCP et agents LLM locaux
budtmo/docker-android réunit un émulateur Android, un bureau web noVNC, le partage des journaux et l’accès adb dans une seule image Docker. Il couvre Android 9 à 14 et sert à la compilation d’applications, aux tests Appium ou Espresso et aux déploiements cloud. Les versions récentes ajoutent une image serveur MCP en bêta et un agent IA en bêta, compatible avec des serveurs LLM locaux comme Ollama et vLLM. Son intérêt est de réduire un banc de test mobile fragile à une commande docker run. Son prix : un hôte Linux avec KVM est indispensable.
Présentation
budtmo/docker-android est un ensemble d’images Docker pour tout ce qui touche à Android. Le projet se présente comme un conteneur pour le développement et le test d’applications natives, web et hybrides. Un seul conteneur réunit un émulateur Android avec le profil d’appareil choisi, un service VNC consultable dans un navigateur, une interface web pour les journaux et un point d’accès adb. Une seule commande docker run suffit pour le démarrer.
La liste des images couvre Android 9 à 14, soit les niveaux d’API 28 à 34. Chaque version possède une étiquette pour la dernière version publiée et une autre pour une version précise. Deux images se distinguent. L’image genymotion se connecte à Genymotion Cloud. L’image mcp est la nouvelle orientation, la plus intéressante. Le README cite des profils comme la famille Samsung Galaxy S6 à S10, les Nexus 4, Nexus 5, Nexus One et Nexus S, ainsi que les tablettes Nexus 7 et Pixel C.
Architecture
On peut lire la conception en trois couches. La couche basse est KVM sur l’hôte. La couche intermédiaire est le SDK Android et le processus d’émulation dans le conteneur, qui charge l’image système du niveau d’API choisi et la configuration de l’appareil. La couche haute regroupe les points d’entrée : un bureau web noVNC, associé par défaut au port 6080, une page web de partage des journaux et un port de débogage que l’hôte atteint avec adb connect.
L’avantage tient à ce point d’entrée unique. Le développeur observe l’émulateur dans un navigateur. Un cadre de test comme Appium ou Espresso pilote l’appareil par adb ou par son port de service. La compilation du projet, les tests unitaires et les tests d’interface partagent la même image : personne ne réinstalle le SDK, les images système et les dépendances sur chaque machine.
Fonctionnement
Un émulateur Android est un virtualiseur de machine complète fondé sur QEMU. Pour obtenir une vitesse exploitable dans un conteneur, l’image système x86 doit utiliser les instructions de virtualisation matérielle du processeur via KVM. Un conteneur n’offre aucune virtualisation ; il partage seulement le noyau de l’hôte. Le projet demande donc de lancer le conteneur avec --device /dev/kvm, qui lui transmet le périphérique. Le démarrage rapide commence aussi par kvm-ok, pour vérifier que l’hôte prend en charge la virtualisation.
Cela explique pourquoi l’image ne tourne que sous Ubuntu. Le README indique que les utilisateurs de macOS et de Windows doivent d’abord passer par une machine virtuelle Ubuntu compatible avec la virtualisation. Pour WSL2 sous Windows 11, il fournit une recette précise : ajouter l’utilisateur au groupe kvm, changer le propriétaire et les droits de /dev/kvm dans la commande de démarrage de /etc/wsl.conf, puis activer nestedVirtualization dans .wslconfig.
Des variables d’environnement règlent le comportement à l’exécution. EMULATOR_DEVICE choisit le profil d’appareil et WEB_VNC=true active le bureau web. Par défaut, l’appareil émulé est détruit au redémarrage du conteneur. Si l’on monte un volume sur /home/androidusr, les applications et les réglages survivent. Ce principe, jetable par défaut et persistant sur demande, correspond à ce que l’intégration continue attend d’un environnement propre.
MCP et agent IA
La nouveauté la plus récente est le serveur MCP et l’agent IA. Le README classe les deux en bêta et ajoute un schéma. MCP est un protocole qui permet à un client IA d’appeler des outils externes de façon standard. Quand un émulateur Android est exposé comme serveur MCP, un assistant de codage peut demander de démarrer un appareil, lire l’écran, toucher, saisir du texte et lire le résultat, sans adaptateur propre à chaque assistant.
L’agent IA va plus loin. Selon le README, il prend en charge deux serveurs de modèles locaux, Ollama et vLLM. Le modèle local a un intérêt net : les captures d’écran et les données de l’application testée restent dans le réseau interne, et aucune facture d’API cloud ne s’ajoute à chaque appel. En contrepartie, il faut de la mémoire GPU et du débit d’inférence, et les petits modèles jugent moins bien les écrans complexes.
Coûts et compromis
Le README ne donne aucun chiffre de référence sur le temps de démarrage, la mémoire ou le débit de test ; il ne faut donc en citer aucun. Plusieurs compromis structurels sont certains. D’abord, l’accélération matérielle rend l’émulateur utilisable, mais chaque conteneur occupe une part importante de mémoire et de processeur, et le parallélisme dépend des ressources de l’hôte.
Ensuite, les images sont séparées par version d’Android : chacune est volumineuse et il faut planifier téléchargements et caches. Enfin, un émulateur n’est pas un vrai téléphone. Capteurs, systèmes modifiés par les constructeurs et comportements liés au matériel demandent des appareils réels ou cloud, d’où l’intégration avec Genymotion Cloud.
Impact pour les développeurs et les entreprises
Pour un développeur isolé, la valeur est un environnement jetable : la machine reste propre et les conflits de versions du SDK disparaissent. Pour une équipe, les étiquettes d’image figent la version, si bien que les exécutions locales, l’intégration continue et le cloud partagent le même environnement. Beaucoup de débats du type « chez moi ça marche » disparaissent. Le projet fournit aussi des documents d’usage pour Jenkins, le déploiement cloud sur Azure, AWS et GCP, la simulation de SMS et Appium.
La portée plus large concerne les chaînes d’outils d’IA. Jusqu’ici, faire vérifier un changement mobile par un assistant de codage supposait qu’une personne prépare un appareil. Avec un émulateur exposé en service MCP, l’assistant dispose d’un vrai environnement d’exécution et peut boucler le cycle : modifier le code, compiler, exécuter, observer, corriger.
Limites et perspectives
Quatre limites principales. D’abord, KVM est obligatoire : l’image ne tourne pas directement sur des hôtes cloud ordinaires sans virtualisation imbriquée, ni dans des conteneurs sur puce Apple. Ensuite, MCP et l’agent restent en bêta ; les interfaces peuvent changer et le caractère non déterministe des modèles les rend, pour l’instant, impropres à servir de seul critère de non-régression. Troisièmement, la liste d’appareils reflète des profils anciens et les écrans récents demandent une configuration manuelle. Enfin, un émulateur ne remplace pas totalement un vrai téléphone.
À l’avenir, on peut attendre davantage de versions d’Android et d’appareils, des définitions d’outils MCP plus stables, un meilleur appui aux modèles locaux multimodaux et des liens plus étroits avec les fermes d’appareils cloud. Pour une équipe qui évalue l’automatisation mobile, un plan réaliste consiste à l’employer d’abord pour les compilations et les tests d’interface courants, puis à essayer l’agent IA en isolation, en gardant les assertions déterministes dans des scripts classiques.