MiReal.me MiReal.me – Tu blog tecnológico con la más actualizada información
Escrito por Iliyan Malchev (Project Treble Architect), Amith Dsouza (Technical Account Manager) y Veerendra Bhora (Strategic Partnerships Manager)
Extensión de las actualizaciones de Android a las plataformas móviles de Qualcomm
En los últimos años, los fabricantes de equipos originales adoptaron el último sistema operativo Android y lo distribuyeron en mayor número a nuestros usuarios. El crecimiento en la adopción ha sido impulsado por los fabricantes de equipos originales (OEM) que proporcionan actualizaciones del sistema operativo más rápidas, aprovechando la arquitectura introducida por Project Treble.
En el momento del lanzamiento de Android 11, había 667 millones de usuarios activos en Android 10, el 82% de los cuales obtuvieron la compilación de Android 10 a través de una actualización OTA (por aire). A pesar de los eventos en el transcurso de 2020, nuestros socios continúan teniendo un impulso para lanzar sus dispositivos en Android 11 u ofrecer OTA para Android 11 en sus dispositivos primero.
Hasta ahora, nuestros esfuerzos se han centrado en hacer que las actualizaciones del sistema operativo sean más fáciles y rápidas de implementar. La otra cara de esta moneda admite actualizaciones durante un período de tiempo más largo y hoy nos gustaría brindar una descripción general de los cambios que estamos realizando para ayudar a nuestros socios a lograrlo.
Proyecto de agudos fue una ambiciosa re-arquitectura de Android que creó una división entre el marco del sistema operativo y el software de bajo nivel específico del dispositivo (llamado implementación del proveedor) a través de una estructura estable y bien definida interfaz de proveedor. Como parte de esta división, el marco del sistema operativo Android garantiza la compatibilidad con versiones anteriores de la implementación del proveedor, que se verifica a través de un conjunto de pruebas de cumplimiento estandarizado: VTS. Con cada versión de Android, Project Treble publica Imágenes de sistema genérico (GSI) que se construyen a partir de fuentes AOSP y se garantiza que son compatibles con versiones anteriores de las 3 versiones anteriores de las implementaciones de los proveedores, así como la versión actual, por supuesto, por un período total de cuatro años. Los dispositivos que arrancan con la nueva versión de Android deben tener implementaciones de proveedores compatibles con ese GSI. Este es el vehículo principal para reducir la fragmentación dentro del marco del sistema operativo. Si bien permitimos y alentamos a nuestros socios a cambiar el marco en sí, los cambios posteriores a Treble deben realizarse de manera que se reduzca el costo de actualización de una versión a otra.
Además de reutilizar la implementación de un proveedor en las actualizaciones del sistema operativo, la arquitectura Treble también facilita la reutilización del mismo código de marco del sistema operativo en implementaciones de diferentes proveedores.
Otro cambio importante introducido por Project Treble es que los nuevos requisitos que afectan a los proveedores para los dispositivos Android nunca son retroactivos. Solo se aplican a dispositivos que arrancan en esa versión de Android y no a dispositivos que se actualizan desde una versión anterior. El término impacto del proveedor aquí se refiere a los requisitos para nuevos HAL, o para enviar un kernel de Linux más nuevo, a la implementación del dispositivo por parte del proveedor. Un buen ejemplo sería una nueva revisión de la cámara HAL para admitir más sensores de la cámara trasera. Dado que el marco de Android garantiza la compatibilidad con HAL anteriores, permitimos que los OEM reutilicen implementaciones de proveedores antiguos para actualizaciones sin el costo considerable de actualizarlas con nuevos requisitos.
Este principio, combinado con la garantía de compatibilidad con versiones anteriores, brinda a los fabricantes de dispositivos (OEM) la flexibilidad para admitir actualizaciones más rápido (ya que solo necesitan actualizar el marco, que cubriría todos sus dispositivos, incluidos aquellos con versiones anteriores. implementación del proveedor), así como a un costo menor (ya que no tienen que tocar implementaciones de proveedores anteriores).
Sin embargo, visto desde el punto de vista de los fabricantes de System-on-Chip, este diseño presenta una mayor complejidad. Para cada modelo de SoC, los fabricantes de SoC ahora tenían que crear múltiples combinaciones de implementaciones de proveedores para apoyar a los OEM que usarían ese conjunto de chips para lanzar nuevos dispositivos e implementar actualizaciones del sistema operativo en dispositivos lanzados anteriormente.
El resultado es que tres años después del lanzamiento de un conjunto de chips, se espera que el proveedor de SoC admita hasta 6 combinaciones de marcos de software de SO e implementaciones de proveedores. Los costos de ingeniería asociados con este soporte limitaron la duración durante la cual los proveedores de SoC ofrecieron soporte para el software del sistema operativo Android en un chipset. Para cada chipset individual, la línea de tiempo de soporte de software se vería así:
Teniendo en cuenta que los proveedores de SoC tienen docenas de modelos de SoC en un momento dado, la imagen completa parece más cercana a esto:
El quid del asunto era que si bien los requisitos del dispositivo nunca fueron retroactivos, los requisitos para los SoC sí lo fueron. Por ejemplo, en Android Pie, los SoC tenían que admitir dos versiones de la API Camera HAL en un conjunto de chips si se usaba para admitir nuevos lanzamientos y actualizaciones de dispositivos.
Desde este punto de vista, la solución era simple: teníamos que extender el principio de irretroactividad tanto a los SoC como a los dispositivos. Con este cambio, el proveedor de SoC podría admitir Android con las mismas implementaciones de proveedor en sus SoC para lanzamientos y actualizaciones de dispositivos.
Durante el año pasado, hemos trabajado duro para implementar esta solución. Basándonos en nuestra profunda colaboración con nuestros colegas de Qualcomm, hoy anunciamos los resultados de este trabajo. En el futuro, todas las nuevas plataformas móviles de Qualcomm que aprovechen el principio de no retroactividad para SoC admitirán 4 versiones del sistema operativo Android y 4 años de actualizaciones de seguridad. Todos los clientes de Qualcomm podrán aprovechar esta estabilidad para reducir aún más los costos de actualización y lanzamiento y ahora pueden admitir sus dispositivos durante períodos de tiempo más largos.
Yendo un paso más allá, también estamos reutilizando el mismo marco de software del sistema operativo en varios conjuntos de chips de Qualcomm. Esto reduce drásticamente la cantidad de combinaciones de marco de sistema operativo e implementación de proveedores que Qualcomm tiene que admitir en sus plataformas móviles y da como resultado costos reducidos de diseño, desarrollo e implementación. El siguiente diagrama indica qué tan significativa es la simplificación. Desde una perspectiva de soporte de software, es una situación completamente diferente:
Este cambio entrará en vigor con todos los SoC lanzados con Android 11 y versiones posteriores. Al trabajar en estrecha colaboración con Qualcomm para ofrecer un período prolongado de actualizaciones de seguridad y del sistema operativo, esperamos poder ofrecer lo mejor de Android a nuestros usuarios más rápido y con mayor seguridad durante un período prolongado.
