Android Debug Bridge (adb)

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 application débogable sur plusieurs appareils distants sans avoir à connecter physiquement votre appareil via USB. Ainsi, vous n'avez plus besoin de résoudre les problèmes de connexion USB courants tels que l'installation du pilote.

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 d'avoir installé la dernière version d'Android Studio. 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 :

  1. Activez les options pour les développeurs sur votre appareil.

  2. 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.

    Menu déroulant "Run configurations" ("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.

    Capture d'écran de la fenêtre pop-up "Pair devices over Wi-Fi" ("Associer des appareils en Wi-Fi")
    Figure 2. Fenêtre pop-up permettant d'associer des appareils à l'aide d'un code QR ou d'un code d'association

  3. Sur votre appareil, appuyez sur Débogage sans fil et associez votre appareil :

    Capture d'écran d'un téléphone Pixel affichant le paramètre système "Wireless debugging" (Débogage sans fil)
    Figure 3. Paramètre Wireless debugging (Débogage sans fil) sur un téléphone Google Pixel

    1. 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.

    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.

      Capture d'écran d'un exemple de saisie de code d'accès
      Figure 4. Exemple de saisie d'un code à six chiffres

  4. 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.

  5. 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.

    Capture d'écran des Blocs Réglages rapides pour les développeurs sur un téléphone Google Pixel.
    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 :

  1. Activez les Options pour les développeurs sur votre appareil, comme décrit précédemment.

  2. Activez le débogage sans fil sur votre appareil, comme décrit précédemment.

  3. Sur votre station de travail, ouvrez une fenêtre de terminal et accédez à android_sdk/platform-tools.

  4. 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.

  5. 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.

  6. Lorsque vous y êtes invité, saisissez le code d'association, comme indiqué ci-dessous.

    Capture d'écran de l'association sur la ligne de commande.
    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

Vous trouverez ci-dessous une liste des problèmes connus concernant le débogage sans fil (avec adb ou Android Studio), ainsi que la procédure à suivre pour 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, peuvent bloquer les connexions p2p et vous empêcher de vous connecter via le Wi-Fi. Essayez de vous connecter avec un câble ou sur un autre réseau Wi-Fi (non professionnel). Une autre option consiste à utiliser une connexion sans fil à l'aide de adb connect ip:port via TCP/IP (après une connexion USB initiale), au cas où vous auriez recours à un réseau autre que celui de l'entreprise.

  • 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: adb s'appuie sur mDNS pour détecter et se connecter automatiquement aux appareils associés. Si la configuration de votre réseau ou de votre appareil n'est pas compatible avec mDNS ou qu'elle l'a désactivé, vous devez vous connecter manuellement à l'appareil à l'aide de adb connect ip:port.

Se connecter sans fil à un appareil après une connexion USB initiale (seule option disponible sur Android 10 et versions antérieures)

Remarque:Ce workflow s'applique également à Android 11 (et versions ultérieures), mais il 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 :

  1. Connectez votre appareil Android et l'ordinateur hôte adb à un réseau Wi-Fi commun.

    2. 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.

  2. Connectez l'appareil à l'ordinateur hôte à l'aide d'un câble USB.
  3. Définissez l'appareil cible pour qu'il écoute une connexion TCP/IP sur le port 5555 : 
    adb tcpip 5555
  4. Débranchez le câble USB de l'appareil cible.
  5. 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.
  6. Connectez-vous à l'appareil à l'aide de son adresse IP : 
    adb connect device_ip_address:5555
  7. Vérifiez que votre ordinateur hôte est connecté à l'appareil cible : 
    $ adb devices
List of devices attached
device_ip_address:5555 device

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 serveur adb. 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 commande devices 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 :

  1. Exécutez la commande devices pour obtenir le numéro de série de la cible.
  2. Une fois celui-ci en votre possession, utilisez l'option -s avec les commandes adb pour spécifier le numéro de série.
    1. 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.
    2. Si vous utilisez à la fois -s et $ANDROID_SERIAL, -s remplace $ANDROID_SERIAL.

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 l'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 est utile si vous téléchargez tous les APK pour un appareil spécifique de votre application depuis la Play Console et que vous souhaitez les installer sur un é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, adb shell setprop key 'two words' est désormais une erreur, car les guillemets sont avalés par le shell local, et l'appareil voit adb shell setprop key two words. 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). Par exemple, adb shell setprop key "'two words'" fonctionne, car l'interface système locale utilise le niveau externe des guillemets, et l'appareil voit toujours le niveau interne des guillemets: setprop key 'two words'. L'échappement est également une option, mais il est généralement plus facile de mettre des guillemets deux fois.

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 :

  • -D : activer le débogage.
  • -W : attendre la fin du lancement.
  • --start-profiler file : démarrer le profileur et envoyer les résultats à file.
  • -P file : comme --start-profiler, mais le profilage s'arrête lorsque l'application devient inactive.
  • -R count : répéter le lancement de l'activité un certain nombre de fois, défini par count. Avant chaque répétition, l'activité principale est terminée.
  • -S : forcer l'arrêt de l'application cible avant de démarrer l'activité.
  • --opengl-trace : activer le traçage des fonctions OpenGL.
  • --user user_id | current : spécifier sous quel utilisateur exécuter. Si non spécifié, exécuter en tant qu'utilisateur actuel.
