Sauter au contenu principal

Terminal de l'émulateur Android : Guide pratique complet

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

Martin Donadieu

Martin Donadieu

Responsable de contenu

Terminal de l'émulateur Android : Guide pratique complet

Votre émulateur est ouvert, l'application est bloquée sur un écran noir, et les contrôles GUI 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 confort 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. L'outil d'émulation de Google vous donne 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 de s'introduire dans votre flux de travail, et CI se brise de manière qui semble aléatoire mais n'est pas.

Table des matières

Pourquoi Vous Avez Besoin du Terminal de l'Émulateur Android

Un GUI bloqué est le cas évident. La fenêtre de l'émulateur est toujours ouverte, mais vous ne pouvez pas y faire confiance, vous ne pouvez pas cliquer à travers elle, 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 gérer, la répétibilité. 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ôle à 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 la ligne de commande de l'émulateur Android.

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

La première fois que cela compte, c'est généralement peu glamour. Un script de test de qualité nécessite un état de dispositif propre, un développeur a besoin du même AVD pour démarrer sous Linux et macOS, ou un exécutant 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 d'abord la voie de la ligne de commande.

Google place également l'émulateur à côté de adb dans l'ensemble de l'outil de ligne de commande officiel, 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 émulateurUtilisez adb pour l'inspection du dispositif et l'accès à la shell, puis utilisez le 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.

The autres préjugés à 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 console Android Emulateur. C'est pourquoi elle se comporte comme un plan de contrôle de grade de production, et non comme un sandbox 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 Android pour les applications Capacitor pour le côté de configuration qui se trouve généralement derrière la session de l'émulateur.

Lancement des émulateurs à partir de 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-le avec emulator -avd <name> ou emulator @<name>. Si le chemin vers le binaire n'est pas sur votre chemin shell PATH, le trouvez à l'intérieur du répertoire de l'émulateur Android SDK sur Windows, macOS ou Linux, puis exécutez-le directement à partir de là.

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 CI et les hôtes sans écran. -no-window est le chemin sans écran, -no-snapshot oblige un état propre, -no-audio et -no-boot-anim élimine le bruit inutile, et -gpu swiftshader_indirect 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 pipeline peut faire confiance ». La commande de lancement devient partie de votre contrat de test, pas juste un wrapper de commodité. Si vous montez un appareil pour un flux de travail d'application Capacitor ou hybride, la même discipline de lancement s'applique avant que n'importe quel pas de débogage ou d'installation ne commence. Un guide pratique pour les développeurs Capacitor d'Android est vaut la peine de le garder à côté de vos commandes de l'émulateur.

Commencez par la liste des appareils, pas par la mémoire

L'erreur que je vois le plus souvent est de faire des hypothèses avant de vérifier ce que la machine a. La liste des AVDs en premier économise du temps car elle vous dit si l'image que vous voulez existe et si votre shell peut la voir. Ensuite, vous lancez un appareil connu, observez le chemin de démarrage, et seulement après cela, vous ajustez les drapeaux.

La bonne habitude : 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 garde la débogage local amical sans rendre l'automatisation négligente. Une fois la mise en route stable, le reste du flux de terminal a enfin quelque chose de fiable à 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 frapper la cible incorrecte. Le numéro de série maintient votre automatisation pointée sur l'émulateur que vous aviez l'intention d'utiliser.

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

Connectez-vous, puis déciderez-vous si vous avez besoin d'une interface de commande

La séparation 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, passez dans une invite interactive et restez-y jusqu'à ce que le travail soit terminé.

adb push et adb pull gère le déplacement de fichiers, adb install -r est le chemin pratique pour des tests locaux répétitifs, et adb exec-out screencap vous donne une capture de screenshot fiable. L'enregistrement de l'écran par adb shell screenrecord est tout aussi direct lorsque vous avez besoin d'un artefact rapide d'une exécution en échec. Pour les flux de travail de chargement local et de side-loading de packages, 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 un 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, puisqu'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 à travers les couches de plugin, le comportement spécifique à la plateforme et les questions relatives à l'état du dispositif, un kit de débogage plus large aide à garder le travail terminal de l'autre côté de la frontière de la supposition. Cette ressource de débogage s'adapte bien aux côtés du workflow adb.


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

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

Le chemin documenté par Google consiste à se connecter avec

attendre telnet localhost console-portpuis émettre OKen utilisant le jeton stocké dans auth auth_token Si 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. ~/.emulator_console_auth_tokenLa console est également découverte.

et help, help commandsont là pour une raison, 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. help-verbose sont là pour une raison, 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 Vous pouvez le faire plus tard.

Savez-vous ce qui doit apparaître dans la console

Les commandes de la console sont pour les cycles de vie et l'état côté-emulateur. avd start et avd stop sont des exemples évidents, mais rotate et ping sont tout aussi utiles lorsque vous vérifiez la responsivité ou que vous simulez des changements de dispositif. L'emulateur 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.

L'erreur commune est de mélanger la console de l'emulateur avec le shell Android. Ils ressemblent à des étrangers de loin, mais les protocoles sont différents. La console est authentifiée et liée au port, tandis que l'accès au shell est généralement géré par adb shell, 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, ce ressource de débogage se marie bien avec les vérifications de disponibilité de la console.

Bon portique d'automatisation : Do pas démarrer les tests à la seule lancement du processus. Démarez-les uniquement après que la main de console réussisse et que le dispositif virtuel signale l'état que vous attendez.

