- F-Droid critica que Android Developer Verification (ADV) ya se desplegó en dispositivos con Android 8 o superior, y que podría convertirse en un mecanismo de control centralizado que impida ejecutar apps de desarrolladores no aprobados por Google
- Google lo presenta como una medida para frenar la propagación de malware, pero F-Droid considera que ADV no logra tanto bloquear la distribución inicial como elevar el costo de que desarrolladores reincidentes vuelvan a registrarse
- El registro de desarrolladores exige crear una cuenta, pagar una cuota, enviar información personal y una identificación emitida por el gobierno, registrar identificadores de apps y claves de firma, y aceptar los términos de Android Developer Console
- La preocupación central es que, si los términos no incluyen una definición clara de malware, Google podría ampliar los objetivos de bloqueo por motivos comerciales o bajo presión gubernamental
- Se aplicará desde el 30 de septiembre de 2026 empezando por Brasil, Indonesia, Singapur y Tailandia; el impacto real sobre la app de F-Droid, las apps instaladas, los datos de las apps y la telemetría de verificación de Google todavía es incierto
Por qué F-Droid comparó ADV con malware
- F-Droid considera que Android Developer Verifier (ADV) está instalado en dispositivos con Android 8 o superior y se encuentra a la espera de activación remota
- Se plantea la estimación de que ADV ya fue desplegado en hasta 4.000 millones de teléfonos y tablets Android, y que podría afectar a cerca de la mitad de la población mundial
- Este servicio del sistema se ejecuta en segundo plano, y F-Droid afirma que no puede bloquearlo, desactivarlo ni eliminarlo
- Play Protect es un servicio que detecta y responde al malware común en dispositivos Android Certified, pero F-Droid critica que ADV se distribuye e instala a través de Play Protect
- Tras su activación, considera que el objetivo de ADV será impedir la ejecución de software de desarrolladores que Google no haya aprobado de forma centralizada
Refutación del argumento de prevención de malware
- F-Droid planteó por primera vez sus preocupaciones sobre Android Developer Verification en septiembre de 2025, en F-Droid and Google’s Developer Registration Decree
- El requisito de registro centralizado de desarrolladores de Google se presenta como una medida para evitar la propagación de malware, pero F-Droid considera que este sistema no impide la distribución inicial por parte de actores maliciosos
- Su efecto real se acercaría más a ralentizar la conducta de infractores reincidentes ya identificados, que tendrían que crear o comprar una cuenta nueva si quisieran seguir distribuyendo malware con una nueva clave de firma
- También plantea que existen alternativas menos coercitivas
- Play Protect podría examinar con mayor detalle las apps recién instaladas con permisos elevados o las apps obtenidas desde rutas sospechosas
- También sería posible un modelo de verificadores federados, en el que el usuario elija directamente en qué verificadores y autoridades confiar, como en DCM: A Developers Certification Model for Mobile Ecosystems
- F-Droid critica que Google use un vector de amenaza estrecho como motivo para rediseñar el ecosistema Android y convertirse en el único gatekeeper que decide qué apps pueden existir
Proceso de registro de desarrolladores y riesgos de los términos
- En contra de la recomendación de F-Droid, si un desarrollador se registra ante Google como desarrollador “verificado”, debe pasar por el siguiente proceso
- Crear una cuenta y pagar una cuota
- Enviar información personal detallada
- Subir una identificación emitida por el gobierno
- Registrar los identificadores y claves de firma de las apps que distribuye actualmente y que distribuirá en el futuro
- El punto más importante de disputa es que se exige aceptar los términos de servicio de Android Developer Console
- La cláusula 6.5 indica que Google puede cancelar el acceso a ADC si el desarrollador infringe los términos o distribuye malware o una harmful application
- F-Droid señala que en ninguna parte del documento hay una definición, criterios o lineamientos oficiales para “malware”
- Si la definición queda vacía, “malware” pasa a ser el software que Google llame así, y su alcance podría variar según motivaciones comerciales o una fuerte presión gubernamental
El problema del alcance del bloqueo que muestra el caso de los ad blockers
- F-Droid advierte que es riesgoso dejar que términos controvertidos sean definidos por una parte con intereses contrapuestos
- Como ejemplo representativo menciona los ad blockers, herramientas personales de filtrado de contenido
- Hace tiempo existen casos de ad blockers prohibidos en Play Store
- En algunos casos, fueron clasificados como malware
- F-Droid teme que Google pueda designar todo el software de bloqueo de anuncios como malware, impedir su instalación en dispositivos Android Certified de todo el mundo y clasificar a sus desarrolladores como creadores de malware
- Considera que esa posibilidad encaja con los incentivos del negocio de tecnología publicitaria de Google y con el texto de los términos de Android Developer Console
Afirmaciones sobre adopción y movimientos de oposición
- Google dijo recientemente que más del 99% de las apps de desarrolladores de Play ya estaban registradas, pero F-Droid responde que eso no puede tomarse como prueba de una adopción amplia de ADV
- Según F-Droid, esos desarrolladores ya estaban atados a contratos existentes de Play Store, por lo que fueron incluidos automáticamente sin suficiente consentimiento previo
- También continúan los movimientos de oposición a ADV
- Cientos de miles de personas firmaron la petición contra ADV
- La Open Letter de keepandroidopen.org fue firmada por más de 70 organizaciones de todo el mundo, entre ellas EFF, FSF, FSFE, ACLU y Forbrukerrådet
- Afirma que un video de una mesa redonda de desarrolladores que intentaba defender el programa recibió dislike del 90% de los espectadores
- F-Droid dice que los legisladores y reguladores hasta ahora no han respondido a las críticas
- Considera que el modelo de seguridad de F-Droid, basado en transparencia de código abierto, entra en conflicto fundamental con el modelo de confianza de las tiendas de apps comerciales cerradas
Incertidumbres restantes antes de la aplicación del 30 de septiembre
- Todavía no se sabe con precisión en qué modo de falla se manifestará la activación de ADV el 30 de septiembre de 2026
- Según el calendario público de Google, los primeros países afectados serán Brasil, Indonesia, Singapur y Tailandia
- Se indica que en esos 4 países viven 580 millones de personas
- El despliegue mundial está previsto para “2027 en adelante”
- Para los usuarios de las regiones afectadas, siguen pendientes preguntas que aún necesitan respuesta
- No se sabe qué ocurrirá al intentar instalar o ejecutar la app de F-Droid
- No está claro si las apps instaladas a través de F-Droid serán desactivadas o eliminadas
- No se sabe si, en caso de que una app de la que se dependía desaparezca repentinamente, se podrá seguir accediendo a los datos que contiene
- No se sabe qué información de telemetría se incluirá cuando toda instalación y ejecución de software sea reportada para la verificación de Google
- F-Droid envió consultas al respecto y afirmó que ofrecerá orientación y soporte adicionales a los usuarios afectados durante las semanas y meses previos a la aplicación del bloqueo
2 comentarios
En realidad, decir que no pasa nada porque existen sistemas operativos alternativos no tiene mucho sentido... Ahora mismo, para instalar otro SO en un Galaxy hay que desactivar el chip de seguridad de hardware, y entonces no podrás usar cosas como pagos o apps bancarias.
Opiniones de Hacker News
Aunque no resuelve el problema actual, vale la pena saber que existen varios sistemas operativos Linux para móviles reales por si no se logra frenar esta tendencia.
SailfishOS está basado en Linux y su comunidad parece bastante inclusiva, pero su stack de UI es de código cerrado. Es el único que puede ejecutar oficialmente apps de Android mediante emulación; es veterano, liviano y parece el más estable y con menos bugs de esta lista.
Ubuntu Touch es completamente open source y está impulsado por la comunidad; usa paquetes snap por seguridad y también podría ejecutar apps de Android. La última vez que lo probé, también era bastante estable.
PureOS es completamente open source y está centrado en la privacidad. Hasta donde sé, entre lo que se lanzó junto con el Librem 5, es el único que permite evitar blobs binarios propietarios para la integración con el hardware. Parece menos estable que SailfishOS o Ubuntu Touch, y para usarlo hay que comprar un Librem 5, que es bastante caro aunque ya sea antiguo.
PostmarketOS es completamente open source y se enfoca en ser liviano y en revivir teléfonos antiguos; tiene muchísimos dispositivos probados y está basado en Alpine.
Mobian es la versión móvil de Debian y, dentro de esta lista, es relativamente nuevo. Hay más sistemas operativos Linux para móviles además de estos, pero hasta donde sé estas son las principales opciones; algunas las probé hace mucho tiempo, así que podría haber imprecisiones, y las dos últimas no las he usado realmente.
Las apps que corren encima no quedan más aisladas del kernel Linux, sino menos. Si te importan la privacidad y la seguridad, estos sistemas operativos son mucho menos privados y mucho menos seguros que Android Open Source Project. No tienen un sandbox de apps completo y funcional ni un modelo de permisos, tampoco mitigaciones modernas de vulnerabilidades, ni funciones serias de cifrado basado en hardware necesarias para impedir la extracción de datos.
A diferencia de un sistema operativo basado en AOSP sobre buen hardware, que puede ser una alternativa al iPhone, estos no son una alternativa seria desde el punto de vista de la privacidad y la seguridad. Esta advertencia se agrega a los sistemas operativos con Google Mobile Services y no afecta negativamente a otros sistemas operativos basados en Android Open Source Project.
Linux no significa necesariamente GNU/Linux ni systemd/Linux, ni implica usar glibc, systemd, GNU coreutils, Bash, GNOME, etc. Los sistemas operativos basados en Android, incluidos AOSP y GrapheneOS, también son distribuciones Linux. Alpine no usa glibc y SailfishOS también tiene su propia combinación de software abierto y cerrado. Usar el stack típico de espacio de usuario de Linux de escritorio no determina si algo es Linux, y ni siquiera en el escritorio la configuración de uso es consistente.
Personalmente no uso apps de Android en el Librem 5, pero Waydroid está en los repositorios de PureOS. Waydroid es un enfoque basado en contenedores que inicia un sistema Android completo en un sistema GNU/Linux común que usa un entorno de escritorio basado en Wayland.
PureOS también ofrece convergencia mediante Phosh. Aquí, convergencia significa usar las mismas apps tanto en el teléfono como en una pantalla grande, y que la GUI se adapte al tamaño de pantalla disponible.
Phosh busca ofrecer un entorno gráfico de usuario sólido y fácil para uso diario en dispositivos móviles que ejecutan Linux mainline. Originalmente lo iniciaron desarrolladores de Purism para el Librem 5, pero ahora se usa en varios dispositivos como smartphones, tablets y convertibles, e incluso se ha visto en laptops.
La UI/UX es costosa, y a la mayoría de los proyectos libres y open source les cuesta hacerla bien sin grandes inversiones empresariales o apoyo de startups. Por ejemplo, los diseñadores de UX de Red Hat contribuyeron mucho a GNOME, y también hay casos de startups como Zed, Element y Bluesky.
Los proyectos sin ese respaldo suelen ser difíciles de usar, al menos desde la perspectiva de la generación Z.
Los usuarios de Android deberían pasarse a Graphene
Alguien debería crear una fundación de sistemas operativos móviles basados en Linux. El dominio de Google también va en contra de los intereses de muchas grandes empresas, y si se acercan a compañías similares a Meta, podrían donar mucho dinero por intereses estratégicos.
Cuando Google sienta que ya logró suficiente estabilidad y compatibilidad con un asignador de memoria reforzado y memoria etiquetada, y pueda hacer que Qualcomm lo soporte en toda su línea de productos, hará que Graphene sea más difícil y al final imposible.
Aunque es un artículo viejo, según [1], Android de Google y los miembros de la Open Handset Alliance tienen prohibido por contrato fabricar dispositivos que Google no haya aprobado.
Para competir, habría que crear también Google Play Services compatibles y encontrar fabricantes que los soporten. Samsung durante un tiempo operó sus propias apps y tienda [2] junto con Tizen, quizá para ganar poder de negociación o para una transición teórica. Pero después abandonó ese esfuerzo.
[1] https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...
[2] https://arstechnica.com/tech-policy/2021/07/google-bought-of...
Muchos usuarios comunes, sobre todo fuera de Estados Unidos, no pueden permitirse eso. Además, comprar un teléfono de Google es alimentar a Google, y personalmente preferiría evitarlo.
Eliminar la necesidad de drivers propietarios en espacio de usuario para componentes como las GPU Mali modernas también es posible con AOSP, y hacerlo así beneficia a la mayor cantidad de gente. Si muchas empresas y otras entidades unen fuerzas, se puede lograr en AOSP.
También podría ocurrir por intervención gubernamental debido a las violaciones antimonopolio de Google, pero si se hace mal, podría manejarse de una forma que perjudique al código abierto.
Entiendo la frustración. Yo también uso fdroid intensamente en varios dispositivos. Pero este texto se ve infantil por expresiones como virus, troyano y “empresa de malware”.
Artículos así les dan a muchos, quizá incluso a Google, una excusa para descartar lo que dice fdroid como “argumentos infantiles que no hace falta tomar en serio”. Por ejemplo, un medio de comunicación respetable no publicaría este texto.
Dicho sea de paso, https://keepandroidopen.org/ es un caso mejor elaborado.
No hay ninguna garantía de que no se use para fines ajenos a la seguridad. Además, también es cierto que en la práctica no ayuda mucho a la seguridad.
Si le preguntas a Google Search, la IA explica que el malware es software diseñado para acceso no autorizado, interferencia, extorsión o toma de control de dispositivos. Aun así, si crees que esta expresión no encaja, imagina que alguien creara una app con la misma funcionalidad. Google la eliminaría de inmediato como malware. La vería como malware evidente.
La razón por la que uso Android es porque puedo instalar lo que quiera en mi teléfono, y esto no debería ser polémico. El teléfono es mío, o no lo es. No quiero la protección de Google. Especialmente si no puedo rechazarla.
En computación, un caballo de Troya es un tipo de malware que se disfraza de programa legítimo para engañar al usuario sobre su verdadera intención [1].
Google, hasta lo de abajo, es todo un caballo de Troya. ¿Cuál es la verdadera intención de casi todos los productos de Google? Recolectar datos.
Todos sus productos son spyware de alguna forma. Subvencionan a fabricantes para que incluyan su spyware, e incluso convirtieron los televisores en caballos de Troya.
[1] https://en.wikipedia.org/wiki/Trojan_horse_(computing)
Para ver algunos puntos, el sideloading lo usa menos del 1-2% de los usuarios de Android en todo el mundo, como mucho unas 50 millones de personas. Google en realidad hizo un favor al dejarlo abierto con solo una demora de 24 horas. Podría haber sido peor, pero por ahora no es gran cosa dentro del eterno hobby de andar toqueteando las opciones de desarrollador. Personalmente, le agradezco a Google
GMS les da una comodidad enorme a los desarrolladores de apps que necesitan un control fuerte, incluidos los gobiernos. Pueden proteger sus apps frente a usuarios de cualquier signo. Si a eso le sumamos la posibilidad de puertas traseras ocultas que faciliten la vigilancia y el lobby directo de Google en la UE, aunque hoy la UE tenga una orientación antiestadounidense, le resultará muy difícil prescindir de GMS, y será lo último que se reemplace en Europa
También hay varios niveles de “desGoogleización”. El espectro va desde instalar un SO completamente abierto, con o sin microG, hasta simplemente no iniciar sesión con una cuenta de Google en un Android básico. Pero quienes están en el extremo libre nunca tendrán los mismos derechos que quienes están en el extremo carcelario
La certificación de desarrolladores no es para impedir el bloqueo de anuncios. Hay formas simples y gratuitas de bloquear lo que quieras a nivel DNS. Basta con elegir Private DNS y poner una URL adecuada de algún servicio como controld.com para bloquear anuncios, rastreadores y porno. Hay que buscar otra justificación. Por ejemplo, un fuerte control del usuario para seguir acostándose con los gobiernos, o el intento de llegar a la vigilancia definitiva del usuario mediante la verificación de identidad infantil que está por venir
Todo lo demás también son distintas formas de defensa de Google. Sinceramente, es profundamente desalentador, y más aún que esta reacción aparezca precisamente en Hacker News
La verificación de origen es un arma poderosa para combatir el software malicioso, pero preservar la capacidad de instalar y ejecutar software anónimo es esencial para enfrentarse a regímenes autoritarios y sistemas corruptos
Si aceptamos que solo el software firmado y autorizado pueda instalarse y ejecutarse en los teléfonos de los usuarios, la democracia y la libertad están acabadas. Da igual si es en Occidente o en Oriente, o si se trata de enfrentarse a señores supremos de la IA
En gran parte del hardware y software del que dependemos no podemos hacer cambios arbitrarios. Tampoco podemos examinar su diseño, reproducirlo ni, a veces, repararlo
A veces ni siquiera podemos saber si fueron diseñados en contra de nuestros intereses, y aunque lo sepamos, en algunos casos no podemos hacer nada. Se nos obliga a elegir entre precio y privacidad, entre interoperabilidad con monopolios o sistemas oficiales y libertad
Que Android dé otro paso en esta dirección es malo. Pero no nos engañemos: llevamos décadas hundidos hasta el cuello en una servidumbre cyberpunk. Incluso si ganamos esta pelea por Android, será apenas una pequeña victoria
No lo digo en plan derrotista, sino para no olvidar la pelea más grande. ¿Cómo termina este Goliat feudal? ¿Cuándo será suficiente?
Mientras tanto, en Luxemburgo, Google perdió el caso contra la multa de 4.700 millones de dólares de la UE por Android
https://www.msn.com/en-us/money/other/google-loses-fight-aga...
Todavía me desconcierta un poco por qué la UE no toma medidas en este asunto. Esto claramente es un abuso de poder de un monopolista, y debería impedirse desde el principio
https://www.eu-digital-markets-act.com/Digital_Markets_Act_A...
Durante décadas aceptamos que los proveedores de SO pudieran hacer estas cosas. Creo que eso fue un error: depender de Google como único proveedor posible. No se puede crear una ley para castigar a Google porque hasta ahora haya sido abierto
Por supuesto, al igual que otros hackers de HN, estoy a favor de obligar también a Apple a abrirse, pero parece que las élites que actualmente dirigen la UE y muchos votantes tienen bastante aprecio por la atestación DRM remota para sus proyectos de identidad digital, que pronto será necesaria para todo lo que no sea apto para niños pequeños y no pueda accederse como dark web
Los usuarios de HN, especialmente los estadounidenses, tienen la ingenuidad de pensar en la UE como un bastión de la libertad. Para nada. La UE solo quiere convertirse en un enorme Estado niñera, y esto no es más que una forma presentable de permitirte hacer cualquier cosa, siempre que esté aprobada