startservice [options] intent Démarrer le Service spécifié par intent.

Consultez Spécification pour les arguments d'intent.

Les options sont les suivantes :

  • --user user_id | current : spécifier sous quel utilisateur exécuter. Si non spécifié, exécuter en tant qu'utilisateur actuel.
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 :

  • --user user_id | all | current : spécifie l'utilisateur dont les processus doivent être arrêtés. Si ce paramètre n'est pas spécifié, arrête les processus de tous les utilisateurs.
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 :

  • [--user user_id | all | current] : spécifier à quel utilisateur envoyer. Si non spécifié, envoyer à tous les utilisateurs.
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 :

  • -r : afficher les résultats bruts (sinon, décoder report_key_streamresult). Utiliser avec [-e perf true] pour générer une sortie brute et mesurer les performances.
  • -e name value : définir l'argument name sur value. Pour les testeurs, la forme courante est -e testrunner_flag value[,value...].
  • -p file : écrire les données de profilage dans file.
  • -w : attendre la fin de l'instrumentation avant de renvoyer. Obligatoire pour les testeurs.
  • --no-window-animation : désactiver les animations de fenêtre pendant l'exécution.
  • --user user_id | current : spécifier pour quel utilisateur l'instrumentation s'exécute. Utilisateur actuel si non spécifié.
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 :

  • --user [user_id | current] : lorsqu'un nom de processus est fourni, spécifier l'utilisateur du processus à vider. Utiliser l'utilisateur actuel si non spécifié.
  • -b [| png | jpg | webp]: vidage des bitmaps à partir de la mémoire graphique (niveau d'API 35 ou version ultérieure). Vous pouvez spécifier le format de vidage (PNG par défaut).
  • -n : vider le tas de mémoire natif au lieu du tas de mémoire géré.
set-debug-app [options] package Configurer le package d'application à déboguer.

Les options sont les suivantes :

  • -w : attendre le débogueur au démarrage de l'application.
  • --persistent : conserver cette valeur.
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 :

  • --gdb : lancer gdbserv sur le port donné en cas de plantage/d'ANR.
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 :
am display-size 1280x800
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 :
am display-density 480
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 :

  • -f : consulter le fichier associé.
  • -d : filtrer pour n'afficher que les packages désactivés.
  • -e : filtrer pour n'afficher que les packages activés.
  • -s : filtrer pour n'afficher que les packages système.
  • -3 : filtrer pour n'afficher que les packages tiers.
  • -i : consulter le programme d'installation des packages.
  • -u : inclure les packages désinstallés.
  • --user user_id : espace utilisateur à interroger.
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 :

  • -g : organiser par groupe.
  • -f : afficher toutes les informations.
  • -s : court résumé.
  • -d : ne lister que les autorisations dangereuses.
  • -u : lister uniquement les autorisations qui seront présentées aux utilisateurs.
list instrumentation [options] Lister tous les packages de test.

Options :

  • -f : lister le fichier APK du package de test.
  • target_package : lister les packages de test uniquement pour cette application.
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 :

  • -r : réinstaller une application existante en conservant ses données.
  • -t : autoriser l'installation des APK de test. Gradle génère un APK de test lorsque vous avez uniquement exécuté ou débogué votre application, ou lorsque vous avez utilisé la commande Build > Build APK (Compiler > Compiler un APK) d'Android Studio. Si l'APK est compilé à l'aide d'un SDK de preview développeur, vous devez inclure l'option -t avec la commande install si vous installez un APK de test.
  • -i installer_package_name : spécifier le nom de package du programme d'installation.
  • --install-location location : définir l'emplacement d'installation à l'aide de l'une des valeurs suivantes :
    • 0 : utiliser l'emplacement d'installation par défaut.
    • 1 : installer sur l'espace de stockage interne de l'appareil.
    • 2 : installer sur un support externe.
  • -f : installer le package dans la mémoire système interne.
  • -d : autoriser le retour à une version antérieure du code de version.
  • -g : accorder toutes les autorisations listées dans le fichier manifeste d'application.
  • --fastdeploy : mettre à jour rapidement un package installé en ne mettant à jour que les parties de l'APK qui ont été modifiées.
  • --incremental : installe suffisamment de l'APK pour lancer l'application tout en diffusant les données restantes en arrière-plan. Pour utiliser cette fonctionnalité, vous devez signer l'APK, créer un fichier APK Signature Scheme v4 et placer ce fichier dans le même répertoire que l'APK. Elle n'est disponible que sur certains appareils. Cette option force adb à utiliser la fonctionnalité ou échoue si elle n'est pas compatible (avec des informations détaillées sur la raison de son échec). Ajoutez l'option --wait pour attendre que l'APK soit entièrement installé avant d'accorder l'accès à l'APK.

    --no-incremental empêche adb d'utiliser cette fonctionnalité.

uninstall [options] package Supprimer un package du système.

Options :

  • -k : conserver les répertoires de données et de cache après la suppression du package.
  • --user user_id : spécifie l'utilisateur pour lequel le package est supprimé.
  • --versionCode version_code : procède à la désinstallation uniquement si l'application dispose du code de version indiqué.
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 :

  • --user user_id : l'utilisateur à désactiver.
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 :
  • 0 : Automatique : laisser le système décider du meilleur emplacement.
  • 1 : Interne : installer sur l'espace de stockage interne de l'appareil.
  • 2 : Externe : installer sur un support externe.

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 :
  • 0 [auto] : laisser le système décider du meilleur emplacement.
  • 1 [internal] : installer sur l'espace de stockage interne de l'appareil.
  • 2 [external] : installer sur un support externe.
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 :

  • none : rien n'a été enregistré pour ce domaine
  • verified : le domaine a bien été vérifié
  • approved : forçage approuvé, généralement via le shell
  • denied : forçage refusé, généralement via le shell
  • migrated : vérification conservée d'une ancienne réponse
  • restored : vérification conservée d'une restauration des données utilisateur
  • legacy_failure : refusé par un ancien vérificateur, raison inconnue
  • system_configured : approuvé automatiquement par la configuration de l'appareil
  • >= 1024 : code d'erreur personnalisé spécifique au vérificateur d'appareil

Les options sont les suivantes :

  • --user user_id: inclure les sélections des utilisateurs. Incluez tous les domaines, pas seulement les domaines autoVerify.
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é.

  • package : le package à réinitialiser ou "all" pour réinitialiser tous les packages.

Les options sont les suivantes :

  • --user user_id: inclure les sélections des utilisateurs. Inclure tous les domaines, pas seulement les domaines autoVerify.
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.

  • --re-verify : envoyer même si le package a enregistré une réponse.
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.

  • --package package : le package à définir ou "all" pour définir tous les packages.
  • state : le code pour définir les domaines. Les valeurs valides sont les suivantes :
    • STATE_NO_RESPONSE (0) : réinitialiser comme si aucune réponse n'avait jamais été enregistrée.
    • STATE_SUCCESS (1) : traiter le domaine comme ayant été validé par l'agent de validation du domaine. Notez que l'agent de validation du domaine peut remplacer cette commande.
    • STATE_APPROVED (2) : traiter le domaine comme toujours approuvé, ce qui empêche l'agent de validation du domaine de le modifier.
    • STATE_DENIED (3) : traiter le domaine comme toujours refusé, ce qui empêche l'agent de validation du domaine de le modifier.
  • domains : liste des domaines à modifier séparés par des espaces ou "all" pour modifier chaque domaine.
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.

  • --user user_id : l'utilisateur pour lequel modifier les sélections.
  • --package package : le package à définir.
  • enabled : approuver le domaine.
  • domains : liste des domaines à modifier séparés par des espaces ou "all" pour modifier chaque domaine.
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.

  • --user user_id : l'utilisateur pour lequel modifier les sélections.
  • --package package : le package à définir.
  • enabled : approuver le domaine.
  • domains : liste des domaines à modifier séparés par des espaces ou "all" pour modifier chaque domaine.
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.

  • --user user_id : l'utilisateur pour lequel modifier les sélections.
  • --package package : le package à définir ou "all" pour définir tous les packages. Les packages seront réinitialisés si aucun package n'est spécifié.
  • allowed : "true" pour permettre au package d'ouvrir les liens validés automatiquement, "false" pour désactiver.
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é.

  • --user user_id : l'utilisateur à interroger.
  • --package package : éventuellement afficher également tous les domaines Web déclarés par un package ou "all" pour afficher tous les packages.
  • domains : liste des domaines à interroger, séparés par des espaces.

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 :

  • --user user_id : spécifier l'utilisateur cible. Vous pouvez également transmettre --user current pour sélectionner l'utilisateur actuel.
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 :

  • --user user_id : spécifier l'utilisateur cible. Vous pouvez également transmettre --user current pour sélectionner l'utilisateur actuel.
  • --name name : indiquer le nom lisible de l'organisation.
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 :

  • --user user_id : spécifier l'utilisateur cible. Vous pouvez également transmettre --user current pour sélectionner l'utilisateur actuel.
  • --name name : indiquer le nom lisible de l'organisation.
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 :

  • --user user_id : spécifier l'utilisateur cible. Vous pouvez également transmettre --user current pour sélectionner l'utilisateur actuel.
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 d'écran en appuyant sur Ctrl+C. Sinon, l'enregistrement s'arrête automatiquement au bout de trois minutes ou une fois que la limite de temps définie par --time-limit s'est écoulée.

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. Il peut utiliser le backend natif de l'OS (Windows, Linux ou macOS) ou le backend libusb. Certaines fonctionnalités, telles que attach, detach et la détection de la vitesse USB, ne sont disponibles 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. À partir de la version ADB v34, 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é par défaut. Si ADB_LIBUSB est défini, il détermine si le backend natif ou libusb est utilisé. Pour en savoir plus sur les variables d'environnement adb, consultez la page du manuel adb.

Backends mDNS adb

ADB peut utiliser le protocole DNS multicast pour connecter automatiquement le serveur et les appareils. Le serveur ADB est fourni avec deux backends, Bonjour (mdnsResponder d'Apple) et Openscreen.

Le backend Bonjour nécessite un daemon en cours d'exécution sur la machine hôte. Sous macOS, le daemon intégré d'Apple est toujours en cours d'exécution, mais sous Windows et Linux, l'utilisateur doit s'assurer que le daemon mdnsd est opérationnel. 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 en cours d'exécution 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. Ce comportement peut être modifié à 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 d'ADB.