Guía completa de uso de ADB para acceso a dispositivos móviles

De la primera conexión a la adquisición forense: un recorrido de cero a cien por la herramienta con la que un ordenador manda de verdad sobre un teléfono Android.

Por qué esta guía, y por qué en abierto

Android Debug Bridge, conocido por sus siglas ADB, es una de esas herramientas que aparecen mencionadas en mil tutoriales y explicadas en casi ninguno. Se da por supuesta. Los manuales de desarrollo la citan de pasada, los foros la usan como quien recita un conjuro y la documentación oficial, excelente en lo técnico, está pensada para quien ya sabe moverse por el ecosistema de Android. El resultado es que mucha gente capaz de aprovecharla a fondo se queda en la superficie, copiando comandos sueltos sin entender qué ocurre por debajo.

Su utilidad va mucho más allá del laboratorio forense. ADB es la navaja del desarrollador que despliega una aplicación en su móvil, del administrador que automatiza cien tablets de una flota corporativa, del técnico que rescata las fotos de un teléfono con la pantalla rota, del aficionado que quiere entender su propio dispositivo y, por supuesto, del perito informático que necesita extraer evidencia con garantías legales. Es gratuita, es oficial —la publica la propia Google como parte del kit de desarrollo de Android— y funciona en Windows, macOS y Linux sin licencias ni dependencias exóticas.

Detectamos, además, una carencia concreta: en español no existe una guía amplia, clara y accesible que lleve al lector desde la primera conexión hasta las técnicas avanzadas, cubriendo tanto el uso general como la vertiente pericial. Hay fragmentos, entradas de blog dispersas y traducciones parciales, pero no un recurso de referencia único y en abierto. Este texto nace para ocupar ese hueco. Está pensado para leerse de principio a fin como un curso, pero también para consultarse por secciones cuando surja la duda concreta. Los comandos aparecen listos para copiar, y los esquemas resumen de un vistazo lo que a veces cuesta párrafos explicar.

Una advertencia antes de empezar, que conviene tener presente en todo momento. ADB concede acceso privilegiado a un dispositivo, y ese acceso debe ejercerse siempre sobre equipos propios o sobre los que se tenga autorización expresa. En el ámbito profesional —peritaje, respuesta a incidentes, administración de flotas— esa autorización toma la forma de un mandato judicial, un contrato o una política corporativa. Manipular un dispositivo ajeno sin permiso es un asunto legal antes que técnico, y queda por completo fuera del propósito de esta guía.

Qué es realmente ADB

Android Debug Bridge es una herramienta de línea de comandos que permite comunicarse con un dispositivo Android desde un ordenador. Forma parte de las platform-tools del SDK de Android y su cometido, en la definición de la propia Google, es «facilitar diversas acciones sobre el dispositivo», desde instalar y depurar aplicaciones hasta abrir una terminal Unix con la que ejecutar órdenes directamente sobre el sistema.

Bajo esa descripción sobria se esconde una capacidad enorme. Android está construido sobre un núcleo Linux, y ADB es el puente que conecta ese Linux oculto con el ordenador del usuario. A través de él se puede leer el sistema de archivos, consultar el estado de la batería o de la red, capturar la pantalla, grabar vídeo, leer los registros del sistema en tiempo real, instalar y desinstalar paquetes, extraer bases de datos de aplicaciones, medir el rendimiento, simular toques y deslizamientos, redirigir puertos de red y, en dispositivos preparados para ello, obtener acceso de superusuario. Es, a la vez, una herramienta de desarrollo, de administración, de diagnóstico y de análisis.

Conviene situar ADB dentro del conjunto de utilidades que Google distribuye. Las platform-tools incluyen tres piezas principales. La primera es el propio adb, protagonista de esta guía. La segunda es fastboot, una herramienta de más bajo nivel que actúa cuando el dispositivo arranca en modo bootloader y que se usa para operaciones como desbloquear el cargador de arranque o escribir imágenes en las particiones; le dedicaremos una sección propia. La tercera es un conjunto de utilidades menores, como etc1tool o sqlite3, de uso más ocasional. Descargando un único paquete se dispone de todas ellas.

A lo largo del texto distinguiremos con cuidado lo que ADB hace por sí mismo —conexión, transferencia de archivos, instalación de aplicaciones, reenvío de puertos— de lo que ejecuta a través del shell del dispositivo, donde el verdadero motor son los binarios de Android como pm, am, dumpsys o settings. Esa distinción, que muchos tutoriales pasan por alto, es la que separa el uso mecánico del uso experto.

Cliente, servidor y daemon: cómo habla ADB con el teléfono

Antes de teclear el primer comando conviene entender la arquitectura, porque explica buena parte de los comportamientos —y de los problemas— que uno encuentra después. Lejos de ser un único programa que dialoga con el teléfono, ADB es un sistema de tres componentes que trabajan coordinados.

Los tres componentes de ADB y el puerto 5037 por el que se coordinan. · Esquema: elaboración propia.

El primer componente es el cliente. Es lo que se ejecuta cada vez que se escribe adb seguido de un comando en la terminal. El cliente es efímero: nace, envía la orden y muere. Cuando un entorno de desarrollo como Android Studio despliega una aplicación, actúa también como cliente de ADB, igual que herramientas de terceros tan populares como scrcpy.

El segundo componente es el servidor, y aquí está la clave de muchos comportamientos aparentemente misteriosos. El servidor es un proceso en segundo plano que se ejecuta en el ordenador y que gestiona toda la comunicación entre los clientes y los dispositivos. Escucha en el puerto TCP 5037 de la dirección local (127.0.0.1) y hace de intermediario: cuando un cliente quiere hablar con un teléfono, en realidad habla con el servidor, y es este quien reenvía la orden. El servidor se arranca solo la primera vez que se ejecuta cualquier comando adb, aunque también puede lanzarse a mano con adb start-server. Que exista un único servidor multiplexando todas las conexiones explica por qué, cuando algo se atasca, la solución universal es reiniciarlo con adb kill-server seguido de adb start-server.

El tercer componente vive dentro del teléfono: es el daemon, llamado adbd (adb daemon). Se trata de un proceso que corre en el dispositivo Android y que ejecuta las órdenes que le llegan desde el servidor. Cuando se activa la depuración USB, lo que se está permitiendo es precisamente que adbd acepte conexiones y actúe en nombre del ordenador. Por defecto, adbd funciona con privilegios limitados —el usuario shell—, aunque en compilaciones de depuración o en dispositivos con acceso de superusuario puede elevarse.

La comunicación entre el servidor y el daemon puede viajar por dos caminos. El habitual es el USB: se conecta el cable y el servidor detecta el dispositivo. El alternativo es TCP/IP, es decir, a través de la red, con lo que se puede trabajar sin cable; en ese caso adbd escucha en el puerto 5555 del teléfono. Ambos caminos los veremos en detalle más adelante.

Esta separación en tres capas tiene una consecuencia práctica que conviene interiorizar desde el principio. Cuando adb devices no muestra un teléfono que está claramente conectado, el fallo puede estar en cualquiera de los eslabones: en el daemon del dispositivo (depuración desactivada o sin autorizar), en el servidor del ordenador (atascado o en una versión incompatible) o en el propio transporte (un cable que solo carga, un controlador que falta). Diagnosticar bien pasa por saber en qué capa mirar.

Instalar ADB en Windows, macOS y Linux

Instalar ADB se reduce, en esencia, a descargar las platform-tools y dejar el ejecutable a mano. No hace falta instalar el enorme Android Studio ni el SDK completo: Google ofrece las platform-tools como un paquete independiente y ligero, que es justo lo que necesitamos.

El primer paso es común a los tres sistemas: descargar el paquete oficial desde la página de desarrolladores de Android (developer.android.com/tools/releases/platform-tools). Se obtiene un archivo comprimido que, al descomprimirse, crea una carpeta llamada platform-tools con el ejecutable adb dentro (adb.exe en Windows). Conviene descargarlo siempre de esa fuente y no de repositorios de terceros, tanto por seguridad como para disponer de la última versión, que es la que mejor entiende los dispositivos recientes.

Descomprimir el paquete basta para usar ADB, pero para poder invocarlo cómodamente desde cualquier carpeta hay que añadir su ubicación a la variable de entorno PATH del sistema. Este paso, opcional pero muy recomendable, evita tener que escribir la ruta completa cada vez.

En Windows, tras descomprimir la carpeta (por ejemplo en C:\platform-tools), se añade esa ruta al PATH desde «Editar las variables de entorno del sistema», en la sección «Variables de entorno», editando la variable Path del usuario. Después conviene abrir una terminal nueva y comprobar:

adb version

Si aparece el número de versión, ADB está operativo. En Windows, además, muchos dispositivos requieren el controlador USB del fabricante para ser reconocidos; Google ofrece un controlador genérico (Google USB Driver) y cada fabricante suele publicar el suyo. Sin el controlador adecuado, el teléfono puede aparecer en el Administrador de dispositivos con una marca de advertencia y ADB no lo verá.

En macOS, la vía más cómoda es el gestor de paquetes Homebrew:

brew install android-platform-tools

Como alternativa, se descomprime el paquete oficial y se añade la carpeta al PATH editando el archivo de perfil del intérprete de comandos (~/.zshrc en las versiones modernas de macOS):

export PATH="$HOME/platform-tools:$PATH"

macOS no necesita controladores adicionales: reconoce los dispositivos Android de forma nativa.

En Linux, la mayoría de las distribuciones ofrecen ADB en sus repositorios, lo que resuelve la instalación en una línea:

# Debian, Ubuntu y derivadas
sudo apt install adb

# Fedora
sudo dnf install android-tools

# Arch Linux
sudo pacman -S android-tools

El paquete de la distribución puede ir por detrás de la última versión oficial; si se necesita la más reciente, se descarga el paquete de Google y se añade al PATH igual que en macOS. En Linux hay un detalle propio que causa muchos quebraderos de cabeza: los permisos de acceso al dispositivo USB. Por defecto, un usuario sin privilegios puede no tener permiso para hablar con el teléfono, y adb devices lo mostrará con el estado no permissions. La solución correcta —mejor que recurrir a sudo— es instalar las reglas udev de Android, que conceden acceso al grupo del usuario:

sudo apt install android-sdk-platform-tools-common

