Todo lo que necesitas saber sobre Project Mainline de Android

Project Mainline es el mayor cambio en Android desde Project Treble. Esto es lo que significa y lo que hacen todos los módulos. ¡Échale un vistazo!

Uno de los mayores cambios en Android en los últimos años que pasó desapercibido, relativamente hablando en contra de su importancia, fue la introducción de Línea principal del proyecto en Android 10. Google exige la inclusión de módulos Mainline específicos en todas las versiones de Android, con androide 11 entrando con un total obligatorio combinado de 25 módulos Mainline. Aquí hay una explicación sobre qué es Project Mainline y qué pretende resolver, junto con una lista de todos los módulos de Project Mainline de Android.

¿Qué es Proyecto Línea Principal?

Para entender correctamente Project Mainline, tendremos que retroceder un poco. Si retrocede unos años, gran parte de la conversación sobre las actualizaciones de Android se centró en el problema de la fragmentación. La fragmentación fue uno de los mayores desafíos que Google tuvo que resolver en Android en la era Ice Cream Sandwich - Lollipop. A pesar de que Android como plataforma recibió actualizaciones periódicas a través de un patrón en gran medida predecible, estas actualizaciones solían tardar mucho tiempo en llegar a manos de los consumidores finales, si es que lo hacían. Entonces, mientras Google solucionaba errores críticos y problemas de seguridad a nivel de plataforma, la implementación real de estos cambios dejaba mucho que desear. Hubo/hay muchos intermediarios (proveedor de SoC, OEM, operadores, etc.) y muchas partes móviles involucradas en la entrega de actualizaciones a su teléfono, y el problema de fragmentación no parecía que se resolvería solo sin requerir un golpe contundente intervenciones.

Uno de los principales esfuerzos para abordar este problema vino en forma de Proyecto triple junto con Android 8.0 Oreo, que involucró una importante reorganización de Android, separando los componentes del marco del sistema operativo Android de los HAL del proveedor y el kernel de Linux. Project Treble, en esencia, modularizó Android al separar el marco del sistema operativo del software de nivel inferior específico del dispositivo. De esta forma, los fabricantes de dispositivos (OEM) no necesitan esperar a que los fabricantes de silicio (proveedor de SoC) actualicen el código de implementación de su proveedor, y los OEM podrían actualizar el marco del sistema operativo Android de forma independiente. El resultado final es una adopción más rápida de las versiones más recientes de Android del OEM, ya que ya no es necesario espere a que el intermediario (proveedor de SoC) termine su trabajo primero antes de que puedan comenzar a hacer suyo.

Si bien la situación de la actualización de Android no mejoró drásticamente desde el principio con Project Treble, permitió en gran medida que OEM más amplio participación en las versiones beta de Android 10 y Android 11, además de facilitar que los OEM actualicen más de sus dispositivos de manera más rápida línea de tiempo Además, todo el concepto de GSI (Imagen genérica del sistema) ha tenido un gran impacto en el desarrollo del mercado de repuestos en nuestros foros.

El desarrollador arranca Android 11 en 22 dispositivos más antiguos con Project Treble GSI

Project Mainline amplía los esfuerzos de Project Treble. Si bien Treble redujo la dependencia de los OEM de los proveedores de SoC para cada actualización del sistema operativo, Mainline redujo la dependencia de Google de los OEM para entregar actualizaciones de seguridad a los componentes clave del sistema operativo. Project Mainline extiende la filosofía Treble a partes más críticas del marco de trabajo de Android, eliminando a los OEM como intermediarios dependientes de esta ecuación. El propósito de Project Mainline es que Google tome el control de los componentes del marco y las aplicaciones del sistema que son crítico para la seguridad y mantener la consistencia del desarrollo lejos de los OEM. Project Mainline se conoce legítimamente como el mayor cambio en Android desde Project Treble.

