Google evalúa restringir el ADB local y amenaza a Shizuku

Un mantenedor de ADB en Google escribió, en un hilo público de Issue Tracker, que el equipo evalúa restringir las conexiones locales del protocolo para frenar a los llamados bad actors. La propuesta, si avanza, rompería el flujo de trabajo de Shizuku, el framework que miles de desarrolladores usan para acceder a APIs de sistema sin rootear el teléfono.

No hay anuncio oficial ni fecha de implementación. El caso lo documentó el desarrollador que firma como Kitsumed, creador de la app ShizuCallRecorder basada en Shizuku, en una publicación de su blog que recopila el hilo completo.

TL;DR

• Un mantenedor de ADB en Google comentó en un hilo de Issue Tracker que evalúan restringir el ADB local para frenar a bad actors.- No es un anuncio oficial: es un comentario en un feature request todavía abierto, sin fecha de implementación confirmada.- La restricción afectaría a Shizuku, el framework que da acceso a APIs de sistema sin rootear el teléfono, y a librerías como libadb.- Android admite ADB por USB, por TCP/IP en el puerto 5555 sin cifrar, y por Wireless Debugging cifrado desde Android 11.- El ADB on-device no es un término oficial: describe correr el cliente y el demonio de ADB en el mismo teléfono, sin PC.- El desarrollador Kitsumed, creador de ShizuCallRecorder, documenta usos legítimos como grabar llamadas por discapacidad.- Google pide feedback técnico detallado en el Issue Tracker y advierte que el spam en el hilo puede hacer que lo cierren.

Qué pasó

El origen del debate es un feature request abierto en el Issue Tracker público de Google, el sistema donde cualquiera puede reportar bugs o pedir cambios en sus productos. En los comentarios de ese hilo, uno de los mantenedores principales de ADB, empleado de Google, planteó restringir las conexiones de ADB local como medida de seguridad.

Kitsumed aclara en su blog que esto no es un anuncio de producto. Es, en sus palabras, una señal temprana que vale la pena tomar en serio sin generar pánico. El propio autor pide a la comunidad que no llene el hilo con comentarios de baja calidad (quejas, insultos, menciones a monopolios), porque eso suele provocar que Google bloquee el issue o deje de compartir actualizaciones públicas sobre el tema.

La recomendación para developers afectados es concreta: si tenés un caso de uso único, escribí un comentario técnico y detallado con tu flujo de trabajo real, con links o soluciones de compromiso. Si tu caso ya fue mencionado, alcanza con darle +1 al issue y activar las notificaciones para seguir la discusión.

Contexto e historia: qué es ADB y sus tres modos de conexión

ADB son las siglas de Android Debug Bridge, un protocolo que Google diseñó para que developers ejecuten tareas de bajo nivel sobre un dispositivo: instalar apps sin pasar por Play Store, leer logs del sistema, otorgar permisos que normalmente exigen interacción manual, o simular eventos de teclado y pantalla. Es una herramienta estándar de cualquier flujo de trabajo Android, documentada en la referencia oficial de ADB.

ADB nació pensado para el cable USB, pero con los años sumó dos formas más de conectar cliente y dispositivo:

• USB: el modo original. El cliente corre en la computadora y se conecta al teléfono por cable.- TCP/IP: se habilita una vez que ya existe una conexión ADB activa. Corre en texto plano sobre el puerto 5555 por defecto y pide confirmar la conexión con un simple sí o no en pantalla.- Wireless Debugging: llegó en Android 11 para reemplazar el flujo TCP/IP. Empareja la computadora con el teléfono mediante un código o un QR y, a partir de ahí, abre una sesión autenticada y cifrada, sin necesitar una conexión ADB previa. ModoCuándo se usaVentajaLimitaciónUSBDebug con cable, primer emparejamientoEstable, no depende de la redRequiere cable y driver en la computadoraTCP/IP (puerto 5555)Automatizar por script, con sesión ya activaNo requiere cable tras la primera conexiónTráfico sin cifrar, solo confirma con sí o noWireless DebuggingEmparejar desde cero, Android 11+Sesión cifrada y autenticada, sin conexión previaHay que reparear si cambia la red Wi-FiADB on-device (loopback)Frameworks como Shizuku, sin computadoraDa permisos de sistema sin rootearEs el modo que Google evalúa restringir ## ADB on-device: el mecanismo detrás de Shizuku