Ese paquete añade un archivo de reglas udev con los identificadores de los fabricantes conocidos. Tras instalarlo, conviene desconectar y reconectar el dispositivo, o recargar las reglas con sudo udevadm control --reload-rules.

Una recomendación transversal: mantener una sola instalación de ADB en el sistema. Tener varias versiones —una del paquete de la distribución, otra descargada a mano, otra que trajo consigo algún programa— es fuente de conflictos difíciles de diagnosticar, porque el servidor de una versión no se entiende bien con el cliente de otra. Si aparecen mensajes sobre versiones de protocolo incompatibles, casi siempre hay más de un adb conviviendo en el equipo.

Preparar el teléfono y hacer la primera conexión

Con ADB instalado en el ordenador, el trabajo se traslada al teléfono. Android no permite el acceso por ADB de fábrica: hay que habilitarlo de forma explícita, y ese proceso está pensado, precisamente, para que no ocurra por accidente ni sin conocimiento del propietario.

Los siete pasos que llevan de un teléfono recién sacado de la caja a una conexión ADB operativa. · Esquema: elaboración propia.

El primer obstáculo deliberado son las opciones de desarrollador, un menú que Android mantiene oculto. Para revelarlo hay que ir a «Ajustes», entrar en «Información del teléfono» (o «Acerca del dispositivo») y pulsar siete veces seguidas sobre «Número de compilación». A partir del tercer o cuarto toque, el sistema muestra un aviso de cuántos toques faltan, y al séptimo confirma que ya se es desarrollador. Este gesto, que parece un juego, es en realidad una barrera intencionada: activa un menú con ajustes potencialmente peligrosos que el usuario medio no debería tocar.

Una vez visible, se entra en «Opciones de desarrollador» —normalmente dentro de «Ajustes», en «Sistema»— y se activa la casilla «Depuración USB». En algunos fabricantes, y sobre todo en dispositivos de origen chino, puede existir además una opción de «depuración USB (ajustes de seguridad)» que permite operaciones adicionales y que exige tener una tarjeta SIM y sesión iniciada; para el uso general basta con la depuración USB estándar.

Con la depuración activada, se conecta el teléfono al ordenador mediante un cable USB. Aquí conviene un aviso que ahorra horas de frustración: no todos los cables sirven. Muchos cables baratos, y casi todos los que vienen con accesorios como baterías externas, están fabricados solo para cargar y no tienen los hilos de datos conectados. Con un cable de solo carga, el teléfono se alimenta pero ADB nunca lo verá. Ante cualquier duda, lo primero es probar otro cable, preferiblemente el original del dispositivo. Al conectar, algunos teléfonos preguntan por el modo de conexión USB; elegir «Transferencia de archivos» (MTP) suele dar los mejores resultados, aunque el modo «Solo carga» también permite la depuración en muchos casos.

Llegamos al momento decisivo: la autorización mediante clave RSA. La primera vez que un ordenador concreto intenta hablar con el teléfono, Android muestra un diálogo en pantalla que pregunta si se permite la depuración desde ese equipo, e incluye la huella de una clave criptográfica. Este mecanismo, introducido en Android 4.2.2, es una salvaguarda fundamental: impide que cualquiera que conecte un cable pueda acceder al dispositivo. Lo que ocurre por debajo es un intercambio de claves. El ordenador dispone de un par de claves RSA generado la primera vez que se ejecutó ADB, guardado en la carpeta del usuario (~/.android/adbkey y adbkey.pub en macOS y Linux; en la carpeta del perfil de usuario en Windows). Al autorizar, la clave pública del ordenador se almacena en el teléfono, en el archivo de claves de confianza. A partir de ese momento, ese equipo queda reconocido y no vuelve a preguntar, siempre que se marque la casilla «Permitir siempre desde este ordenador».

Comprender este intercambio importa por dos razones. La primera es de diagnóstico: si el teléfono aparece como unauthorized, casi siempre es porque este diálogo está pendiente en la pantalla, y basta con desbloquearla y aceptar. La segunda es de seguridad: la clave privada del ordenador es, en la práctica, la llave del teléfono para ADB; quien la copie puede suplantar a ese equipo de confianza. Si se ha autorizado un ordenador por error, se pueden revocar todas las autorizaciones desde «Opciones de desarrollador», en «Revocar autorizaciones de depuración USB».

El comando que cierra el círculo, y con el que empieza toda sesión de trabajo, es:

adb devices

Este comando arranca el servidor si no estaba en marcha, pregunta a todos los dispositivos conectados quiénes son y en qué estado están, y devuelve la lista. Con un teléfono correctamente autorizado, la salida se parece a esto:

List of devices attached
R58M31XDKPL     device

La primera columna es el número de serie del dispositivo, un identificador único que conviene anotar; la segunda es el estado. Cuando aparece device, todo está listo para trabajar. Una variante muy útil es adb devices -l, que añade información descriptiva de cada dispositivo (modelo, producto y ruta de transporte), especialmente práctica cuando hay varios conectados a la vez.

Cuando algo no encaja: los estados del dispositivo

Rara vez el camino es tan limpio como el ejemplo anterior. La columna de estado de adb devices es la primera herramienta de diagnóstico, y merece conocerse a fondo, porque cada estado apunta a una causa y a una solución distintas.

Los estados que puede mostrar adb devices y la forma de resolver cada uno. · Esquema: elaboración propia.

El estado device es el ideal: el dispositivo está conectado, la depuración activa y la clave del ordenador aceptada. En versiones modernas de ADB es sinónimo de «autorizado y operativo». No hay nada que hacer salvo empezar a trabajar.

El estado unauthorized indica que el dispositivo está conectado y con depuración activa, pero que aún no se ha aceptado la clave RSA del ordenador. Es, con diferencia, la situación más frecuente al conectar un teléfono por primera vez. La solución es desbloquear la pantalla y pulsar «Permitir» en el diálogo que estará esperando. Si el diálogo no aparece, ayuda desconectar y reconectar, o reiniciar el servidor con adb kill-server && adb start-server.

El estado offline significa que ADB detecta el dispositivo pero no logra establecer una comunicación fiable con él. Suele deberse a un cable defectuoso, a un controlador problemático o a que el daemon del teléfono se ha quedado en un estado inconsistente. Las soluciones habituales son cambiar de cable o de puerto USB, reiniciar el servidor de ADB y, si persiste, reiniciar el teléfono.

El estado no permissions es propio de Linux y aparece cuando el sistema operativo del ordenador no concede al usuario permiso para acceder al dispositivo USB. Es un problema de configuración del equipo, no del teléfono, y se resuelve instalando las reglas udev descritas en la sección de instalación, evitando así tener que recurrir a sudo.

Los estados recovery y sideload indican que el teléfono arrancó en el modo de recuperación en lugar de en Android normal. En recovery, algunos comandos funcionan y es posible acceder a ciertas particiones del sistema, pero no a los datos de usuario de la forma habitual. En sideload, el dispositivo está esperando la instalación de un paquete de actualización, y no es un estado útil para el trabajo general; se sale reiniciando a Android.

Por último, una lista vacía —solo la cabecera «List of devices attached» sin ninguna línea debajo— significa que ADB no detecta nada. Las causas típicas son la depuración desactivada, la falta de controlador en Windows, un cable de solo carga o un puerto que no transmite datos. Es el momento de revisar los fundamentos: cable, controlador y depuración.

Un caso que conviene aclarar porque genera confusión: si el teléfono está en modo bootloader o fastboot, no aparecerá en adb devices en absoluto, porque en ese modo el dispositivo ejecuta el daemon de fastboot en lugar del de ADB. Para verlo hay que usar fastboot devices, una herramienta distinta que trataremos más adelante.

Conectar sin cables: Wi-Fi y depuración inalámbrica

El cable USB es el punto de partida de todo, pero ADB también funciona a través de la red, lo que resulta cómodo cuando el puerto del teléfono está dañado, cuando interesa moverse con libertad mientras se prueba una aplicación o cuando se trabaja con dispositivos de difícil acceso físico. Existen dos vías, y conviene no confundirlas, porque pertenecen a épocas distintas de Android.

Las tres formas de conectar: por cable, por Wi-Fi clásico y por depuración inalámbrica moderna. · Esquema: elaboración propia.

La vía clásica, disponible en cualquier versión de Android, parte de una conexión por cable. Con el teléfono conectado por USB y autorizado, se ordena al daemon que empiece a escuchar por red:

adb tcpip 5555

Este comando reinicia adbd en el dispositivo en modo TCP/IP, a la escucha en el puerto 5555. A continuación se averigua la dirección IP del teléfono —en «Ajustes», dentro de la información de la red Wi-Fi, o con adb shell ip route— y se desconecta el cable. Ya sin cable, se establece la conexión por red:

adb connect 192.168.1.45:5555

Si todo va bien, adb devices mostrará ahora el dispositivo identificado por su dirección de red en lugar de por su número de serie. Para volver al modo USB basta con adb usb, o simplemente reiniciar el teléfono. Conviene recordar que dejar el puerto 5555 abierto es un riesgo de seguridad considerable, sobre el que volveremos: cualquiera en la misma red podría intentar conectarse.

La vía moderna, la depuración inalámbrica, llegó con Android 11 y es más segura porque incorpora un emparejamiento con código. Se activa dentro de «Opciones de desarrollador», en «Depuración inalámbrica», y desde ahí se elige «Vincular dispositivo con un código de emparejamiento». El teléfono muestra entonces un código de seis cifras y una dirección con un puerto —distinto del de conexión—, y en el ordenador se ejecuta:

adb pair 192.168.1.45:37100

ADB pedirá el código de seis cifras; al introducirlo, el dispositivo y el ordenador quedan vinculados de forma segura. Después, ya se puede establecer la conexión propiamente dicha usando el puerto de conexión que muestra la pantalla de depuración inalámbrica (que no es el mismo que el de emparejamiento):

adb connect 192.168.1.45:39500

Este método no necesita un cable inicial y protege el enlace con criptografía, lo que lo hace preferible siempre que el dispositivo lo soporte. En ambos casos, la conexión por red es más lenta y menos estable que la USB, y para operaciones que muevan mucho volumen de datos —una imagen de partición, por ejemplo— el cable sigue siendo la opción sensata.

Comandos de cabecera para el día a día

