Allez directement au contenu principal

Guide pratique complet de l'émulateur Android Terminal

Maîtrisez le terminal de l'émulateur Android avec adb shell, commandes de console, mise en route de port et conseils de dépannage pour Windows, macOS et Linux en 2026.

Martin Donadieu

Martin Donadieu

Spécialiste du contenu

Guide pratique complet de l'émulateur Android Terminal

Votre émulateur est ouvert, l'application est bloquée sur un écran noir et les contrôles graphiques ne vous aident pas. Ou peut-être vous trouvez-vous face à un job CI qui n'a pas d'affichage du tout, et la seule chose qui reste est une invite de terminal et un appareil virtuel qui doit démarrer, accepter des commandes et se comporter de la même manière à chaque exécution. C'est là que le terminal de l'émulateur Android cesse d'être un avantage et devient le plan de contrôle dont vous avez besoin.

Le changement important est simple : le terminal n'est pas juste une façon différente de cliquer sur les mêmes boutons. Les outils d'émulation de Google vous donnent des couches séparées pour la mise en route, le travail de shell et le contrôle de console, et chaque couche résout une classe différente de problème. Si vous les traitez comme une seule chose, les scripts deviennent instables, les anciens drapeaux continuent à s'introduire dans votre flux de travail et le CI se brise de manière qui semble aléatoire mais n'est pas.

Tableau de Contenu

Pourquoi vous avez besoin du terminal de l'émulateur Android

Un GUI bloqué est le cas évident. L'émulateur est toujours ouvert, mais vous ne pouvez pas y faire confiance, vous ne pouvez pas cliquer dessus et ce flux de travail ne s'adapte pas à un serveur de build. Le terminal gère la partie que la fenêtre ne pouvait jamais faire, la répétabilité. Les documents de l'émulateur de Google décrivent la ligne de commande et la console comme des outils pour l'automatisation et le contrôl’à distance, avec une syntaxe de lancement comme emulator -avd avd_name ou emulator @avd_nameet la liste complète des options disponibles à travers emulator -help Référence de commande de l'émulateur Android.

Pourquoi les équipes standardisent-elles le contrôle terminal

La première fois que cela compte est généralement peu glamour. Un script de test nécessite un état de périphérique propre, un développeur a besoin du même AVD pour démarrer sous Linux et macOS, ou un exécuteur de CI doit lancer une cible de test sans que personne regarde une fenêtre. À ce stade, l'émulateur cesse de se comporter comme une application de bureau et commence à se comporter comme de l'infrastructure.

Règle pratique : si une tâche doit être répétée, enregistrée ou récupérée après une erreur, utilisez la voie terminal en premier.

Google place également l'émulateur aux côtés de adb dans l'ensemble de commandes de ligne officielles, ce qui compte car l'automatisation Android est un empilement d'interfaces, pas une seule interface qui prétend faire tout Outils Android adb et émulateur. Utilisez adb pour l'inspection de périphérique et l'accès à la console, puis utilisez la console de l'émulateur pour le contrôle de cycle de vie et les commandes spécifiques à l'émulateur. Mélanger ces rôles est comment les scripts deviennent fragiles.

Les autres idées reçues à abandonner sont que le terminal de l'émulateur est juste un wrapper autour de l'interface graphique. Ce n'est pas le cas. La console est authentifiée, liée aux ports localhost, et prend en charge des commandes comme avd start, avd stop, avd status, ping, et rotate Référence du terminal Android Emulateur. C'est pourquoi il se comporte comme un plan de contrôle de qualité de production, et non comme un environnement de débutant.

Pour les workflows hybrides et Capacitor , la même discipline compte avant d'installer ou de déboguer quoi que ce soit. Voir Configuration d'Android pour les applications Capacitor pour la partie de configuration qui se trouve généralement derrière la session de l'émulateur.

Lancement des émulateurs depuis la ligne de commande

La première commande qui compte est celle qui vous montre ce qui est déjà disponible. Exécutez emulator -list-avds, choisissez l'AVD que vous souhaitez, puis lancez-l’avec emulator -avd <name> ou emulator @<name>. If the path to the binary isn’t on your shell PATH, find it inside the Android SDK’s emulator directory on Windows, macOS, or Linux, then run it directly from there.

