Pour les ingénieurs QA : Comment utiliser Android Debug Bridge dans les tests d'applications mobiles

Bonjour Hackernoon ! Je m'appelle Alexander Karpenko et je travaille comme ingénieur QA chez inDrive . J'ai préparé cet article pour les spécialistes novices en QA. Ci-dessous, je vais vous expliquer comment utiliser Android Debug Bridge (ADB) dans les tests d'applications mobiles et pourquoi il est nécessaire en premier lieu.

J'imagine que vous avez déjà des connaissances de base sur les fondamentaux des tests, je vais donc sauter le processus de préparation et de mise en place de projets.

Les capacités d'ADB sont en constante expansion, mais je partagerai quelques techniques précieuses qui amélioreront votre flux de travail quotidien. Comme mon histoire porte sur les tests d'applications mobiles, je me concentrerai sur macOS, qui vous permet de travailler efficacement avec toutes les plates-formes mobiles populaires. Pour d'autres systèmes d'exploitation, les exemples peuvent être légèrement différents, mais j'espère que les utilisateurs de Windows ne m'en voudront pas.

Pour commencer, abordons les commandes les plus élémentaires pour nous assurer que les derniers points sont présentés dans une séquence logique.

Affichage d'une liste des appareils connectés et connexion à l'appareil

Normalement, nous travaillons avec un seul appareil, mais parfois plusieurs appareils sont connectés, par exemple via TCP/IP. Dans ce cas, nous devons spécifier manuellement l'appareil sur lequel nous voulons exécuter la commande.

Afficher la liste de tous les appareils connectés pour obtenir un identifiant

adb devices — affiche la liste des appareils connectés (l'utilisation du commutateur -l affiche une liste étendue de propriétés). Ceci est utile si plusieurs appareils sont connectés et qu'il n'est pas immédiatement clair de celui dont nous avons besoin.

Pour indiquer à ADB quel appareil cibler, le numéro de série de l'appareil doit être spécifié après le commutateur -s :

adb -s <serial_number> <command> , où <serial_number> est le numéro de série de l'appareil de la liste et <command> est la commande à exécuter sur l'appareil.

Par exemple, installer une application sur un appareil spécifique de la liste :

adb -s 32312b96 install user/download/app.apk

Un autre scénario fréquent est celui où l'opération implique simultanément un dispositif réel et un émulateur, par exemple pour les différents rôles d'exécuteur/initiateur. Dans ce cas, les périphériques se distinguent facilement non pas par leur numéro de série mais sur la base des commutateurs —d —e après la commande adb. Exemple:

adb —d install user/download/app.apk — la commande sera exécutée sur l'appareil réel, avec le commutateur —е sur l'émulateur.

Nous pouvons également nous connecter à l'appareil via TCP/IP lorsqu'il utilise le même réseau Wi-Fi. Pour ce faire, connectez l'appareil au PC avec un câble et changez le mode de fonctionnement de l'appareil de USB à TCP/IP en utilisant la commande :

adb tcpip 5555

Déterminer l'adresse IP de l'appareil par n'importe quelle méthode disponible

Par exemple, via les paramètres du téléphone dans Informations générales ou avec la commande :

adb shell ifconfig wlan0

Si votre appareil est déjà déconnecté du PC à ce stade, assurez-vous de spécifier en plus le S/N de l'appareil. Ensuite, nous nous y connectons :

adb connect ip_address:5555

L'appareil peut être désactivé avec la commande :

adb disconnect ip_address:5555

adb disconnect — pour désactiver tous nos appareils TCP/IP.

Pour revenir en mode USB, utilisez la commande :

adb usb (les minuscules sont importantes).

Installation et désinstallation de l'application et localisation du package sur l'appareil

L'application s'installe à l'aide de la commande :

adb install <apk_path> , où <apk_path> est le chemin absolu vers notre fichier d'application APK.

Voici quelques commutateurs utiles après la commande d'installation qui sont souvent utilisés :

—d — se réinstalle avec une version rétrogradée. Sinon, il y aura un échec (erreur) [INSTALL_FAILED_VERSION_DOWNGRADE] ).