Para Project Mainline, Google hace uso de los módulos de Mainline que se entregan a través del marco de Google Play Services y Google Play Store. Cada módulo de Mainline se entrega como un archivo APK, un archivo APEX o como un APK en APEX. Cuando se actualiza un módulo de Mainline, el usuario ve una notificación de "Actualización del sistema de Google Play" (GPSU) en su dispositivo. Efectivamente, para entregar actualizaciones de componentes críticos, Google ha evitado la necesidad de esperar a que un OEM implemente una actualización, eligiendo hacer la tarea por sí mismo.

Como Estados de Google en la web de Android:

Los componentes del sistema modular permiten a los socios de Google y Android distribuir actualizaciones de manera amplia, rápida y sin problemas a los dispositivos de los usuarios finales de una manera no intrusiva. Por ejemplo, la combinación de fragmentación de códecs de medios y errores críticos puede ralentizar drásticamente la adopción de aplicaciones y la participación de los usuarios. Las actualizaciones frecuentes de los módulos relacionados con los medios pueden reducir la fragmentación del códec para hacer que el comportamiento de las aplicaciones de medios sea más consistente en diferentes dispositivos Android y corregir errores críticos para generar confianza en los usuarios.

Android 10 o superior convierte los componentes del sistema seleccionados en módulos, algunos de los cuales usan el formato de contenedor APEX (introducido en Android 10) y otros usan el formato APK. La arquitectura modular permite que los componentes del sistema se actualicen con correcciones de errores críticos y otros mejoras según sea necesario, sin afectar las implementaciones de proveedores de nivel inferior o aplicaciones de nivel superior y servicios.

Como Ars Technica menciones:

Project Mainline, también conocido como "Actualizaciones del sistema de Google Play", se introdujo en Android 10 como un gran esfuerzo para hacer que los componentes centrales del sistema de Android sean más modulares y actualizables. Mainline introdujo un nuevo tipo de archivo "APEX" específicamente para los componentes del sistema, con el objetivo de enviar el código principal de Android a través de Play Store tan fácilmente como envía una actualización de la aplicación. Anteriormente, el único bloque de código que se podía enviar de Android era el APK, un tipo de archivo diseñado originalmente para aplicaciones de terceros. Esto vino con todo tipo de restricciones de seguridad y solo podía iniciarse tarde en el proceso de arranque, por lo que APEX se creó con componentes de sistema más potentes en mente. Los APEX solo pueden ser creados por Google o el fabricante de su dispositivo, por lo que pueden ser notablemente más potentes y albergar componentes críticos de arranque como el tiempo de ejecución de la aplicación.

Mainline no es solo una solución técnica, también se trata de hacer que más partes de Android sean distribuidas centralmente por Google, que implica negociar con los fabricantes de dispositivos y lograr que todos acepten enviar el mismo bloque de código. Los módulos de Mainline finalmente se vuelven obligatorios para enviar, por lo que Mainline es en realidad una gran colaboración con los fabricantes de dispositivos para garantizar que un solo módulo para todo el ecosistema satisfaga las necesidades de todos. No todos los módulos de Mainline son módulos APEX ultrapotentes; algunos son solo APK que ahora son códigos de Android distribuidos por Google.

Línea principal del proyecto — Módulos

Con Android 10, Google ordenó la inclusión de 13 módulos Mainline específicos. Con Android 11, el número total de módulos obligatorios es de 25. Aquí está la lista completa, junto con algunos detalles clave:

Nombre del módulo

Nombre del paquete

Tipo

Dispositivo actualizado o iniciado con Android 11

DispositivoLanzado con Android 10

Dispositivo actualizado a Android 10

adbd

com.google.android.adbd

APÉNDICE

Debe

no soportado

no soportado

Tiempo de ejecución de la API de red neuronal de Android

com.google.android.neuralnetworks

APÉNDICE

Debe

no soportado

no soportado

Inicio de sesión en el portal cautivo

com.google.android.captiveportallogin