A un développeur tapant des commandes CLI sur un écran d'ordinateur portable tout en travaillant à un bureau en bois.

Les drapeaux de lancement qui comptent encore

Une démarrage propre est la différence entre une exécution saine et une session de débogage qui dévore votre matinée. Dans le travail quotidien, les drapeaux de terminal utiles sont ceux qui rendent le comportement de démarrage prévisible, surtout pour les hôtes sans écran et CI. -no-window est le chemin sans écran, -no-snapshot oblige une état propre, -no-audio et -no-boot-anim context -gpu swiftshader_indirect Page/area: Site web de marketing Capgo. Role: Étiquette de navigation courte ou élément UI. Vu dans: page trust.astro. Message clé `and` (Et).

That combination is the difference between “the emulator started” and “the emulator started in a way that a pipeline can trust.” The launch command becomes part of your test contract, not just a convenience wrapper. If you’re bringing up a device for a Capacitor or hybrid app workflow, the same launch discipline applies before any debugging or install step begins. A practical Android setup guide for Capacitor developers is est un fallback pratique lorsque l'accélération matérielle n'est pas disponible..

Cette combinaison est la différence entre « l'emulateur a démarré » et « l'emulateur a démarré d'une manière que la chaîne de production peut faire confiance ». La commande de lancement devient partie de votre contrat de test, et non juste un wrapper de commodité. Si vous montez un appareil pour un flux de travail d'application __CAPGO_KEEP_0__ ou hybride, la même discipline de lancement s'applique avant que n'importe quelle étape de débogage ou d'installation ne commence. Une guide pratique de configuration d'Android pour les développeurs __CAPGO_KEEP_1__ est

vaut la peine de le garder à côté de vos commandes d'emulateur.

Comportement utile : gardez une commande de lancement propre pour le travail local et une commande plus stricte pour la CI. N'obligez pas le pipeline à hériter de chaque drapeau de commodité de votre ordinateur portable.

Cette séparation maintient le débogage local amical sans rendre l'automatisation négligente. Une fois la mise en route stable, le reste du flux de travail terminal a enfin quelque chose de fiable à quoi s'attacher.

Contrôler l'émulateur avec adb Shell

Une fois l'émulateur en cours d'exécution : adb devient la surface de commande que vous utilisez le plus souvent. adb devices montre ce qui est attaché, et adb -s emulator-5554 shell vous permet de cibler une instance spécifique sur un port spécifique. Cela compte sur une machine avec plusieurs appareils virtuels, car les commandes génériques peuvent facilement cibler la mauvaise cible. Le numéro de série maintient votre automatisation pointée sur l'émulateur que vous aviez l'intention d'utiliser.

Infographie à trois étapes montrant le flux de commande de l'interface de commande adb pour la gestion et le développement de l'émulateur Android.

Se connecter, puis déterminer si vous avez besoin d'une interface de commande

La distinction entre des commandes uniques et une interface de commande interactive compte plus qu'elle ne le suggère au premier abord. Si vous n'avez besoin que d'inspecter une configuration ou de collecter un fichier, une commande unique est suffisante. adb shell La commande est plus propre. Si vous suivez l'activité de l'application étape par étape, connectez-vous à une invite interactive et restez-y jusqu'à ce que le travail soit terminé.

adb push et adb pull gérez le mouvement des fichiers, adb install -r est le chemin pratique pour des tests locaux répétitifs, et adb exec-out screencap vous donne une capture d'écran fiable. La prise de vue d'écran par adb shell screenrecord est tout aussi directe lorsque vous avez besoin d'un artefact rapide d'une exécution en échec. Pour les flux de travail d'installation de packages et de chargement côté local, cette guide d'installation est un compagnon utile.

Utilisez adb pour le travail d'application, pas le travail de cycle de vie de l'emulateur

adb est le bon niveau pour les commandes qui s'exécutent à l'intérieur d'Android lui-même. Si vous avez un script stocké dans le stockage partagé, adb shell sh /sdcard/run.sh correspond bien aux empilements d'automatisation réels. Il s'agit également du niveau où run-as <package> devient utile pour les builds de débogage, car il vous donne des fichiers privés de l'application sans forcer la root.