—r — réinstalle l'application avec les données enregistrées.

—g — accorde toutes les autorisations spécifiées dans le manifeste de l'application pendant le processus d'installation.

Par exemple, une application installée avec ce commutateur ne vous demandera pas d'autoriser l'accès à la géolocalisation ou à l'espace de stockage pour télécharger des photos.

L'application est désinstallée en fonction du nom du package. Pour ce faire, vous devez savoir comment l'application est enregistrée dans le système. Utilisez le Shell et le Package Manager (pm).

Exécutez la commande suivante pour afficher la liste de toutes les applications installées :

adb shell pm list packages

La liste peut être filtrée par nom d'application. Vous en aurez besoin si la liste est assez longue, mais nous savons quel mot est contenu dans le nom du paquet :

adb shell pm list packages | grep com.myApp

Vous pouvez également sortir dans un fichier séparé et y trouver le package nécessaire :

adb shell pm list packages > /Users/username/packages.txt

Maintenant que nous savons comment déterminer le nom du package d'application, revenons à la façon de le supprimer de l'appareil. Cela peut être fait en utilisant la commande :

adb uninstall com.myApp

adb uninstall -k com.myApp - supprime l'application mais enregistre les données et les fichiers de cache.

Je vais présenter séparément une commande qui peut souvent s'avérer utile :

adb shell pm clear com.myApp — nettoie le cache et les données de l'application.

Téléchargement du fichier APK depuis l'appareil

Je pense que c'est une situation rare à rencontrer. Mais cela pourrait être utile pour quelqu'un, tout comme cela l'a été pour moi. Toutes les applications installées stockent leurs fichiers APK dans le dossier /data/app. Puisque vous connaissez le nom du package, vous pouvez trouver l'endroit où l'application est installée et télécharger son APK à partir de là. Pour ce faire, exécutez la commande suivante :

adb shell pm path com.myApp — affiche le répertoire d'installation de l'application.

Cela peut ne pas sembler tout à fait présentable :

package:/data/app/~~YcTsnr19yQR6ENa0q2EMag==/com.myApp—IHasf91SDB0erQLagc8j0Q==/base.apk

Mais c'est exactement à cela que nous devons ressembler. Avançons un peu et voyons comment nous pouvons copier le fichier dont nous avons besoin sur le PC à partir du téléphone. Cela peut être fait en utilisant la commande :

adb pull <crazyPath> /Users/username/ , où <crazyPath> est la sortie de notre commande précédente, /Users/username/ est le chemin sur le PC sur lequel vous souhaitez copier notre fichier.

Champs de texte

Parlons brièvement de la vérification des champs de texte. Par exemple, vous devez vérifier la limite du nombre maximum de caractères pouvant être saisis dans un champ de texte. Si vous utilisez un seul appareil, différents ensembles de données transférées peuvent être stockés sur le téléphone ou dans le cloud. Cependant, si le test doit être effectué sur différents appareils, les données de test peuvent être stockées sur le PC et transférées aux appareils via les commandes suivantes :

adb shell input text <text>

Exemple:

adb shell input text test%stest — la chaîne "test test" sera entrée. Remplacez les espaces par les caractères spéciaux %s , sinon seule la partie précédant l'espace sera envoyée à l'appareil. Si nous utilisons des caractères spéciaux comme !@# dans le texte transmis, ils doivent être marqués en insérant une barre oblique inverse ( \ ) devant eux.

Par exemple, la commande :

adb shell input text test\!\@\#\$%stest affichera “test!@#$ test” à l'écran

(ADB ne fonctionne pas avec les caractères cyrilliques et génère une erreur NullPointerException).

Le contenu d'un presse-papiers peut être transféré de cette manière :

adb shell input text $(pbpaste)

