Google Pixel ya no es un dispositivo de referencia de AOSP

• Google publicó el código fuente de Android 16 en AOSP, pero no hizo público el repositorio de hardware de Pixel
• Debido a que no se publicaron los árboles de dispositivos Pixel ni el código relacionado, en parte de la comunidad surgieron sospechas de una “eliminación de AOSP”
• Google lo negó oficialmente al afirmar que "AOSP no se va a descontinuar" y reiteró que seguirá publicando y actualizando el código fuente de AOSP
• A partir de ahora, AOSP apuntará a un objetivo de referencia (reference target) no ligado a hardware existente, y se espera una transición hacia dispositivos virtuales y equipos generalizados como 'Cuttlefish', que son más flexibles y de menor costo, así como GSI
• Esto podría dificultar las actualizaciones del sistema operativo y la investigación para desarrolladores de ROM personalizadas e investigadores de seguridad

---

Lanzamiento de Android 16 y polémica por la publicación del código fuente

• Junto con el lanzamiento de Android 16, Google no publicó el repositorio de hardware Pixel ni el código del árbol de dispositivos (Device tree)
  • Hasta ahora, el código para hardware Pixel se entregaba junto con AOSP y había cumplido un papel esencial para el desarrollo de ROM personalizadas de Android
• Por esto, se prevé que desarrolladores de ROM personalizadas e investigadores de seguridad enfrenten dificultades en el desarrollo de sistemas operativos personalizados, las actualizaciones más recientes de Android y la investigación de vulnerabilidades de seguridad

Postura oficial de Google sobre AOSP

• En parte de la comunidad circularon rumores de que "AOSP iba a terminarse", pero Seang Chau, VP del área de Android, lo negó oficialmente al decir:
  • "AOSP no va a desaparecer"
  • "Seguimos comprometidos con las actualizaciones de AOSP"
• Sin embargo, la respuesta oficial del equipo de Android sí sugiere que en adelante ya no se proporcionarán elementos como el árbol de dispositivos Pixel
• El objetivo de referencia (reference target) que ofrecerá AOSP buscará ser independiente de hardware específico
  • Apuntará a un dispositivo de referencia flexible, configurable y de bajo costo, sin relación con ningún hardware específico, incluido el de Google
  • Durante años, la comunidad ha usado Cuttlefish (dispositivo de referencia) y el objetivo GSI compilados desde el código fuente para pruebas y desarrollo
  • Estos dispositivos de referencia seguirán estando disponibles para los desarrolladores

Impacto en la comunidad de ROM personalizadas y seguridad

• Google subraya oficialmente su intención de seguir apoyando AOSP
• Pero, al desaparecer el soporte directo para hardware, se espera que la complejidad del desarrollo y la barrera de entrada aumenten considerablemente para la creación y el mantenimiento de ROM personalizadas, así como para la investigación de seguridad

[GN⁺]

Comentarios en Hacker News

• Puede que me vean raro, pero la única razón por la que compré un Pixel recientemente fue con la intención de instalarle GrapheneOS de inmediato en cuanto lo comprara. Hasta ahora, la experiencia ha sido realmente satisfactoria. Intento evitar en lo posible cualquier cosa relacionada con Google, a menos que sea por trabajo. Hay demasiadas cosas de Google que no me gustan. Claro, Google en realidad no tiene la obligación de seguir proporcionando esos blobs binarios, pero otra vez me decepciona ver que cortan de golpe algo que venían haciendo desde hace mucho tiempo, sin aviso. Como cuando cierran otros servicios, creo que debieron avisar con suficiente anticipación. Entiendo que seguir distribuyendo los binarios y garantizar que funcionen implica una carga extra, pero al final ellos de todos modos tienen que hacer ese trabajo internamente. Mi impresión es que Google tomó una decisión estratégica: perder dinero en el dispositivo para algunos usuarios de GrapheneOS y enfocarse en cosas que les generan ingresos de forma secundaria, como el ecosistema cerrado, la minería de datos o la publicidad

  • Yo compré un Pixel exactamente por la misma razón. Como ya todos sabemos que hoy en día el rastreo ocurre en casi todas las capas, creo que comprar un Pixel y flashearle GrapheneOS de inmediato es la decisión más sensata. Todos los teléfonos de mi casa (el de mi esposa y el mío) se usan así. Ni siquiera hay que preocuparse por Play Services, las apps de Google o Facebook. Solo quiero que mi vida no termine formando parte de la publicidad dirigida ni de datos que quizá se usen para algo en el futuro. Lo que más me sorprende es que haya tanta gente tan indiferente con la privacidad

  • Te estoy juzgando con benevolencia. Yo hago exactamente lo mismo

  • Tengo una perspectiva algo distinta sobre la afirmación de que “Google dejó de ofrecer binarios sin avisar con suficiente anticipación”. Es raro depender de un comportamiento no documentado y luego quejarse cuando cambia. Si eres ingeniero de software, lo normal es no depender de ese tipo de cosas. Si alguien usara un Pixel como pisapapeles y luego dejara de servir por el relieve de la cámara, también me parecería absurdo culpar a la empresa por eso

