Google cierra Android: el sideloading se convierte en una odisea de 9 pasos y 24 horas de espera

Llevamos años diciéndolo: Android es Android precisamente por lo que iOS nunca ha sido. La libertad de instalar lo que quieras, desde donde quieras, sin tener que pedir permiso a nadie. Esa libertad tiene nombre: sideloading. Y a partir de septiembre de 2026, Google va a hacer todo lo posible para que esa libertad deje de ser cómoda, accesible y, en muchos casos, viable.

Si eres usuario avanzado, desarrollador indie o simplemente alguien que alguna vez instaló una APK de F-Droid, APKMirror o GitHub, lo que viene a continuación te va a interesar —y probablemente a enfurecer— en igual medida.

¿Qué está pasando exactamente?

Leemos en XDA que Google ha anunciado a través de su blog oficial de desarrolladores que, comenzando en septiembre de 2026 en dispositivos certificados Android de regiones seleccionadas, implantará un nuevo sistema de verificación de desarrolladores. La política se extenderá progresivamente a todos los dispositivos certificados a nivel mundial.

En términos simples: si una app no está distribuida por un desarrollador registrado directamente con Google, tu teléfono pondrá todas las trabas del mundo para que no puedas instalarla.
El proceso actual de sideloading es relativamente sencillo: activas la opción de «orígenes desconocidos» en los ajustes y listo. Lo que viene es otra historia.

El nuevo «flujo avanzado»: 9 pasos y una espera de 24 horas

Google lo llama oficialmente «Sideloading with… advanced flow» y, si no fuera tan grave, casi resultaría cómico. Estos son los pasos que tendrás que seguir para instalar una app de un desarrollador no registrado:

• Ir a Ajustes del sistema y pulsar el número de compilación del software 7 veces para activar el Modo Desarrollador.
• Navegar a Ajustes → Sistema → Opciones de desarrollador.
• Activar el nuevo interruptor «Permitir paquetes no verificados».
• Confirmar en una pantalla de advertencia que no estás siendo coaccionado.
• Introducir tu PIN o contraseña biométrica.
• Reiniciar el dispositivo.
• Esperar el período de espera obligatorio e irrenunciable de 24 horas.
• Volver al menú de paquetes no verificados y pasar por pantallas adicionales de advertencia.
• Elegir si permites la instalación de forma temporal (7 días) o indefinida, reconfirmando que entiendes los «graves riesgos» del sideloading.

Sí, has leído bien. Un día de espera. Como si Google hubiera decidido modelar su política de seguridad en los anuncios no saltables de YouTube.

Un sistema de tres niveles: no todos los desarrolladores son iguales

La nueva política establece una jerarquía clara en función del estado de verificación del desarrollador:

• Tier 1 — Desarrolladores verificados (sin cambios): Grandes compañías como Netflix, WhatsApp, Microsoft… Nada cambia para ellos. Puedes seguir descargando su APK desde APKMirror o cualquier fuente de confianza sin que Google te ponga trabas. El sistema mantiene la ilusión de plataforma abierta para estos actores.
• Tier 2 — Cuentas de distribución limitada: Para los desarrolladores indie que no quieran pagar los 25$ de la tasa de registro ni entregar su DNI a Google, existirán las llamadas «limited distribution accounts». ¿El problema? Solo podrán instalar su app en 20 dispositivos únicos. Eso mata de raíz cualquier programa de beta testing comunitario, cualquier proyecto open source que dependa de la distribución boca a boca, y cualquier desarrollador hobbyista que quiera compartir su trabajo sin pasar por el aro corporativo.
• Tier 3 — Desarrolladores no registrados: El famoso advanced flow de los 9 pasos descrito anteriormente. Bienvenido al infierno burocrático del sideloading.

El argumento de Google: seguridad. El problema: no se sostiene

Google justifica este cambio citando la necesidad de proteger a los usuarios de la coacción en estafas de phishing, donde actores maliciosos mantienen a las víctimas al teléfono para saltarse las advertencias de seguridad. Es un vector de ataque real y los que trabajamos en seguridad Android lo conocemos bien.

Sin embargo, el argumento tiene un problema fundamental: Android ya tiene Google Play Protect, que analiza localmente cada app instalada en busca de malware, independientemente del origen de la APK y de la identidad del desarrollador. Si la herramienta ya existe y funciona, ¿por qué añadir esta capa de burocracia que penaliza a millones de usuarios avanzados?

La respuesta incómoda es que esto no va realmente de seguridad. O al menos no solo de seguridad.

Lo que Google no dice: el dinero detrás de la decisión