APK

Debe

Muy recomendado

Opcional

Difusión celular

com.google.android.cellbroadcast

APÉNDICE

Debe

no soportado

no soportado

conscripta

com.google.android.conscrypt

APÉNDICE

Debe

Muy recomendado

Opcional

Resolución de DNS

com.google.android.resolv

APÉNDICE

Debe

Muy recomendado

Opcional

Interfaz de usuario de documentos

com.google.android.documentsui

APK

Debe

Debe

Opcional

ExtServices - APK

com.google.android.ext.servicios

APK

Debe

Debe

Debe

ExtServices - APÉNDICE

com.google.android.extservices

APÉNDICE

Debe

no soportado

no soportado

Biblioteca IPsec/IKEv2

com.google.android.ipsec

APÉNDICE

Debe

no soportado

no soportado

Códecs multimedia

com.google.android.media.swcodec

APÉNDICE

Debe

Debe

Opcional

Componentes del marco de medios

com.google.android.media

APÉNDICE

Debe

Debe

Opcional

Proveedor de medios

com.google.android.proveedor de medios

APÉNDICE

Debe

no soportado

no soportado

Metadatos del módulo

com.google.android.modulemetadata

APK

Debe

Debe

Debe

Componentes de la pila de red

com.google.android.networkstack

APK

Debe

Muy recomendado

Opcional

Configuración de permisos de pila de red

com.google.android.networkstack.permissionconfig

APK

Debe

Muy recomendado

Opcional

Controlador de permisos - APK

com.google.android.controlador de permisos

APK

Debe

Debe

Debe

Controlador de permisos - APÉNDICE

com.google.android.permiso

APÉNDICE

Debe

no soportado

no soportado

Extensiones SDK

com.google.android.sdkext

APÉNDICE

Debe

no soportado

no soportado

Estadísticas

com.google.android.os.statsd

APÉNDICE

Debe

no soportado

no soportado

Paquete de versión de tren de telemetría

com.google.mainline.telemetría

APK

Debe

no soportado

no soportado

Atando

com.google.android.tethering

APÉNDICE

Debe

no soportado

no soportado

Datos de zona horaria

com.google.android.tzdata

APÉNDICE

No debe

Debe

Opcional

Datos de zona horaria 2

com.google.android.tzdata2

APÉNDICE

Debe

no soportado

no soportado

Wifi³

com.google.android.wifi

APÉNDICE

Debe

no soportado

no soportado

Para proporcionar algo de contexto a las columnas anteriores, la columna titulada "Dispositivo actualizado o lanzado con Android 11" incluye detalles sobre si el módulo debe estar presente (o no debe estarlo). presente, en el caso de los datos de zona horaria debido a la inclusión de su alternativa) en todos los dispositivos que se han actualizado a Android 11 o que se están lanzando con Android 11 fuera del caja. Del mismo modo, los dispositivos que se inician con Android 10 deben incluir algunos módulos, se recomienda encarecidamente que incluyan algunos otros y no son compatibles con el resto. Para los dispositivos que se actualizan a Android 10 (a diferencia de los que se lanzaron con Android), la lista de módulos necesarios es más corta.

¿Qué hace cada módulo de Mainline?

Aquí hay una breve explicación para cada uno de los módulos de Mainline:

Adbd

El módulo adbd administra las sesiones de depuración de IDE y adb de línea de comandos. La modularización de adbd permite a Google ofrecer mejoras de rendimiento y correcciones de errores más rápido. Esto es crucial ya que algunos errores en el pasado estaban relacionados con el agotamiento de la batería y podrían hacer que los dispositivos continuaran usando el 100% de la CPU hasta que el teléfono se agote. Por lo tanto, obtener estas correcciones es crucial para Google, ya que los desarrolladores de aplicaciones y los OEM utilizan ampliamente adb para realizar pruebas.

Tiempo de ejecución de la API de redes neuronales de Android