Gardez à l'esprit que certains caractères peuvent ne pas être transmis tels qu'ils apparaissent sur le PC. Le problème peut être résolu en utilisant un éditeur de texte en continu (sed). Voici un exemple de commande étendue dans laquelle nous remplaçons tous les espaces du tampon par les caractères spéciaux dont nous avons besoin pour nous assurer que le texte est correctement transféré vers l'appareil :

adb shell input text $(pbpaste | sed -e 's/ /\%s/g')

pbpaste est le texte contenu dans le tampon.

Le commutateur ”—e” vous permet d'exécuter les commandes nécessaires pour éditer le texte.

“s/take this/change_it_to/option” est le modèle (pattern) à utiliser.

/g est le drapeau pour remplacer toutes les correspondances pour un modèle particulier, sans exception.

Liens profonds

Gardons à l'esprit qu'il est préférable que les tests soient effectués dans un environnement aussi proche que possible de la vie réelle, mais il est utile de savoir que cette option est également disponible.

Cette stratégie vous aidera à vérifier les liens profonds vers les écrans nécessaires, lorsque plusieurs écrans sont utilisés, ou si nous avons des problèmes avec l'infrastructure et qu'aucune notification push n'arrive, ou si aucune d'entre elles n'est encore arrivée mais vous devez vérifier comment le l'application se comporte.

Vous pouvez également vérifier si l'application fonctionne correctement et ne plante pas si un lien profond invalide apparaît dans l'alerte de notification push. Ou lorsqu'il s'agit d'une situation où nous suivons un lien profond vers un écran qui n'existe plus, ou dont le statut a changé, ou si nous ne devrions pas avoir accès à cet écran en premier lieu, parce que l'alerte push a été dans le notifications pendant une longue période. Il peut y avoir beaucoup de situations comme celle-ci.

Dans Shell ADB, nous pouvons utiliser le gestionnaire d'activités (AM) pour exécuter des commandes.

Nous commençons notre activité et envoyons le lien profond que nous voulons vérifier. Le lien profond contient généralement le caractère "&", qui sépare les écrans. Par conséquent, lors de l'ouverture via un terminal, une barre oblique inverse (\) doit être insérée devant celui-ci.

adb shell am start -W -a android.intent.action.VIEW -d “myApp://open/client/trip\&last_trip=test” com.myApp

am — appelle le gestionnaire d'activités.

W — en attente de téléchargement avant d'exécuter une commande.

a — détermine l'action à entreprendre. Dans ce cas, c'est action.View .

d — données nécessaires pour l'exécution. Dans ce cas, nous parlons du lien profond lui-même, puis de l'application qui doit être utilisée pour l'ouvrir.

Vous devrez peut-être réinsérer les guillemets manuellement ou les remplacer par des guillemets simples lors du transfert de la commande vers le terminal. S'il y a une erreur de syntaxe, vous pouvez recevoir un message approprié.

Création de captures d'écran et enregistrement de vidéos à partir de l'écran de l'appareil

Utilisez cette commande pour prendre une capture d'écran :

adb shell screencap -p <device_path/screenshot_name.png>

Exemple:

adb shell screencap -p /sdcard/screencap.png — prend une capture d'écran et enregistre un fichier nommé screencap.png sur l'appareil dans le dossier /sdcard/screencap.png .

Vous pouvez enregistrer la capture d'écran sur votre ordinateur comme suit :

adb pull /sdcard/screencap.png — par défaut, le fichier est copié dans le répertoire de l'utilisateur actuel, c'est-à-dire /Users/username/screencap.png .

Ou vous pouvez exécuter la commande entière en une seule fois :

adb shell screencap -p /sdcard/screencap.png && adb pull /sdcard/screencap.png

Dans les dernières versions d'ADB, la commande suivante peut être utilisée pour obtenir une capture d'écran :

adb exec—out screencap —p > screen.png — le fichier de capture d'écran apparaîtra également dans le répertoire de l'utilisateur actuel sur le PC.