Aquí es donde la cosa se pone interesante. Pensemos en el proyecto ReVanced: herramientas de parcheo que permiten a usuarios técnicamente competentes disfrutar de reproducción en segundo plano y YouTube sin anuncios, funciones que Google vende bajo su suscripción YouTube Premium. Google lleva años en guerra con estos proyectos y esta nueva política les pone directamente a su merced.

Si ReVanced o cualquier proyecto similar no quiere registrar su app en la consola de desarrolladores de Android, acordar términos irrevocables y entregar las claves de firma privadas a Google, sus herramientas se vuelven inútiles para el 99% de los usuarios. Y si lo hace, Google tendrá toda la información necesaria para tomar medidas legales o técnicas en cualquier momento.

Los programas de acceso anticipado para la verificación de desarrolladores ya están en marcha. Las cuentas de distribución limitada están a punto de lanzarse globalmente. El reloj corre.

El impacto en desarrolladores: más allá de las grandes plataformas

Hay un colectivo que normalmente queda fuera del debate y que aquí se lleva la peor parte: los desarrolladores que distribuyen exclusivamente fuera de Google Play. F-Droid, GitHub, itch.io… todos ellos están en el punto de mira.

Aunque tu app nunca haya estado en la Play Store, aunque nunca hayas cobrado un euro por ella y aunque la distribuyas libremente, Google exigirá que la registres en su Developer Console, que aceptes sus términos y que subas evidencia de tus claves de firma privadas. Si no lo haces, Google puede bloquear silenciosamente tu app en todos los dispositivos Android del mundo.

¿El impacto en la privacidad? Periodistas, activistas, whistleblowers y desarrolladores que operan bajo regímenes autoritarios y que dependen del anonimato se verán forzados a salir de Android.

Hay también un punto filosófico importante: esto se implementa directamente a través de Google Play Services, que es código propietario, no parte del AOSP (Android Open Source Project). Esto significa que Google puede endurecer o eliminar completamente esta vía de sideloading en cualquier momento, sin necesidad de una actualización del sistema operativo, sin previo aviso y sin necesidad de consentimiento del usuario.

La hipocresía del argumento de seguridad

Hay algo profundamente irónico en que Google tome estas medidas para proteger a los usuarios del malware externo mientras la Play Store sigue siendo un hervidero de apps scam, adware de baja calidad y clones fraudulentos. No es un secreto ni una opinión controvertida: los informes de seguridad año tras año documentan cómo la inmensa mayoría del malware que infecta dispositivos Android llega precisamente a través de la tienda oficial.
Añadir una capa extra de burocracia para las apps externas mientras el problema endémico del malware en la propia plataforma sigue sin resolverse huele a lo que es: un movimiento estratégico disfrazado de actualización de seguridad.

¿Hay algo que puedas hacer?

Sí. Existe la iniciativa KeepAndroidOpen en keepandroidopen.org, donde la comunidad está coordinando respuestas a esta política. Si te importa la apertura de Android, es el momento de involucrarse.
Más allá de eso, estas son las implicaciones prácticas que deberías tener en cuenta de cara a septiembre:

Si usas apps de F-Droid que no tienen versión en Play Store, comprueba si sus desarrolladores planean registrarse en el sistema de verificación.
Si eres desarrollador y distribuyes fuera de Play Store, empieza a valorar el coste-beneficio de registrarte o no en la Developer Console.
Si eres usuario avanzado que instala APKs habitualmente, asegúrate de hacer copias de seguridad de las versiones actuales de las apps que más usas.

Y si todo esto te parece demasiado y estás buscando alternativas, quizás sea el momento de echarle un ojo serio a lo que están haciendo proyectos como postmarketOS o Ubuntu Touch. Linux en smartphones lleva años madurando y, aunque todavía no está al nivel de Android, las restricciones que vienen quizás aceleran su adopción más de lo que nadie esperaba.

Android ya no será lo que era

Hay cambios que son graduales y cambios que marcan una ruptura. Este es del segundo tipo. La capacidad de instalar software libremente en hardware que tú posees ha sido durante 15 años una de las razones fundamentales por las que millones de usuarios eligieron Android sobre iOS. No era un bug del sistema: era una funcionalidad, era una filosofía.

Google puede argumentar hasta el infinito que esto es por la seguridad de los usuarios. Pero cuando implementas estos cambios a través de código propietario, cuando exiges claves de firma privadas de desarrolladores independientes, cuando eliminas funcionalidades de forma silenciosa sin posibilidad de apelación… eso no es seguridad. Es control.

El jardín amurallado de Apple siempre fue su identidad. El jardín de Google siempre se presentó como lo opuesto. A partir de septiembre, ya no habrá tanta diferencia entre ambos.

¿Qué opinas de este movimiento de Google? ¿Crees que es una medida de seguridad justificada o un ataque directo a la apertura de Android? Déjanos tu opinión en los comentarios.