Antes de entrar en los grandes territorios de ADB conviene tener a mano unos cuantos comandos de uso constante, la clase de órdenes que uno teclea decenas de veces en cualquier sesión. Dominarlos da soltura y evita perder tiempo.

La consulta básica de dispositivos ya la conocemos; su versión detallada aporta contexto:

adb devices -l

El estado de la conexión y el número de serie se pueden obtener también de forma aislada, algo útil en scripts:

adb get-state
adb get-serialno

El control del servidor es la primera medicina ante casi cualquier atasco. Detener y volver a arrancar el servidor resuelve una sorprendente proporción de problemas de comunicación:

adb kill-server
adb start-server

ADB puede esperar a que un dispositivo esté disponible antes de continuar, lo que resulta esencial en scripts que actúan justo después de un reinicio:

adb wait-for-device

Los reinicios se ordenan desde el propio ADB, y no solo el reinicio normal: también se puede arrancar directamente en los modos especiales, algo que usaremos al hablar de fastboot y de recuperación:

adb reboot
adb reboot recovery
adb reboot bootloader
adb reboot sideload

En dispositivos que lo permiten —emuladores, compilaciones de ingeniería o teléfonos con acceso de superusuario—, se puede pedir que el daemon se ejecute con privilegios de administrador, lo que abre el acceso a zonas del sistema normalmente vetadas:

adb root
adb unroot

Conviene tener claro que en un teléfono comercial de fábrica adb root fallará con un mensaje del tipo «adbd cannot run as root in production builds»; solo funciona donde el sistema está preparado para ello.

Queda un modificador que se vuelve imprescindible en cuanto hay más de un dispositivo en juego. Si el ordenador tiene conectados varios teléfonos, o un teléfono y un emulador, casi cualquier comando fallará con el aviso de que hay más de un dispositivo y no sabe sobre cuál actuar. La solución es especificar el destino con la opción -s seguida del número de serie:

adb -s R58M31XDKPL shell getprop ro.product.model

Existen atajos para los casos más comunes: -d dirige el comando al único dispositivo físico conectado por USB, y -e al único emulador. Cuando se trabaja con flotas de dispositivos, la combinación de adb devices para obtener los números de serie y adb -s para actuar sobre cada uno es la base de toda automatización.

El mapa de ADB: ocho familias de comandos

ADB tiene decenas de comandos, y enumerarlos sin más abruma. Resulta mucho más útil agruparlos por territorios, según la clase de trabajo que resuelven. Esta panorámica sirve de mapa para el resto de la guía: cada familia tendrá después su sección detallada.

Las ocho grandes familias de comandos de ADB, con ejemplos representativos de cada una. · Esquema: elaboración propia.

La familia de conexión y estado agrupa lo que ya hemos visto: devices, get-state, connect, disconnect, kill-server y compañía. Es la puerta de entrada de cada sesión.

La familia de aplicaciones se ocupa del ciclo de vida del software: instalar (install), desinstalar (uninstall) y, a través del shell, gobernar los paquetes con pm (package manager).

La familia de archivos mueve datos entre el ordenador y el teléfono en ambos sentidos, con push para subir y pull para descargar.

La familia de shell y sistema es la más amplia, porque abre una terminal Unix dentro del dispositivo desde la que se ejecutan los binarios de Android: getprop, settings, svc y muchos más.

La familia de registros y diagnóstico permite ver qué ocurre por dentro: logcat para los registros en vivo, dumpsys para el estado de cada servicio del sistema y bugreport para un volcado exhaustivo.

La familia de interacción y captura actúa sobre la pantalla y la entrada: screencap para capturar imágenes, screenrecord para grabar vídeo e input para simular toques, textos y teclas.

La familia de depuración de red tiende túneles entre el ordenador y el teléfono con forward y reverse, y expone los puertos de depuración de la máquina virtual con jdwp.

La familia de energía y arranque gobierna el estado del dispositivo: reboot y sus variantes, root y la puerta hacia fastboot.

Con este mapa en la cabeza, recorramos ahora cada territorio.

Instalar, desinstalar y gobernar aplicaciones

Una de las tareas más habituales con ADB es la gestión de aplicaciones, y aquí la herramienta ofrece mucho más de lo que la mayoría utiliza. La instalación de un paquete APK desde el ordenador es directa:

adb install aplicacion.apk

Este comando cobra potencia con sus modificadores. La opción -r reinstala una aplicación conservando sus datos, algo esencial cuando se prueba una nueva versión sobre una instalación existente. La opción -d permite una reinstalación a una versión anterior (downgrade). La opción -g concede de golpe todos los permisos en tiempo de ejecución que la aplicación declara, muy práctica para pruebas. Y -t autoriza la instalación de aplicaciones marcadas como de prueba:

adb install -r -g aplicacion.apk

Las aplicaciones modernas rara vez son un único APK. El formato de distribución de Google, el Android App Bundle, se materializa en el dispositivo como un conjunto de APK divididos: uno base y varios para la densidad de pantalla, la arquitectura del procesador y el idioma. Para instalar ese conjunto se usa una variante específica que los coloca todos como una unidad:

adb install-multiple base.apk split_config.arm64_v8a.apk split_config.xxhdpi.apk

La desinstalación es igual de sencilla, y tiene un matiz forense y de administración importante. Por defecto, adb uninstall elimina la aplicación y sus datos:

adb uninstall com.ejemplo.aplicacion

La opción -k conserva los datos y la caché de la aplicación aunque se elimine el paquete, lo que permite recuperar esa información más adelante:

adb uninstall -k com.ejemplo.aplicacion

El verdadero poder sobre las aplicaciones llega a través del package manager, invocado con pm dentro del shell. Listar los paquetes instalados es el punto de partida de casi cualquier análisis:

adb shell pm list packages

Este comando acepta filtros muy útiles. La opción -3 muestra solo las aplicaciones de terceros (las que no vienen de fábrica), -s solo las del sistema, -e las habilitadas y -d las deshabilitadas. La opción -f añade la ruta del archivo APK de cada paquete, dato imprescindible cuando se quiere extraer una aplicación concreta:

adb shell pm list packages -3
adb shell pm list packages -f com.whatsapp

Conocida la ruta de un paquete, se puede extraer su APK al ordenador combinando pm path con pull:

adb shell pm path com.ejemplo.aplicacion
adb pull /data/app/com.ejemplo.aplicacion-1/base.apk

El package manager también permite intervenir sobre el estado de las aplicaciones. Se pueden borrar los datos de una aplicación (dejándola como recién instalada), deshabilitarla sin desinstalarla, volverla a habilitar o gestionar sus permisos de forma individual:

adb shell pm clear com.ejemplo.aplicacion
adb shell pm disable-user com.ejemplo.aplicacion
adb shell pm enable com.ejemplo.aplicacion
adb shell pm grant com.ejemplo.aplicacion android.permission.CAMERA
adb shell pm revoke com.ejemplo.aplicacion android.permission.CAMERA

La capacidad de conceder y revocar permisos desde la línea de comandos resulta valiosísima tanto en el desarrollo, para probar el comportamiento de una aplicación ante distintos escenarios de permisos, como en la administración de dispositivos corporativos. Para conocer a fondo un paquete —su versión, sus permisos, sus actividades, cuándo se instaló y actualizó— el servicio package de dumpsys ofrece un informe completo:

adb shell dumpsys package com.ejemplo.aplicacion

Mover archivos entre el ordenador y el teléfono

El intercambio de archivos es una de las capacidades más inmediatas y agradecidas de ADB. Dos comandos cubren la mayor parte de las necesidades, y su lógica es fácil de recordar pensando desde el punto de vista del ordenador: se «empuja» hacia el teléfono y se «tira» de él para traer datos.

Para copiar un archivo o una carpeta desde el ordenador al dispositivo se usa push, indicando primero el origen (en el ordenador) y después el destino (en el teléfono):

adb push documento.pdf /sdcard/Download/
adb push carpeta_local/ /sdcard/destino/

Para traer datos del teléfono al ordenador se usa pull, con el origen en el dispositivo y el destino en el equipo (si se omite el destino, se guarda en la carpeta actual):

adb pull /sdcard/DCIM/Camera/ ./fotos_extraidas/
adb pull /sdcard/Download/informe.pdf

Estas órdenes respetan la estructura de carpetas y son la vía natural para, por ejemplo, hacer una copia de las fotografías de un dispositivo, extraer documentos o trasladar archivos de configuración. Su alcance, eso sí, está limitado por los permisos del usuario shell: las zonas públicas del almacenamiento, como /sdcard/, son accesibles sin problema, mientras que los datos privados de cada aplicación, en /data/data/, quedan fuera del alcance sin privilegios elevados, una frontera sobre la que volveremos al hablar del shell y del análisis forense.

Existe un tercer comando, adb sync, que sincroniza directorios y se usa sobre todo en flujos de desarrollo del propio sistema Android. Para el trabajo cotidiano, push y pull bastan. Y para casos en los que hay que traer datos binarios generados sobre la marcha —como una captura de pantalla— es preferible adb exec-out, que transmite la salida en binario puro sin que el intérprete de comandos la altere; lo veremos en la sección de capturas.

El shell de Android: una terminal dentro del teléfono

Si adb devices es el apretón de manos, adb shell es cruzar la puerta. Este comando abre una terminal Unix completa que se ejecuta dentro del dispositivo, el mismo entorno que el propio sistema operativo utiliza para funcionar. Es, para un forense o un administrador, la diferencia entre mirar un edificio desde la calle y poder recorrer sus habitaciones.

Cómo un comando de shell viaja desde el ordenador hasta los binarios del sistema, y qué herramientas encuentra allí. · Esquema: elaboración propia.

Conviene entender qué es exactamente ese shell. Android se asienta sobre un núcleo Linux, y por debajo de la interfaz táctil, las aplicaciones y la tienda de Google existe un sistema de archivos Unix completo, con usuarios, permisos, procesos y demonios. adb shell conecta con ese sistema a través del daemon adbd, ofreciendo una sesión de terminal parecida a la de una conexión remota por SSH. La diferencia decisiva respecto a un Linux convencional es el usuario con el que se entra: se trata del usuario shell, con identificador 2000, un usuario sin privilegios de administrador y con acceso deliberadamente limitado, pensado precisamente para la depuración.