• Recuerdo haber agradecido mucho que se pudiera comprar hardware real para consumidores como un Pixel (o antes un Nexus), bajar AOSP y los blobs propietarios, y construir una compilación en la que todo el hardware funcionara sin hacer gran cosa. Puede que Cuttlefish sea un dispositivo de referencia más eficaz, pero eso es distinto de poder reutilizar el dispositivo para muchas otras cosas, como pasa con un Pixel en usos como GrapheneOS. Siento que correr Android compilado por mí mismo en un dispositivo real tiene un atractivo que no se consigue en una VM

  • Según el artículo, también se ofrece soporte para GSI (Generic System Image) como dispositivo de referencia, y eso se acerca más al hardware real. Aun así, GSI tiene varias incomodidades: según las especificaciones de bajo nivel del dispositivo (esquema de particiones, versión inicial de Android con la que salió, etc.), el tipo de compilación cambia. Aun así, no es una mala alternativa. Últimamente también apareció GKI (Google Generic Kernel Image), que está diseñado para funcionar en dispositivos recientes (excepto módulos personalizados y blobs). Eso sí, no es lo mismo que el mainline del kernel de Linux; sigue siendo una rama downstream con muchos parches personalizados. Pero aun así facilita las pruebas y el desarrollo de una forma unificada, sin depender de un dispositivo concreto

• Creo que GrapheneOS exageró la situación y terminó cometiendo su propio error (efecto “Pedro y el lobo”). Desde la perspectiva de la empresa, es fácil responder a críticas que se sabe claramente que son falsas. Afirmaciones como “Google is killing AOSP” llaman la atención, pero también son demasiado fáciles de refutar por parte de la compañía. Lo que está ocurriendo ahora es simplemente que GrapheneOS obtenía blobs binarios gracias a la buena voluntad de Google, y como Google no tenía ninguna obligación, dejó de ofrecerlos porque tenía sus propias razones. Además, cuando GrapheneOS menciona temas legales o de monopolio, los desarrolladores simplemente dejan de involucrarse y todo pasa al equipo legal

  • Me gustaría saber específicamente qué es lo que se exageró. Qué es falso, si GrapheneOS ya había hecho esto antes y exactamente qué parte estuvo mal

  • Creo que a raíz de esto GrapheneOS terminará dando soporte a una gama más amplia de dispositivos, más allá de Pixel. De hecho, pienso que ya debería haberlo hecho, y aunque el soporte de hardware sea bueno, incluso sin eso sigue siendo muchísimo más seguro que Android stock

  • Mi postura es que no hace falta defender activamente a Google, siendo una de las dos empresas que en la práctica son monopolistas

• Siempre me preocupa que, sin el repositorio de hardware de Pixel (árboles de dispositivo, binarios de drivers, etc.), desarrollar actualizaciones del sistema operativo para ROMs personalizadas de Android se vuelva muy difícil. También podría afectar la investigación en seguridad

  • Me preocupa todavía más porque en el Twitter oficial de GrapheneOS publicaron esto

• Sin GrapheneOS, probablemente me pasaría al iPhone. Llevo mucho tiempo usando GrapheneOS y me encanta esa sensación de ligereza y simplicidad, sin componentes innecesarios de Google. El Pixel oficial de Google ya no es para mí

• Un elemento más para la lista del Google Graveyard. Si ya no puedo controlarlo yo mismo, no tengo razón para usar un Pixel. Voy a volver a probar con iPhone, aceptar sus desventajas y disfrutar de muchas de sus ventajas

• Se me viene a la cabeza la réplica de “AOSP sigue vivo, aunque sea en el emulador”. En el artículo dicen: “Durante años, los desarrolladores han construido desde el código fuente Cuttlefish (referencia en GitHub) y objetivos GSI para usarlos como referencia. Eso se seguirá ofreciendo con fines de pruebas y desarrollo”. Soy principiante en AOSP, así que me da curiosidad saber, desde la perspectiva de la comunidad, si esos dispositivos de referencia realmente sirven de forma práctica para desarrollar ROMs personalizadas o si es más bien algo cosmético

• Creo que quizá esta era la razón por la que GrapheneOS funcionaba tan bien en Pixel. Espero que, una vez superado el obstáculo inicial y entendido el cambio de fondo, incluso puedan ampliar el soporte a más dispositivos

  • Solo es parcialmente cierto. Según el FAQ oficial, las razones principales son (1) funciones de seguridad de hardware de primer nivel, como memory tagging, (2) entrega rápida de parches y (3) soporte oficial a largo plazo

  • O también podría pasar que, con este cambio, GrapheneOS ya no dé soporte a nuevos dispositivos

• GrapheneOS era la única razón por la que compraba Pixel

• Es un poco repetido enlace relacionado