Esta es una biblioteca que se encuentra entre una aplicación y los controladores de back-end. La API, a su vez, es una API C de Android para ejecutar operaciones de aprendizaje automático de computación intensiva en dispositivos móviles y para habilitar operaciones de inferencia aceleradas por hardware.

Difusión celular

Cell Broadcast se refiere a alertas de emergencia y de no emergencia (como las alertas AMBER). Este módulo se ocupa de las tareas relacionadas con estas alertas y con otras funciones auxiliares, como la decodificación de SMS y la geolocalización para alertas de emergencia inalámbricas.

conscripta

El módulo Conscrypt maneja la implementación de TLS de Android y otras funciones criptográficas, como generadores de claves, cifrados y resúmenes de mensajes. Enviar esto como un módulo le permite a Google acelerar las mejoras de seguridad, sin necesidad de depender de las actualizaciones de OTA.

Resolución de DNS

Como su nombre lo indica, el solucionador de DNS resuelve el DNS, es decir, convierte las URL legibles por humanos en direcciones IP. El módulo contiene el código que implementa el resolutor de código auxiliar de DNS, y enviarlo como un módulo permite que Google brinde una mejor protección al usuario contra la intercepción de DNS y los ataques de actualización de configuración.

Interfaz de usuario de documentos

La interfaz de usuario de Documentos es el módulo responsable de controlar el acceso a archivos específicos para componentes que manejan permisos de documentos. Como afirma Google, convertir el acceso y los permisos de almacenamiento en un módulo aumenta la privacidad y la seguridad de los usuarios finales, mientras que la función de superposición de recursos en tiempo de ejecución (RRO) permite a los OEM personalizar la experiencia (refiriéndose a la aplicación Archivos) si es necesario a. Como módulo, todos los dispositivos Google-Android se enviarán con la misma experiencia de interfaz de usuario de Documentos.

ExtServices

Este módulo incluye componentes de marco para la funcionalidad central del sistema operativo, como clasificación de notificaciones, estrategias de coincidencia de texto de autocompletar, caché de almacenamiento, vigilancia de paquetes y otros servicios.

Biblioteca IPsec/IKEv2

Este módulo de biblioteca se ocupa de las características nuevas y existentes de Interworking Wireless LAN (IWLAN) y VPN, como la negociación de parámetros de seguridad como claves, algoritmos y túnel configuraciones La idea de modularizar estas funciones es promover la coherencia del ecosistema y proporcionar una forma de ofrecer soluciones rápidas para problemas de seguridad e interoperabilidad.

Estos son tres módulos bifurcados, pero tienen funciones que dependen unas de otras. Estos módulos de medios manejan tipos y códigos de medios, interactúan con ExoPlayer, exponen controles de transporte e información de reproducción al marco, optimizan metadatos indexados, etc. Recordar Stagefright, el exploit que cambió Android y generó el concepto mismo de actualizaciones de seguridad mensuales para la plataforma? Ese exploit se basó en vulnerabilidades dentro de la biblioteca de reproducción de medios. Por lo tanto, una modularización de los componentes de medios permite que Google reaccione rápida y ampliamente en caso de que se encuentren errores de seguridad en este componente a menudo objetivo.

La función de este módulo queda inmediatamente clara por su nombre, aunque su propósito no lo es. Metadatos del módulo El módulo contiene... metadatos sobre la lista de módulos en el dispositivo. Y eso es todo.

Componentes de pila de red, configuración de permisos de pila de red, inicio de sesión de portal cautivo

El módulo Network Stack Components proporciona servicios de IP comunes, monitoreo de conectividad de red, detección de portal de inicio de sesión cautivo. El módulo Configuración de permisos define el permiso que permite que otros módulos realicen tareas relacionadas con la red. El módulo de inicio de sesión del portal cautivo se ocupa de los portales cautivos: páginas web que se muestran cuando conectado a ciertas redes Wi-Fi públicas, donde se le pide al usuario que ingrese los detalles para obtener acceso a Internet acceso.