El shell admite dos modos de uso, y la elección tiene consecuencias, sobre todo en contextos donde importa el registro de lo actuado. El modo interactivo abre una sesión y permite ir tecleando comandos uno a uno:

adb shell
# ya se está dentro del dispositivo
whoami        # devuelve: shell
pwd           # devuelve: /
ls /sdcard/
exit

El modo directo ejecuta una sola orden y devuelve su salida al instante, sin abrir sesión. Es el preferido en análisis forense porque cada comando queda como una línea independiente, fechada y aislada en el registro de la sesión:

adb shell whoami
adb shell getprop ro.product.model
adb shell ls /sdcard/

El sistema de archivos que se encuentra al entrar sigue la estructura clásica de Unix, con algunas carpetas de especial interés. En la raíz conviven /system (el sistema operativo, normalmente de solo lectura), /data (los datos de las aplicaciones y del usuario, en su mayoría protegidos), /sdcard (el almacenamiento accesible al usuario, en realidad un enlace al almacenamiento interno), /proc y /sys (información del núcleo en tiempo real), /dev (los dispositivos de bloque, es decir, las particiones físicas) y /cache. La ruta más valiosa desde el punto de vista del análisis es /data/data/, donde cada aplicación guarda su base de datos, sus preferencias y sus credenciales; el problema es que, sin privilegios de superusuario, el usuario shell ve el directorio pero no puede leer su contenido, porque cada aplicación vive aislada en su propio recinto de seguridad.

Ese aislamiento, el sandbox de Android, es el límite más importante que se encuentra desde el shell. Cada aplicación se ejecuta con su propio usuario de sistema, y sus datos son inaccesibles para los demás. Al intentar leer la carpeta privada de una aplicación sin ser superusuario, la respuesta es tajante:

adb shell ls /data/data/com.whatsapp/databases/
# opendir failed, Permission denied

Ese «Permission denied» es en sí mismo información: confirma que los datos existen y revela la estructura del directorio, aunque haga falta otra vía para acceder a su contenido. Las alternativas legítimas son el sistema de copia de seguridad de Android, los proveedores de contenido públicos que cada aplicación decida exponer, o el trabajo sobre dispositivos con acceso de superusuario.

Dentro del shell, el motor real son los binarios del sistema, cada uno una herramienta con su propia especialidad. El más transversal es getprop, que muestra las propiedades del sistema —modelo, versión de Android, número de serie, características del hardware— y que es la forma más rápida de identificar un dispositivo:

adb shell getprop ro.product.model
adb shell getprop ro.build.version.release
adb shell getprop ro.serialno
adb shell getprop            # todas las propiedades de una vez

A su lado trabajan pm (el gestor de paquetes que ya vimos), am (el gestor de actividades que veremos enseguida), dumpsys (el inspector de servicios), settings (que lee y escribe la configuración del sistema), content (que consulta los proveedores de contenido), input (que simula la interacción), svc (que gobierna subsistemas como la red o la energía), wm (el gestor de ventanas) y utilidades Unix de toda la vida como ls, ps, top, cat, grep, df o mount. Conocer este repertorio es lo que convierte el shell en una herramienta ilimitada: casi cualquier información del dispositivo está a un comando de distancia.

Identificar el dispositivo: la huella de getprop

Antes de tocar nada en un dispositivo conviene saber con exactitud ante qué se está, y el comando getprop es la vía más rápida y completa para averiguarlo. Cada teléfono mantiene cientos de propiedades del sistema —pares de clave y valor— que describen el hardware, la versión del software y el estado del arranque. Volcarlas todas de golpe da una fotografía completa, y consultarlas de una en una permite componer una ficha de identificación precisa:

adb shell getprop ro.product.manufacturer      # fabricante (p. ej. samsung)
adb shell getprop ro.product.model             # modelo comercial (SM-S911B)
adb shell getprop ro.product.device            # nombre interno del dispositivo
adb shell getprop ro.build.version.release     # versión de Android (14)
adb shell getprop ro.build.version.sdk         # nivel de API (34)
adb shell getprop ro.build.version.security_patch   # fecha del parche de seguridad
adb shell getprop ro.build.fingerprint         # huella única de la compilación
adb shell getprop ro.product.cpu.abi           # arquitectura del procesador (arm64-v8a)

Para un análisis pericial, la identificación tiene una exigencia añadida: demostrar que se trabaja sobre el dispositivo correcto. Aquí ayuda el cotejo de tres fuentes del número de serie, que deben coincidir entre sí y con el que muestra adb devices:

adb get-serialno                          # el que ve ADB
adb shell getprop ro.serialno             # el que declara el sistema
adb shell getprop ro.boot.serialno        # el que declara el cargador de arranque

Cuando las tres coinciden, se dispone de una confirmación triple que conviene anotar en el informe. La huella de compilación (ro.build.fingerprint) merece atención especial, porque es una cadena que identifica de forma única la versión exacta del sistema instalada —marca, modelo, versión, número de compilación y tipo de firma— y sirve para detectar sistemas modificados o no oficiales. La fecha del parche de seguridad, por su parte, sitúa en el tiempo la última actualización y es un dato relevante tanto para la seguridad como para valorar qué vulnerabilidades podían estar presentes en un momento dado.

El identificador internacional del terminal, el IMEI, es otro dato de referencia en cualquier informe. La forma universal de obtenerlo es marcar *#06# en el teclado del teléfono, que lo muestra en pantalla para fotografiarlo. Por línea de comandos, las versiones modernas de Android han restringido su lectura por privacidad, de modo que las órdenes que antes lo devolvían pueden no funcionar sin permisos elevados; cuando el objetivo es documental, la vía del marcador sigue siendo la más fiable y menos intrusiva.

El inspector dumpsys, servicio por servicio

El dumpsys merece un recorrido más detenido, porque es la ventana más rica al estado interno de Android y buena parte de su valor se pierde si solo se conoce de pasada. Android ejecuta decenas de servicios del sistema, y dumpsys puede interrogar a cada uno por separado. La lista completa de servicios disponibles se obtiene con:

adb shell dumpsys -l

A partir de ahí, cada servicio cuenta algo distinto. Estos son los más útiles en el trabajo diario y en el análisis, con una idea de lo que aporta cada uno:

adb shell dumpsys battery          # nivel, temperatura, estado y salud de la batería
adb shell dumpsys batterystats     # consumo por aplicación e historial de energía
adb shell dumpsys activity recents # las últimas aplicaciones y pantallas abiertas
adb shell dumpsys usagestats       # qué apps se usaron y cuándo (línea de actividad)
adb shell dumpsys wifi             # redes conocidas, estado y conexión actual
adb shell dumpsys connectivity     # estado de las conexiones de red del sistema
adb shell dumpsys location         # servicio de localización y últimas posiciones
adb shell dumpsys notification     # historial reciente de notificaciones
adb shell dumpsys netstats         # estadísticas de consumo de datos por app
adb shell dumpsys procstats        # estadísticas de procesos a lo largo del tiempo

El valor forense de algunos de estos servicios es considerable. El usagestats reconstruye qué aplicaciones estuvieron en primer plano y en qué momento, un elemento clave para situar la actividad del usuario en una línea temporal. El dumpsys wifi revela las redes a las que el dispositivo se ha conectado, dato que puede vincular a una persona con un lugar. El batterystats guarda un historial de eventos energéticos con marcas de tiempo. Y el activity recents muestra las últimas pantallas abiertas, una instantánea del uso más reciente.

Estos volcados son extensos, de modo que en la práctica se combinan con un filtro para localizar lo relevante. Por ejemplo, para extraer solo la última posición conocida del servicio de localización, o para ver el estado de una aplicación concreta:

adb shell dumpsys location | grep -i "last known"
adb shell dumpsys package com.ejemplo.aplicacion | grep -i version

Conviene recordar, una vez más, que todas estas consultas son de lectura y encajan sin reservas en un flujo forense, siempre que se registre el comando exacto que se ejecutó. Su riqueza convierte a dumpsys en una de las herramientas que más información aporta por comando, y en un recurso que compensa conocer a fondo.

Controlar la interfaz: simular toques, textos y teclas

ADB no se limita a observar el dispositivo: también puede manejarlo, simulando la interacción de un dedo humano sobre la pantalla. El comando input, ejecutado a través del shell, es la puerta a esa automatización, y resulta útil tanto para pruebas de desarrollo como para operar un teléfono con la pantalla táctil averiada.

Un toque en un punto concreto de la pantalla se ordena con las coordenadas en píxeles:

adb shell input tap 500 1200

Un deslizamiento se define con el punto de origen, el de destino y, opcionalmente, la duración en milisegundos, lo que permite desde un gesto rápido hasta un arrastre lento:

adb shell input swipe 300 1000 300 300 500

Se puede escribir texto directamente en el campo que tenga el foco, aunque con la limitación de que los espacios deben sustituirse por %s y los caracteres especiales requieren cuidado:

adb shell input text "Hola%smundo"

Y se pueden enviar pulsaciones de teclas físicas o virtuales mediante sus códigos, lo que abarca desde el botón de inicio o el de retroceso hasta el bloqueo de pantalla o los controles de volumen:

adb shell input keyevent KEYCODE_HOME
adb shell input keyevent KEYCODE_BACK
adb shell input keyevent KEYCODE_POWER
adb shell input keyevent 26        # también por número: 26 = POWER

Para operar un teléfono cuya pantalla no responde al tacto pero cuyo sistema sigue funcionando, esta combinación de toques y teclas, guiada por una captura de pantalla previa que indique dónde pulsar, permite navegar por los menús desde el ordenador. Existen además herramientas de más alto nivel, como monkey, que genera secuencias de eventos aleatorios para pruebas de estrés, o uiautomator, capaz de volcar la jerarquía de elementos de la pantalla actual en un archivo XML para identificar con precisión dónde está cada botón:

adb shell monkey -p com.ejemplo.aplicacion 500
adb shell uiautomator dump
adb pull /sdcard/window_dump.xml

