Adiós al ADB local: Android va a restringirlo y Shizuku dejará de funcionar para siempre

Si alguna vez usaste Shizuku para conceder permisos sin root, o conectaste tu celular a Android Studio por WiFi, esta noticia te va a doler.

Google está considerando restringir las conexiones ADB locales (las que vienen del mismo dispositivo) para "proteger a los usuarios de actores maliciosos". Y si el cambio se concreta, Shizuku, libadb y un ecosistema entero de apps de poder van a dejar de funcionar.

Aquí te explico qué está pasando, por qué Google lo quiere hacer, y cómo podría afectarte antes de que sea demasiado tarde.

¿Qué es ADB local y por qué debería importarte?

ADB (Android Debug Bridge) es el protocolo que Google creó para que los desarrolladores pudieran hacer cosas de desarrollador en Android: depurar apps, ejecutar comandos avanzados, acceder a archivos del sistema. Cosas útiles. Cosas de power users.

Pero desde Android 11, los desarrolladores descubrieron que podían usar ADB de una forma que Google no anticipó: conexiones loopback locales. Básicamente, el mismo teléfono se conecta a sí mismo vía ADB. Y de ahí nació Shizuku.

Shizuku permite que apps sin root ejecuten comandos con privilegios elevados usando una conexión ADB local. Es la base de herramientas como libadb, Call Recorder, y decenas de apps de automatización. Sin root. Sin riesgos de seguridad. Sin anular la garantía.

Y ahora Google quiere matarlo.

¿Qué cambia exactamente?

En un issue de Google IssueTracker, uno de los mantenedores principales de ADB (empleado de Google) comentó que están evaluando restringir las conexiones ADB que vienen del mismo dispositivo.

La justificación: "proteger a los usuarios de actores maliciosos".

Según Google, un malware podría usar ADB local para escalar privilegios sin que el usuario se dé cuenta. En teoría, tienen razón. En la práctica, Shizuku ya tiene capas de seguridad — cada app que quiere usarlo debe ser autorizada explícitamente por el usuario, y el token ADB se genera en cada sesión.

Kitsumed, el desarrollador de ShizukuCallRecorder (una app basada en Shizuku que usa ADB local), lo explicó mejor:

"Si Google bloquea loopback ADB, mataría un ecosistema entero de aplicaciones open-source para power users, configuraciones de desarrollo móvil, y herramientas de privacidad sin root."

¿A quién afecta realmente?

1. Usuarios de Shizuku — Si usas Shizuku para conceder permisos a apps como MacroDroid, Call Recorder, o cualquier herramienta de automatización, dejas de poder hacerlo. Sin root, sin alternativa.

2. Desarrolladores que usan ADB inalámbrico — Android 11+ permite depurar por WiFi. Con el cambio, las conexiones TCP/IP locales (desde el mismo dispositivo) también estarían restringidas. Sí, eso incluye conectarte desde Termux a tu propio teléfono.

3. Usuarios con discapacidades — Kitsumed desarrolló ShizukuCallRecorder precisamente porque necesitaba grabar llamadas para accesibilidad. La grabación de llamadas en Android es un desastre, y Shizuku era la única forma de hacerlo sin perder privacidad en apps de terceros cerradas.

4. Cualquiera que quiera control sobre su propio dispositivo — En un mundo donde cada fabricante te dice cómo usar "tu" teléfono, ADB local era una de las últimas herramientas de libertad.

¿Es necesario o es sobrecontrol?

Google argumenta que el cambio es por seguridad. Y sí, técnicamente, un malware con acceso al puerto ADB podría causar daños. Pero el mismo argumento aplicaría a decir "vamos a quitarle el volante a los autos porque algunos conductores chocan".

ADB es una herramienta de desarrollador. Requiere activación explícita en Opciones de Desarrollador. Shizuku requiere autorización expresa por app. No es un vector de ataque masivo porque el usuario ya saltó 3 barreras de seguridad para activarlo.

Y cabe preguntarse: si Google realmente quisiera proteger a los usuarios, ¿por qué no ponen una advertencia adicional en lugar de romper todo el ecosistema?

La respuesta, como siempre, es que a Google no le conviene que los usuarios tengan control real sobre sus dispositivos. Un usuario que puede grabar llamadas, automatizar tareas y modificar comportamientos del sistema sin pasar por Google Play Services es un usuario que no necesita el "jardín amurallado" de Google.

¿Hay esperanza?

Aún no es oficial. Esto es, por ahora, un comentario en un IssueTracker. Pero el mantenedor de ADB está asignado al tema, y el cambio está en evaluación activa. Kitsumed recomienda:

• Si tienes un caso de uso legítimo, publica un comentario constructivo en el IssueTracker de Google explicando tu workflow
• No hagas spam ni publiques quejas genéricas — eso solo hará que Google cierre el hilo y tome la decisión sin feedback real
• Sigue el progreso del issue para saber cuándo y cómo se implementa (si se implementa)

Mientras tanto, no actualices Android a la versión que implemente este cambio. Si tienes un dispositivo que pueda quedarse en una versión anterior, considera mantenerlo ahí.

El futuro de Android es más control, no menos

Google está cerrando la puerta a los power users lentamente, una decisión a la vez. Primero fue la restricción de permisos de llamadas. Luego la eliminación del acceso a archivos sin Scoped Storage. Ahora esto.

Android era el sistema operativo de la libertad. Donde podías hacer lo que quisieras con tu dispositivo porque era tuyo. Cada vez se parece más a iOS: un sistema donde Apple/Google deciden qué puedes y no puedes hacer.

Si esto sigue así, en cinco años no habrá diferencia entre Android y iPhone. La pregunta es: ¿vamos a dejar que pase?

Comparte esto si crees que tu teléfono debería seguir siendo tuyo.