El uso pensado originalmente para ADB necesita dos dispositivos: el teléfono corre el demonio (adbd) y una computadora corre el cliente adb. No todos los developers tienen una segunda máquina a mano. De ahí surgió lo que la comunidad llama ADB on-device: correr cliente y demonio en el mismo teléfono, conectándose a sí mismo por loopback, ya sea vía TCP/IP local o vía Wireless Debugging emparejado con el propio dispositivo.

Ese truco es la base de Shizuku, un framework open source que expone permisos y APIs de sistema (los mismos que usa ADB) a apps normales, sin exigir que el usuario rootee el teléfono. Una vez activo, las apps compatibles piden autorización a través del gestor de Shizuku y después llaman funciones que de otro modo estarían bloqueadas para una app instalada desde Play Store.

💭 Clave: ADB on-device no es un término oficial de Google. La comunidad lo usa para describir cualquier flujo donde el cliente y el demonio de ADB corren en el mismo teléfono, sin pasar por una computadora.
El modo TCP/IP usa el puerto 5555 sin cifrar, a diferencia del Wireless Debugging.

Shizuku, libadb y los casos de uso reales

Kitsumed usa Shizuku para ShizuCallRecorder, una app que graba llamadas. La construyó para compensar una discapacidad propia: puede vivir sin ella, dice, pero el día a día es más simple con la app activa. También cuenta que descubrió usos que no esperaba, como el de una persona en Reddit que la usó para conservar el buzón de voz de un ser querido fallecido.

La grabación de llamadas en Android es un tema espinoso desde hace años. Hubo un intento oficial de sumarla como API nativa en Android 11 que Google canceló después. Mientras tanto, circulan apps cerradas que resuelven el problema con métodos invasivos para la privacidad, y algunos fabricantes fuerzan un aviso de audio del tipo This call is being recorded incluso en lugares donde no es un requisito legal.

El argumento de fondo, según Kitsumed: si Google cierra la puerta del ADB local sin ofrecer una alternativa, la señal que reciben los usuarios con necesidades reales es que el camino transparente deja de existir y solo quedan las soluciones cerradas y menos auditables.

Cómo probarlo hoy: ADB local y Shizuku paso a paso

Para el flujo clásico de dos dispositivos necesitás platform-tools de Android instalado en tu computadora. La instalación cambia según el sistema operativo:

# Windows (PowerShell)
winget install --id Google.PlatformTools

# macOS (Homebrew)
brew install android-platform-tools

# Linux (Debian/Ubuntu)
sudo apt install android-sdk-platform-tools

# Emparejar por Wireless Debugging (Android 11+)
adb pair 192.168.1.42:41381
adb connect 192.168.1.42:38217
adb shell getprop ro.build.version.release

El comando adb pair usa el código que te muestra el teléfono en Ajustes > Opciones de desarrollador > Depuración inalámbrica. El último comando confirma que la sesión está viva devolviendo la versión de Android instalada.

Para el flujo on-device, instalá la app Shizuku desde su repositorio oficial y activala usando la opción de Wireless Debugging directamente desde los Ajustes del sistema, sin pasar por una computadora. Una vez que el gestor de Shizuku muestra el estado activo, cualquier app compatible puede pedir el permiso:

val binderActivo = Shizuku.pingBinder()
if (binderActivo && Shizuku.checkSelfPermission() == PackageManager.PERMISSION_GRANTED) {
    val proceso = Shizuku.newProcess(
        arrayOf("pm", "grant", packageName, "android.permission.READ_CALL_LOG"),
        null,
        null
    )
    proceso.waitFor()
} else {
    Shizuku.requestPermission(CODIGO_SOLICITUD_SHIZUKU)
}

Ese snippet pide el binder de Shizuku, comprueba si la app ya tiene permiso y, si lo tiene, ejecuta un comando con privilegios equivalentes a los de una sesión ADB. Para confirmar que Shizuku sigue corriendo desde la terminal, podés correr adb shell dumpsys activity services rikka.shizuku y buscar el estado de ejecución en la salida.

flowchart TD
A["App compatible con Shizuku"] --> B["Shizuku Manager (rish)"]
B --> C["ADB local (loopback)"]
C --> D["APIs de sistema Android"]
subgraph "Mismo dispositivo"
B
C
D
end

Shizuku corre el demonio y el cliente de ADB en el mismo dispositivo, sin PC.

Impacto y análisis