La limite est claire. adb ne remplace pas la console de l'émulateur, et ce n'est pas l'outil approprié pour un contrôle plus approfondi du cycle de vie de l'émulateur ou des actions console uniquement. Utilisez-le pour le transfert de fichiers, la gestion de packages, l'exécution de commandes et la reconnaissance rapide, puis arrêtez là.

Règle pratique : si l'action appartient à Android, commencez par adb shellSi l'action appartient à l'émulateur lui-même, utilisez la console.

Pour les équipes travaillant sur les couches de plugins, le comportement spécifique à la plateforme et les questions relatives à l'état du dispositif, un kit de débogage plus large aide à garder les travaux de terminal de l'émulateur loin de la spéculation. Cette ressource de débogage s'adapte bien aux côtés du workflow adb.


Utiliser la console de l'émulateur au-delà de adb

La console de l'émulateur est un plan de contrôle distinct, et cette distinction compte. Google la documente comme étant en écoute uniquement sur les ports localhost 5554 à 5585avec une authentification requise avant que les commandes soient acceptées, et avec des commandes comme avd start, avd stop, avd status, pinget rotate disponible dès que vous êtes connecté. Cela en fait l'outil approprié pour les actions au niveau de l'émulateur qui adb ne peuvent pas exprimer clairement.

Un graphique intitulé Éléments essentiels de la console de l'émulateur montrant quatre étapes numérotées pour contrôler un émulateur Android via terminal.

Authentifier avant d'envoyer quoi que ce soit d'utile

La voie documentée par Google consiste à se connecter avec telnet localhost console-port, attendre OK, puis émettre auth auth_token en utilisant le jeton stocké dans ~/.emulator_console_auth_tokenSi ce fichier de jeton n'existe pas, la connexion telnet le crée avec un jeton aléatoire. Dans les environnements CI éphémères, cela signifie que vous devez soit conserver intentionnellement le fichier, soit le réinitialiser délibérément, car les échecs d'authentification inattendus sont presque toujours des erreurs de gestion d'état.

La console est également découverte. help, help command, et help-verbose ont une raison d'être, et ils économisent du temps lorsque vous vérifiez les commandes que l'émulateur accepte. C'est une meilleure habitude que de deviner et d'espérer adb peut le couvrir plus tard.

Savoir ce qui appartient à la console

Les commandes de la console sont pour le cycle de vie et l'état du côté de l'émulateur. avd start et avd stop contexte : Page/zone : Site de marketing Capgo. Rôle : Étiquette de navigation ou élément UI court. Vu dans : page trust.astro. Clé de message `et` (Et). rotate sont des exemples évidents, mais ping et

contexte : Page/zone : Site de marketing Capgo. Rôle : Étiquette de navigation ou élément UI court. Vu dans : page trust.astro. Clé de message `et` (Et). adb shellsont tout aussi utiles lorsque vous vérifiez la responsivité ou que vous simulez des changements de dispositif. L'émulateur fonctionne comme une infrastructure dans ce contexte, car vous pouvez scripter la disponibilité et la fermeture dans le même endroit où vous scriptez le démarrage. La faute commune est de mélanger la console de l'émulateur avec la shell Android. Ils ressemblent à des écrans similaires à distance, mais les protocoles sont différents. La console est authentifiée et liée au port, tandis que l'accès à la shell est généralement géré à travers , donc les scripts nécessitent des temps d'attente différents et des traitements de faillite différents. Pour la fiabilité du terminal dans les workflows spécifiques au plateau

cette ressource de débogage s'associe bien aux vérifications de disponibilité de la console. ne pas lancer les tests lors du lancement du processus seul. Lancer-les uniquement après que la console ait établi un échange de données et que le dispositif virtuel ait signalé l'état que vous attendez.

Cette décision élimine un grand nombre de « échecs de démarrage mais pas prêt » avant qu'ils ne frappent votre ensemble de tests.

Applications de Terminal et Accès Root à l'intérieur de l'Émulateur