Controlador de permisos

Este módulo ofrece políticas de privacidad y elementos de interfaz de usuario actualizables sobre la concesión y gestión de permisos. Si esto suena familiar a lo que hace Package Installer, es porque lo es. Funciones como la concesión de permisos de tiempo de ejecución, la gestión y el seguimiento del uso formaban parte de la aplicación Package Installer hasta Android 9. En Android 10, la aplicación Package Installer se divide en secciones para permitir que se actualice la lógica de permisos. El módulo del controlador de permisos se entrega como un archivo APK y, en Android 11, el módulo puede revocar automáticamente los permisos de tiempo de ejecución para las aplicaciones que no se han utilizado durante un período prolongado.

Extensiones SDK

Este módulo es un poco difícil de entender y, en consecuencia, de explicar. A cada versión de Android se le asigna un nivel SDK (generalmente +1 de su predecesor). Cuando una aplicación se dirige a un SDK en particular, se supone que el desarrollador ha tenido en cuenta los cambios en el comportamiento de la plataforma y en la API que trajo consigo la versión de Android.

El módulo Extensiones de SDK decide el nivel de "SDK de extensión" del dispositivo y expone las API para que las aplicaciones consulten el nivel de SDK de extensión. Eso es todo lo que menciona la documentación oficial. ArsTechnica, sin embargo, menciona que esta es probablemente una capa de API secundaria que se enviará a través de Play Store.

Statsd, paquete de versión de tren de telemetría

Statsd es responsable de recopilar las métricas del dispositivo. El paquete de la versión del tren de telemetría, por otro lado, no contiene un código activo ni ninguna funcionalidad propia. Simplemente contiene un número de versión para el "Tren de telemetría" que, según Google, es un conjunto de módulos relacionados con las métricas. Según el número de versión, Google Play muestra la versión del parche de seguridad a los usuarios finales y determina si hay actualizaciones disponibles para los módulos relacionados con las métricas.

Atando

El módulo Tethering comparte la conexión a Internet del dispositivo con otros dispositivos cliente conectados a través de Wi-Fi, USB, Bluetooth o Ethernet. El módulo incluye los componentes de anclaje y sus dependencias. Mediante el uso de este módulo Tethering, los OEM pueden confiar en una única implementación de referencia estándar y brindar una experiencia uniforme en todos los dispositivos.

Datos de zona horaria

El módulo de datos de zona horaria actualiza el horario de verano (DST) y las zonas horarias en dispositivos Android, estandarizando tanto los datos (que pueden y cambia con bastante frecuencia en respuesta a razones religiosas, políticas y geopolíticas) y el mecanismo de actualización en todo el ecosistema. Android 8.1 y Android 9 usaban un mecanismo de actualización de datos de zona horaria basado en APK, y Android 10 lo reemplaza con un mecanismo de actualización de módulo basado en APEX. Google afirma que AOSP continúa incluyendo el código de plataforma necesario para las actualizaciones basadas en APK, por lo que los dispositivos que se actualizan a Android 10 aún pueden recibir actualizaciones de datos de zona horaria proporcionadas por socios a través del APK. Sin embargo, Google advierte que las actualizaciones basadas en APK reemplazan una actualización basada en APEX.

Wifi

Este es el módulo para la funcionalidad Wi-Fi. Los usuarios finales ahora pueden obtener una experiencia Wi-Fi uniforme en todos los dispositivos Android, así como soluciones a problemas de interoperabilidad a través de actualizaciones de módulos, aplicaciones los desarrolladores pueden reducir la fragmentación de la plataforma y los OEM pueden cumplir con los requisitos de los operadores y, al mismo tiempo, reducir los costos para los usuarios individuales. personalizaciones


Con suerte, este artículo destaca cuán importante es Project Mainline para el ecosistema Android de Google.