Google está a punto de cambiar las reglas del ecosistema Android de una manera que todavía no muchos están viendo con claridad. A partir de septiembre de 2026, en países seleccionados, y con despliegue global en 2027, cualquier desarrollador que quiera que su APK se instale en un dispositivo certificado con Android tendrá que registrar su identidad real en la Android Developer Console: identificación oficial, correo electrónico, número de teléfono. Sin excepción. El argumento oficial es reducir el malware en aplicaciones instaladas por sideload, que según Google genera cincuenta veces más infecciones que las apps distribuidas por Play Store. El argumento real —el que vale la pena analizar— es considerablemente más complicado.

Antes de descartar esto como un problema técnico menor, conviene entender qué significa el sideload en la práctica cotidiana. No es solo para usuarios avanzados que instalan ROMs personalizadas. Es la vía por la que millones de personas acceden a aplicaciones que Google ha decidido excluir de su tienda por razones que le convienen a su modelo de negocio. AdGuard, uno de los bloqueadores de anuncios más respetados del mundo, no está en Play Store precisamente porque bloquear publicidad atenta contra los ingresos de Google. Lo mismo aplica a decenas de herramientas de privacidad, apps de código abierto y proyectos personales que no tienen cabida en el ecosistema oficial.

La política de verificación obligatoria pone a estos desarrolladores en una posición incómoda. AdGuard, por ejemplo, ha construido parte de su propuesta de valor sobre la posibilidad de distribuir su software de forma independiente, sin revelar datos de identidad a la plataforma que tiene incentivos directos para sabotear su negocio. Con la nueva política, ese anonimato desaparece. No es paranoia: es una tensión estructural real entre el verificador y el verificado. AdGuard ya lanzó la campaña #KeepAndroidOpen junto con otros actores del ecosistema, y la presión comunitaria va creciendo, aunque todavía no hay demandas formales en proceso.

Reconozco estas constantes en otros contextos donde una plataforma dominante introduce requisitos de "seguridad" que, por diseño o por consecuencia, terminan eliminando a los competidores más incómodos. No hace falta especular mucho: la historia de las plataformas tecnológicas está llena de movimientos así. Microsoft y el mercado de navegadores en los años noventa. Apple y las restricciones al sideload en iOS, que tardaron años en generar respuesta regulatoria europea. Ahora Google y Android, el sistema operativo que nació bajo la promesa de ser abierto.

Lo que está en juego no es solo la comodidad de unos cuantos desarrolladores independientes. F-Droid, el repositorio de código abierto que funciona como alternativa comunitaria a Play Store, quedaría efectivamente bloqueado para usuarios de dispositivos certificados si sus contribuyentes —muchos de ellos anónimos o pseudónimos por elección— no se registran con identidad real. Proyectos personales, herramientas educativas, apps sin fines de lucro: todos caen en el mismo saco. Y la barrera de los veinticinco dólares de la cuenta de desarrollador, que puede parecer trivial, es suficiente para excluir a aficionados en economías donde ese monto no es insignificante.

El argumento del malware merece tomarse en serio, porque no es falso. Las apps instaladas por fuera de las tiendas oficiales tienen tasas de infección considerablemente más altas, y eso genera daño real a usuarios reales. Pero la solución propuesta tiene un problema de proporcionalidad. Es como responder a los robos en un mercado construyendo una muralla que solo deja entrar a quienes pagan una cuota y muestran identificación, y luego llamarle "seguridad" al hecho de que los vendedores pequeños ya no pueden entrar. La muralla reduce algunos robos, sí. También concentra todo el comercio en manos de quien controla la puerta.

Este tipo de movimiento tiene precedentes históricos claros. Los gremios medievales europeos usaron exactamente esta lógica: la certificación obligatoria como mecanismo de calidad que, en la práctica, funcionaba para excluir competencia externa y consolidar el poder de los miembros establecidos. No era malicia pura; había genuina preocupación por estándares. Pero el resultado estructural era concentración. Cuando los mercados se abrieron y los gremios perdieron control, la innovación explotó en múltiples direcciones. Esa tendencia —certificación como dominio de mercado disfrazado de estándar de calidad— sigue apareciendo cada vez que una plataforma dominante siente presión de competidores que no puede comprar ni absorber.

El momento elegido no es casual. Google enfrenta presión antimonopolio en múltiples frentes, incluyendo el fallo de agosto de 2024 en EE.UU. que determinó que mantuvo ilegalmente su monopolio en búsquedas. En ese contexto, reforzar el dominio sobre Android —el sistema operativo que corre en más del ochenta por ciento de los dispositivos móviles globales— tiene una lógica defensiva. Si el ecosistema de apps queda más centralizado bajo verificación de Google, la capacidad de competidores para distribuir software alternativo se reduce, y con ella la presión sobre el modelo publicitario que es el corazón del negocio.

La resistencia que está emergiendo es interesante porque no es solo técnica. Hay cartas públicas de desarrolladores, hay organizaciones de derechos digitales documentando el impacto, y hay una conversación creciente sobre qué significa "código abierto" cuando la plataforma que lo ejecuta puede decidir quién tiene acceso. F-Droid y proyectos similares llevan años construyendo infraestructura alternativa, y ese trabajo cobra más relevancia ahora. Las economías emergentes, que en muchos casos dependen más del sideload por razones de acceso y costo, tienen mucho que perder con esta política y probablemente mucho que decir en los próximos meses.

Todavía no está claro cómo termina esto. La presión regulatoria europea, que ya obligó a Apple a abrir iOS al sideload en la Unión Europea, podría eventualmente alcanzar a Google en territorios similares. Pero eso toma tiempo, y para septiembre de 2026 la política ya estará operando. Lo que sí es claro es que la respuesta más inteligente no es solo resistencia pasiva: es fortalecer las alternativas. F-Droid necesita más contribuyentes. Los bloqueadores de anuncios necesitan más usuarios que entiendan por qué importa su independencia. Y la conversación sobre qué Android queremos —abierto de verdad o abierto solo en el nombre— necesita salir del círculo técnico y llegar a usuarios que todavía no saben que esta decisión los afecta directamente.

Las organizaciones tienden a cerrarse cuando se vuelven rentables y cuando quienes las controlan sienten que la apertura les cuesta más de lo que les da. Android llegó a ese punto. La pregunta no es si Google tiene el derecho técnico de implementar esta política —probablemente lo tiene, dentro de los límites legales actuales—. La pregunta es si los usuarios, los desarrolladores y los reguladores van a aceptar que "abierto" se redefina hasta significar lo opuesto.

Las piedras no mienten, pero los historiadores a veces sí.

Fuentes:

1. Google Android Developer Policy Center — Developer identity verification requirements (2025)

2. AdGuard Blog — #KeepAndroidOpen campaign documentation

3. F-Droid Project — Official repository and contributor guidelines (f-droid.org)

4. U.S. Department of Justice v. Google LLC — Fallo antimonopolio, agosto 2024

5. European Commission — Digital Markets Act, obligaciones de sideload para gatekeepers (2023-2024)