Parfois, le travail appartient à l'intérieur du VM, et non sur le hôte. Dans ce cas, installer une application de terminal réelle à l'intérieur de l'émulateur est la plus simple des solutions, et Termux est la choix standard. Cela vous donne un environnement de shell sur appareil qui est beaucoup plus proche d'un workflow Unix réel que de taper autour dans les écrans de paramètres.

Root lorsque l'image le permet

Accès root est dépendant de l'image, et non magique. Sur les images système qui le permettent, adb root et adb shell su puisqu'il peut vous emmener où vous avez besoin d'aller, mais les images Google Play par défaut ne sont généralement pas le lieu où vous pouvez attendre un accès root confortable. Les AVDs personnalisés sont généralement plus flexibles lorsque vous avez besoin d'un accès plus profond.

BusyBox est toujours utile à ce niveau car il remplit les lacunes dans l'ensemble de commandes que vous auriez sinon manqué. Si vous effectuez une inspection de fichiers, une scripting sur appareil ou des diagnostics rapides à l'intérieur de l'émulateur, un toolkit Unix plus complet rend la machine beaucoup moins contrainte. Les vérifications d'accès root liées aux projets Capacitor sont discutées dans ce guide du plugin.

Utilisez l'accès privé de l'application avant de monter d'échelon

Non tous les problèmes nécessitent un accès root. Pour les builds de débogage, adb shell run-as <package> est souvent suffisant pour inspecter les répertoires privés de l'application sans élargir le rayon d'action. C'est une habitude plus propre car elle maintient votre flux de travail aligné avec l'outil le moins puissant qui peut encore faire le travail.

Si vous avez besoin d'écritures système, la partition système doit être écrivable, et c'est une classe de configuration différente. adb shell reste le point de départ le mieux adapté pour les travaux de l'émulateur quotidien, et les terminaux sur appareil sont traités comme une couche spécialisée pour les cas où l'accès hôte n'est pas suffisant.

La règle de doigt est simple : utilisez l'autorité la plus petite qui peut toujours reproduire le bug.

Réseau, redirection de port et raccourcis clavier adb reverse tcp:8080 tcp:8080 Un flux de travail terminalisé de l'émulateur devient réel dès que le trafic doit traverser la limite hôte. adb forward est la manière la plus propre de pointer un émulateur vers un serveur de développement local exécuté sur votre machine, surtout lorsque l'application s'attend à appeler les services hôte.

gestionne le cas inverse, où le trafic du dispositif doit atteindre un écouteur sur l'hôte.

Choisissez la bonne direction avant de déboguer le mauvais niveau adb reverse Un grand nombre de temps perdu provient de l'appel de chaque problème de réseau « un problème d'émulateur ». Dans la pratique, la direction du port est souvent incorrecte. adb forward permet à l'émulateur de rejoindre un service hôte, tandis que

envoie le trafic du dispositif vers un port hôte, de sorte que le chemin de la connexion décide de l'application de la commande appropriée. adb shell ip route et inspecter les interfaces avec ifconfig. Lorsque la routage semble normal mais que le service refuse toujours les connexions, la faute se situe généralement sur l'écouteur hôte ou dans la configuration de redirection, et non dans Android lui-même. ce guide sur la latence de réseau est un complément utile de lecture.

Le contrôle de la touche clavier fait partie de l'histoire du terminal

La carte de clavier de Google transforme l'emulateur en un cible de bureau beaucoup plus performante. F2 ouvre le menu ESC agit comme Retour F7 gère le redémarrage, et Alt-Entrée active le plein écran. La même carte de correspondance couvre également les contrôles de la caméra, du volume et de l'orientation, donc beaucoup de comportement de l'appareil reste sur le clavier au lieu d'être enterré dans la barre d'outils.

Cela compte sur les ordinateurs portables et les écrans grands.

