11 puntos por GN⁺ 2025-09-17 | 7 comentarios | Compartir por WhatsApp
  • A medida que el ecosistema de Android se cierra rápidamente, crece la necesidad de desarrollar smartphones basados en Linux como alternativa abierta
  • Google volvió privado el desarrollo de algunos componentes de AOSP, y los principales fabricantes eliminan la opción de desbloquear el bootloader, limitando la libertad de los usuarios
  • Debido a la Play Integrity API, la instalación de apps queda restringida sin iniciar sesión con una cuenta de Google, e incluso la billetera de identidad de la UE fuerza esta dependencia
  • La verificación obligatoria de identidad para desarrolladores afecta a la mayoría de los dispositivos y acelera la contracción del ecosistema de apps open source, como ya se vio con la descontinuación de Syncthing Android y el rechazo de actualizaciones de NextCloud
  • En la práctica, Android está convergiendo hacia una plataforma cerrada como Apple, por lo que el avance de un OS móvil abierto basado en Linux se vuelve urgente para preservar la competencia y la innovación

Introducción

Últimamente, el entorno de Android se está moviendo con rapidez hacia un mayor cierre, en vez de mantener su apertura

El cierre del ecosistema Android

  • Google muestra una tendencia a pasar al desarrollo privado de cada vez más componentes clave dentro de AOSP (Android Open Source Project)
  • Fabricantes importantes como Samsung, Xiaomi y OnePlus están eliminando la posibilidad de desbloquear el bootloader en todos sus dispositivos, aumentando así las restricciones para los usuarios
  • Se espera que Google también se sume a esto en el futuro

La política de Google de reforzar el control

  • Google está imponiendo la Play Integrity API y recomendando a los desarrolladores implementar funciones relacionadas
    • Como resultado, para usar apps de Google Play Store ahora se requiere iniciar sesión con una cuenta del OS a nivel de todo el sistema
    • Incluso apps oficiales de verificación de identidad exigidas por la Unión Europea (UE) están siguiendo esta política, lo que ha generado polémica
    • La reacción de desarrolladores open source en Github y otros sitios ha continuado
  • También está previsto introducir la obligatoriedad de la verificación de desarrolladores (verification) en el sistema Android
    • No afecta directamente a los OS de terceros, pero sí alcanza a la mayoría de los dispositivos Android
    • En adelante, es muy probable que muchos desarrolladores open source, en desacuerdo con las políticas de Google, abandonen por completo el desarrollo de apps para Android

La crisis del desarrollo de apps open source en Android

  • De hecho, el proyecto SyncThing dejó de desarrollar su app para Android por problemas con las políticas de Google Play
  • Las actualizaciones de la app de NextCloud también fueron rechazadas varias veces por Google (sin explicar el motivo), y solo se restablecieron tras protestas masivas
  • Google incluso está avanzando con políticas que clasifican como “riesgoso” o “no confiable” software que refuerza la soberanía del usuario, como los bloqueadores de anuncios
  • Se espera que esta serie de mecanismos de verificación y control se aplique todavía más en el futuro

La necesidad de un OS alternativo

  • Antes existía una competencia de plataformas entre Google y Apple, pero tras recientes grandes juicios antimonopolio en los que Google salió prácticamente sin sanciones, la competencia real ha desaparecido
  • Google está tomando como referencia el modelo de control de mercado de Apple y avanzando en la dirección de abandonar la apertura de Android
  • El Android actual ya no puede considerarse realmente una “plataforma abierta”, y corre el riesgo de perder por completo la apertura que antes tenía en un futuro cercano

Conclusión: urge desarrollar teléfonos Linux

  • Si Android en la práctica converge hacia una plataforma cerrada,
    • hará falta una plataforma alternativa libre tanto para desarrolladores como para usuarios
  • Los OS móviles basados en Linux todavía están incompletos, pero
    • en este momento es importante acelerar la inversión y el ritmo de desarrollo
  • Esto no significa simplemente “cambiarse a Linux ahora mismo”, sino prepararse para la futura dinámica competitiva