El archivo window_dump.xml que genera uiautomator es más útil de lo que parece: contiene la jerarquía completa de la pantalla y, para cada elemento, sus coordenadas exactas (el atributo bounds), su texto y su identificador. Con esa información se puede localizar con precisión dónde está un botón y calcular el centro de su rectángulo para dirigir allí un input tap, lo que permite automatizar de forma fiable sin depender de coordenadas fijas que cambian entre modelos. Encadenando un volcado, la búsqueda del elemento deseado y el toque correspondiente se construyen secuencias de automatización robustas, la base de muchas herramientas de pruebas de interfaz.

La herramienta monkey, por su parte, admite parámetros que la hacen más controlable de lo que sugiere su nombre. La opción -s fija una semilla, de modo que la secuencia de eventos aleatorios sea reproducible entre ejecuciones; --throttle introduce una pausa entre eventos para no saturar la aplicación; y se puede restringir a categorías concretas de eventos. Una prueba de estrés reproducible sobre una aplicación tendría este aspecto:

adb shell monkey -p com.ejemplo.aplicacion -s 42 --throttle 300 -v 1000

Esta capacidad de guiar la interfaz desde la línea de comandos tiene aplicaciones que van del desarrollo y las pruebas automatizadas a la accesibilidad, e incluye ese caso tan práctico de manejar un teléfono cuya pantalla táctil ha dejado de responder pero cuyo sistema sigue vivo.

Ver lo que pasa dentro: logcat, dumpsys y bugreport

Una parte esencial del trabajo con ADB consiste en observar el estado interno del dispositivo, y para ello hay tres herramientas de distinto calibre: logcat para los registros en vivo, dumpsys para el estado de los servicios y bugreport para el volcado total.

El logcat es la memoria a corto plazo de Android: un flujo continuo donde el sistema y las aplicaciones anotan lo que hacen, los errores que encuentran y los eventos que se producen. Volcarlo completo y salir de inmediato es la operación básica:

adb logcat -d > registro.txt

La opción -d (dump) es importante: vuelca el contenido actual del búfer y termina. Sin ella, logcat se queda escuchando indefinidamente, lo que sirve para observar en tiempo real pero nunca «termina» de escribir un archivo. Android mantiene además varios búferes separados, cada uno con una historia distinta —el principal, el de radio (red móvil, SMS, llamadas), el de eventos y el del sistema—, y se pueden consultar de forma selectiva o todos a la vez:

adb logcat -b main -d > log_main.txt
adb logcat -b radio -d > log_radio.txt
adb logcat -b all -d > log_completo.txt

El registro se puede filtrar por prioridad y por etiqueta, lo que evita ahogarse en el ruido. La sintaxis de filtro asocia una etiqueta a un nivel mínimo de prioridad (V, D, I, W, E, F), y *:S silencia todo lo demás:

adb logcat ActivityManager:I *:S
adb logcat *:E          # solo errores y fallos graves

También se puede cambiar el formato de salida con -v para incluir marcas de tiempo precisas, identificadores de proceso o el nombre de la etiqueta, algo valioso cuando se reconstruye una secuencia de acontecimientos:

adb logcat -v time -d > registro_con_hora.txt

El dumpsys es un inspector del estado de cada servicio del sistema. Ejecutado a secas produce un informe gigantesco; su verdadero valor está en apuntar a un servicio concreto. Algunos de los más útiles son la batería (que revela el estado de carga y datos temporales relevantes), la memoria, el uso de procesador, la actividad (con la pila de aplicaciones y las últimas abiertas), el wifi, la localización y las estadísticas de uso de aplicaciones:

adb shell dumpsys battery
adb shell dumpsys meminfo com.ejemplo.aplicacion
adb shell dumpsys activity activities
adb shell dumpsys wifi
adb shell dumpsys location
adb shell dumpsys usagestats

El dumpsys usagestats, por ejemplo, muestra qué aplicaciones se usaron y cuándo, un dato de enorme interés en cualquier reconstrucción de la actividad de un dispositivo. Y el dumpsys battery incluye información temporal que, en un análisis, ayuda a situar acontecimientos en el tiempo.

El bugreport es la artillería pesada: un volcado exhaustivo que reúne los registros, el estado de los servicios, la información del sistema y mucho más en un único paquete comprimido. Está pensado para acompañar informes de errores, pero también sirve como fotografía completa del estado de un dispositivo en un instante:

adb bugreport informe_completo.zip

Genera un archivo voluminoso —decenas de megabytes— que después puede analizarse con calma, incluso con herramientas específicas que lo interpretan de forma visual.

Capturar la pantalla y grabar vídeo

Documentar lo que muestra un dispositivo en un momento dado es una necesidad constante, ya sea para ilustrar un error, para preparar documentación o para dejar constancia del estado de un teléfono en una intervención. ADB captura tanto imágenes fijas como vídeo.

La captura de pantalla se realiza con screencap, y la forma recomendable de traerla al ordenador es a través de exec-out, que transmite los datos binarios de la imagen sin que el intérprete de comandos los corrompa:

adb exec-out screencap -p > pantalla.png

La alternativa clásica guarda primero la imagen en el teléfono y luego la descarga, lo que deja un rastro en el dispositivo que a veces conviene evitar:

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

Para grabar vídeo de la pantalla se usa screenrecord, con una limitación propia de Android: la grabación se detiene automáticamente a los tres minutos, de modo que para secuencias largas hay que encadenar varias. El vídeo se guarda en el dispositivo y luego se extrae:

adb shell screenrecord --time-limit 180 /sdcard/sesion.mp4
adb pull /sdcard/sesion.mp4

Se pueden ajustar parámetros como la resolución (--size) o la tasa de bits (--bit-rate) para equilibrar calidad y tamaño. Estas capturas son la forma más directa de dejar constancia visual del estado de un dispositivo, y en contextos donde importa la volatilidad —lo veremos— son de las primeras evidencias que conviene asegurar.

Activity Manager: lanzar, difundir y detener

Así como pm gobierna los paquetes, el Activity Manager, invocado con am, gobierna lo que se ejecuta: permite lanzar pantallas concretas de una aplicación, enviar mensajes al sistema y detener procesos. Es una herramienta de desarrollo de primer orden y también un recurso valioso para automatizar y depurar.

Lanzar una actividad concreta —una pantalla específica de una aplicación— se hace indicando su componente, con el nombre del paquete y el de la actividad separados por una barra:

adb shell am start -n com.android.settings/.Settings

El sistema de intents de Android permite arrancar acciones sin conocer la aplicación exacta, indicando qué se quiere hacer y sobre qué dato. Así se puede, por ejemplo, abrir una página web en el navegador predeterminado:

adb shell am start -a android.intent.action.VIEW -d https://actumforensepress.es

Se pueden difundir mensajes al sistema (broadcasts), útiles para simular eventos como la finalización del arranque o cambios de estado, y se pueden pasar datos adicionales con las opciones de extras (--es para texto, --ei para enteros, --ez para booleanos):

adb shell am broadcast -a android.intent.action.BOOT_COMPLETED

Detener por completo una aplicación, cerrando todos sus procesos, es una operación frecuente en pruebas y en la resolución de problemas:

adb shell am force-stop com.ejemplo.aplicacion

También se pueden arrancar servicios, incluidos los de primer plano, y limpiar el estado de la aplicación combinando am con pm. Este conjunto de capacidades convierte a am en la herramienta con la que se orquesta el comportamiento del dispositivo desde la línea de comandos, sin tocar la pantalla.

Leer la configuración y los proveedores de contenido

Dos herramientas del shell merecen una mención propia porque abren el acceso ordenado a información que de otro modo quedaría dispersa: settings, que gobierna la configuración del sistema, y content, que consulta los proveedores de contenido de Android.

El comando settings lee y escribe los ajustes del sistema, organizados en tres espacios: global (para todo el dispositivo), system (preferencias del usuario) y secure (ajustes protegidos). Consultar un valor es inmediato, y comprobar si la depuración estaba ya activada —dato de interés cuando se recibe un dispositivo— es un buen ejemplo:

adb shell settings get global adb_enabled       # 1 si estaba activada, 0 si no
adb shell settings get system screen_off_timeout
adb shell settings list secure                  # todos los ajustes protegidos

Escribir ajustes también es posible, aunque en un dispositivo intervenido esto modifica el estado y debe evitarse; en el propio o en pruebas resulta cómodo, por ejemplo, para fijar el brillo o el tiempo de apagado de pantalla:

adb shell settings put system screen_brightness 200

El comando content consulta los proveedores de contenido, el mecanismo con el que Android expone datos estructurados de forma controlada. A través de él, y siempre dentro de los límites de permisos que imponga cada versión, se pueden consultar el registro de llamadas, los mensajes cortos o los contactos, indicando la dirección content:// correspondiente:

adb shell content query --uri content://call_log/calls
adb shell content query --uri content://sms

Conviene una precaución importante: las versiones modernas de Android han restringido notablemente el acceso a muchos proveedores por motivos de privacidad, de modo que estas consultas pueden devolver datos limitados o requerir permisos que el usuario shell no siempre posee. Aun así, cuando funcionan son una vía de lectura ordenada y directa a información de gran valor, tanto para el desarrollo como para reconstruir la actividad de un dispositivo en un análisis. Como toda lectura, encajan sin problema en un flujo forense, siempre que se documente la consulta exacta realizada.

Reenvío de puertos: forward y reverse

Entre las capacidades más potentes y menos conocidas de ADB está el reenvío de puertos, que permite tender un túnel de red entre el ordenador y el teléfono. Con él, un puerto de una máquina se hace accesible desde la otra, algo imprescindible en el desarrollo de aplicaciones que se comunican por red y muy útil en depuración avanzada. Hay dos direcciones posibles, y entenderlas bien evita mucha confusión.

Las dos direcciones del reenvío de puertos: forward lleva del ordenador al teléfono; reverse, del teléfono al ordenador. · Esquema: elaboración propia.

El forward abre un puerto en el ordenador que se reenvía a un puerto del dispositivo. Dicho de otro modo, permite que el ordenador acceda a un servicio que se está ejecutando dentro del teléfono. El caso típico es depurar un servidor o un componente que corre en la aplicación: se ordena que el puerto local 8080 del ordenador desemboque en el puerto 8080 del teléfono, y a partir de ahí basta con abrir localhost:8080 en el ordenador para llegar al servicio del móvil:

adb forward tcp:8080 tcp:8080