Le chemin par défaut peut être modifié manuellement en étant ajouté à la fin de la commande :

adb exec—out screencap -p > downloads/test/screen.png — et la capture d'écran apparaîtra dans le dossier /Users/username/downloads/test/screen.png .

Si vous êtes intéressé, vous pouvez également automatiser un peu ce processus en ajoutant un alias à bash_profile . Dans macOS, vous pouvez utiliser le service Automator pour créer et configurer des raccourcis clavier.

Utilisez cette commande pour enregistrer une vidéo :

adb shell screenrecord device_path .

Exemple:

adb shell screenrecord /sdcard/screenrecord.mp4 - utilisez cette commande pour commencer à enregistrer l'écran de l'appareil en fonction des paramètres par défaut pendant trois minutes et enregistrez le résultat dans le fichier /sdcard/screenrecord.mp4 sur l'appareil.

Vous pouvez spécifier manuellement la durée d'enregistrement à l'aide du commutateur de —time—limit time (en secondes, mais la durée de l'enregistrement est toujours limitée à 180 secondes).

L'enregistrement peut être arrêté à l'avance en appuyant sur CTRL + C

Le fichier peut également être copié à l'aide de la commande pull, d'une manière similaire à la procédure de capture d'écran.

Vous pouvez également consulter les fonctionnalités supplémentaires de cet utilitaire en utilisant le commutateur --help . Incidemment, il est capable de modifier la résolution et le débit d'enregistrement, ainsi que d'ajouter des données supplémentaires pour le rapport de bogue.

Il est utile d'utiliser le commutateur -bugreport , qui ajoute des informations sur le système utilisé pour l'enregistrement en tant que première image de la vidéo.

Maintenant que nous avons expliqué comment télécharger du contenu à partir de l'appareil, concentrons-nous un peu sur la façon de télécharger quelque chose dessus.

Nous l'avons ouvert sur notre PC, ajusté le format et le contenu, effectué un téléchargement sur notre téléphone et vérifié que l'application répondait correctement aux formats inconnus et aux limites de surdimensionnement. Pour télécharger un fichier sur votre téléphone depuis votre PC, vous pouvez utiliser cette commande :

adb push /Users/username/file <device_path>

Exécutons la commande :

adb push /Users/username/screen.png sdcard — ceci copiera notre fichier screen.png sur la carte SD du téléphone.

Vérifier si l'état de l'application a été restauré après sa suppression par le système

Un autre exemple tiré de l'expérience consiste à vérifier si l'état de l'application a été restauré après sa suppression par le système. Réduire l'application, tuer le processus - cette action simule la situation où le système arrête le processus car il n'y a pas assez de mémoire disponible :

adb shell am kill com.myApp

Exécutez-le à nouveau et vérifiez si tout fonctionne correctement.

Nous sommes tombés sur ce scénario : un utilisateur minimise une application alors qu'il est sur un certain écran. Après un certain temps, le système ralentit le processus et met en cache son état. Lorsque l'utilisateur essaie de développer l'application, celle-ci se bloque. Cela se produit lors de l'accès aux données du cache, car les fragments restaurent leur pile et leur état, mais le cache est déjà vide. Malheureusement, ce bogue a été négligé pendant la phase de test, car nous ne l'avions pas rencontré auparavant, et il s'est donc retrouvé en production. Maintenant que vous savez que c'est possible, vous pouvez vous assurer de ne pas répéter nos erreurs.

Journaux

C'est une bonne idée de vérifier les journaux lorsque vous essayez de découvrir ce qui a causé le plantage d'une application. Si vous souhaitez enregistrer le contenu actuel du tampon de journalisation, vous pouvez le faire à l'aide de la commande suivante :

adb logcat — affiche les journaux en temps réel.

adb logcat —d — affiche les informations du journal au moment où la commande est exécutée, sans ajouter d'événements réels sur l'appareil. Il est également possible de sortir le journal dans un fichier séparé en utilisant la commande : adb logcat —d > file.log (le fichier est créé dans le répertoire de l'utilisateur actuel).

Et la commande adb logcat >> file.log écrira le journal directement dans le fichier, en ajoutant tous les événements réels sur l'appareil.

Il existe plusieurs niveaux par ordre croissant de priorité : V — Verbose, D — Debug, I — Info, W — Warn, E — Error, F — Fatal, S — Silent, par exemple :

adb logcat '*:E' — produira des journaux avec des erreurs et un niveau supérieur.

Arrêtons-nous maintenant brièvement sur le formatage et les filtres de sortie. Vous pouvez modifier le format de la sortie vers la console à l'aide du commutateur -v, par exemple :

adb logcat -v time - génère les journaux de manière séquentielle en enregistrant des points de temps.

adb logcat -v color — affiche chaque niveau de journaux dans une couleur différente (ce qui est utile lors de la lecture).

adb logcat -v brief — affiche la priorité du processus, la balise et le PID.

Chaque message de journal a une balise et sa priorité associée. Vous pouvez les utiliser pour réduire la quantité de sortie vers la console :

adb logcat SwrveSDK:I '*:S' — affichera les événements d'analyse que nous envoyons via le service swrve. Le paramètre *:S (-s) indique que la sortie du journal est limitée à l'expression de filtre que nous avons explicitement spécifiée.

Et comme toujours, vous pouvez utiliser l'utilitaire grep pour filtrer la sortie :

adb logcat '*:E' —v color | grep com.myApp

Traditionnellement, pour plus d'informations, vous pouvez toujours vous tourner vers votre assistant adb logcat --help

Voyons maintenant comment l'utiliser

Par exemple, si un bogue se reproduit alors que l'appareil n'est pas connecté, vous pouvez immédiatement le connecter et rediriger le journal vers un fichier.

Pour un débogage plus poussé, avant de collecter les journaux, vous pouvez pré-effacer le tampon du journal avant de reproduire le bogue afin d'éliminer les données superflues. Cela peut être fait via la commande :

adb logcat —c , puis nous reproduisons le bogue et adb logcat —d

Pour ceux qui aiment fouiller dans des piles de journaux, il existe un autre outil à considérer - le rapport de bogue ADB. Cet outil vous permet de créer des archives zip avec des informations de débogage complètes au format texte brut ( .txt ).

adb bugreport /Users/username — crée une archive zip dans le répertoire spécifié.

Copie toutes les informations sur le périphérique, telles que les données dumpstate, dumpsys et logcat dans le dossier spécifié. Par défaut, les rapports d'erreurs sont stockés dans /bugreports et peuvent être consultés via :

adb shell ls /bugreports/

Les informations les plus importantes pour nous sont stockées dans bugreport-BUILD_ID-DATE.txt

Crash Monitoring et ANR (Application Not Responding) est un autre outil intéressant pour travailler avec les plantages. Exécutez-le en utilisant cette commande :

adb shell am monitor , puis nous reproduisons notre plantage. La console affichera des informations sur le plantage sans aucun détail redondant et trois options pour poursuivre nos efforts de surveillance : (c)ontinue: show crash dialog, (k)ill: immediately kill app, (q)uit: finish monitoring .

Émulateurs

Affichage d'une liste des émulateurs configurés :

emulator -list-avds

Pour exécuter l'émulateur, nous avons besoin de :

emulator @avdname

Lorsque vous travaillez avec des émulateurs, il est parfois nécessaire de redémarrer les services, et le serveur doit être réinitialisé une fois l'émulateur démarré, mais assez souvent, une seule commande suffit : adb kill-server . Si cela ne vous aide pas, exécutez l'intégralité du script :

emulator -list-avds — affiche une liste des émulateurs configurés.

adb kill-server — arrête le serveur.

emulator -avd avdname (ou emulator @avdname )— où avdname est le nom de l'émulateur.

adb start—server — redémarre le serveur.

adb devices — affiche la liste des appareils connectés où notre émulateur perdu devrait apparaître.

Pour les plus paresseux d'entre vous, un émulateur peut être créé depuis la ligne de commande. Par exemple, la commande suivante crée un émulateur nommé "test" à l'aide d'une image système x86 avec API 25 :) :

avdmanager create avd —n test —k "system—images;android—25;google_apis;x86"

Si l'image souhaitée n'est pas disponible, vous pouvez la pré-installer avec la commande :

sdkmanager --install "system—images;android—25;google_apis;x86"

sdkmanager --list | grep system—images — affiche une liste des images disponibles au téléchargement

Avec les émulateurs, des problèmes "fantômes" surviennent également parfois pendant le fonctionnement, et une commande fréquemment utilisée qui aide ici consiste à "démarrer à froid" l'émulateur sans extraire l'instantané automatique. L'instantané fait à la sortie sera le suivant :

emulator @avdname —no—snapshot—load

Voici quelques autres commutateurs utiles à prendre en compte lors du démarrage de l'émulateur :

-no-snapshot-save — aucun instantané automatique ne sera enregistré

-no-snapshot — aucun instantané ne sera téléchargé ou enregistré

Si l'émulateur ne fonctionne toujours pas correctement, il peut être effacé en utilisant le commutateur qui ramène l'émulateur à son état d'origine : -wipe-data

La création d'instantanés est une fonctionnalité très utile pour enregistrer les différents états de l'appareil. Manuellement, cela peut être fait via les paramètres de l'émulateur ou en exécutant cette commande :

adb emu avd snapshot save test — enregistre l'état de l'émulateur où test est le nom de l'instantané à stocker sur l'appareil

emulator @avdname —snapshot—list — exécute notre émulateur nommé @avd et affiche la liste des instantanés dans la console

Ensuite, vous pouvez charger un instantané précédemment enregistré à l'aide de cette commande :

adb emu avd snapshot load test — où test est le nom d'un instantané précédemment enregistré

adb emu avd snapshot delete test - supprime l'instantané nommé test

Il est également possible d'exécuter immédiatement l'émulateur avec l'instantané dont nous avons besoin :

emulator @avdname -snapshot test

Vous pouvez également utiliser la commande pull pour obtenir un instantané de l'appareil :

adb emu avd snapshot pull test /Users/username/

Notre émulateur peut être utilisé via la console telnet . Mais vous devez d'abord l'installer. La façon la plus simple de le faire est d'utiliser le gestionnaire de paquets d' brew , si vous l'avez. Si ce n'est pas le cas, il est temps de découvrir ce que c'est et comment l'utiliser. Alors, installez telnet en utilisant la commande : brew install telnet.

Ensuite, lancez notre émulateur, et dans un autre onglet du terminal, connectez-vous à celui-ci avec la commande : telnet localhost port, Exemple :

telnet localhost 5554 — se connecte à notre émulateur qui utilise le port 5554

Après avoir terminé la commande, nous pouvons faire toutes sortes de choses utiles avec notre émulateur, y compris travailler avec geo (par exemple, la commande geo fix 40.748840 -73.984279 définira notre emplacement souhaité aux coordonnées spécifiées), le réseau ou la batterie, alors qu'un la liste complète des commandes peut toujours être trouvée via l'aide.

Par exemple, la même procédure avec les instantanés est quelque peu simplifiée, tandis que les commandes décrites dans la section précédente sont réduites à avd snapshot <command> .

Modification de la résolution sur l'appareil

Le gestionnaire de fenêtres (wm) dispose de quelques commandes utiles pour s'assurer que les éléments sur l'écran de l'appareil s'affichent correctement. Ils vous permettent d'ajuster la résolution de densité de pixels afin que vous puissiez parcourir toutes les options nécessaires pour les tailles d'écran et voir comment notre application s'y adaptera, sans avoir le nombre approprié d'appareils sous la main :

adb shell wm size 1080x1920 — définit la résolution d'écran personnalisée, avec une largeur de 1080 et une hauteur de 1920.

adb shell wm size reset — réinitialise tous nos paramètres modifiés.

adb shell wm density X — modifie la densité de pixels, où la valeur minimale est de 72. Plus la valeur est élevée, plus les éléments à l'écran sont grands.

adb shell wm density reset — réinitialise tous nos paramètres modifiés.

Si nous exécutons nos commandes sans aucun argument, nous récupérerons la résolution d'écran actuelle et la densité de pixels de l'appareil/de l'émulateur connecté.

Singe

Séparément, nous pouvons mentionner le singe - un outil qui génère des événements utilisateur aléatoires sur l'émulateur ou l'appareil, tels que des clics, des tapotements et des gestes, ainsi qu'un certain nombre d'événements au niveau du système qui ressemblent aux mouvements d'un singe idiot. Le singe peut être utilisé pour les tests de résistance.

adb shell monkey — affiche tous les paramètres de Monkey.

Exemple de scénario complet :

adb shell monkey ——throttle 100 ——pct—syskeys 0 —p com.myApp —v 10

La touche --throttle — définit le délai entre les actions en millisecondes. Comme le Monkey effectue toutes les actions rapidement, ce commutateur (touche) est généralement utilisé lorsque nous voulons contrôler visuellement ce qui se passe à l'écran.

La clé --pct-syskeys — définit le pourcentage de boutons système qui seront enfoncés pendant un scénario. Dans cet exemple, il est défini sur 0, ce qui implique qu'aucun bouton système ne sera enfoncé.

Le commutateur -p — le nom du paquet transmis

Le commutateur -v — le nombre d'actions à effectuer

Autorisations d'application

Normalement, les opérations impliquées ici impliquent la révocation des autorisations de l'application, car les autorisations sont généralement accordées via une demande d'application - quelque chose qui peut être fait rapidement et facilement - tandis que la révocation des autorisations se fait via les paramètres système.

adb shell dumpsys package com.MyApp | grep permission — affiche une liste des autorisations d'application disponibles, par exemple, les install permissions — les autorisations obligatoires qui sont accordées lors de l'installation de l'application, runtime permissions — les autorisations qui sont demandées à un moment précis, par exemple, lors de l'accès au stockage de fichiers. Notez que si une autorisation est manquante dans la liste des autorisations demandées, vous ne pourrez pas lui accorder l'accès.

Ainsi, la commande suivante doit être exécutée pour révoquer l'autorisation de notre application :

adb shell pm revoke packageName permissionName , exemple :

adb shell pm revoke com.MyApp android.permission.CAMERA — révoque l'accès de com.myApp à la caméra. Une fois que nous reviendrons à l'application et que nous essaierons d'utiliser la caméra à travers elle, nous verrons une nouvelle demande d'autorisation.

La commande grant donne l'autorisation à l'application, par exemple :

adb shell pm grant com.myApp android.permission.CAMERA — accorde l'accès à l'appareil photo du téléphone pour notre application.

La batterie

Jetons un bref coup d'œil ici à la batterie et au mode veille.

adb shell dumpsys battery - affiche les informations sur la batterie.

adb shell dumpsys battery set level X — définit le niveau de charge de la batterie, où X est le pourcentage de charge.

adb shell dumpsys battery unplug — simule un débranchement de la batterie.

adb shell dumpsys battery reset - réinitialise tous nos paramètres modifiés.

Regardons maintenant les modes de veille. À partir d'Android 6, il existe la fonction connue sous le nom de mode Doze, pour économiser l'énergie de la batterie et prolonger la durée de vie de la batterie en limitant l'activité de l'application après que l'utilisateur n'a pas interagi avec l'appareil pendant un certain temps et lorsque l'appareil n'est pas en charge.

Le système quitte périodiquement le mode Doze pour terminer les tâches d'arrière-plan en attente. App Standby est une autre fonctionnalité Android similaire. Contrairement au mode Doze, il suit l'état d'une application spécifique qui a été inactive pendant un certain temps, puis active le mode veille. Notre travail consiste à nous assurer que l'application récupère normalement après avoir quitté ces deux modes d'économie d'énergie, qu'elle ne plante pas, que les notifications continuent d'arriver, etc.

Pour basculer l'appareil en mode Doze, exécutez les commandes suivantes :

adb shell dumpsys battery unplug — débranche la batterie.

adb shell dumpsys deviceidle step — la commande peut devoir être exécutée plusieurs fois jusqu'à ce que s'affiche : Stepped to deep: IDLE .

Après toutes les routines que nous avons effectuées avec la batterie, il est préférable d'exécuter la commande :

adb shell dumpsys battery reset - qui la ramène à son état d'origine.

Cette commande peut également être utilisée pour forcer l'appareil en mode Doze :

adb shell dumpsys deviceidle force—idle — parfois, avant cela, vous devez exécuter la commande : adb shell dumpsys deviceidle enable.

Vous pouvez le réactiver depuis le mode Doze avec la commande :

adb shell dumpsys deviceidle unforce — et n'oubliez pas de réinitialiser l'état de la batterie :

adb shell dumpsys battery reset .

Maintenant, un peu sur App Standby. Pour déployer l'application dans ce mode, les commandes suivantes doivent être exécutées :

adb shell dumpsys battery unplug — déconnecte la batterie comme dans le cas précédent.

adb shell am set—inactive com.myApp true — déploie l'application en mode App Standby.

Ensuite, sortez notre application du mode App Standby en utilisant cette commande :

adb shell am set—inactive com.myApp false .

Vous pouvez vérifier l'état de l'application en exécutant cette commande :

adb shell am get—inactive com.myApp

Quelques commandes plus utiles à considérer

adb reboot — redémarre l'appareil (pertinent également pour l'appareil réel).

adb shell dumpsys package com.myApp — affiche des informations complètes sur une application spécifique.

adb shell dumpsys meminfo com.myApp - pour vérifier l'utilisation de la mémoire de l'application sur l'appareil, allant de l'espace occupé à l'affichage des bases de données utilisées par cette application, ainsi que le chemin d'accès à celles-ci.

adb shell getprop — affiche une liste des propriétés de périphérique disponibles (fabricant, modèle de périphérique, spécifications matérielles, etc.)

Affichez la liste des activités accessibles pour l'application :

adb shell dumpsys package com.myApp | grep —i Activity .

Affichez le nom de l'activité en cours :

adb shell dumpsys window | grep Focused .

Exécutez l'activité d'application sélectionnée :

adb shell am start —n com.myApp/.ActivityClass - de cette façon, vous pouvez exécuter toutes les applications installées, y compris les applications système. Exemple : adb shell am start -n com.android.settings/.Settings affiche les paramètres de notre téléphone.

Passer un appel au numéro de téléphone spécifié :

adb shell am start —a android.intent.action.CALL tel:+790900000XX .

Ouvrez une page dans votre navigateur Web :

adb shell am start —a android.intent.action.VIEW 'https://indriver.com'

Dernières pensées

Je tiens à souligner qu'il est impossible de regrouper toutes les fonctionnalités d'Android Debug Bridge dans un seul article ou de les étudier en profondeur. Des changements se produisent constamment : ce qui fonctionne aujourd'hui peut soudainement cesser de fonctionner demain, et le besoin de connaître certains outils se fera sentir au fur et à mesure que nous chercherons des solutions à des problèmes spécifiques. Mais je peux dire avec confiance que le matériel que nous avons couvert aujourd'hui est suffisant pour vous permettre de démarrer et de continuer pendant un certain temps.

Bonne chance dans vos efforts et j'espère que vous apprécierez de plonger dans le monde passionnant des tests de logiciels !