Cette décision élimine un grand nombre de « échecs de démarrage mais pas prêt » flous 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, l'installation d'une application de terminal réelle à l'intérieur de l'émulateur est la plus simple, 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 cliquer autour des écrans de paramètres.

Root lorsque l'image le permet

L'accès root dépend de l'image, et non de la magie. Sur les images système qui le permettent, adb root et adb shell su peut vous emmener où vous le souhaitez, mais les images Google Play standard ne sont généralement pas le lieu où vous pouvez attendre un travail 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 le jeu de commandes que vous auriez sinon manqué. Si vous effectuez une inspection de fichiers, une scripting côté appareil ou des diagnostics rapides à l'intérieur de l'émulateur, un kit de 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 debug, adb shell run-as <package> est souvent suffisant pour inspecter les dossiers 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 fait encore 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. Pour le travail de l'émulateur de tous les jours, l'hôte reste le point de départ le plus approprié, 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 du pouce est simple : utilisez l'autorité la plus petite qui peut toujours reproduire le bug. adb shell Réseau, redirection de port et raccourcis clavier

Un flux de travail d'émulateur axé sur les terminaux devient réel dès que le trafic doit traverser la limite de l'hôte.

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 de l'hôte. adb reverse tcp:8080 tcp:8080 gestionne le cas opposé, où le trafic de l'appareil doit atteindre un écouteur sur l'hôte. adb forward Choisissez la bonne direction avant de déboguer le mauvais niveau

Un grand 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.

permet à l'émulateur de rejoindre un service hôte, tandis que adb reverse envoie le trafic de l'appareil vers un port hôte, de sorte que le chemin de la connexion décide de la commande qui s'applique. adb forward Si la connectivité semble toujours défectueuse, vérifiez la table de routage à l'intérieur de la machine virtuelle.

Si la connectivité semble toujours défectueuse, vérifiez la table de routage à l'intérieur de la machine virtuelle. adb shell ip route et inspecter les interfaces avec ifconfig. Lorsque la mise en route semble normale mais que le service refuse toujours les connexions, la faute se situe généralement sur l'écouteur de l'hôte ou dans la configuration de redirection, et non dans Android lui-même. Pour une vision plus large de la façon dont les retards de trafic local façonnent ce que vous voyez lors de la débogage, cette explication sur la latence réseau est un complément utile à lire.

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

La carte de correspondance de la touche clavier de Google transforme lémulateur en un cible de bureau beaucoup meilleure. F2 ouvre le menu, ESC agit comme Annuler, 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 de grand format. Une fois que la surface de commande vit sur le clavier, l'émulateur 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 Ce qu'il faisait autrefois Remplacement moderne
-audio-in Contrôle d'entrée audio activé Supprimez-le des scripts de démarrage, il ne fonctionne plus dans les documents actuels
-audio-out Contrôle de sortie audio activé Supprimez-le des scripts de démarrage, il ne fonctionne plus dans les documents actuels
-enable-kvm A demandé un chemin de virtualisation Supprimez-le des scripts de démarrage, il ne fonctionne plus dans les documents actuels
-gps Contrôle du comportement GPS Supprimez-le des scripts de lancement, il ne fonctionne plus dans les documents actuels
-skin Définir la peau de l'appareil Supprimez-le des scripts de lancement, il ne fonctionne plus dans les documents actuels
-skindir Pointe vers un répertoire de peau Supprimez-le des scripts de lancement, il ne fonctionne plus dans les documents actuels
-useaudio Activez l'utilisation audio Supprimez-le des scripts de lancement, il ne fonctionne plus dans les documents actuels

Google classe 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 de shell partagé, supprimez-les et testez la lancement à nouveau.

Dépannage et flux de travail Terminal 2026

Ecran noir, conflits de ports et snapshots obsolètes sont le lot habituel de problèmes. Les solutions sont simples lorsque vous associez symptôme à cause. Un démarrage bloqué pointe souvent vers l'état du snapshot, tandis que les échecs d'authentification de console signifient généralement que le fichier de jeton ou la main de poche est hors synchronisme. offline, unauthorized, KO: missing authCapture d'écran depuis https://__CAPGO_KEEP_0__.app

Screenshot from https://capgo.app

Si l'emulateur ne parvient jamais à passer d'un écran noir, redémarrez avec un chemin de lancement propre et supprimez l'état obsolète. Si

dit adb ou offline , reconnectez le périphérique et vérifiez que l'hôte et l'instance d'emulateur correspondent toujours. Si la console renvoie unauthorized, vérifiez d'abord le fichier de jeton et le chemin de main de poche, car la console ne prendra pas en charge les commandes avant que ce pas soit correct. KO: missing authLes conflits de ports sont généralement un signe que l'emulateur 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, supposez un dérive de snapshot jusqu'à preuve du contraire et forcez un démarrage déterministe. Cette habitude, plus que toute drapeau individuel, est ce qui rend la workflow de terminal fiable en 2026.

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

Le modèle durable est un démarrage prévisible, un accès à la console authentifié,

Treat the workflow like a system, not a sequence of clicks adb shell pour le travail d'appel, 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 mise en production contrôlée.

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 vous 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 mise en production et de récupération fiables aux côtés de tests dirigés 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. Capgo __CAPGO_KEEP_0__

Mises à jour en temps réel pour les applications Capacitor

Lorsqu'un bug de la couche web est en ligne, expédiez la correction à travers Capgo au lieu de 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 le chemin de revue normal.

Commencez dès maintenant

Dernières actualités de notre blog

Capgo vous donne les meilleures informations dont vous avez besoin pour créer une application mobile vraiment professionnelle.