El reverse hace justo lo contrario: abre un puerto en el dispositivo que se reenvía a un puerto del ordenador, de modo que una aplicación del teléfono pueda acceder a un servicio que se ejecuta en el equipo de desarrollo. Es el escenario habitual cuando la aplicación en pruebas necesita hablar con un servidor local levantado en el ordenador; se le dice que su puerto 3000 salga hacia el puerto 3000 del equipo, y la aplicación puede entonces pedir localhost:3000 como si el servidor estuviera dentro del propio teléfono:

adb reverse tcp:3000 tcp:3000

Los reenvíos activos se pueden listar y eliminar, lo que ayuda a mantener el orden cuando se trabaja con varios túneles a la vez:

adb forward --list
adb forward --remove-all
adb reverse --list
adb reverse --remove-all

Una nota técnica: reverse requiere una versión razonablemente moderna del daemon en el dispositivo y no funciona en modos limitados como la recuperación. Para el desarrollo de aplicaciones conectadas, sin embargo, es una de las herramientas que más tiempo ahorra, porque evita tener que desplegar servidores intermedios o exponer servicios a la red local.

Espejo y control con scrcpy

Aunque no forma parte de las platform-tools, merece una mención destacada una herramienta libre que se apoya por completo en ADB y que multiplica su comodidad: scrcpy (pronunciado «screen copy»). Desarrollada por Genymobile y disponible de forma gratuita, muestra la pantalla del teléfono en una ventana del ordenador y permite controlarlo con el ratón y el teclado, todo a través de la conexión de ADB y sin necesidad de instalar nada en el dispositivo.

Su funcionamiento es transparente: cuando se lanza, scrcpy usa ADB para desplegar un pequeño servidor temporal en el teléfono, establece la conexión y transmite el vídeo en tiempo real con muy poca latencia. Basta con tener el dispositivo conectado y autorizado —exactamente el mismo requisito que para cualquier comando de ADB— y ejecutar:

scrcpy

Para quien trabaja a diario con dispositivos, ya sea en desarrollo, en soporte o en demostraciones, scrcpy convierte el teléfono en una ventana más del escritorio. Y para operar un dispositivo con la pantalla rota pero funcional, ofrece una alternativa mucho más cómoda que la combinación manual de capturas y comandos input. Es un buen ejemplo de cómo ADB, al ser una base abierta y bien documentada, ha dado lugar a todo un ecosistema de herramientas construidas sobre él.

Trabajar con emuladores

ADB no distingue entre un teléfono físico y un emulador: para el servidor, ambos son dispositivos con los que hablar. Los emuladores creados con Android Studio —los llamados AVD, Android Virtual Device— aparecen en adb devices con un nombre característico, emulator-5554, donde el número es el puerto por el que se comunican. La opción -e dirige un comando al único emulador en marcha, igual que -d lo hacía al único dispositivo físico:

adb devices
# emulator-5554   device
adb -e shell getprop ro.product.model

Los emuladores ofrecen, además, una consola propia con capacidades que el hardware real no permite simular con tanta comodidad. A través de adb emu, o conectándose por telnet al puerto del emulador, se pueden falsear condiciones para las pruebas: fijar una posición GPS, simular la recepción de un mensaje o una llamada, cambiar el estado de la batería o la calidad de la red. Establecer unas coordenadas de localización, por ejemplo, es tan directo como:

adb emu geo fix -3.7038 40.4168     # longitud y latitud (Madrid)

Esta equivalencia entre dispositivos reales y virtuales hace que todo lo aprendido en esta guía sirva por igual para ambos, lo que resulta muy cómodo en desarrollo: se prueba primero en el emulador, con sus condiciones controladas, y después en hardware real sin cambiar de herramienta.

Gobernar flotas: varios dispositivos y automatización con scripts

Cuando el trabajo deja de ser sobre un teléfono y pasa a ser sobre decenas —una flota de tablets en un colegio, terminales de punto de venta, dispositivos de una empresa—, ADB muestra otra de sus virtudes: se presta a la automatización. La combinación de adb devices, que enumera todos los dispositivos, con la opción -s, que dirige cada comando a uno concreto, es la base de cualquier operación masiva.

Un guion sencillo puede instalar una aplicación en todos los dispositivos conectados a la vez. En un intérprete de comandos de tipo Unix, se recorren los números de serie de los dispositivos en estado operativo y se actúa sobre cada uno:

for serial in $(adb devices | grep -w device | cut -f1); do
    echo "Instalando en $serial…"
    adb -s "$serial" install -r aplicacion.apk
done

El mismo patrón sirve para inventariar una flota, recogiendo el modelo y la versión de Android de cada dispositivo en un informe:

for serial in $(adb devices | grep -w device | cut -f1); do
    modelo=$(adb -s "$serial" shell getprop ro.product.model)
    version=$(adb -s "$serial" shell getprop ro.build.version.release)
    echo "$serial;$modelo;$version"
done

En Windows, el mismo trabajo se resuelve con PowerShell, aprovechando su capacidad para tratar la salida de adb devices y recorrerla. La lógica es idéntica: obtener la lista de dispositivos operativos y aplicar a cada uno la orden deseada con -s.

Algunas buenas prácticas hacen que estos guiones sean fiables. Conviene esperar a que cada dispositivo esté listo con adb wait-for-device antes de actuar sobre él, comprobar el estado para saltar los que aparezcan como unauthorized u offline, y registrar la salida de cada operación para poder revisar después qué funcionó y qué no. Con esos cuidados, ADB se convierte en el motor de despliegues, configuraciones e inventarios que, hechos a mano, serían inabordables.

Copias de seguridad con adb backup, y por qué ya casi no se usan

Durante años, ADB ofreció un mecanismo de copia de seguridad integrado que permitía volcar los datos de las aplicaciones a un archivo del ordenador. El comando sigue existiendo y conviene conocerlo, aunque su utilidad ha menguado mucho con el tiempo. Una copia completa se solicita así:

adb backup -apk -all -f copia.ab

Las opciones controlan qué se incluye: -apk guarda también los archivos de instalación de las aplicaciones, -all abarca todas las aplicaciones, y -f indica el archivo de destino, con extensión .ab (Android backup). Al ejecutarlo, el teléfono pide confirmación en pantalla y ofrece cifrar la copia con una contraseña. El archivo resultante se puede convertir a un formato estándar para su inspección con utilidades de terceros como Android Backup Extractor.

El problema es que este mecanismo depende de que cada aplicación permita la copia, a través de un atributo de su manifiesto (allowBackup). Por motivos de seguridad, cada vez más aplicaciones —y muy especialmente las de mensajería y banca— lo desactivan, con lo que adb backup devuelve una copia vacía o incompleta para ellas. Además, Google ha marcado el comando como obsoleto y ha ido reduciendo su alcance en las versiones recientes de Android. En la práctica, hoy solo resulta fiable para aplicaciones que no hayan bloqueado la copia, y las alternativas —la sincronización en la nube, las herramientas específicas de cada fabricante o, en el ámbito forense, la extracción especializada— han ocupado su lugar. Aun así, en un dispositivo concreto y para una aplicación que lo permita, sigue siendo una forma rápida de obtener sus datos sin necesidad de privilegios de superusuario.

Más allá de ADB: fastboot y los modos de arranque

Un teléfono Android no arranca siempre en el mismo sitio. Además del sistema normal, dispone de modos especiales de arranque, y ADB solo funciona en algunos de ellos. Entender ese mapa es necesario para operaciones avanzadas y para no desconcertarse cuando un dispositivo «desaparece» de adb devices.

En el arranque normal —el sistema Android completo— es donde vive el daemon adbd y donde funcionan todos los comandos que hemos visto. El modo de recuperación (recovery) es un entorno mínimo, separado, que se usa para aplicar actualizaciones, borrar datos o reparar el sistema; algunos comandos de ADB funcionan en él de forma limitada, y a él se llega con adb reboot recovery. El modo de arranque (bootloader o fastboot) es de aún más bajo nivel: en él Android no llega a arrancar, y en su lugar corre un programa mínimo que permite escribir directamente en las particiones del dispositivo. A ese modo se llega con adb reboot bootloader, y una vez allí ADB deja de servir: el diálogo pasa a manos de fastboot.

fastboot es la herramienta hermana de ADB dentro de las platform-tools, y su comando de comprobación es análogo:

fastboot devices

Desde fastboot se realizan las operaciones más delicadas sobre un dispositivo. La más conocida es el desbloqueo del cargador de arranque, requisito para instalar sistemas alternativos, que primero exige activar «Desbloqueo de OEM» en las opciones de desarrollador y después ejecutar el comando de desbloqueo, el cual borra por completo el dispositivo como medida de seguridad:

fastboot flashing unlock

También se escriben imágenes en particiones concretas (fastboot flash), se arranca temporalmente una imagen sin instalarla (fastboot boot) o se reinicia el dispositivo (fastboot reboot). Conviene subrayar el enorme cuidado que exigen estas operaciones: un error al escribir en una partición del sistema puede dejar el dispositivo inservible, y el desbloqueo del cargador borra todos los datos. En un contexto forense, además, cualquiera de estas acciones modifica el dispositivo de forma profunda y, salvo casos muy justificados y documentados, queda descartada. Aquí las mencionamos para completar el mapa; su uso responsable requiere conocer a fondo el modelo concreto sobre el que se actúa.

ADB como herramienta forense: acceso con garantías

Todo lo anterior configura una herramienta de propósito general. Llega el momento de mirarla con los ojos del perito informático, porque en el análisis forense de dispositivos móviles ADB ocupa un lugar especial: es accesible, gratuita, transparente y está siempre disponible, cualidades que la hacen valiosísima cuando faltan medios para soluciones comerciales o cuando se necesita una granularidad que esas soluciones no ofrecen. Android domina el mercado mundial de teléfonos, de modo que saber extraer evidencia de un dispositivo Android con garantías es una competencia central de la informática forense.

El principio que gobierna todo el trabajo forense con ADB se puede enunciar en una frase: no contaminar la escena digital. Igual que en la investigación de una escena física no se toca nada sin guantes y sin documentar, en el trabajo con ADB la regla es no modificar el dispositivo. Cada comando que se ejecuta deja, potencialmente, una huella, y la defensa de cualquier caso examinará con lupa si el perito alteró aquello que dice haber analizado. De ahí que la primera clasificación mental que debe hacer un forense sea distinguir los comandos que solo leen de los que escriben.

