El emulador de Android Studio es cómodo, pero hay comportamientos que solo aparecen en un móvil físico: rendimiento real del GPS, consumo de batería, cómo reacciona la app cuando el sistema mata procesos en segundo plano, o cómo se ve realmente la interfaz en una pantalla con una densidad de píxeles distinta a la que simula el emulador. En el desarrollo de Caladero, que depende bastante de la ubicación y del mapa, probar en un móvil físico no es opcional. ADB (Android Debug Bridge) es la herramienta que hace posible esa conexión entre el ordenador y el dispositivo real.

Qué es ADB y por qué hace falta

ADB es una herramienta de línea de comandos que viene incluida con el Android SDK y permite comunicarse con un dispositivo Android (físico o emulado) desde el ordenador: instalar apps, ver logs en tiempo real, ejecutar comandos del sistema, o depurar directamente desde Android Studio. Sin ADB, la única forma de probar una app en un móvil real sería exportar un APK e instalarlo manualmente cada vez, sin logs ni depuración en directo, lo cual es inviable durante el desarrollo activo.

Activar las opciones de desarrollador en el móvil

Antes de que ADB pueda ver el dispositivo, hay que activar el modo desarrollador en el propio móvil:

  1. Entrar en Ajustes → Acerca del teléfono.
  2. Pulsar siete veces seguidas sobre "Número de compilación" hasta que aparezca el mensaje de que el modo desarrollador está activado.
  3. Volver a Ajustes, entrar en la nueva sección "Opciones de desarrollador".
  4. Activar "Depuración por USB".

Este paso varía ligeramente según el fabricante (Samsung, Xiaomi y otros a veces esconden esta opción en submenús distintos), pero el patrón de "pulsar varias veces sobre el número de compilación" es constante en Android desde hace años. La documentación oficial de Android sobre configuración de un dispositivo para desarrollo está en developer.android.com.

Conectar por USB

Con el cable conectado y la depuración USB activada, el primer comando que ejecuto siempre es:

adb devices

La primera vez que conectas un móvil nuevo, aparece un diálogo en la pantalla del propio dispositivo pidiendo autorizar el acceso desde ese ordenador, con la huella RSA del equipo. Hay que aceptar ese diálogo, y opcionalmente marcar "recordar en este ordenador" para no repetirlo cada vez. Si el comando adb devices no muestra el dispositivo, suele deberse a uno de estos motivos: el cable USB es solo de carga y no transmite datos, el diálogo de autorización no se aceptó, o faltan los drivers USB del fabricante en el ordenador (más frecuente en Windows).

Conectar por Wi-Fi sin cable

Una vez emparejado el dispositivo por USB al menos una vez, es posible pasar a depuración inalámbrica, algo que agradezco especialmente cuando pruebo funcionalidades de ubicación y necesito moverme físicamente con el móvil sin arrastrar el cable:

adb tcpip 5555
adb connect 192.168.1.50:5555

La IP es la del móvil dentro de la red local, visible en Ajustes → Wi-Fi → detalles de la red conectada. A partir de versiones recientes de Android, existe también el emparejamiento inalámbrico mediante código QR desde las propias opciones de desarrollador, sin pasar primero por USB, lo cual simplifica bastante el proceso en dispositivos nuevos.

Ver los logs en tiempo real

El comando que más uso durante el desarrollo es logcat, que muestra el flujo de logs del sistema y de la propia app en tiempo real:

adb logcat --pid=$(adb shell pidof -s dev.caprini.caladero)

Filtrar por el PID del proceso de la propia app evita el ruido de logs de todo el sistema operativo, que en un móvil real es mucho mayor que en un emulador limpio. También uso filtros por etiqueta cuando quiero seguir solo los logs de un componente concreto:

adb logcat -s "PuntosRepository:*" "*:E"

Ese comando muestra solo los logs con la etiqueta PuntosRepository en cualquier nivel, más cualquier error (E) de cualquier otra parte de la app, lo que es útil para no perder de vista errores inesperados mientras sigo el rastro de un componente concreto.

Un caso práctico: depurar un fallo de ubicación que no aparecía en el emulador

Durante el desarrollo de Caladero tuve un bug donde la app tardaba mucho más de lo esperado en obtener la primera ubicación GPS al abrir la pantalla del mapa, pero solo en el móvil físico, nunca en el emulador. El emulador simula una ubicación fija instantánea, así que ese problema era literalmente invisible sin probar en hardware real.

Usando adb logcat filtrado por el proveedor de ubicación pude ver que el sistema estaba esperando una señal de GPS con precisión alta antes de entregar cualquier resultado, mientras que mi código no estaba aprovechando la última ubicación conocida como valor provisional mientras llegaba una lectura más precisa. La solución fue mostrar la última ubicación conocida (getLastLocation()) de inmediato y actualizar después con la lectura en tiempo real, en vez de esperar a que llegara la primera lectura antes de mostrar nada en el mapa. Sin depuración en dispositivo físico, este comportamiento habría llegado sin detectar hasta una prueba manual mucho más tardía.

Errores comunes y cómo los resuelvo

  • "unauthorized" en adb devices: normalmente significa que el diálogo de autorización en el móvil no se aceptó, o quedó pendiente detrás de otra pantalla. Desbloquear el móvil y revisar notificaciones suele resolverlo.
  • El dispositivo desaparece tras un rato en Wi-Fi: la conexión ADB por Wi-Fi se puede perder si el móvil entra en modo ahorro de energía agresivo, algo común en Xiaomi y Huawei. Añadir la app y el propio proceso ADB a la lista de apps sin restricciones de batería suele solucionarlo.
  • INSTALL_FAILED_INSUFFICIENT_STORAGE: aparece con más frecuencia en dispositivos físicos con poco espacio libre que en el emulador, donde el almacenamiento suele ser generoso por defecto.

Conclusión

ADB no es opcional para quien desarrolla en Android más allá de un prototipo trivial. El emulador es rápido para iterar sobre la interfaz, pero el comportamiento real de sensores, ubicación, batería y rendimiento del sistema solo se ve con fiabilidad en un dispositivo físico. Aprender a conectar por USB y por Wi-Fi, y sobre todo a leer los logs de forma dirigida con logcat, es de las habilidades que más tiempo me ha ahorrado en el desarrollo diario, mucho más que cualquier configuración avanzada de Android Studio.