Une fois que la surface de contrôle vit sur le clavier, l'emulateur commence à se comporter comme un outil que vous pouvez travailler toute la journée, et non comme une fenêtre que vous faites glisser avec la souris. Drapeau obsolète Cela faisait autrefois
-audio-in Remplacement moderne Activer le contrôle d'entrée audio
-audio-out Retirez-le des scripts de lancement, il ne fonctionne plus dans les documents actuels Activer le contrôle de sortie audio
-enable-kvm Retirez-le des scripts de lancement, il ne fonctionne plus dans les documents actuels Demander un chemin de virtualisation : 
-gps Comportement GPS contrôlé Enlevez-le des scripts de démarrage, il ne fonctionne plus dans les documents actuels
-skin Définir la peau du dispositif Enlevez-le des scripts de démarrage, il ne fonctionne plus dans les documents actuels
-skindir Pointe vers un répertoire de peau Enlevez-le des scripts de démarrage, il ne fonctionne plus dans les documents actuels
-useaudio Activer l'utilisation audio Enlevez-le des scripts de démarrage, il ne fonctionne plus dans les documents actuels

Google liste ces drapeaux comme ne fonctionnant plus dans les documents de l'émulateur actuel, donc les anciens snippets ont tendance à pourrir rapidement lorsqu'ils sont copiés dans un script frais Notes de ligne de commande de l'émulateur actuelSi vous les avez toujours dans un script shell partagé, enlevez-les et testez la mise en route à nouveau.

Dépannage et flux de travail Terminal 2026

Écran noir, offline, unauthorized, KO: missing authLes problèmes courants incluent les conflits de port et les snapshots obsolètes. Les solutions sont simples lorsque l'on identifie la cause correspondant au symptôme. Un démarrage bloqué peut indiquer un problème de snapshot, tandis que les échecs d'authentification de console sont souvent liés à un fichier de jeton ou à un handshake désynchronisé.

Capture d'écran depuis https://capgo.app

Corrections rapides pour les erreurs qui gaspillent le plus de temps

Si l'émulateur ne parvient jamais à passer d'une écran noir, redémarrez avec un chemin d'exécution propre et supprimez l'état obsolète. adb dit offline ou unauthorizedRéconnectez le périphérique et vérifiez que l'hôte et l'instance de l'émulateur correspondent toujours. Si la console renvoie KO: missing authVérifiez d'abord le fichier de jeton et le chemin de la main de poche, car la console ne prendra pas en charge les commandes avant que ce pas ne soit correct.

Les conflits de ports sont généralement un signe que l'émulateur précédent n'a pas quitté proprement, il faut donc libérer le port occupé avant la prochaine exécution. Si le démarrage ne se termine jamais, on suppose un dérive de snapshot jusqu'à preuve du contraire et on force un démarrage déterministe. C'est cette habitude, plus que tout drapeau individuel, qui rend la workflow terminal fiable en 2026.

Traitez le flux de travail comme un système, et non comme une séquence de clics.

Le modèle durable est un démarrage prévisible, accès au console authentifié. adb shell pour le travail au niveau de l'application, et un chemin de reversion lorsque les états dérivent. C'est la discipline derrière l'itération mobile rapide, qu'il s'agisse de tester une application native ou de livrer des mises à jour à une application Capacitor via un pipeline de lancement contrôlé.

La confiance est le gain. Une fois que le terminal de l'émulateur est connecté en tant que plan de contrôle, vous arrêtez de vous demander si la fenêtre est réactive et commencez à vous demander si l'état du dispositif est exactement ce que votre test attend.


Si vous construisez des applications mobiles qui nécessitent des chemins de lancement et de reversion fiables aux côtés de la testification pilotée par l'émulateur, Capgo donne aux équipes un moyen rapide de livrer des correctifs JavaScript, CSS, de configuration et d'actifs sans attendre la revue de la boutique. Visitez Capgo pour voir comment les mises à jour en direct, la protection de reversion et les contrôles de lancement s'intègrent dans un flux de travail où la testification Android pilotée par le terminal compte.

Mises à jour en direct pour les applications Capacitor

Quand un bug de la couche web est en ligne, expédiez la correction par Capgo au lieu d'attendre des jours pour l'approbation de la boutique d'applications. Les utilisateurs reçoivent la mise à jour en arrière-plan tandis que les modifications natives restent dans la voie de revue normale.

Support humain de Martin

Démarrer maintenant

Dernières actualités de notre Blog

Capgo vous offre les meilleures informations dont vous avez besoin pour créer une application mobile véritablement professionnelle.