Comando	Qué hace	Riesgo
Conexión y reconocimiento
`adb devices`	Lista los dispositivos conectados y su estado	Lectura
`adb shell getprop ro.product.model`	Modelo exacto del dispositivo	Lectura
`adb shell dumpsys battery`	Estado de la batería y marcas temporales	Lectura
Extracción de datos
`adb pull /sdcard/DCIM/`	Copia la galería al ordenador	Lectura
`adb exec-out screencap -p > p.png`	Captura el estado actual de la pantalla	Lectura
`adb logcat -b all -d > log.txt`	Vuelca los registros del sistema	Lectura
`adb backup -all -f copia.ab`	Copia de datos, si la aplicación lo permite	Precaución
Adquisición profunda e integridad
`adb shell dd if=/dev/block/...`	Imagen bit a bit de una partición	Lectura
`adb shell sha256sum ruta`	Calcula el hash de integridad de un archivo	Lectura
Interacción (documentar siempre)
`adb tcpip 5555`	Abre la depuración por red (puerto expuesto)	Precaución
`adb shell input tap x y`	Simula un toque en la pantalla	Precaución
Nunca sobre un dispositivo intervenido
`adb push archivo destino`	Escribe archivos: invalida la evidencia	Modifica
`adb install app.apk`	Instala software: contamina la escena digital	Modifica
`adb shell rm archivo`	Borra archivos: destrucción de evidencia	Modifica

La tabla anterior resume esa clasificación con un semáforo. En verde, los comandos de solo lectura, que son la inmensa mayoría de los útiles y los que forman el grueso de una adquisición. En ámbar, los que exigen precaución porque, aun siendo legítimos, implican alguna interacción que debe documentarse. En rojo, los tres comandos que nunca deberían ejecutarse sobre un dispositivo intervenido, porque escriben en él y, con ello, comprometen la integridad de la evidencia: adb push, que escribe archivos; adb install, que instala software; y adb shell rm, que borra datos. Tenerlos siempre presentes, y saber cuáles evitar, es tan importante como conocer los que sí se usan.

El orden de volatilidad

Cuando se adquiere evidencia de un dispositivo encendido, el orden importa, y no es arbitrario. Rige el llamado principio de volatilidad: se captura primero lo que antes puede desaparecer. Un dato en la memoria o en la pantalla es efímero; una imagen de partición es permanente y lenta de obtener. Por eso, en una intervención real, la secuencia sensata va de lo más volátil a lo más permanente.

El orden de captura por volatilidad y la cadena de custodia, del dispositivo al tribunal. · Esquema: elaboración propia.

En la práctica, esto significa asegurar primero la captura de pantalla, que refleja el estado exacto del dispositivo en ese instante —qué aplicación estaba abierta, qué conversación era visible—; después los registros del sistema, que se sobrescriben continuamente; a continuación las bases de datos de las aplicaciones, persistentes pero sensibles a cualquier escritura del sistema; y por último la imagen de partición, que es la evidencia más completa pero cuya extracción puede llevar horas, tiempo durante el cual la evidencia volátil ya habría desaparecido si no se hubiera capturado antes. Y, cerrando todo, la verificación de integridad de cada elemento obtenido.

La imagen de partición

La adquisición más completa que permite ADB es la imagen bit a bit de una partición, una copia exacta del dispositivo de bloque completo que abarca los archivos visibles y, además, el espacio no asignado, los restos de archivos borrados y los metadatos del sistema de archivos. Es la base de cualquier análisis posterior con herramientas como Autopsy. Primero se identifican las particiones, cuyos nombres varían entre fabricantes, y después se canaliza dd desde el dispositivo hacia el ordenador:

# Identificar las particiones por nombre
adb shell ls -la /dev/block/by-name/

# Imagen de la partición de datos de usuario (la más relevante)
adb shell "dd if=/dev/block/by-name/userdata bs=4096 conv=noerror,sync" > userdata.img

Los modificadores de dd son importantes: conv=noerror evita que la copia se detenga ante un sector defectuoso, y conv=sync rellena esos sectores para mantener la alineación exacta. Aquí aparece la gran limitación de los dispositivos modernos: el cifrado. Con el cifrado basado en archivos (FBE) o el cifrado de disco completo (FDE), la imagen extraída estará cifrada, y sin la clave —derivada del PIN del usuario y del hardware— los bytes son inservibles. Documentar si el dispositivo tenía cifrado activo es parte del informe.

La extracción de datos de aplicaciones

Las aplicaciones guardan casi todo en bases de datos SQLite dentro de su recinto privado. Cuando se dispone de acceso —en dispositivos con superusuario o mediante los mecanismos que cada aplicación exponga—, esas bases de datos son la mina de la investigación: mensajes, registros de llamadas, contactos, historiales. La extracción se hace con pull, y el análisis puede iniciarse con cualquier visor de SQLite. Sin privilegios de superusuario, muchas de esas rutas devolverán «Permission denied», y la vía alternativa es el sistema de copia de seguridad para las aplicaciones que lo permitan. En todos los casos, sobre un dispositivo intervenido rige una norma que no admite excepción: trabajar en modo lectura y no escribir jamás.

La verificación de integridad

Todo archivo extraído debe sellarse con una función hash, que es la demostración matemática de que no se ha alterado desde el momento de la adquisición. El procedimiento es el mismo para una imagen de 64 GB que para una captura de pantalla de 2 MB:

# Sellar todos los archivos extraídos
sha256sum *.img *.db *.txt *.png > HASHES_EVIDENCIA.txt

# Verificar la integridad en cualquier momento posterior
sha256sum -c HASHES_EVIDENCIA.txt

Ese archivo de hashes es en sí mismo un documento forense que debe firmarse digitalmente y fecharse. En España, la firma con certificado reconocido —el DNI electrónico o un certificado de la FNMT— le añade validez legal.

La cadena de custodia y el marco legal

Toda la técnica anterior tiene un único destino: un tribunal. Y allí la pregunta decisiva será cómo se demuestra que lo presentado es exactamente lo que había en el dispositivo, sin alteración alguna, desde la incautación hasta el juicio; el hallazgo concreto pierde todo su valor si ese cómo no se sostiene. Esa demostración documentada es la cadena de custodia, que va del acta de incautación —con la hora certificada, el estado del dispositivo y el número de precinto— al traslado en bolsa de Faraday que aísla el equipo de toda señal, y de ahí a la estación forense con bloqueador de escritura, la adquisición en modo lectura, el sellado con hash, el trabajo siempre sobre copia y nunca sobre el original, y el informe pericial final.

En el ordenamiento español, la evidencia digital se rige principalmente por la Ley de Enjuiciamiento Criminal, reformada por la Ley Orgánica 13/2015, cuyos artículos 588 sexies regulan el registro de dispositivos de almacenamiento masivo de información. El artículo 11 de la Ley Orgánica del Poder Judicial establece que las pruebas obtenidas vulnerando derechos fundamentales son nulas de pleno derecho, lo que significa que una cadena de custodia rota no solo debilita la prueba: la anula. Como marco técnico de referencia, la norma ISO/IEC 27037 sobre identificación, recogida, adquisición y preservación de evidencia digital orienta la práctica de los laboratorios acreditados. Documentar cada paso con este rigor ofrece un registro verificable de la verdad técnica que el sistema judicial puede examinar, cuestionar y contrastar, con independencia de a quién acabe favoreciendo. Eso es, exactamente, lo que la ciencia forense debe aportar.

Una sesión de adquisición, paso a paso

Todo lo anterior se entiende mejor viéndolo en acción. Reconstruyamos, de forma resumida, cómo sería una sesión de adquisición ordenada sobre un dispositivo autorizado, siguiendo el orden de volatilidad y dejando constancia de cada paso. Sirve de guion mental para cuando llegue el caso real.

El primer acto ocurre antes de tocar el teléfono: documentar el entorno forense. Se registra el equipo desde el que se trabaja, la versión exacta de ADB y el bloqueador de escritura empleado, y se abre un registro de sesión que capture todo lo que se teclee, con sus tiempos. En un equipo de tipo Unix, la utilidad script cumple ese cometido:

script -t 2> tiempos_sesion.log registro_sesion.log
adb version >> entorno.txt
date >> entorno.txt

A continuación se identifica el dispositivo, con el cotejo triple del número de serie y la ficha de propiedades que ya conocemos, de modo que quede probado sobre qué equipo se actúa:

adb devices -l
adb get-serialno
adb shell getprop ro.serialno
adb shell getprop ro.boot.serialno
adb shell getprop ro.product.model
adb shell getprop ro.build.fingerprint

Empieza entonces la captura, y aquí manda el orden de volatilidad. Primero, el estado más efímero: una captura de la pantalla tal como se recibió el dispositivo. Después, los registros del sistema, que se sobrescriben sin descanso:

adb exec-out screencap -p > 01_pantalla.png
adb logcat -b all -d > 02_logcat.txt

A continuación se recogen los datos persistentes accesibles —las zonas públicas del almacenamiento y, si el dispositivo lo permite, las copias de las aplicaciones que lo consientan— y, cuando el caso lo justifica y hay medios, la imagen de la partición de datos, que es la operación más lenta y por eso viene después de lo volátil:

adb pull /sdcard/ ./03_almacenamiento/
adb shell "dd if=/dev/block/by-name/userdata bs=4096 conv=noerror,sync" > 04_userdata.img

El cierre es la verificación de integridad de todo lo obtenido, que sella cada archivo con su hash y produce el documento que sostendrá la cadena de custodia:

sha256sum 01_pantalla.png 02_logcat.txt 04_userdata.img > HASHES.txt

Por último se cierra el registro de sesión (con exit, si se abrió con script), y ese archivo, junto con los hashes, la ficha del dispositivo y el acta, forma el expediente técnico. Cada comando ha quedado fechado y en orden, cada archivo sellado, y el original intacto para cualquier pericia contradictoria. Lo que en abstracto parecía una lista de normas se convierte, ejecutado con método, en una sesión de trabajo limpia y defendible.

La cara insegura de ADB: riesgos y defensa

La misma potencia que hace de ADB una herramienta tan útil la convierte en un riesgo cuando se usa sin cuidado, y conviene conocer su lado oscuro tanto para no crear vulnerabilidades como para entender ciertos ataques.

