Android Debug Bridge (adb
) est un outil de ligne de commande polyvalent qui vous permet de communiquer avec un appareil. La commande adb
facilite diverses actions sur l'appareil, telles que l'installation et le débogage des applications. adb
donne accès à un shell Unix que vous pouvez utiliser pour exécuter différentes commandes sur un appareil. Il s'agit d'un programme client-serveur qui comprend trois composants :
- Un client, qui envoie des commandes. Le client s'exécute sur votre ordinateur de développement. Vous pouvez appeler un client à partir d'un terminal de ligne de commande en exécutant une commande
adb
. - Un daemon (adbd), qui exécute des commandes sur un appareil. Le daemon s'exécute en tant que processus en arrière-plan sur chaque appareil.
- Un serveur, qui gère la communication entre le client et le daemon. Le serveur s'exécute en tant que processus en arrière-plan sur votre ordinateur de développement.
adb
est inclus dans le package d'outils de plate-forme du SDK Android. Téléchargez ce package à l'aide de SDK Manager, qui l'installe à l'adresse android_sdk/platform-tools/
. Si vous souhaitez utiliser le package autonome d'outils de plate-forme du SDK Android, vous pouvez le télécharger ici.
Pour en savoir plus sur la connexion d'un appareil à utiliser via adb
, y compris sur l'utilisation de l'assistant de connexion pour résoudre les problèmes courants, consultez Exécuter des applications sur un appareil matériel.
Fonctionnement d'adb
Lorsque vous démarrez un client adb
, il vérifie d'abord si un processus de serveur adb
est déjà en cours d'exécution. Dans le cas contraire, il lance le processus de serveur.
Lorsque le serveur démarre, il se lie au port TCP local 5037 et écoute les commandes envoyées par les clients adb
.
Remarque : Tous les clients adb
utilisent le port 5037 pour communiquer avec le serveur adb
.
Le serveur configure ensuite les connexions à tous les appareils en cours d'exécution.
Il localise les émulateurs en analysant les ports impairs compris dans la plage 5555-5585, qui est utilisée par les 16 premiers émulateurs. Lorsque le serveur trouve un daemon adb
(adbd), il établit une connexion à ce port.
Chaque émulateur utilise une paire de ports séquentiels : un port pair pour les connexions à la console et un port impair pour les connexions adb
. Exemple :
Émulateur 1, console : 5554
Émulateur 1, adb
: 5555
Émulateur 2, console : 5556
Émulateur 2, adb
: 5557
, etc.
Comme indiqué, l'émulateur connecté à adb
sur le port 5555 est le même que l'émulateur dont la console écoute sur le port 5554.
Une fois que le serveur a établi les connexions à tous les appareils, vous pouvez utiliser les commandes adb
pour accéder à ces appareils. Comme le serveur gère les connexions aux appareils ainsi que les commandes de plusieurs clients adb
, vous pouvez contrôler n'importe quel appareil depuis n'importe quel client (ou à partir d'un script).
Activer le débogage adb sur votre appareil
Pour utiliser adb avec un appareil connecté via USB, vous devez activer le débogage USB dans les paramètres système de l'appareil, sous Options pour les développeurs. Sur Android 4.2 (niveau d'API 17) ou version ultérieure, l'écran Developer options (Options pour les développeurs) est masqué par défaut. Pour le rendre visible, activez les options pour les développeurs.
Vous pouvez désormais connecter votre appareil à l'aide d'un câble USB. Pour vérifier que votre appareil est connecté, vous pouvez exécuter adb devices
à partir du répertoire android_sdk/platform-tools/
. S'il est connecté, le nom de l'appareil indique "appareil".
Remarque : Lorsque vous connectez un appareil exécutant Android 4.2.2 (niveau d'API 17) ou version ultérieure, le système affiche une boîte de dialogue demandant s'il faut accepter une clé RSA qui permet le débogage via cet ordinateur. Ce mécanisme de sécurité protège les appareils des utilisateurs, car il garantit que le débogage USB et les autres commandes adb ne peuvent être exécutés que si vous pouvez déverrouiller l'appareil et confirmer la boîte de dialogue.
Pour en savoir plus sur la connexion à un appareil via USB, consultez Exécuter des applications sur un appareil matériel.
Se connecter à un appareil via le Wi-Fi
Remarque : Les instructions ci-dessous ne s'appliquent pas aux appareils Wear exécutant Android 11 (niveau d'API 30). Pour en savoir plus, consultez le guide sur le débogage d'une application Wear OS.
Android 11 (niveau d'API 30) ou version ultérieure est compatible avec le déploiement et le débogage sans fil de votre application depuis votre poste de travail à l'aide d'Android Debug Bridge (adb). Par exemple, vous pouvez déployer votre fichier l'application à plusieurs appareils distants sans jamais avoir besoin de connecter physiquement votre appareil via USB. Il n'est donc plus nécessaire de résoudre les problèmes de connexion USB courants, tels que les pilotes l'installation.
Avant de pouvoir utiliser le débogage sans fil, procédez comme suit :
-
Assurez-vous que votre station de travail et votre appareil sont connectés au même réseau sans fil.
-
Assurez-vous que votre appareil est équipé d'Android 11 (niveau d'API 30) ou version ultérieure pour téléphone, ou d'Android 13 (niveau d'API 33) ou version ultérieure pour téléviseur et Wear OS. Pour en savoir plus, consultez Vérifier la version d'Android utilisée et la mettre à jour.
-
Si vous utilisez l'IDE, assurez-vous que la dernière version d'Android Studio est installée. Vous pouvez le télécharger ici.
-
Sur votre station de travail, installez la dernière version de SDK Platform Tools.
Pour utiliser le débogage sans fil, vous devez associer votre appareil à votre station de travail à l'aide d'un code QR ou d'un code d'association. Votre station de travail et votre appareil doivent être connectés au même réseau sans fil. Pour vous connecter à votre appareil, procédez comme suit :
-
Activez les options pour les développeurs sur votre appareil.
-
Ouvrez Android Studio, puis sélectionnez Pair Devices Using Wi-Fi (Associer des appareils à l'aide du Wi-Fi) dans le menu des configurations d'exécution.
Figure 1. Menu "Run configurations" ("Configurations d'exécution")La fenêtre Pair devices over Wi-Fi (Associer des appareils en Wi-Fi) s'affiche, comme illustré dans la figure 2.
Figure 2. Fenêtre pop-up permettant d'associer des appareils à l'aide d'un code QR ou d'un code d'association -
Sur votre appareil, appuyez sur Débogage sans fil et associez votre appareil :
Figure 3. Paramètre Wireless debugging (Débogage sans fil) sur un téléphone Google Pixel-
Pour associer votre appareil à un code QR, sélectionnez Associer un appareil avec un code QR, puis scannez le code QR obtenu dans la fenêtre pop-up Associer des appareils en Wi-Fi, comme illustré dans la figure 2.
-
Pour associer votre appareil avec un code d'association, sélectionnez Associer l'appareil avec un code d'association dans la fenêtre pop-up Associer des appareils en Wi-Fi. Sur votre appareil, sélectionnez Associer à l'aide du code d'association, puis notez le code à six chiffres fourni. Une fois que votre appareil apparaît dans la fenêtre Associer des appareils en Wi-Fi, vous pouvez sélectionner Associer et saisir le code à six chiffres affiché sur votre appareil.
Figure 4. Exemple de saisie d'un code à six chiffres
-
-
Une fois votre appareil associé, vous pouvez essayer de déployer votre application sur votre appareil.
Pour associer un autre appareil ou pour supprimer l'appareil actuel de votre station de travail, accédez à Débogage sans fil sur votre appareil. Appuyez ensuite sur le nom de votre station de travail sous Appareils associés, puis sélectionnez Supprimer.
-
Si vous souhaitez activer et désactiver rapidement le débogage sans fil, vous pouvez utiliser les Blocs Réglages rapides pour les développeurs pour le Débogage sans fil, sous Options pour les développeurs > Blocs Réglages rapides pour les développeurs.
Figure 5. Le paramètre Blocs Réglages rapides pour les développeurs vous permet d'activer et de désactiver rapidement le débogage sans fil.
Connexion Wi-Fi via la ligne de commande
Pour vous connecter à votre appareil via la ligne de commande sans Android Studio, procédez comme suit :
-
Activez les Options pour les développeurs sur votre appareil, comme décrit précédemment.
-
Activez le débogage sans fil sur votre appareil, comme décrit précédemment.
-
Sur votre station de travail, ouvrez une fenêtre de terminal et accédez à
android_sdk/platform-tools
. -
Recherchez votre adresse IP, votre numéro de port et votre code d'association en sélectionnant Associer l'appareil avec un code d'association. Notez l'adresse IP, le numéro de port et le code d'association affichés sur l'appareil.
-
Sur le terminal de votre station de travail, exécutez
adb pair ipaddr:port
. Utilisez l'adresse IP et le numéro de port ci-dessus. -
Lorsque vous y êtes invité, saisissez le code d'association, comme indiqué ci-dessous.
Figure 6. Un message indique que votre appareil a bien été associé.
Résoudre les problèmes de connexion sans fil
Si vous rencontrez des problèmes pour vous connecter à votre appareil en mode sans fil, suivez les étapes de dépannage ci-dessous.
Vérifier si votre station de travail et votre appareil remplissent les conditions préalables
Vérifiez que la station de travail et l'appareil remplissent les conditions préalables indiquées au début de cette section.
Rechercher d'autres problèmes connus
Voici une liste des problèmes connus actuels liés au débogage sans fil (avec adb ou Android). Studio) et comment les résoudre:
-
Le Wi-Fi ne se connecte pas: les réseaux Wi-Fi sécurisés, tels que les réseaux Wi-Fi d'entreprise, peut bloquer les connexions p2p et vous empêcher de vous connecter en Wi-Fi. Essayez de vous connecter avec un câble ou un autre réseau Wi-Fi (non professionnel). Connexion sans fil avec
adb connect ip:port
sur tcp/ip (après une connexion USB initiale) est une autre option, au cas où le recours à un réseau non professionnel serait une option. -
adb
via le Wi-Fi s'arrête parfois automatiquement : cela peut se produire si l'appareil change de réseau Wi-Fi ou se déconnecte du réseau. Pour résoudre le problème, reconnectez-vous au réseau. -
L'appareil ne se connecte pas après l'association réussie:
adb
s'appuie sur un mDNS pour détecter les appareils associés et s'y connecter automatiquement. Si votre réseau ou votre appareil n'est pas compatible avec le mDNS ou l'a désactivé, vous devez alors connectez-vous à l'appareil à l'aide deadb connect ip:port
.
Se connecter sans fil à un appareil après une connexion USB initiale (seule option disponible sur Android 10 ou version antérieure)
Remarque:Ce workflow s'applique également à Android 11 (et la mise en garde est qu’elle implique également une connexion *initiale* via USB physique.
Remarque : Les instructions suivantes ne s'appliquent pas aux appareils Wear exécutant Android 10 (niveau d'API 29) ou version antérieure. Pour en savoir plus, consultez le guide sur le débogage d'une application Wear OS.
En principe, adb
communique avec l'appareil via USB, mais vous pouvez aussi utiliser adb
via le Wi-Fi. Pour connecter un appareil équipé d'Android 10 (niveau d'API 29) ou version antérieure, procédez comme suit via USB :
-
Connectez votre appareil Android et l'ordinateur hôte
adb
à un réseau Wi-Fi commun. - Connectez l'appareil à l'ordinateur hôte à l'aide d'un câble USB.
-
Définissez l'appareil cible pour qu'il écoute une connexion TCP/IP sur le port 5555 :
adb tcpip 5555
- Débranchez le câble USB de l'appareil cible.
- Recherchez l'adresse IP de l'appareil Android. Par exemple, sur un appareil Nexus, vous pouvez trouver l'adresse IP dans Paramètres > À propos de la tablette (ou À propos du téléphone) > État > Adresse IP.
-
Connectez-vous à l'appareil par son adresse IP :
adb connect device_ip_address:5555
-
Vérifiez que votre ordinateur hôte est connecté à l'appareil cible :
$ adb devices List of devices attached device_ip_address:5555 device
Remarque : Tous les points d'accès ne conviennent pas. Vous devrez peut-être utiliser un point d'accès dont le pare-feu est correctement configuré pour prendre en charge adb
.
Votre appareil est désormais connecté à adb
.
Si la connexion adb
à votre appareil est perdue :
- Assurez-vous que votre hôte est toujours connecté au même réseau Wi-Fi que votre appareil Android.
-
Reconnectez-vous en exécutant à nouveau l'étape
adb connect
. -
Si cela ne fonctionne pas, réinitialisez votre hôte
adb
:adb kill-server
Ensuite, recommencez depuis le début.
Requête pour des appareils
Avant d'exécuter des commandes adb
, il est utile de savoir quelles instances d'appareil sont connectées au serveur adb
. Générez une liste des appareils associés à l'aide de la commande devices
:
adb devices -l
En réponse, adb
affiche ces informations d'état pour chaque appareil :
- Numéro de série :
adb
crée une chaîne pour identifier l'appareil de manière unique par son numéro de port. Voici un exemple de numéro de série :emulator-5554
- État : l'état de connexion de l'appareil peut être l'un des suivants :
offline
: l'appareil n'est pas connecté àadb
ou ne répond pas.device
: l'appareil est connecté au serveuradb
. Notez que cet état ne signifie pas que le système Android est entièrement démarré et opérationnel, car l'appareil se connecte àadb
alors que le système est encore en train de démarrer. Après le démarrage, il s'agit de l'état opérationnel normal d'un appareil.no device
: aucun appareil n'est connecté.
- Description : si vous incluez l'option
-l
, la commandedevices
vous indique de quel appareil il s'agit. Ces informations sont utiles lorsque plusieurs appareils sont connectés afin de pouvoir les différencier.
L'exemple suivant montre la commande devices
et sa sortie. Trois appareils sont en cours d'exécution. Les deux premières lignes de la liste sont des émulateurs, et la troisième ligne est un appareil matériel connecté à l'ordinateur.
$ adb devices List of devices attached emulator-5556 device product:sdk_google_phone_x86_64 model:Android_SDK_built_for_x86_64 device:generic_x86_64 emulator-5554 device product:sdk_google_phone_x86 model:Android_SDK_built_for_x86 device:generic_x86 0a388e93 device usb:1-1 product:razor model:Nexus_7 device:flo
Émulateur non listé
La commande adb devices
présente une séquence de commandes corner-case qui empêche les émulateurs en cours d'exécution de s'afficher dans la sortie adb devices
même si les émulateurs sont visibles sur votre ordinateur. Cela se produit lorsque toutes les conditions suivantes sont remplies :
- Le serveur
adb
n'est pas en cours d'exécution. - Vous utilisez la commande
emulator
avec l'option-port
ou-ports
avec un port impair compris entre 5554 et 5584. - Le port impair que vous avez choisi n'est pas occupé. La connexion peut donc être établie au numéro de port spécifié. Si le port est occupé, l'émulateur bascule sur un autre port répondant aux exigences du point 2.
- Vous démarrez le serveur
adb
après avoir démarré l'émulateur.
Pour éviter cette situation, vous pouvez laisser l'émulateur choisir ses propres ports et ne pas exécuter plus de 16 émulateurs à la fois. Une autre méthode consiste à toujours démarrer le serveur adb
avant d'utiliser la commande emulator
, comme expliqué dans les exemples suivants.
Exemple 1 : Dans la séquence de commandes suivante, la commande adb devices
démarre le serveur adb
, mais la liste d'appareils ne s'affiche pas.
Arrêtez le serveur adb
, puis saisissez les commandes suivantes dans l'ordre indiqué. Pour le nom de l'appareil virtuel Android (AVD, Android Virtual Device), indiquez un nom valide depuis votre système. Pour obtenir la liste des noms d'AVD, saisissez emulator -list-avds
. La commande emulator
se trouve dans le répertoire android_sdk/tools
.
$ adb kill-server $ emulator -avd Nexus_6_API_25 -port 5555 $ adb devices List of devices attached * daemon not running. starting it now on port 5037 * * daemon started successfully *
Exemple 2 : Dans la séquence de commandes suivante, adb devices
affiche la liste des appareils, car le serveur adb
a été démarré en premier.
Pour afficher l'émulateur dans la sortie adb devices
, arrêtez le serveur adb
, puis redémarrez-le après avoir utilisé la commande emulator
et avant d'utiliser la commande adb devices
, comme suit :
$ adb kill-server $ emulator -avd Nexus_6_API_25 -port 5557 $ adb start-server $ adb devices List of devices attached emulator-5557 device
Pour en savoir plus sur les options de ligne de commande de l'émulateur, consultez Options de démarrage de la ligne de commande.
Envoyer des commandes à un appareil spécifique
Si plusieurs appareils sont en cours d'exécution, vous devez spécifier l'appareil cible lorsque vous émettez la commande adb
.
Pour spécifier la cible :
- Exécutez la commande
devices
pour obtenir le numéro de série de la cible. - Une fois celui-ci en votre possession, utilisez l'option
-s
avec les commandesadb
pour spécifier le numéro de série.- Si vous prévoyez d'émettre de nombreuses commandes
adb
, vous pouvez définir la variable d'environnement$ANDROID_SERIAL
pour qu'elle contienne le numéro de série à la place. - Si vous utilisez à la fois
-s
et$ANDROID_SERIAL
,-s
remplace$ANDROID_SERIAL
.
- Si vous prévoyez d'émettre de nombreuses commandes
Dans l'exemple suivant, la liste des appareils connectés est obtenue, puis le numéro de série de l'un des appareils est utilisé pour installer helloWorld.apk
sur cet appareil :
$ adb devices List of devices attached emulator-5554 device emulator-5555 device 0.0.0.0:6520 device # To install on emulator-5555 $ adb -s emulator-5555 install helloWorld.apk # To install on 0.0.0.0:6520 $ adb -s 0.0.0.0:6520 install helloWorld.apk
Remarque:Si vous émettez une commande sans spécifier d'appareil cible
Lorsque plusieurs appareils sont disponibles, adb
affiche une erreur.
"adb: more than one device/emulator".
Si plusieurs appareils sont disponibles, mais qu'un seul d'entre eux est un émulateur, utilisez l'option -e
pour lui envoyer des commandes. S'il existe plusieurs appareils, mais qu'un seul appareil matériel est associé, utilisez l'option -d
pour lui envoyer des commandes.
Installer une application
Vous pouvez utiliser adb
pour installer un APK sur un émulateur ou un appareil connecté à l'aide de la commande install
:
adb install path_to_apk
Vous devez utiliser l'option -t
avec la commande install
lorsque vous installez un APK de test. Pour en savoir plus, consultez -t
.
Pour installer plusieurs APK, utilisez install-multiple
. Cela peut s'avérer utile si vous téléchargez
les APK d'un appareil spécifique pour votre application à partir de la Play Console et que vous souhaitez les installer sur un
l'émulateur ou un appareil physique.
Pour savoir comment créer un fichier APK que vous pouvez installer sur une instance d'émulateur/d'appareil, consultez Compiler et exécuter votre application.
Remarque : Si vous utilisez Android Studio, vous n'avez pas besoin d'utiliser directement adb
pour installer votre application sur l'émulateur/l'appareil. Android Studio se charge de créer le package et d'installer l'application.
Configurer le transfert de port
Exécutez la commande forward
pour configurer le transfert de port arbitraire, qui transfère les requêtes sur un port hôte spécifique vers un autre port d'un appareil.
Dans l'exemple suivant, la commande permet de configurer le transfert du port hôte 6100 vers le port 7100 de l'appareil :
adb forward tcp:6100 tcp:7100
Dans l'exemple suivant, la commande permet de configurer le transfert du port hôte 6100 vers local:logd :
adb forward tcp:6100 local:logd
Cela peut être utile si vous essayez de déterminer ce qui est envoyé à un port spécifique de l'appareil. Toutes les données reçues seront écrites dans le daemon de journalisation système et affichées dans les journaux de l'appareil.
Copier des fichiers vers et depuis un appareil
Exécutez les commandes pull
et push
pour copier des fichiers vers et depuis un appareil. Contrairement à la commande install
, qui copie uniquement un fichier APK dans un emplacement spécifique, les commandes pull
et push
vous permettent de copier des répertoires et des fichiers arbitraires dans n'importe quel emplacement d'un appareil.
Pour copier un fichier ou un répertoire et ses sous-répertoires depuis l'appareil, procédez comme suit :
adb pull remote local
Pour copier un fichier ou un répertoire et ses sous-répertoires vers l'appareil, procédez comme suit :
adb push local remote
Remplacez local
et remote
par les chemins d'accès aux fichiers/répertoire cibles sur votre ordinateur de développement (local) et sur l'appareil (distant). Par exemple :
adb push myfile.txt /sdcard/myfile.txt
Arrêter le serveur adb
Dans certains cas, vous devrez peut-être arrêter le processus de serveur adb
, puis le redémarrer pour résoudre le problème (par exemple, si adb
ne répond pas à une commande).
Pour arrêter le serveur adb
, exécutez la commande adb kill-server
.
Vous pouvez ensuite redémarrer le serveur en émettant n'importe quelle autre commande adb
.
Émettre des commandes adb
Exécutez des commandes adb
à partir d'une ligne de commande sur votre ordinateur de développement ou à partir d'un script à l'aide de la syntaxe suivante :
adb [-d | -e | -s serial_number] command
Si un seul émulateur est en cours d'exécution ou si un seul appareil est connecté, la commande adb
est envoyée par défaut à cet appareil. Si plusieurs émulateurs sont en cours d'exécution et/ou plusieurs appareils sont connectés, vous devez utiliser l'option -d
, -e
ou -s
pour spécifier l'appareil cible auquel la commande doit être dirigée.
Vous pouvez afficher une liste détaillée de toutes les commandes adb
compatibles à l'aide de la commande suivante :
adb --help
Exécuter des commandes shell
Vous pouvez utiliser la commande shell
pour émettre des commandes d'appareil via adb
ou pour démarrer un shell interactif. Pour émettre une seule commande, exécutez la commande shell
comme suit :
adb [-d |-e | -s serial_number] shell shell_command
Pour démarrer un shell interactif sur un appareil, exécutez la commande shell
comme suit :
adb [-d | -e | -s serial_number] shell
Pour quitter un shell interactif, appuyez sur Control+D
ou saisissez exit
.
Android fournit la plupart des outils de ligne de commande Unix habituels. Pour obtenir la liste des outils disponibles, utilisez la commande suivante :
adb shell ls /system/bin
Vous pouvez obtenir de l'aide pour la plupart des commandes via l'argument --help
.
De nombreuses commandes d'interface système sont fournies par toybox.
Une aide générale applicable à toutes les commandes toybox est disponible via toybox --help
.
Avec les outils de plate-forme Android 23 et versions ultérieures, adb
gère les arguments de la même manière que la commande ssh(1)
. Cette modification a résolu de nombreux problèmes liés à l'injection de commande et permet d'exécuter de manière sécurisée des commandes contenant des métacaractères de shell tels que adb install Let\'sGo.apk
. Cette nouveauté signifie que l'interprétation de toute commande contenant des métacaractères de shell a également changé.
Par exemple, la commande adb shell setprop key 'value'
est désormais une erreur, car les guillemets simples ('
) sont avalés par le shell local, et l'appareil voit adb shell setprop key value
. Pour que la commande fonctionne, placez-la entre deux paires de guillemets : une paire pour le shell local et une autre pour le shell distant, comme vous le faites avec ssh(1)
. Exemple : adb shell setprop key 'value'
.
Reportez-vous également à l'outil de ligne de commande Logcat, qui permet de surveiller le journal système.
Appeler le gestionnaire d'activités
Dans un shell adb
, vous pouvez émettre des commandes avec le gestionnaire d'activités (am
) pour effectuer diverses actions système, comme démarrer une activité, forcer l'arrêt d'un processus, diffuser un intent, modifier les propriétés de l'écran de l'appareil, etc.
Dans un shell, la syntaxe am
est la suivante :
am command
Vous pouvez également émettre une commande de gestionnaire d'activités directement depuis adb
sans accéder à un shell distant. Exemple :
adb shell am start -a android.intent.action.VIEW
Tableau 1. Commandes disponibles dans le gestionnaire d'activités
Commande | Description |
---|---|
start [options] intent
|
Démarrez une Activity spécifiée par intent . Consultez Spécification pour les arguments d'intent. Les options sont les suivantes :
|
startservice [options] intent
|
Démarrer le Service spécifié par intent . Consultez Spécification pour les arguments d'intent. Les options sont les suivantes :
|
force-stop package
|
Forcer l'arrêt de tous les éléments associés à package .
|
kill [options] package
|
Arrêtez tous les processus associés à package . Cette commande n'interrompt que les processus pouvant être arrêtés de manière sécurisée et qui n'ont pas d'incidence sur l'expérience utilisateur.
Les options sont les suivantes :
|
kill-all
|
Arrêter tous les processus en arrière-plan. |
broadcast [options] intent
|
Émettre un intent de diffusion. Consultez Spécification pour les arguments d'intent. Les options sont les suivantes :
|
instrument [options] component
|
Démarrer la surveillance avec une instance Instrumentation .
Généralement, la cible component est au format test_package/runner_class . Les options sont les suivantes :
|
profile start process file
|
Démarrer le profileur sur process , écrire les résultats dans file .
|
profile stop process
|
Arrêter le profileur sur process .
|
dumpheap [options] process file
|
Vider le tas de mémoire de process , écrire dans file . Les options sont les suivantes :
|
set-debug-app [options] package
|
Configurer le package d'application à déboguer. Les options sont les suivantes :
|
clear-debug-app
|
Effacer l'ensemble de packages précédent pour le débogage avec set-debug-app .
|
monitor [options]
|
Commencer à surveiller les plantages ou les erreurs ANR. Les options sont les suivantes :
|
screen-compat {on | off} package
|
Contrôler le mode de compatibilité d'écran de package .
|
display-size [reset | widthxheight]
|
Remplacer la taille d'affichage de l'appareil.
Cette commande est utile pour tester votre application sur différentes tailles d'écran en imitant une petite résolution d'écran à l'aide d'un appareil avec un grand écran, et inversement.
Exemple : |
display-density dpi
|
Remplacer la densité d'affichage de l'appareil.
Cette commande est utile pour tester votre application sur différentes densités d'écran en imitant un environnement d'écran haute densité à l'aide d'un écran basse densité, et inversement.
Exemple : |
to-uri intent
|
Imprimer la spécification d'intent donnée en tant qu'URI. Consultez Spécification pour les arguments d'intent. |
to-intent-uri intent
|
Afficher la spécification d'intent donnée en tant qu'URI intent: . Consultez Spécification pour les arguments d'intent. |
Spécification pour les arguments d'intent
Pour les commandes du gestionnaire d'activités qui acceptent un argument intent
, vous pouvez spécifier l'intent à l'aide des options suivantes :
Appeler le gestionnaire de paquets (pm
)
Dans un shell adb
, vous pouvez émettre des commandes avec le gestionnaire de paquets (pm
) pour effectuer des actions et des requêtes sur les packages d'applications installés sur l'appareil.
Dans un shell, la syntaxe pm
est la suivante :
pm command
Vous pouvez également émettre une commande de gestionnaire de paquets directement depuis adb
sans accéder à un shell distant. Exemple :
adb shell pm uninstall com.example.MyApp
Tableau 2. Commandes disponibles dans le gestionnaire de paquets
Commande | Description |
---|---|
list packages [options] filter
|
Afficher tous les packages, éventuellement uniquement ceux dont le nom de package contient le texte dans filter . Options :
|
list permission-groups
|
Afficher tous les groupes d'autorisations connus. |
list permissions [options] group
|
Afficher toutes les autorisations connues, éventuellement uniquement celles de group . Options :
|
list instrumentation [options]
|
Lister tous les packages de test. Options :
|
list features
|
Afficher toutes les fonctionnalités du système. |
list libraries
|
Afficher toutes les bibliothèques compatibles avec l'appareil actuel. |
list users
|
Afficher tous les utilisateurs du système. |
path package
|
Afficher le chemin d'accès à l'APK de l'élément package indiqué.
|
install [options] path
|
Installer un package (spécifié par path ) sur le système. Options :
|
uninstall [options] package
|
Supprimer un package du système. Options :
|
clear package
|
Supprimer toutes les données associées à un package. |
enable package_or_component
|
Activer le package ou le composant donné (écrit sous la forme "package/class"). |
disable package_or_component
|
Désactiver le package ou le composant donné (écrit sous la forme "package/class"). |
disable-user [options] package_or_component
|
Options :
|
grant package_name permission
|
Accorder une autorisation à une application. Sur les appareils équipés d'Android 6.0 (niveau d'API 23) et versions ultérieures, l'autorisation peut être n'importe quelle autorisation déclarée dans le fichier manifeste d'application. Sur les appareils équipés d'Android 5.1 (niveau d'API 22) et versions antérieures, il doit s'agir d'une autorisation facultative définie par l'application. |
revoke package_name permission
|
Révoquer une autorisation d'une application. Sur les appareils équipés d'Android 6.0 (niveau d'API 23) et versions ultérieures, l'autorisation peut être n'importe quelle autorisation déclarée dans le fichier manifeste d'application. Sur les appareils équipés d'Android 5.1 (niveau d'API 22) et versions antérieures, il doit s'agir d'une autorisation facultative définie par l'application. |
set-install-location location
|
Modifier l'emplacement d'installation par défaut. Valeurs d'emplacement :
Remarque : Cette commande n'est destinée qu'au débogage. Son utilisation peut entraîner le dysfonctionnement des applications et d'autres comportements indésirables. |
get-install-location
|
Renvoyer l'emplacement d'installation actuel. Valeurs renvoyées :
|
set-permission-enforced permission [true | false]
|
Indiquer si l'autorisation donnée doit être appliquée. |
trim-caches desired_free_space
|
Couper les fichiers de cache pour atteindre l'espace disponible donné. |
create-user user_name
|
Créer un utilisateur avec le user_name donné, en affichant le nouvel identifiant de l'utilisateur.
|
remove-user user_id
|
Retirer l'utilisateur avec le user_id donné, en supprimant toutes les données associées à cet utilisateur.
|
get-max-users
|
Afficher le nombre maximal d'utilisateurs accepté par l'appareil. |
get-app-links [options] [package]
|
Afficher l'état de validation du domaine pour le package donné ou pour tous les packages si aucun n'est spécifié. Les codes d'état sont définis comme suit :
Les options sont les suivantes :
|
reset-app-links [options] [package]
|
Réinitialiser l'état de validation du domaine pour le package donné ou pour tous les packages si aucun n'est spécifié.
Les options sont les suivantes :
|
verify-app-links [--re-verify] [package]
|
Diffuser une requête de validation pour le package donné ou pour tous les packages si aucun n'est spécifié. Envoyer uniquement si le package n'a pas enregistré de réponse auparavant.
|
set-app-links [--package package] state domains
|
Définir manuellement l'état d'un domaine pour un package. Le domaine doit être déclaré par le package en tant qu'autoVerify pour que cela fonctionne. Cette commande ne signalera pas d'échec pour les domaines qui n'ont pas pu être appliqués.
|
set-app-links-user-selection --user user_id [--package package]
enabled domains
|
Définir manuellement l'état d'une sélection d'utilisateur hôte pour un package. Le domaine doit être déclaré par le package pour que cela fonctionne. Cette commande ne signalera pas d'échec pour les domaines qui n'ont pas pu être appliqués.
|
set-app-links-user-selection --user user_id [--package package]
enabled domains
|
Définir manuellement l'état d'une sélection d'utilisateur hôte pour un package. Le domaine doit être déclaré par le package pour que cela fonctionne. Cette commande ne signalera pas d'échec pour les domaines qui n'ont pas pu être appliqués.
|
set-app-links-allowed --user user_id [--package package] allowed
|
Activer/Désactiver le paramètre de gestion des liens validés automatiquement pour un package.
|
get-app-link-owners --user user_id [--package package] domains
|
Afficher les propriétaires d'un domaine spécifique pour un utilisateur donné, dans l'ordre croissant de priorité.
|
Appeler le gestionnaire de règles de l'appareil (dpm
)
Pour vous aider à développer et à tester vos applications de gestion des appareils, envoyez des commandes au gestionnaire de règles de l'appareil (dpm
). Utilisez cet outil pour contrôler l'application d'administration active ou modifier les données d'état d'une règle sur l'appareil.
Dans un shell, la syntaxe dpm
est la suivante :
dpm command
Vous pouvez également émettre une commande de gestionnaire de règles de l'appareil directement depuis adb
sans accéder à un shell distant :
adb shell dpm command
Tableau 3. Commandes disponibles dans le gestionnaire de règles de l'appareil
Commande | Description |
---|---|
set-active-admin [options] component
|
Définit component comme administrateur actif.
Les options sont les suivantes :
|
set-profile-owner [options] component
|
Définir component comme administrateur actif et son package en tant que propriétaire de profil pour un utilisateur existant.
Les options sont les suivantes :
|
set-device-owner [options] component
|
Définir component comme administrateur actif et son package en tant que propriétaire de l'appareil.
Les options sont les suivantes :
|
remove-active-admin [options] component
|
Désactiver un administrateur actif. L'application doit déclarer android:testOnly dans le fichier manifeste. Cette commande supprime également les propriétaires de l'appareil et du profil.
Les options sont les suivantes :
|
clear-freeze-period-record
|
Effacer l'enregistrement de l'appareil des périodes de blocage précédemment définies pour les mises à jour OTA du système. Cela permet d'éviter les restrictions de planification de l'appareil lors du développement d'applications qui gèrent des périodes de blocage. Consultez Gérer les mises à jour du système.
Compatible avec les appareils équipés d'Android 9.0 (niveau d'API 28) et versions ultérieures. |
force-network-logs
|
Forcer le système à préparer tous les journaux réseau existants pour qu'ils puissent être récupérés par un DPC. Si des journaux de connexion ou DNS sont disponibles, le DPC reçoit le rappel onNetworkLogsAvailable() . Consultez Journalisation de l'activité réseau.
Cette commande est limitée en débit. Compatible avec les appareils équipés d'Android 9.0 (niveau d'API 28) et versions ultérieures. |
force-security-logs
|
Forcer le système à mettre tous les journaux de sécurité existants à la disposition du DPC. Si des journaux sont disponibles, le DPC reçoit le rappel onSecurityLogsAvailable() . Consultez Journaliser l'activité des appareils de l'entreprise.
Cette commande est limitée en débit. Compatible avec les appareils équipés d'Android 9.0 (niveau d'API 28) et versions ultérieures. |
Faire une capture d'écran
La commande screencap
est un utilitaire de shell qui permet de faire une capture de l'écran d'un appareil.
Dans un shell, la syntaxe screencap
est la suivante :
screencap filename
Pour utiliser screencap
à partir de la ligne de commande, saisissez la commande suivante :
adb shell screencap /sdcard/screen.png
Voici un exemple de session de capture d'écran, utilisant le shell adb
pour effectuer la capture d'écran et la commande pull
pour télécharger le fichier depuis l'appareil :
$ adb shell shell@ $ screencap /sdcard/screen.png shell@ $ exit $ adb pull /sdcard/screen.png
Enregistrer une vidéo
La commande screenrecord
est un utilitaire d'interface système qui permet d'enregistrer l'écran des appareils équipés d'Android 4.4 (niveau d'API 19) et versions ultérieures. L'utilitaire enregistre l'activité de l'écran dans un fichier MPEG-4. Vous pouvez utiliser ce fichier pour créer des vidéos promotionnelles ou de formation, ou pour le débogage et le test.
Dans un shell, utilisez la syntaxe suivante :
screenrecord [options] filename
Pour utiliser screenrecord
à partir de la ligne de commande, saisissez la commande suivante :
adb shell screenrecord /sdcard/demo.mp4
Arrêtez l'enregistrement de l'écran en appuyant sur Ctrl+C. Sinon, l'enregistrement
s'arrête automatiquement au bout de trois minutes ou de la limite de temps définie par --time-limit
.
Pour commencer l'enregistrement de l'écran de votre appareil, exécutez la commande screenrecord
pour enregistrer la vidéo. Exécutez ensuite la commande pull
pour télécharger la vidéo depuis l'appareil sur l'ordinateur hôte. Voici un exemple de session d'enregistrement :
$ adb shell shell@ $ screenrecord --verbose /sdcard/demo.mp4 (press Control + C to stop) shell@ $ exit $ adb pull /sdcard/demo.mp4
L'utilitaire screenrecord
peut enregistrer à n'importe quelle résolution et débit binaire compatibles que vous demandez, tout en conservant le format de l'écran de l'appareil. L'utilitaire enregistre par défaut la résolution et l'orientation d'écran natives, avec une durée maximale de trois minutes.
Limites de l'utilitaire screenrecord
:
- L'audio n'est pas enregistré avec le fichier vidéo.
- L'enregistrement vidéo n'est pas disponible pour les appareils équipés de Wear OS.
- Certains appareils risquent de ne pas pouvoir enregistrer avec leur résolution d'écran native. Si vous rencontrez des problèmes avec l'enregistrement de l'écran, essayez une résolution d'écran inférieure.
- La rotation de l'écran pendant l'enregistrement n'est pas disponible. Si l'écran pivote pendant l'enregistrement, une partie de celui-ci est coupée dans l'enregistrement.
Tableau 4. Options screenrecord
Options | Description |
---|---|
--help
|
Afficher la syntaxe de la commande et les options. |
--size widthxheight
|
Définir la taille de la vidéo : 1280x720 . La valeur par défaut est la résolution d'écran native de l'appareil (si compatible), 1 280 x 720 dans le cas contraire. Pour de meilleurs résultats, vous devez utiliser une taille compatible avec l'encodeur AVC (Advanced Video Coding) de l'appareil. |
--bit-rate rate |
Définir le débit de la vidéo, en mégabits par seconde. La valeur par défaut est de 20 Mbit/s.
Vous pouvez augmenter le débit pour améliorer la qualité vidéo, mais en procédant ainsi, vous obtiendrez des fichiers vidéo plus volumineux. L'exemple suivant définit le débit d'enregistrement sur 6 Mbit/s :
screenrecord --bit-rate 6000000 /sdcard/demo.mp4 |
--time-limit time |
Définir la durée d'enregistrement maximale, en secondes. La valeur maximale par défaut est de 180 (3 minutes). |
--rotate |
Faire pivoter la sortie de 90 degrés. Cette fonctionnalité est expérimentale. |
--verbose |
Afficher les informations de journal sur l'écran de ligne de commande. Si vous ne définissez pas cette option, l'utilitaire n'affiche aucune information pendant l'exécution. |
Lire les profils ART pour les applications
À partir d'Android 7.0 (niveau d'API 24), Android Runtime (ART) collecte les profils d'exécution des applications installées, qui sont utilisés pour optimiser les performances des applications. Examinez les profils collectés pour identifier les méthodes qui sont fréquemment exécutées et les classes qui sont utilisées au démarrage de l'application.
Remarque : Pour récupérer le nom de fichier du profil d'exécution, vous devez disposer d'un accès racine au système de fichiers (sur un émulateur, par exemple).
Pour générer le texte des informations de profil, exécutez la commande suivante :
adb shell cmd package dump-profiles package
Pour récupérer le fichier généré, exécutez la commande suivante :
adb pull /data/misc/profman/package.prof.txt
Réinitialiser les appareils de test
Si vous testez votre application sur plusieurs appareils de test, il peut être utile de réinitialiser votre appareil entre les tests, par exemple pour supprimer les données utilisateur et réinitialiser l'environnement de test. Vous pouvez rétablir la configuration d'usine d'un appareil de test équipé d'Android 10 (niveau d'API 29) ou version ultérieure à l'aide de la commande de shell testharness
adb
, comme indiqué ci-dessous :
adb shell cmd testharness enable
Lorsque vous restaurez l'appareil à l'aide de testharness
, il sauvegarde automatiquement la clé RSA qui permet le débogage via la station de travail actuelle dans un emplacement persistant. Autrement dit, une fois l'appareil réinitialisé, la station de travail peut continuer à déboguer et à émettre des commandes adb
vers l'appareil sans avoir à enregistrer manuellement une nouvelle clé.
En outre, afin de continuer à tester votre application de manière plus simple et plus sécurisée, l'utilisation de testharness
pour restaurer un appareil modifie également les paramètres suivants :
- L'appareil configure certains paramètres système de sorte que les assistants de configuration initiale de l'appareil ne s'affichent pas. Autrement dit, l'appareil entre dans un état permettant d'installer, de déboguer et de tester rapidement votre application.
- Paramètres :
- Désactive l'écran de verrouillage
- Désactive les alertes d'urgence
- Désactive la synchronisation automatique des comptes
- Désactive les mises à jour automatiques du système
- Autre :
- Désactive les applications de sécurité préinstallées
Si votre application doit détecter les paramètres par défaut de la commande testharness
et s'y adapter, utilisez ActivityManager.isRunningInUserTestHarness()
.
sqlite
sqlite3
démarre le programme de ligne de commande sqlite
pour examiner les bases de données SQLite.
Il inclut des commandes telles que .dump
pour afficher le contenu d'une table et .schema
pour imprimer l'instruction SQL CREATE
d'une table existante.
Vous pouvez également exécuter des commandes SQLite à partir de la ligne de commande, comme indiqué ci-dessous :
$ adb -s emulator-5554 shell $ sqlite3 /data/data/com.example.app/databases/rssitems.db SQLite version 3.3.12 Enter ".help" for instructions
Remarque : Pour accéder à une base de données SQLite, vous devez disposer d'un accès racine au système de fichiers (sur un émulateur, par exemple).
Pour en savoir plus, consultez la documentation sur la ligne de commande sqlite3
.
Backends USB adb
Le serveur adb peut interagir avec la pile USB via deux backends. Elle peut soit utiliser le format natif
du système d'exploitation (Windows, Linux ou macOS), ou utiliser le backend libusb
.
Certaines fonctionnalités, telles que attach
, detach
et la détection de vitesse USB, sont
n'est disponible que lorsque vous utilisez le backend libusb
.
Vous pouvez choisir un backend à l'aide de la variable d'environnement ADB_LIBUSB
.
Si elle n'est pas définie, adb utilise son backend par défaut. Le comportement par défaut varie selon les systèmes d'exploitation. Démarrage...
avec ADB v34, la
Le backend liubusb
est utilisé par défaut sur tous les systèmes d'exploitation, à l'exception de Windows, où le backend natif est
utilisés par défaut. Si ADB_LIBUSB
correspond à
définie, elle détermine si le backend natif ou libusb
est utilisé. Consultez le
page du manuel adb
pour en savoir plus sur les variables d'environnement adb.
Backends mDNS adb
ADB peut utiliser le protocole DNS de multidiffusion pour connecter automatiquement le serveur et les appareils. Le serveur ADB est fourni avec deux backends, Bonjour (mdnsAnswerer d'Apple) et Openscreen.
Le backend Bonjour nécessite qu'un daemon soit en cours d'exécution sur la machine hôte.
Sous macOS et Linux, l'utilisateur doit s'assurer que le daemon mdnsd
est opérationnel (sous Windows et Linux).
Si la commande adb mdns check
renvoie une erreur, il est probable qu'ADB utilise le backend Bonjour, mais qu'aucun daemon Bonjour n'est en cours d'exécution.
Le backend Openscreen n'a pas besoin d'un daemon pour s'exécuter sur la machine. La prise en charge du backend Openscreen sur macOS commence dans ADB v35. Windows et Linux sont compatibles à partir d'ADB v34.
Par défaut, ADB utilise le backend Bonjour. Vous pouvez modifier ce comportement à l'aide de la variable d'environnement ADB_MDNS_OPENSCREEN
(définie sur 1
ou 0
).
Pour en savoir plus, consultez la page du manuel ADB.