Resumen de comentarios: "¿Por qué importan los teléfonos Linux?"

Expectativas sobre alternativas Linux

  • Anekdoteles: está dispuesto a soportar inconvenientes y cambiarse a una alternativa Linux tras el EOL para salir de la dependencia de las big tech
  • thastings: presenta Droidian (basado en Debian+Phosh, usando drivers de Android mediante Halium)
    • La mayoría de las funciones, incluida la cámara, funcionan bien, y con Waydroid se pueden ejecutar apps de Android
    • Recomienda dispositivos con soporte para SoC recientes como Thinkphone (Motorola, SD8+ Gen1)
    • Furilabs FLX1 también sería una buena alternativa
  • freebee: imagina como escenario ideal un Valve SteamPhone — hardware potente + Arch + soporte para contenedor con modo Android

Límites reales y frustración

  • Raptor: el problema no son las apps ni el OS, sino la calidad del hardware; faltan prestaciones básicas de un teléfono, como los parlantes
  • hendrik: cuenta su experiencia con Pinephone; el hardware es lento y faltan funciones clave como connected standby y notificaciones, por lo que casi no sirve para uso real
    • Tenía expectativas desde el Nokia N900 de 2009, pero el progreso ha sido lento y ve poco probable que aparezca una alternativa antes de que Google endurezca sus políticas en 2027
  • glitching: un teléfono Linux no es una alternativa a Android sino básicamente un “PDA que corre Linux”
    • La batería, la flexibilidad, las llamadas y la cámara siguen siendo deficientes
    • Las apps están pensadas sobre todo para escritorio, así que no se adaptan bien a la UX móvil
    • El proceso de instalación también es complejo y con alta tasa de fallos
    • En la práctica hoy no hay nada que realmente “reemplace” a Android; como mucho se puede experimentar instalando LineageOS/pmOS en un flagship usado

Debate sobre proyectos y ecosistema

  • Ulrich: no se trata de cambiarse ya mismo, sino de que ahora es justamente cuando hace falta acelerar el desarrollo
    • PostmarketOS parece lo más maduro, pero hace falta colaboración de toda la comunidad
  • Vittelius: Ubuntu Touch y Sailfish son las alternativas más pulidas comercialmente
    • PostmarketOS se siente como “poner Linux de escritorio en un teléfono”, por lo que la UX queda corta
    • En cambio, UT y Sailfish fueron diseñados desde el inicio como OS móviles y tienen un mayor nivel de acabado
  • eldavi: no tiene sentido compararlo con el capital de las grandes corporaciones; hay que reconocer los límites de los proyectos comunitarios
  • hendrik (réplica): Linux ya logró enormes avances en servidores y PC, y por eso hay que mantener expectativas altas también en teléfonos
  • Zink: el smartphone ya es solo un “electrodoméstico de comunicación”, usado principalmente como sustituto de apps de PC
    • Un teléfono Linux con dock podría ser ideal, pero las oportunidades estarían más en el mercado empresarial que en la adopción masiva

En conjunto

  • Los usuarios coinciden en que hacen falta alternativas ante la profundización de la dependencia de las big tech, pero
  • hay mucho pesimismo realista porque faltan funciones básicas para el uso diario, como calidad de hardware, apps esenciales, notificaciones/standby/batería
  • Se mencionan Droidian, PostmarketOS, Ubuntu Touch y Sailfish, y se vuelve a enfatizar que la colaboración comunitaria y la inversión de largo plazo son indispensables

7 comentarios

 
mango 2025-09-19

Android está bueno jaja, mucho mejor que iOS

 
anjin225 2025-09-17

Vamos, Tizen

 
carnoxen 2025-09-17

Viendo que Firefox OS fracasó, pues no sé...

 
chcv0313 2025-09-17