El peligro más citado es la depuración por red mal cerrada. Cuando se activa adb tcpip 5555, el teléfono queda escuchando conexiones ADB en ese puerto, y si el dispositivo está en una red no confiable —o, peor, expuesto a internet—, cualquiera que alcance ese puerto puede conectarse sin autorización, porque en modo TCP no siempre media el diálogo de clave RSA. Ha habido campañas de programas maliciosos que rastreaban internet en busca de dispositivos con el puerto 5555 abierto para infectarlos de forma automática; el caso de ADB.Miner, que propagó minado de criptomonedas entre dispositivos Android expuestos, es el ejemplo más conocido. La defensa es simple: no dejar la depuración por red activada más allá de lo imprescindible, y volver a USB con adb usb en cuanto se termina.

El segundo riesgo tiene que ver con las claves de autorización. La clave privada que el ordenador guarda en su carpeta de usuario es la llave que el teléfono reconoce; quien la copie puede suplantar a ese equipo de confianza y acceder al dispositivo sin que vuelva a pedirse permiso. De ahí la importancia de proteger el equipo forense o de desarrollo, y de revocar las autorizaciones de depuración desde el teléfono cuando se sospeche un compromiso o simplemente cuando se deje de confiar en un ordenador.

El tercero es de higiene general: dejar la depuración USB activada en un teléfono de uso diario amplía su superficie de ataque. Si el dispositivo se pierde o es sustraído, la depuración activa facilita el acceso a quien lo tenga en sus manos, sobre todo si además está desbloqueado. La recomendación para el usuario común es mantener la depuración desactivada salvo cuando se necesite, y no autorizar ordenadores en los que no se confíe plenamente. En entornos corporativos, las políticas de gestión de dispositivos suelen controlar o prohibir la depuración precisamente por este motivo.

Cuando ADB no coopera: diagnóstico de problemas

Pocas herramientas generan tanta frustración inicial como ADB cuando, sin más, no ve el teléfono. La buena noticia es que casi todos los problemas se reducen a unas pocas causas, y abordarlas con método las resuelve casi siempre.

Si adb devices no muestra nada, el orden de comprobación es claro. Primero, el cable: hay que descartar que sea de solo carga probando con otro, preferiblemente el original. Segundo, la depuración USB: confirmar que está activada en las opciones de desarrollador. Tercero, en Windows, el controlador: revisar en el Administrador de dispositivos que el teléfono aparece correctamente y, si no, instalar el controlador del fabricante o el genérico de Google. Cuarto, reiniciar el servidor con adb kill-server && adb start-server. Y quinto, probar otro puerto USB, evitando los concentradores y conectando directamente al ordenador.

Si el dispositivo aparece como unauthorized, el diálogo de autorización está pendiente: desbloquear la pantalla, aceptarlo y marcar «Permitir siempre». Si el diálogo no reaparece, ayuda revocar las autorizaciones en el teléfono y volver a conectar, o borrar las claves del ordenador (adbkey y adbkey.pub en la carpeta .android del usuario) para forzar que se generen de nuevo.

Si aparece como offline, el problema suele estar en el transporte o en un daemon atascado: cambiar de cable o de puerto, reiniciar el servidor y, si persiste, reiniciar el teléfono. En Linux con no permissions, la solución son las reglas udev, como vimos. Y si aparecen mensajes sobre versiones de protocolo incompatibles, casi siempre hay más de una instalación de ADB en el sistema: conviene localizarlas y quedarse con una sola, actualizada. Un último consejo que resuelve un número sorprendente de casos raros: reiniciar tanto el ordenador como el teléfono antes de dar por perdida una conexión.

Chuleta de referencia rápida

Reunimos aquí, a modo de consulta, los comandos más utilizados de esta guía, agrupados por función. Es la tabla que conviene tener cerca hasta que los dedos los recuerden solos.

Comando	Para qué sirve
Conexión y estado
`adb devices -l`	Lista los dispositivos con detalle
`adb kill-server / start-server`	Reinicia el servidor de ADB
`adb connect IP:5555`	Conecta por red (Wi-Fi)
`adb -s SERIAL <comando>`	Actúa sobre un dispositivo concreto
Aplicaciones
`adb install -r app.apk`	Instala o reinstala conservando datos
`adb uninstall paquete`	Desinstala una aplicación
`adb shell pm list packages -3`	Lista las aplicaciones de terceros
`adb shell pm path paquete`	Muestra la ruta del APK
Archivos
`adb push local remoto`	Sube un archivo al dispositivo
`adb pull remoto local`	Descarga un archivo al ordenador
Shell y sistema
`adb shell`	Abre la terminal del dispositivo
`adb shell getprop`	Muestra las propiedades del sistema
`adb shell settings get global ...`	Lee un valor de configuración
Registros y diagnóstico
`adb logcat -d`	Vuelca los registros y termina
`adb shell dumpsys <servicio>`	Estado de un servicio del sistema
`adb bugreport informe.zip`	Volcado completo de diagnóstico
Captura e interacción
`adb exec-out screencap -p`	Captura de pantalla al ordenador
`adb shell screenrecord ruta`	Graba vídeo de la pantalla
`adb shell input tap x y`	Simula un toque
Red y arranque
`adb forward tcp:X tcp:Y`	Puerto local del PC hacia el dispositivo
`adb reverse tcp:X tcp:Y`	Puerto del dispositivo hacia el PC
`adb reboot [recovery\|bootloader]`	Reinicia, opcionalmente a un modo
`fastboot devices`	Lista dispositivos en modo fastboot

Un puente que conviene conocer

ADB tiene algo de puente en un sentido muy literal: conecta dos mundos que, de otro modo, se dan la espalda. De un lado, el ordenador, con su comodidad, su almacenamiento y sus herramientas de análisis. Del otro, el teléfono, ese objeto cerrado que guarda buena parte de nuestra vida y que, sin una vía de entrada, resulta casi impenetrable. Aprender a cruzar ese puente con soltura abre posibilidades que van desde lo cotidiano —recuperar unas fotos, automatizar una tarea repetitiva— hasta lo decisivo, como reconstruir la actividad de un dispositivo en una investigación judicial.

A lo largo de estas páginas hemos recorrido el camino completo: qué es ADB y cómo se organiza por dentro, cómo instalarlo y hacer la primera conexión, cómo gestionar aplicaciones y archivos, cómo asomarse al shell y a los registros del sistema, cómo tender túneles de red y cómo emplear todo ello con las garantías que exige el trabajo pericial. No es un conocimiento que se agote en una lectura; la soltura llega con la práctica, y no hay mejor consejo para adquirirla que hacerse con unos cuantos teléfonos Android antiguos y experimentar sin miedo. Se descubre entonces algo revelador: incluso dentro de una misma familia de dispositivos, el ecosistema es sorprendentemente diverso, y cada modelo tiene sus rarezas. Dominar ADB es, en el fondo, aprender a conversar con esa diversidad.

Publicamos esta guía en abierto con la convicción de que el conocimiento técnico riguroso, explicado con claridad y en español, es un bien que merece circular. Ojalá sirva a quien empieza y también a quien, sabiendo ya, busca ordenar y afianzar lo que conoce.

Glosario mínimo

ADB (Android Debug Bridge). Herramienta oficial de línea de comandos, parte del SDK de Android, para comunicarse con un dispositivo desde un ordenador.

adbd. El daemon de ADB que se ejecuta dentro del dispositivo Android y atiende las órdenes que llegan del servidor.

Servidor ADB. Proceso en segundo plano del ordenador que gestiona la comunicación entre los clientes y los dispositivos, a la escucha en el puerto 5037.

platform-tools. Paquete oficial de Google que contiene adb, fastboot y otras utilidades.

fastboot. Herramienta de bajo nivel que opera cuando el dispositivo arranca en modo bootloader, usada para escribir particiones y desbloquear el cargador de arranque.

Sandbox. El aislamiento con el que Android confina cada aplicación, de modo que sus datos privados quedan fuera del alcance de las demás y del usuario shell.

FBE / FDE. Cifrado basado en archivos (File-Based Encryption) y cifrado de disco completo (Full-Disk Encryption), los dos esquemas de cifrado de Android.

Sideload. Modo en el que el dispositivo, desde la recuperación, espera la instalación de un paquete de actualización enviado desde el ordenador.

Clave RSA de autorización. Par de claves criptográficas con el que el teléfono reconoce a un ordenador de confianza para la depuración.

Orden de volatilidad. Principio forense según el cual se captura primero la evidencia más efímera y después la más permanente.

Fuentes y lecturas recomendadas

Android Open Source Project. (s. f.). ADB (Android Debug Bridge). AOSP. Recuperado de https://android.googlesource.com/platform/packages/modules/adb/+/refs/heads/main/README.md

Google. (s. f.). Android Debug Bridge (adb). Android Developers. Recuperado de https://developer.android.com/tools/adb

Google. (s. f.). SDK Platform Tools release notes. Android Developers. Recuperado de https://developer.android.com/tools/releases/platform-tools

Google. (s. f.). Run apps on a hardware device. Android Developers. Recuperado de https://developer.android.com/studio/run/device

Google. (s. f.). logcat command-line tool. Android Developers. Recuperado de https://developer.android.com/tools/logcat

International Organization for Standardization. (2012). ISO/IEC 27037:2012. Information technology — Security techniques — Guidelines for identification, collection, acquisition and preservation of digital evidence. ISO.

Jefatura del Estado. (2015). Ley Orgánica 13/2015, de 5 de octubre, de modificación de la Ley de Enjuiciamiento Criminal para el fortalecimiento de las garantías procesales y la regulación de las medidas de investigación tecnológica. Boletín Oficial del Estado, núm. 239. https://www.boe.es/eli/es/lo/2015/10/05/13

Genymobile. (s. f.). scrcpy: Display and control your Android device. GitHub. Recuperado de https://github.com/Genymobile/scrcpy

Créditos de los esquemas

Los ocho esquemas que ilustran esta guía (arquitectura de ADB, puesta en marcha, estados del dispositivo, conexión inalámbrica, mapa de comandos, anatomía del shell, reenvío de puertos y flujo forense con cadena de custodia) son de elaboración propia, realizados expresamente para este trabajo. La composición de portada (16:9) es igualmente original.