Si Google restringe el ADB local, el golpe no cae solo sobre Shizuku. Cualquier herramienta construida sobre libadb o sobre el proceso que deja corriendo Shizuku pierde su vía de acceso: automatizadores como MacroDroid o Tasker con módulos Shizuku, apps de accesibilidad, y utilidades de debug que corren directo desde el teléfono sin computadora.

El argumento de seguridad tiene sustento técnico. El ADB local, al no requerir una segunda máquina, es más fácil de automatizar desde una app maliciosa que desde un flujo tradicional que exige intervención humana en una computadora distinta. Kitsumed reconoce esto en su blog, aunque insiste en que la mayoría del uso real es legítimo y que bloquear el mecanismo entero castiga a los casos de uso válidos junto con los abusivos.

⚠️ Ojo: El argumento de Google para restringir el ADB local es de seguridad: una app maliciosa que automatice el emparejamiento podría intentar escalar privilegios sin que el usuario lo note. Es una preocupación distinta, pero relacionada, con los cambios recientes de Google en las políticas de sideloading de Android.

Para desarrolladores en LATAM que dependen de Shizuku en apps de accesibilidad, automatización o testing, la señal a seguir de cerca no es el timeline (todavía no existe), sino qué tipo de compromiso técnico propone Google si el cambio avanza: un permiso explícito adicional sería mucho menos disruptivo que un bloqueo total del loopback.

Qué sigue

No hay fecha ni documento de producto público. Kitsumed menciona que vio actualizaciones recientes de asignación de tareas relacionadas con quien lideraba el trabajo de ADB en Google, lo que podría significar que el tema avanza internamente, aunque no hay confirmación de qué forma tomará el cambio final.

La recomendación sigue siendo la misma: developers con un caso de uso concreto deberían dejar feedback técnico y detallado en el Issue Tracker, con su flujo de trabajo real y, si es posible, una propuesta de compromiso. El resto de la comunidad puede sumar un +1 al issue y activar notificaciones para seguir la discusión sin saturar el hilo.

📖 Resumen en Telegram: Ver resumen

Probalo vos: instalá platform-tools, emparejá tu teléfono con adb pair y sumá tu caso de uso al feature request del Issue Tracker antes de que Google tome una decisión final.

Preguntas frecuentes

¿Qué es Shizuku y por qué depende del ADB local?

Shizuku es un framework open source que usa el mismo canal de permisos que ADB para darle a apps normales acceso a APIs de sistema, sin pedir root. Necesita una sesión ADB, por Wireless Debugging o por loopback, para arrancar su proceso con privilegios elevados.

¿Google ya confirmó que va a restringir el ADB local?

No. Lo único público es un comentario de un mantenedor de ADB en un feature request del Issue Tracker. No hay changelog, fecha ni documento oficial de producto todavía.

¿Cuál es la diferencia entre ADB por TCP/IP y Wireless Debugging?

TCP/IP corre sobre el puerto 5555 sin cifrar y necesita que ya exista una conexión ADB activa para habilitarse. Wireless Debugging, sumado en Android 11, empareja por código o QR y abre una sesión cifrada sin depender de una conexión previa.

¿Qué otras apps se verían afectadas además de Shizuku?

Cualquier herramienta construida sobre libadb o sobre el proceso de Shizuku: automatizadores como MacroDroid o Tasker con módulos Shizuku, apps de accesibilidad, y utilidades de debug que corren directo desde el teléfono.

¿Cómo puedo dar feedback a Google sobre este cambio?

Si tenés un caso de uso puntual, sumá un comentario técnico y detallado en el Issue Tracker, con tu flujo de trabajo real. Si tu caso ya está mencionado, alcanza con darle +1 al issue y activar notificaciones.

¿Hay alguna alternativa si Google restringe el loopback de ADB?

Todavía no. Por eso Kitsumed pide feedback técnico en el hilo: la idea es que Google evalúe un compromiso, por ejemplo algún tipo de permiso explícito, en vez de bloquear el mecanismo por completo.

Referencias

• Kitsumed Blog: publicación original que documenta el hilo de Issue Tracker sobre restringir el ADB on-device.- Android Debug Bridge (referencia oficial): documentación de Google sobre los modos USB, TCP/IP y Wireless Debugging de ADB.- Shizuku en GitHub: repositorio oficial del framework que expone APIs de sistema sin root usando ADB.- Google Issue Tracker: sistema público donde se reportan bugs y feature requests de productos de Google, incluido ADB.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.