Debe poder cumplir con problemas legales como las restricciones sobre la grabación de llamadas en cada país, ¿pero será posible?

 
coremaker 2025-09-17

Esto no solo implica un tema de software, sino también de hardware terminado,
así que me parece que sería difícil que este tipo de ideas se hagan realidad.

Al final se llegará a una situación en la que habrá que cobrar dinero,
y si por eso surgen problemas comerciales (seguridad, errores, hackeos, robo, etc.),
¿no terminará convergiendo en la misma dirección que Android?

 
opminsu 2025-09-17

Estoy de acuerdo.

 
GN⁺ 2025-09-17
Opiniones de Hacker News
  • Mi teléfono Android no me deja tomar capturas de pantalla si el desarrollador de la app no quiere.
    Si mi operadora lo exige, tampoco me deja grabar llamadas. Eso aunque en mi jurisdicción sea legal.
    Esta tendencia no me gusta nada.

    • Lo más frustrante de que los desarrolladores bloqueen las capturas es que no te enteras de que están bloqueadas hasta que intentas hacer una.
      Tomas la captura y solo queda una imagen completamente blanca.
      Las apps financieras usan mucho esta política creyendo que así están protegidas.
    • No es solo un problema del teléfono.
      Si le haces a una IA como ChatGPT o Gemini una pregunta que no gusta en Silicon Valley, cuesta obtener respuesta.
      El ambiente es de que solo se permite una respuesta.
      Y parece que esto va a empeorar.
    • Antes tuve este problema con mi banco por culpa de Google Pay.
      El banco me decía que consultara con Google, y el soporte de Google me mandaba de vuelta al banco.
      Después de varios correos, soporte de Google me pidió capturas de pantalla de la app del banco y de Google Pay.
      Así que necesitaba un segundo teléfono o simplemente dejar de quejarme.
      Recién volvió a funcionar años después, tras pasar por tres teléfonos.
    • Me recordó una vez que el banco me pidió capturas de pantalla.
      Cuando les dije que su app bloqueaba las capturas, se sorprendieron.
      Les expliqué una forma de hacerlo por medio del sitio web y con eso se resolvió, y el banco quedó conforme.
      Normalmente es un buen banco, pero igual pasó esta tontería.
    • Vivimos en una realidad donde solo las operadoras pueden grabar llamadas.
      (Nota: es imprescindible que se entienda que esto es una broma)
  • Puedo aguantar todo tipo de absurdos —hardware caro y lento, UI mala, correcciones interminables de bugs, etc.—, pero la duración de batería de los dispositivos móviles con Linux sí los vuelve imposibles de usar en la práctica.
    ¿Existe aunque sea un solo teléfono o tablet con Linux que realmente aguante 8 horas de uso durante el día? Librem, Pinephone, Juno: ninguno. Lo mismo con uConsole.
    La mini laptop de MNT dura unas 4 horas, pero si la dejas mucho tiempo en espera se descarga.
    En cambio, los dispositivos móviles grandes de marca, incluso usados de hace 3 a 5 años, no te hacen preocuparte por la batería en todo el día.
    Puedes dejar YouTube reproduciendo toda la noche y en la mañana siguen funcionando.
    Yo quiero un teléfono Linux, pero si incluso invirtiendo mucho esfuerzo sigue siendo tan difícil usarlo a diario, me pregunto quién podría hacerlo.

    • Supongo que depende de qué signifique "uso real".
      El Furi FLX1 es el teléfono Linux con mejor batería que he visto.
      Solo en espera dura más de 3 días.
      Los dispositivos oficiales de SailfishOS también parecen aguantar bien un día de uso.
    • Si hablamos solo de horas de uso real, es un problema de calcular consumo promedio y capacidad de batería.
      Ejemplo: 1W durante 8 horas requiere 8Wh; a 3.7V eso son unos 2162mAh, así que debería alcanzar.
      Los fabricantes optimizan de verdad para los patrones de uso reales de los consumidores, como dejar YouTube toda la noche.
      Ajustan brillo de pantalla, diseño del circuito, batería y todo tipo de trucos.
      En cambio, los dispositivos Linux parecen no tener casi ninguna optimización energética.
      Ni siquiera da la impresión de que hagan pruebas ambientales.
      Como consumidor, no quiero aceptar una situación así.
    • Justamente por esto se desarrolló Android al principio.
      La estructura de los SO y apps de escritorio no funciona en móvil.
      Las APIs restrictivas de Google pueden ser duras para los desarrolladores, pero están muy optimizadas para eficiencia de batería y consumo energético.
    • Estoy usando PostmarketOS en un Google Pixel 3a.
      Con uso ligero, la batería baja como 20% al día, y aunque haga mucho scroll en redes sociales llega más o menos a 60%.
      La verdad, eso me pareció bastante bien.
      Después de reinstalar recientemente, la batería mejoró mucho; antes parece que era porque Syncthing se quedaba corriendo en segundo plano.
      Si usas s2idle suspend, el consumo en espera baja más, pero en ese modo no puedes recibir llamadas (aunque eso podría mejorar en el futuro).
    • Hay muchas tablets o dispositivos 2 en 1 con chip AMD que aguantan 8 horas con uso ligero.
  • Mi próximo teléfono casi seguro será un esquema de dos dispositivos.
    Uno será un Android estándar barato, solo para cosas como apps bancarias que sí o sí necesitan Google Play (súper bloqueado, y casi siempre apagado).
    El otro será para usar el teléfono como una computadora de propósito general para lo que yo quiero hacer (terminal, sshd, emacs, emuladores, reproductor multimedia, etc.).
    Cada vez parece más difícil tener ambos mundos en un solo dispositivo.
    Por ahora todavía se puede medio lograr con Android, pero va empeorando.

    • Siguiendo con el comentario que acabo de publicar, la verdad esta idea me parece muy buena.
      Usar dos dispositivos puede ser realista.
      Un teléfono PAYG que se usa solo en casa para apps bancarias y usos específicos.
      Y todo lo demás en un teléfono GNU/Linux... solo de imaginar Emacs en el teléfono me emociona.
    • De hecho lo he probado, pero mantenerlo es muy engorroso.
      Incluso el dispositivo "tonto" tiene que recibir actualizaciones para que siga siendo seguro o para poder usar apps bancarias.
      Normalmente a los 3 años el soporte del teléfono se corta rápido.
      Incluso usando LineageOS, no pasa las verificaciones de integridad de Google, así que parece que hay que comprar un dumb phone nuevo cada 2 años.
    • Necesito un Android por una app específica.
      Pero mi equipo principal sigue siendo un teléfono Linux; lo ha sido desde los Nokia N9/N900.
      Directamente no guardo datos sensibles en el teléfono.
    • Me puse a pensar si no se podrían correr dos SO con un hipervisor, como en un servidor.
      Pero seguro el consumo de batería sería brutal.
    • El segundo teléfono se siente casi como una mini laptop.
      El teléfono "aburrido" tiene la configuración de fábrica, tres apps: MyGov, Dropbox y ni me acuerdo cuál otra.
      Y además llevo una mini laptop genial y la conecto por tethering al teléfono para usarla en serio.
      Uno es un electrodoméstico, el otro es una computadora de verdad.
  • Aunque salga un buen teléfono Linux, no sirve de mucho si el gobierno exige que para pagar impuestos tengas que comprar hardware y software bendecidos por cierta empresa estadounidense.
    Si no pagas impuestos te meten a la cárcel, así que al final tienes que obedecer.
    El problema real no es Google, sino que, aun siendo ciudadanos libres, dependemos para aspectos esenciales de la vida de hardware y software de empresas externas que no podemos controlar.
    Hay que resistirse con fuerza a entregar nuestras vidas a software y hardware que no podemos controlar.
    En especial, hay que alejarse de una estructura donde dos empresas estadounidenses controlan todo.

  • Aunque comparto las críticas a Android, también sería raro volver a Linux con su modelo de seguridad inexistente y su mala UI/UX móvil.
    Más bien, ¿por qué no usar un fork de AOSP o GOS? (aumentaría la compatibilidad, aunque tal vez sacrificando seguridad).
    También se podría investigar seriamente empaquetar apps GUI de Linux como APK de Android; haría falta integración con Wayland/DBus y algo de trabajo adicional, pero así podrías quedarte con las ventajas de ambos lados.

    • fork de AOSP o GOS
      Ambos sistemas tienen que seguir la estrategia de desarrollo de Google, así que no son independencia real; ese es precisamente el problema (discusión relacionada en HN).
      Poner GOS en un Librem 5 o Pinephone es una idea razonable, pero el equipo de GOS rechazó esa dirección (discusión relacionada en HN).
      Sobre el "modelo de seguridad inexistente" de Linux, en la práctica se basa en confiar en el software que instalas desde repositorios de código abierto.
      Y eso funciona bastante bien.

  • (Aclaración: no soy experto en marketing o negocios, soy ingeniero de software/producto).
    Si los smartphones Linux de verdad quieren hacerse un lugar en el mercado, una forma realista sería desarrollar soporte perfecto para un único hardware barato y fácil de conseguir con Debian puro o PostmarketOS.
    Si además se ajusta para funcionar con el Phosh de Purism sin drivers cerrados ni blobs, aumentaría la demanda por la plataforma y componentes open source de Purism (o de su hardware sucesor), además de las contribuciones de la comunidad.
    Si el teléfono barato fuera algo como un PinePhone, quizá no canibalizaría demasiado las ventas del flagship de Purism.
    Una comunidad más grande incluso podría darle a la marca más demanda y más confianza.
    Aparecerían competidores, claro, pero como tendrían que apuntar a clientes que valoran confiabilidad y hardware/software abierto, necesariamente tendrían que aportar a upstream en open source.
    (No necesariamente tendría que ser un PinePhone; también podría servir un Pixel usado fácil de desbloquear. A futuro, incluso dispositivos dedicados a GrapheneOS podrían aprovechar una plataforma Linux abierta parecida).

    • Hacer un teléfono totalmente abierto y sin blobs, incluso a nivel de hardware, es extremadamente difícil.
      Los teléfonos Linux actuales ya intentan usar componentes lo más abiertos posible, pero normalmente eso significa diseños viejos casi fuera de producción o rendimiento de tercera.
      El baseband inevitablemente es cerrado.
      Un teléfono completamente alineado con la ideología FOSS es, en la práctica, imposible.
      ¿Quién va a comprar un teléfono con chip y batería de tercera?
      Como el mercado es pequeño, los precios siguen altos.
      Al final, parece que la solución es "hacer primero un buen teléfono" y luego ponerle Linux.
      (A menos que, como en el mercado de PC, todos los drivers ya fueran abiertos, hoy la barrera es demasiado grande).
    • Incluso si fuera un teléfono chino baratísimo, si es un modelo viejo con buena documentación técnica, podría funcionar.
      Si por $50 puedes ponerle Linux, seguro venderías 100 mil unidades, aunque solo sea por curiosidad.
      Eso sí, por lo que entiendo la UI de Linux móvil todavía está por debajo de lo aceptable.
      Ni siquiera se consigue aún una experiencia al nivel del viejo N900 (256 MB de RAM).
      Proyectos como los ports de Maemo desaparecen por falta de hardware.
  • Soy usuario de Sailfish OS desde 2016.
    Antes de eso usé Meego y Maemo (N900, N9).
    Ahora también tengo un teléfono Android (solo por la app de Deutsche Post), y lo uso únicamente para envíos.
    Mi teléfono principal es un Gigaset alemán (batería de 4KmA), normalmente me dura 2 días, o 1 día si publico mucho.
    También puede correr SDL2 (como Godot 3.5) y un compositor Wayland, y la interfaz no está mal.
    La falta de apps es el problema, pero justo por eso también es divertido porque hay mucho por desarrollar.
    Da la sensación de que Linux móvil ya se estableció y se mantiene.

    • Hola, creo que te he visto por tu apodo en el foro de Jolla.
      Tengo dos equipos, un Gigaset GX290 y un GX4 Pro, pero he ido posponiendo instalar SailfishOS porque hay que hacer un respaldo de Android y crear un archivo scatter desde una PC con Windows.
      Las herramientas de MTK no son oficiales y hay que bajar ejecutables raros de sitios extraños, lo cual es incómodo.
      Me sorprende que no exista una herramienta oficial para esto.
      Quisiera preguntarte algo:
      Trabajo con Linux embebido, pero no entiendo bien a nivel conceptual el proceso de portar un SO como Sailfish a un dispositivo Android cualquiera.
      ¿Qué pasa exactamente cuando flasheas Sailfish en un dispositivo Android específico?
      ¿Por qué hace falta? ¿Qué es libhybris, y por qué no se reutilizan simplemente los drivers binarios de Android?
      Los términos de Android y los de Linux embebido también son distintos, así que me confunde más.
      Gracias por todo el esfuerzo de desarrollo hasta ahora, y ojalá pronto me vuelva a sumar como usuario de SFOS.
    • Tengo curiosidad por saber en qué dispositivo usas Sailfish OS. ¿Es un Jolla C2?
  • No entiendo por qué de repente todos los fabricantes están volviendo los teléfonos más cerrados, ni por qué Google va en esa dirección.
    No me queda claro cuál es la intención real.

    • Creo que es una consecuencia no intencional de la regulación europea.
      Apple respondió cumpliendo solo lo mínimo para ajustarse a la normativa de la UE, y Google está siguiendo ese mismo nivel.
    • Algunos creen que parte de la intención tiene que ver con eSIM y con la importancia de la integridad de identidad.
    • Es por más dinero y más poder.
      Es una tendencia nacida de la codicia.
      El progreso social lo impulsaron unos pocos concretos (por ejemplo Richard Stallman), pero ahora el sistema lo manejan personas comunes.
    • Una respuesta sin conspiraciones:
      La eliminación del desbloqueo del bootloader no ocurrió de golpe.
      El panorama cambió cuando Samsung (el fabricante Android número 1) dejó de apoyarlo.
      Mantener esta función ya no da una relación costo/beneficio aceptable, así que se fue volviendo minoritaria.
      Algunos grandes clientes directamente exigen que no se permita.
      El desbloqueo no implica solo abrir el equipo; también requiere gestionar cosas complejas como la aprobación de la operadora, el manejo de shared secrets entre dispositivo y fabricante, y que el SO siga funcionando correctamente aunque se rompa la cadena de confianza.
      Comercialmente, desde el principio fue una función con poco incentivo.
      Que varios fabricantes la ofrecieran por un tiempo se debió a que en esa época los márgenes eran más altos.
      Hoy incluso las actualizaciones del SO son difíciles de prever a 2 o 3 años, así que el desbloqueo mismo se volvió un factor de riesgo.
      La comunidad de SO de terceros también se ha ido achicando.
      Tras el colapso de Cyanogen (el líder), quedaron todavía menos usuarios de SO alternativos.
      Las causas son:
      1. más fragmentación del mercado
      2. la calidad y las actualizaciones del Android base mejoraron muchísimo
      3. Google introdujo verificaciones de integridad del dispositivo (ahora la mayoría de apps bancarias y de entretenimiento dejan de funcionar, y los equipos desbloqueados quedan bloqueados)
        Parece que la única vía que queda es convertir esto en un incentivo legal.
        Si no, hardware perfectamente usable termina todos los días en un cajón o en la basura.
        Si se obligara a los fabricantes a proveer la capa de software abierta del hardware y la documentación correspondiente, los SO comunitarios podrían mantenerse y crecer.
        Pero para que eso se vuelva ley habría que demostrar un efecto social positivo, y en la práctica la probabilidad es muy baja.
    • No es algo repentino, sino un proceso continuo de mayor control.
      Antes hasta se podía cambiar la batería del teléfono por cuenta propia, y los fabricantes fueron eliminando poco a poco todas esas libertades.
  • Si los teléfonos Linux no permiten usar apps del gobierno y del banco, para la gente común no sirven para nada.

    • En el post original también se dice en letras grandes que "no se está diciendo que uses un teléfono Linux ya mismo, sino que el desarrollo debería acelerarse".
      No hace falta criticar con tanta prisa.
    • No me gusta la realidad en la que las apps del gobierno y del banco solo están en la Play Store.
      Para usarlas tienes que crear una cuenta de Google y aceptar sus términos.
      Hay alternativas como Aurora Store, pero algunas apps bancarias revisan específicamente si se descargaron desde Play Store y entonces no funcionan.
    • Escucho mucho ese argumento, pero no lo entiendo.
      ¿Qué app de gobierno es tan indispensable?
      ¿Y por qué habría que consultar la cuenta bancaria desde el teléfono?
      En mi país ese modelo es poco común; seguimos siendo una sociedad donde se paga casi todo con tarjeta de crédito.
    • En Linux se puede hacer emulación de Android.
      La mayoría de los bancos también ofrece sitio web.
      El verdadero obstáculo es que en los entornos de emulación Android no suele integrarse bien la verificación con fotos de la cámara.
    • La única forma realmente práctica es usar dos dispositivos: uno dedicado a servicios gubernamentales y financieros, y otro para todo lo demás y para privacidad.
  • “¿Android no es también Linux?”
    No lo digo por ser quisquilloso; de verdad me da curiosidad.
    Hay muchos clones de Android que funcionan sin Google Play.
    ¿No bastaría con usar uno de esos? ¿Qué valor extra aporta un “teléfono Linux”?

    • "Linux" es el nombre del kernel, pero normalmente se usa para referirse a algo más amplio.
      Cuando la gente habla de un "Linux Phone", no queda claro qué pila de software concreta quiere, y aun así intenta distinguirlo de Android, aunque Android ya se basa en Linux.
    • Hacer un fork de Android probablemente sería mucho menos problemático que construir un teléfono Linux desde cero.
      Además mantendrías la compatibilidad.
    • Android es un kernel Linux con parches y un userspace aparte.
    • Hay alternativas de Android sin Google Play como microG GmsCore, pero igual sigue siendo casi imposible; en la práctica es un monopolio.
    • A nadie le importa realmente el kernel en sí.
      Lo que la gente quiere de verdad es usar su teléfono como quiera, con un userspace "general" que no dependa de las políticas cambiantes de los fabricantes.
      No quieren andar con estafadores, espías y apps de origen dudoso pegados al teléfono.
      Cuando Stallman insistía en decir "GNU/Linux", eso se volvió motivo de burla, pero ahora la distinción sí importa de verdad.
      Por ejemplo, si Debian cambiara su base a BSD, yo igual seguiría usando Debian.
      Pero si iOS cambiara solo el kernel por Linux, yo no lo usaría.
      Al final, lo que en verdad se busca es la “protección política” que ofrece la GPL y los proyectos que la sostienen (como Debian).
      Muchas veces los usuarios no reconocen ese deseo en sí mismos, o su política cotidiana y su forma de vida no coinciden.
      Como quieren salir de un monopolio de unos pocos, terminan valorando lo abierto.