¡Hola, Hackeroon! Mi nombre es Alexander Karpenko y trabajo como ingeniero de control de calidad en inDrive . He preparado este artículo para especialistas novatos en control de calidad. A continuación, le diré cómo usar Android Debug Bridge (ADB) en las pruebas de aplicaciones móviles y por qué es necesario en primer lugar.
Me imagino que ya tiene conocimientos básicos sobre los fundamentos de las pruebas, por lo que me saltaré el proceso de preparación y configuración de proyectos.
Las capacidades de ADB se expanden constantemente, pero compartiré algunas técnicas valiosas que mejorarán su flujo de trabajo diario. Dado que mi historia trata sobre las pruebas de aplicaciones móviles, me centraré en macOS, que le permite trabajar de forma eficaz con todas las plataformas móviles populares. Para otros sistemas operativos, los ejemplos pueden ser ligeramente diferentes, pero con suerte, los usuarios de Windows no me reprocharán esto.
Para empezar, veamos los comandos más básicos para asegurarnos de que los puntos posteriores se presenten en una secuencia lógica.
Normalmente, trabajamos con un dispositivo, pero a veces se conectan varios dispositivos, por ejemplo, a través de TCP/IP. En este caso, tenemos que especificar manualmente el dispositivo en el que queremos ejecutar el comando.
adb devices
: muestra la lista de dispositivos conectados (usando el -l
se abre una lista extendida de propiedades). Esto es útil si hay varios dispositivos conectados y no está claro de inmediato cuál necesitamos.
Para decirle a ADB a qué dispositivo apuntar, el número de serie del dispositivo debe especificarse después del interruptor -s
:
adb -s <serial_number> <command>
, donde <serial_number>
es el número de serie del dispositivo de la lista y <command>
es el comando a ejecutar en el dispositivo.
Por ejemplo, instalar una aplicación en un dispositivo específico de la lista:
adb -s 32312b96 install user/download/app.apk
Otro escenario frecuente es cuando la operación involucra simultáneamente un dispositivo real y un emulador, por ejemplo, para los diferentes roles de ejecutor/iniciador. En este caso, los dispositivos se distinguen fácilmente no por su número de serie sino por los interruptores —d —e
después del comando adb. Ejemplo:
adb —d install user/download/app.apk
— el comando se ejecutará en el dispositivo real, con el interruptor —е
en el emulador.
También podemos conectarnos al dispositivo a través de TCP/IP cuando utiliza la misma red Wi-Fi. Para hacer esto, conecte el dispositivo a la PC con un cable y cambie el modo de funcionamiento en el dispositivo de USB a TCP/IP usando el comando:
adb tcpip 5555
Por ejemplo, a través de la configuración del teléfono en Información general o con el comando:
adb shell ifconfig wlan0
Si su dispositivo ya está desconectado de la PC en este punto, asegúrese de especificar adicionalmente el S/N del dispositivo. A continuación, nos conectamos a él:
adb connect ip_address:5555
El dispositivo se puede desactivar con el comando:
adb disconnect ip_address:5555
adb disconnect
: para deshabilitar todos nuestros dispositivos TCP/IP.
Para volver al modo USB, use el comando:
adb usb
(las minúsculas son importantes).
La aplicación se instala usando el comando:
adb install <apk_path>
, donde <apk_path>
es la ruta absoluta a nuestro archivo de aplicación APK.
Aquí hay algunos interruptores útiles después del comando de instalación que se usan a menudo:
—d
— reinstala con una versión degradada. De lo contrario, habrá una falla (error) [INSTALL_FAILED_VERSION_DOWNGRADE]
).
—r
— reinstala la aplicación con los datos guardados.
—g
— otorga todos los permisos especificados en el manifiesto de la aplicación durante el proceso de instalación.
Por ejemplo, una aplicación instalada con este interruptor no le pedirá que permita el acceso a la geolocalización o al espacio de almacenamiento para descargar fotos.
La aplicación se desinstala según el nombre del paquete. Para hacer esto, necesita saber cómo está registrada la aplicación en el sistema. Use Shell y Package Manager (pm).
Ejecute el siguiente comando para mostrar la lista de todas las aplicaciones instaladas:
adb shell pm list packages
La lista se puede filtrar por nombre de aplicación. Necesitará esto si la lista es bastante grande, pero sabemos qué palabra está contenida en el nombre del paquete:
adb shell pm list packages | grep com.myApp
También puede enviar a un archivo separado y encontrar el paquete necesario allí:
adb shell pm list packages > /Users/username/packages.txt
Ahora que sabemos cómo averiguar el nombre del paquete de la aplicación, volvamos a cómo eliminarlo del dispositivo. Esto se puede hacer usando el comando:
adb uninstall com.myApp
adb uninstall -k com.myApp
: elimina la aplicación pero guarda los datos y los archivos de caché.
Presentaré por separado un comando que a menudo puede resultar útil:
adb shell pm clear com.myApp
: limpia el caché y los datos de la aplicación.
Creo que esta es una situación rara de encontrar. Pero esto podría ser útil para alguien, tal como lo fue para mí. Todas las aplicaciones instaladas almacenan sus archivos APK en la carpeta /data/app. Como conoce el nombre del paquete, puede encontrar el lugar donde está instalada la aplicación y descargar su APK desde allí. Para hacer esto, ejecute el siguiente comando:
adb shell pm path com.myApp
: muestra el directorio de instalación de la aplicación.
Esto puede no parecer tan presentable:
package:/data/app/~~YcTsnr19yQR6ENa0q2EMag==/com.myApp—IHasf91SDB0erQLagc8j0Q==/base.apk
Pero así es exactamente como necesitamos que se vea este camino. Avancemos un poco y veamos cómo podemos copiar el archivo que necesitamos a la PC desde el teléfono. Esto se puede hacer usando el comando:
adb pull <crazyPath> /Users/username/
, donde <crazyPath>
es el resultado de nuestro comando anterior, /Users/username/
es la ruta en la PC donde desea copiar nuestro archivo.
Hablemos brevemente sobre la verificación de campos de texto. Por ejemplo, debe verificar el límite de la cantidad máxima de caracteres que se pueden ingresar en un campo de texto. Si usa un solo dispositivo, se pueden almacenar diferentes conjuntos de datos transferidos en el teléfono o en la nube. Sin embargo, si la prueba debe realizarse en diferentes dispositivos, los datos de la prueba pueden almacenarse en la PC y transferirse a los dispositivos a través de los siguientes comandos:
adb shell input text <text>
Ejemplo:
adb shell input text test%stest
: se ingresará la cadena "test test". Reemplace los espacios con los caracteres especiales %s
, de lo contrario, solo se enviará al dispositivo la parte que precede al espacio. Si usamos caracteres especiales como !@#
en el texto que se transmite, deben marcarse insertando una barra invertida ( \
) delante de ellos.
Por ejemplo, el comando:
adb shell input text test\!\@\#\$%stest
mostrará “test!@#$ test”
en pantalla
(ADB no funciona con caracteres cirílicos y genera un error NullPointerException).
El contenido de un portapapeles se puede transferir de esta manera:
adb shell input text $(pbpaste)
Tenga en cuenta que es posible que algunos caracteres no se transmitan tal como aparecen en la PC. El problema se puede resolver utilizando un editor de texto de transmisión (sed). Aquí hay un ejemplo de un comando extendido donde reemplazamos todos los espacios en el búfer con los caracteres especiales que necesitamos para asegurarnos de que el texto se transfiera al dispositivo de la manera correcta:
adb shell input text $(pbpaste | sed -e 's/ /\%s/g')
pbpaste
es el texto que está contenido en el búfer.
El interruptor ”—e”
le permite ejecutar los comandos necesarios para editar texto.
“s/take this/change_it_to/option”
es la plantilla (patrón) a usar.
/g
es el indicador para reemplazar todas las coincidencias de una plantilla en particular, sin excepción.
Tengamos en cuenta que es mejor cuando la prueba se realiza en un entorno lo más parecido posible a la vida real, pero es útil saber que esta opción también está disponible.
Esta estrategia lo ayudará a verificar los enlaces profundos a las pantallas necesarias, cuando se usan varias pantallas, o si tenemos problemas con la infraestructura y no llegan las notificaciones automáticas, o si ninguna de ellas ha llegado todavía pero necesita verificar cómo el se comporta la aplicación.
También puede verificar si la aplicación funciona correctamente y no se bloquea si aparece un enlace profundo no válido en la alerta de notificación automática. O cuando se trata de una situación en la que seguimos un enlace profundo a una pantalla que ya no existe, o cuyo estado ha cambiado, o si no deberíamos tener acceso a esa pantalla en primer lugar, porque la alerta de inserción ha estado en el notificaciones durante mucho tiempo. Puede haber muchas situaciones como esta.
En Shell ADB, podemos usar el Administrador de actividades (AM) para ejecutar comandos.
Iniciamos nuestra actividad y enviamos el enlace profundo que queremos consultar. El enlace profundo suele contener el carácter “&”, que separa las pantallas. Por lo tanto, al abrir a través de una terminal, se debe insertar una barra invertida (\) delante de ella.
adb shell am start -W -a android.intent.action.VIEW -d “myApp://open/client/trip\&last_trip=test” com.myApp
am
: abre el Administrador de actividades.
W
: esperando la descarga antes de ejecutar un comando.
a
— determina qué acción se debe tomar. En este caso, es action.View .
d
: datos necesarios para la ejecución. En este caso, estamos hablando del enlace profundo en sí y luego de la aplicación que debe usarse para abrirlo.
Es posible que deba volver a insertar las comillas manualmente o reemplazarlas con comillas simples al transferir el comando al terminal. Si hay un error de sintaxis, puede recibir un mensaje apropiado.
Use este comando para tomar una captura de pantalla:
adb shell screencap -p <device_path/screenshot_name.png>
Ejemplo:
adb shell screencap -p /sdcard/screencap.png
: toma una captura de pantalla y guarda un archivo llamado screencap.png
en el dispositivo en la carpeta /sdcard/screencap.png
.
Puede guardar la captura de pantalla en su computadora de la siguiente manera:
adb pull /sdcard/screencap.png
: de forma predeterminada, el archivo se copia en el directorio del usuario actual, es decir, /Users/username/screencap.png
.
O puede ejecutar todo el comando a la vez:
adb shell screencap -p /sdcard/screencap.png && adb pull /sdcard/screencap.png
En las últimas versiones de ADB, se puede usar el siguiente comando para obtener una captura de pantalla:
adb exec—out screencap —p > screen.png
— el archivo de captura de pantalla también aparecerá en el directorio del usuario actual en la PC.
La ruta predeterminada se puede cambiar manualmente al agregarla al final del comando:
adb exec—out screencap -p > downloads/test/screen.png
— y la captura de pantalla aparecerá en la carpeta /Users/username/downloads/test/screen.png
.
Si está interesado, también puede automatizar un poco este proceso agregando un alias a bash_profile
. En macOS, puede usar Automator Service para crear y configurar teclas de acceso rápido.
Use este comando para grabar un video:
adb shell screenrecord device_path
.
Ejemplo:
adb shell screenrecord /sdcard/screenrecord.mp4
: use este comando para comenzar a grabar la pantalla del dispositivo según la configuración predeterminada durante tres minutos y guarde el resultado en el archivo /sdcard/screenrecord.mp4
en el dispositivo.
Puede especificar manualmente el tiempo de grabación usando el interruptor —time—limit time
—time— (en segundos, pero la duración de la grabación todavía está limitada a 180 segundos).
La grabación se puede detener antes de tiempo presionando CTRL + C
El archivo también se puede copiar utilizando el comando de extracción, de forma similar al procedimiento de captura de pantalla.
También puede consultar las funciones adicionales de esta utilidad utilizando el --help
. Por cierto, puede cambiar la resolución de grabación y la tasa de bits, así como agregar datos adicionales para el informe de errores.
Es útil usar el -bugreport
, que agrega información sobre el sistema utilizado para la grabación como el primer cuadro del video.
Ahora que hemos cubierto cómo descargar contenido del dispositivo, centrémonos un poco en cómo cargar algo en él.
Lo abrimos en nuestra PC, ajustamos el formato y el contenido, hicimos una descarga a nuestro teléfono y verificamos que la aplicación responda correctamente a formatos desconocidos y límites de tamaño excesivo. Para cargar un archivo a su teléfono desde su PC, puede usar este comando:
adb push /Users/username/file <device_path>
Ejecutemos el comando:
adb push /Users/username/screen.png sdcard
: esto copiará nuestro archivo screen.png
en la tarjeta SD del teléfono.
Otro ejemplo de la experiencia tiene que ver con verificar si el estado de la aplicación se restableció después de que el sistema la eliminó. Contraer la aplicación, eliminar el proceso: esta acción simula la situación en la que el sistema detiene el proceso porque no hay suficiente memoria disponible:
adb shell am kill com.myApp
Vuelva a ejecutarlo y compruebe si todo funciona bien.
Nos encontramos con este escenario: un usuario minimiza una aplicación mientras está en una pantalla determinada. Después de un tiempo, el sistema ralentiza el proceso y almacena en caché su estado. Cuando el usuario intenta expandir la aplicación, se bloquea. Esto sucede cuando se accede a los datos del caché, porque los fragmentos están restaurando su pila y estado, pero el caché ya está vacío. Desafortunadamente, este error se pasó por alto durante la fase de prueba, porque no lo habíamos encontrado antes, por lo que terminó en producción. Ahora que sabes que es posible, puedes asegurarte de no repetir nuestros errores.
Es una buena idea consultar los registros cuando se trata de averiguar qué provocó el bloqueo de una aplicación. Si desea guardar el contenido del búfer de registro actual, puede hacerlo con el siguiente comando:
adb logcat
: muestra los registros en tiempo real.
adb logcat —d
— muestra información de registro en el momento en que se ejecuta el comando, sin agregar eventos reales en el dispositivo. También es posible enviar el registro a un archivo separado usando el comando: adb logcat —d > file.log
(el archivo se crea en el directorio del usuario actual).
Y el comando adb logcat >> file.log
escribirá el registro directamente en el archivo, agregando todos los eventos reales en el dispositivo.
Hay varios niveles en orden ascendente de prioridad: V — Verbose, D — Debug, I — Info, W — Warn, E — Error, F — Fatal, S — Silent, por ejemplo:
adb logcat '*:E'
: generará registros con errores y un nivel superior.
Ahora detengámonos brevemente en el formato de salida y los filtros. Puede cambiar el formato de la salida a la consola usando el modificador -v, por ejemplo:
adb logcat -v time
: genera registros secuencialmente mediante la grabación de puntos de tiempo.
adb logcat -v color
: muestra cada nivel de registros en un color diferente (lo cual es útil al leer).
adb logcat -v brief
: muestra la prioridad, la etiqueta y el PID del proceso.
Cada mensaje de registro tiene una etiqueta y su prioridad relacionada. Puede usarlos para reducir la cantidad de salida a la consola:
adb logcat SwrveSDK:I '*:S'
: mostrará los eventos analíticos que enviamos a través del servicio swrve. El parámetro *:S (-s)
indica que la salida del registro está limitada a la expresión de filtro que especificamos explícitamente.
Y como siempre, puede usar la utilidad grep para filtrar la salida:
adb logcat '*:E' —v color | grep com.myApp
Tradicionalmente, para obtener más información, siempre puede dirigirse a su asistente adb logcat --help
Por ejemplo, si se reproduce un error mientras el dispositivo no está conectado, puede conectarlo inmediatamente y redirigir el registro a un archivo.
Para una mayor depuración, antes de recopilar registros, puede borrar previamente el búfer de registro antes de reproducir el error para eliminar los datos superfluos. Esto se puede hacer a través del comando:
adb logcat —c
, luego reproducimos el error y ejecutamos adb logcat —d
Para aquellos a los que les gusta cavar a través de montones de troncos, hay otra herramienta a considerar: ADB bugreport. Esta herramienta le permite crear archivos zip con información de depuración completa en formato de texto sin formato ( .txt
).
adb bugreport /Users/username
: crea un archivo zip en el directorio especificado.
Copia toda la información sobre el dispositivo, como datos de dumpstate, dumpsys y logcat en la carpeta especificada. De forma predeterminada, los informes de errores se almacenan en /bugreports y se pueden ver a través de:
adb shell ls /bugreports/
La información más importante para nosotros se almacena en bugreport-BUILD_ID-DATE.txt
Crash Monitoring and ANR (Application Not Responding) es otra herramienta interesante para trabajar con bloqueos. Ejecútelo usando este comando:
adb shell am monitor
, y luego reproducimos nuestro bloqueo. La consola mostrará información sobre el bloqueo sin detalles redundantes y tres opciones para continuar con nuestros esfuerzos de monitoreo: (c)ontinue: show crash dialog, (k)ill: immediately kill app, (q)uit: finish monitoring
.
Mostrando una lista de emuladores configurados:
emulator -list-avds
Ejecutando el emulador necesitamos:
emulator @avdname
Cuando se trabaja con emuladores, a veces es necesario reiniciar los servicios y el servidor debe reiniciarse una vez que se inicia el emulador, pero con bastante frecuencia, incluso un comando es suficiente: adb kill-server
. Si esto no ayuda, ejecute el script completo:
emulator -list-avds
: muestra una lista de emuladores configurados.
adb kill-server
: detiene el servidor.
emulator -avd avdname
(o emulator @avdname
)— donde avdname
es el nombre del emulador.
adb start—server
— reinicia el servidor.
adb devices
: muestra la lista de dispositivos conectados donde debería aparecer nuestro emulador perdido.
Para los más vagos, se puede crear un emulador desde la línea de comandos. Por ejemplo, el siguiente comando crea un emulador llamado "prueba" utilizando una imagen del sistema x86 con API 25 :)
avdmanager create avd —n test —k "system—images;android—25;google_apis;x86"
Si la imagen deseada no está disponible, puede preinstalarla con el comando:
sdkmanager --install "system—images;android—25;google_apis;x86"
sdkmanager --list | grep system—images
— muestra una lista de imágenes disponibles para descargar
Con los emuladores, a veces también ocurren problemas "fantasmas" durante la operación, y un comando de uso frecuente que ayuda aquí es "arrancar en frío" el emulador sin abrir la instantánea automática. La instantánea realizada a la salida será la siguiente:
emulator @avdname —no—snapshot—load
Aquí hay algunos cambios más útiles para considerar al iniciar el emulador:
-no-snapshot-save
— no se guardará ninguna instantánea automática
-no-snapshot
— no se descargará ni guardará ninguna instantánea
Si el emulador aún no funciona correctamente, se puede borrar usando el interruptor que devuelve el emulador a su estado original: -wipe-data
La creación de instantáneas es una característica muy útil para guardar los diferentes estados del dispositivo. Manualmente, esto se puede hacer a través de la configuración del emulador o ejecutando este comando:
adb emu avd snapshot save test
: guarda el estado del emulador donde test es el nombre de la instantánea que se almacenará en el dispositivo
emulator @avdname —snapshot—list
— ejecuta nuestro emulador llamado @avd y muestra la lista de instantáneas en la consola
A continuación, puede cargar una instantánea guardada previamente con este comando:
adb emu avd snapshot load test
— donde test es el nombre de una instantánea guardada previamente
adb emu avd snapshot delete test
— elimina la instantánea llamada test
También es posible ejecutar inmediatamente el emulador con la instantánea que necesitamos:
emulator @avdname -snapshot test
También puede usar el comando pull
para obtener una instantánea del dispositivo:
adb emu avd snapshot pull test /Users/username/
Nuestro emulador se puede operar a través de la consola telnet
. Pero primero tienes que instalarlo. La forma más fácil de hacerlo es a través del administrador de paquetes brew
, si lo tiene. Si no, entonces es hora de averiguar qué es y cómo usarlo. Entonces, instale telnet
usando el comando: brew install telnet.
A continuación, ejecute nuestro emulador y, en otra pestaña de la terminal, conéctese con el comando: telnet localhost port,
Ejemplo:
telnet localhost 5554
: se conecta a nuestro emulador que usa el puerto 5554
Después de completar el comando, podemos hacer todo tipo de cosas útiles con nuestro emulador, incluido trabajar con geo (por ejemplo, el comando geo fix 40.748840 -73.984279
establecerá nuestra ubicación deseada en las coordenadas especificadas), la red o la batería, mientras que un La lista completa de comandos, como siempre, se puede encontrar a través de la ayuda.
Por ejemplo, el mismo procedimiento con instantáneas se simplifica un poco, mientras que los comandos descritos en la sección anterior se reducen a avd snapshot <command>
.
El administrador de ventanas (wm) tiene algunos comandos útiles para asegurarse de que los elementos en la pantalla del dispositivo se muestren correctamente. Te permiten ajustar la resolución de la densidad de píxeles para que puedas pasar por todas las opciones necesarias para los tamaños de pantalla y ver cómo nuestra aplicación se adaptará a ellos, sin tener a mano la cantidad adecuada de dispositivos:
adb shell wm size 1080x1920
: establece la resolución de pantalla personalizada, con un ancho de 1080 y una altura de 1920.
adb shell wm size reset
— restablece todas nuestras configuraciones modificadas.
adb shell wm density X
: cambia la densidad de píxeles, donde el valor mínimo es 72. Cuanto mayor sea el valor, más grandes serán los elementos en la pantalla.
restablecimiento de adb shell wm density reset
: restablece todas nuestras configuraciones modificadas.
Si ejecutamos nuestros comandos sin ningún argumento, recuperaremos la resolución de pantalla actual y la densidad de píxeles del dispositivo/emulador conectado.
Por separado, podemos mencionar el Mono, una herramienta que genera eventos de usuario aleatorios en el emulador o dispositivo, como clics, toques y gestos, así como una serie de eventos a nivel del sistema que se asemejan a los movimientos de un mono tonto. El mono se puede utilizar para pruebas de estrés.
adb shell monkey
: muestra todos los parámetros de Monkey.
Ejemplo de un escenario completo:
adb shell monkey ——throttle 100 ——pct—syskeys 0 —p com.myApp —v 10
La tecla --throttle
establece el retraso entre acciones en milisegundos. Como el Mono realiza todas las acciones rápidamente, este interruptor (tecla) se suele utilizar cuando queremos controlar visualmente lo que sucede en pantalla.
La --pct-syskeys
— define el porcentaje de botones del sistema que se presionarán durante un escenario. En este ejemplo, se establece en 0, lo que implica que no se presionará ningún botón del sistema.
El -p
: el nombre del paquete que se transmite
El -v
: el número de acciones que se realizarán
Normalmente, las operaciones involucradas aquí implican revocar los permisos de la aplicación, porque los permisos generalmente se otorgan a través de una solicitud de la aplicación, algo que se puede hacer de manera rápida y sencilla, mientras que la revocación de permisos se realiza a través de la configuración del sistema.
adb shell dumpsys package com.MyApp | grep permission
: muestra una lista de permisos de aplicación disponibles, por ejemplo, permisos de install permissions
obligatorios que se otorgan al instalar la aplicación, permisos de tiempo de runtime permissions
: permisos que se solicitan en un momento específico, por ejemplo, al acceder al almacenamiento de archivos. Tenga en cuenta que si falta un permiso en la lista de permisos solicitados, no podrá otorgarle acceso.
Entonces, se debe ejecutar el siguiente comando para revocar el permiso de nuestra aplicación:
adb shell pm revoke packageName permissionName
, ejemplo:
adb shell pm revoke com.MyApp android.permission.CAMERA
— revoca el acceso de com.myApp
a la cámara. Una vez volvamos a la aplicación e intentemos usar la cámara a través de ella, veremos una nueva solicitud de permiso.
El comando grant da permiso a la aplicación, por ejemplo:
adb shell pm grant com.myApp android.permission.CAMERA
— otorga acceso a la cámara del teléfono para nuestra aplicación.
Echemos un breve vistazo aquí a la batería y al modo de espera.
adb shell dumpsys battery
: muestra información sobre la batería.
adb shell dumpsys battery set level X
: establece el nivel de carga de la batería, donde X es el porcentaje de carga.
adb shell dumpsys battery unplug
: simula una desconexión de la batería.
adb shell dumpsys battery reset
: restablece todas nuestras configuraciones modificadas.
Ahora echemos un vistazo a los modos de espera. A partir de Android 6 existe la función conocida como Doze Mode, para ahorrar energía de la batería y prolongar la vida útil de la batería al limitar la actividad de la aplicación después de que el usuario no haya interactuado con el dispositivo durante algún tiempo y cuando el dispositivo no esté cargando.
El sistema sale periódicamente del modo Doze para completar las tareas en segundo plano pendientes. App Standby es otra característica similar de Android. A diferencia del modo Doze, rastrea el estado de una aplicación específica que ha estado inactiva durante un cierto período de tiempo y luego activa el modo de espera. Nuestro trabajo es asegurarnos de que la aplicación se recupere normalmente después de salir de estos dos modos de ahorro de energía, que no se bloquee, que las notificaciones sigan llegando, etc.
Para cambiar el dispositivo al modo Doze, ejecute los siguientes comandos:
adb shell dumpsys battery unplug
— desconecta la batería.
adb shell dumpsys deviceidle step
: es posible que el comando deba ejecutarse varias veces hasta que se muestre: Stepped to deep: IDLE
.
Después de todas las rutinas que hemos realizado con la batería, lo mejor es ejecutar el comando:
adb shell dumpsys battery reset
, que lo devuelve a su estado original.
Este comando también se puede usar para forzar el dispositivo al modo Doze:
adb shell dumpsys deviceidle force—idle
—a veces, antes de esto, debe ejecutar el comando: adb shell dumpsys deviceidle enable.
Puede reactivarlo desde el modo Doze con el comando:
adb shell dumpsys deviceidle unforce
— y no olvide restablecer el estado de la batería:
adb shell dumpsys battery reset
.
Ahora un poco sobre App Standby. Para implementar la aplicación en este modo, se deben ejecutar los siguientes comandos:
adb shell dumpsys battery unplug
— desconecta la batería como en el caso anterior.
adb shell am set—inactive com.myApp true
—implementa la aplicación en el modo App Standby.
Luego, cambie nuestra aplicación del modo de espera de la aplicación usando este comando:
adb shell am set—inactive com.myApp false
.
Puede verificar el estado de la aplicación ejecutando este comando:
adb shell am get—inactive com.myApp
adb reboot
— reinicia el dispositivo (también relevante para el dispositivo real).
adb shell dumpsys package com.myApp
: muestra información completa sobre una aplicación específica.
adb shell dumpsys meminfo com.myApp
: para comprobar el uso de la memoria de la aplicación en el dispositivo, desde el espacio ocupado hasta la visualización de las bases de datos utilizadas por esta aplicación, así como la ruta a ellas.
adb shell getprop
: muestra una lista de propiedades de dispositivos disponibles (fabricante, modelo de dispositivo, especificaciones de hardware, etc.)
Muestre la lista de actividades que son accesibles para la aplicación:
adb shell dumpsys package com.myApp | grep —i Activity
.
Mostrar el nombre de la actividad en ejecución:
adb shell dumpsys window | grep Focused
.
Ejecute la actividad de la aplicación seleccionada:
adb shell am start —n com.myApp/.ActivityClass
— de esta manera puede ejecutar cualquier aplicación instalada, incluidas las aplicaciones del sistema. Ejemplo: adb shell am start -n com.android.settings/.Settings muestra la configuración de nuestro teléfono.
Realice una llamada al número de teléfono especificado:
adb shell am start —a android.intent.action.CALL tel:+790900000XX
.
Abra una página en su navegador web:
adb shell am start —a android.intent.action.VIEW 'https://indriver.com'
Me gustaría señalar que es imposible incluir todas las características de Android Debug Bridge en un artículo o realizar un estudio exhaustivo de ellas. Los cambios están ocurriendo constantemente: lo que funciona hoy puede dejar de funcionar repentinamente mañana, y la necesidad de conocer ciertas herramientas surgirá a medida que busquemos soluciones a problemas específicos. Pero puedo decir con confianza que el material que hemos cubierto hoy es suficiente para comenzar y continuar por un tiempo.
¡Buena suerte en sus esfuerzos y espero que disfrute sumergirse en el apasionante mundo de las pruebas de software!