Detrás de las actualizaciones dinámicas del sistema en Android Q: Cómo Google está usando Project Treble para mejorar futuras versiones de Android

Junto con el lanzamiento de Android 8.0 Oreo, Google presentó Project Treble: una importante reestructuración en la forma en que se comunican el marco del sistema operativo Android y los HAL del proveedor y el kernel de Linux. Treble es una iniciativa importante diseñada para reducir la versión de la plataforma Android y la fragmentación de parches de seguridad, y todos los dispositivos con la marca Android que se inician con Android Pie son necesarios para admitir Project Treble. Los fabricantes de equipos originales y los proveedores prueban la compatibilidad de Treble mediante el arranque de una Imagen del sistema genérico (GSI), una compilación pura de Android de AOSP, y pasan el Vendor Test Suite (VTS) y la Prueba de compatibilidad Suite-on-Generic System Image (CTS-on-GSI ) El GSI ha demostrado ser útil no solo al permitir que los ingenieros de software que trabajan para OEM prueben la compatibilidad de Treble, sino que también ha abierto la puerta para una gran comunidad ROM personalizada. Para el lanzamiento de Android Q, Google quiere que los GSI sean útiles para otro grupo: los desarrolladores de aplicaciones.

Dado que la primera versión estable y la caída del código fuente de cualquier versión de la plataforma Android generalmente se produce en agosto, los desarrolladores que deseen probar la próxima versión de Android en un dispositivo real generalmente necesitan acceso a un teléfono inteligente Google si no quieren esperar la actualización para llegar a su propio hardware. Sin embargo, Google trabajó con los fabricantes de equipos originales para llevar una versión beta de Android P a varios dispositivos el año pasado, y este año lo han seguido con una versión beta de Android Q. Junto con un Android Q beta oficial, Google este año también lanzó un Q beta GSI oficial para que cualquier desarrollador con un dispositivo compatible con Project Treble pueda instalar la última versión Q sin tener que esperar meses para que la compilación llegue a sus dispositivos. Esta nueva forma de probar la próxima versión de Android ofrece a los desarrolladores más oportunidades y, por lo tanto, más tiempo, para probar sus aplicaciones frente a cambios importantes en Android.

Desafortunadamente, el método actual de instalación de un GSI puede ser difícil. Requiere desbloquear el gestor de arranque, lo que significa borrar todos los datos del usuario y / o anular la garantía, y flashear una imagen a través del protocolo fastboot. No es un proceso rápido y sencillo para un desarrollador de aplicaciones, incluso si su dispositivo permite desbloquear el gestor de arranque. Es por eso que, durante los últimos meses, Google ha trabajado en una nueva forma de arrancar GSI. Ingrese una nueva función llamada Actualización dinámica del sistema o DSU.

(Esta característica fue desarrollada previamente bajo los nombres de "Imagen en vivo", "Android dinámico" y "Android on Tap", así que no se sorprenda si Google lo llama de otra manera en unas pocas semanas o meses).

Actualizaciones dinámicas del sistema en Android Q

El objetivo de la función DSU es permitir que un desarrollador arranque en un GSI sin interferir con la instalación actual. Eso significa que el gestor de arranque no necesita ser desbloqueado y no es necesario borrar los datos del usuario. El proceso de instalación también se simplifica enormemente, ya que Google ha proporcionado una interfaz de línea de comandos a través de ADB y una aplicación que se puede controlar a través de intentos. Esto es lo que parece arrancar un GSI usando DSU:

En este video *, un Google Pixel 3 XL con Android Q beta 3 se reinicia en un GSI. En este entorno, un desarrollador de aplicaciones puede instalar y probar su aplicación para la compatibilidad Q API. Cuando terminen las pruebas, simplemente pueden reiniciar en el software Q beta 3 normal en el dispositivo. Básicamente, tiene un arranque dual de un GSI para que pueda probar su aplicación de forma segura.

* Grabamos este video en Google I / O 2019 cuando DSU aún no estaba disponible públicamente, por lo que la versión Q beta 3 en el Pixel 3 XL filmado fue ligeramente modificada por Google para incluir soporte DSU. Los dispositivos que ejecutan Q beta 4 y posterior son elegibles para admitir DSU si cumplen los requisitos a continuación.

Requisitos para actualizaciones dinámicas del sistema

Obtener lo que es esencialmente el arranque dual en funcionamiento no fue una tarea fácil para Google. Se tuvieron que hacer cambios importantes en la forma en que se administran las particiones en Pixel 3, el banco de pruebas de Google para DSU. Por lo tanto, el primer requisito importante para la compatibilidad con DSU es que el dispositivo admite particiones dinámicas . Las particiones dinámicas implican una partición real de almacenamiento que se divide en particiones lógicas redimensionables como sistema, proveedor, odm, oem, producto, etc. Durante la instalación de un GSI, el espacio se reserva para nuevas particiones de sistema y datos de usuario al tomar bloques no utilizados de los existentes. partición de datos de usuario. Dado que estas nuevas particiones pueden tener un tamaño de varios gigabytes, la compatibilidad con DSU solo tiene sentido con particiones lógicas; de lo contrario, un dispositivo necesitaría reservar permanentemente varios gigabytes de espacio de almacenamiento para instalaciones GSI.

Otros requisitos incluyen un ramdisk, que decide si arrancar desde la recuperación, el sistema o una partición lógica, y una partición de metadatos para almacenar los metadatos del GSI. En general, los componentes básicos para el soporte de DSU son los requisitos de lanzamiento de Android Q, según el líder de Project Treble, Iliyan Malchev. No estamos seguros de si todo lo que se necesita para admitir DSU es un requisito de lanzamiento de Android Q, pero podemos suponer que la mayoría, si no todos los dispositivos que se inician con Android Q pueden admitir DSU, incluso si Google no los requiere actualmente. Hasta ahora, solo Pixel 3, Pixel 3 XL, Pixel 3a y Pixel 3a XL tienen particiones dinámicas, y de estos dispositivos, solo Pixel 3 y Pixel 3 XL admiten DSU en Android Q beta 4. Aunque el soporte DSU no es requerido, Google espera que los OEM habiliten la función de todos modos porque simplifica las pruebas de compatibilidad de Treble de forma segura. Por ejemplo, un ingeniero de software OEM puede colocar un GSI en una tarjeta SD para que pueda arrancar rápidamente en múltiples dispositivos para probar la compatibilidad de Treble.

Seguridad para actualizaciones dinámicas del sistema

Dado que DSU introduce esencialmente un segundo sistema operativo en la mezcla, Google debe asegurarse de que esta nueva instalación no pueda ser manipulada para romper la integridad del dispositivo. Por lo tanto, las mismas protecciones de seguridad básicas para la instalación original están vigentes para la instalación de GSI : Android Verified Boot y las políticas de SELinux. Además, solo las aplicaciones con el permiso privilegiado firma | INSTALL_DYNAMIC_SYSTEM pueden iniciar una instalación GSI, mientras que las aplicaciones con el permiso de firma MANAGE_DYNAMIC_SYSTEM pueden habilitar / deshabilitar o borrar una instalación GSI. Esto significa que solo las aplicaciones confiables de nivel de sistema pueden funcionar con DSU.

Para garantizar que los datos originales del usuario estén protegidos, Google ha agregado un mecanismo de protección adicional en Android Q. Llamado " punto de control ", la función protege contra la destrucción de datos del usuario al restaurar las particiones con puntos de verificación a su estado original. Sin embargo, los puntos de control son útiles no solo para DSU. También se usan para proteger contra el módulo APEX del Proyecto Mainline fallido y las actualizaciones A / B OTA. (Los dispositivos con particiones A / B ya tienen protección de retroceso, pero esos retrocesos requieren restablecimientos de datos de fábrica, mientras que los puntos de control de datos de usuario no lo hacen).

Instalar un GSI

Si su dispositivo admite DSU como la serie Pixel 3, entonces es fácil instalar un GSI. Primero debe asegurarse de que el indicador de función del Sistema dinámico esté habilitado de dos maneras:

  1. Si está en una compilación de depuración de usuario, habilite el indicador settings_dynamic_android en Configuración> Sistema> Opciones de desarrollador> Indicadores de funciones.
  2. Si está en una compilación de usuario, ejecute el siguiente comando de shell adb:
     setprop persist.sys.fflag.override.settings_dynamic_system 1 

Luego, descargue el último Android Q beta GSI de Google o del OEM de su dispositivo. (DSU solo permite instalar GSI firmados por Google o un OEM). Una vez descargado, use simg2img para convertir la imagen dispersa en una imagen sin formato. Use gzip para empaquetar la imagen en bruto y luego copie el archivo resultante en una ubicación en el almacenamiento externo de su dispositivo (por ejemplo, / data / media / 0 / Download) o en un medio de almacenamiento externo real (como una tarjeta SD física). Por último, inicie la aplicación DynamicSystemInstallationService con la intención correcta de comenzar la instalación:

 adb shell am start-activity \ -n com.android.dynsystem/com.android.dynsystem.VerificationActivity \ -a android.os.image.action.START_INSTALL \ -d file:///storage/emulated/0/Download/system_raw.gz \ --el KEY_SYSTEM_SIZE $(du -b system_raw.img|cut -f1) \ --el KEY_USERDATA_SIZE 8589934592 

Instalación de GSI en progreso. Fuente: Google.

Notificación de DSU. Fuente: Google.

Una vez que haga clic en reiniciar, iniciará en el GSI. La usabilidad del dispositivo en el GSI depende de qué tan bien el OEM de su dispositivo implementó Treble (o más bien, cuán poco violaron la compatibilidad de Treble). Algunos dispositivos funcionarán mejor con GSI que otros, pero en general, no espere usar esto instalación como conductor diario. Debes probar tu aplicación y luego salir reiniciando. Si desea permanecer en la instalación de GSI para realizar más pruebas, puede utilizar el comando de shell gsi_tool.

Las instrucciones completas de instalación de GSI para DSU se pueden encontrar aquí. Los errores se pueden archivar en Google Issue Tracker, Reddit o Stack Overflow.

La razón detrás de las actualizaciones dinámicas del sistema

Cuando hablé con Iliyan Malchev en Google I / O, reiteró lo que Hung-ying Tyan del equipo de Treble dijo sobre el acceso temprano a GSI en la Android Dev Summit de noviembre. Google hizo DSU para solicitar comentarios de una audiencia tan amplia como sea posible . El objetivo es mejorar la calidad del GSI, que a su vez mejora la calidad del futuro lanzamiento de Android, ya que un GSI es la forma más pura de Android. Actualmente, Google es la única compañía que prueba la compatibilidad con GSI de la próxima versión (por ejemplo, qué tan bien funciona la imagen del sistema Android Q además de la implementación del proveedor de Android P), pero a medida que más personas muestren GSI y den su opinión, los OEM pueden corregir la compatibilidad de Treble violaciones para que los GSI funcionen aún mejor en el futuro. Iliyan dice que hay un gran interés de los fabricantes de equipos originales y proveedores como Qualcomm en reutilizar las imágenes de los proveedores de la versión anterior de Android con la imagen del sistema de la próxima versión. Iniciativas como DSU ayudan a Google y OEM a cerrar la brecha en la cobertura de pruebas automatizadas como VTS y CTS-on-GSI. Por lo tanto, Google obtiene más probadores beta para dar su opinión sobre la próxima versión de Android, al tiempo que escucha sobre las violaciones de compatibilidad de Treble para que los OEM puedan mejorar su trabajo.

La adición de actualizaciones dinámicas del sistema en Android Q es bienvenida, pero no será la solución de arranque dual que algunos de ustedes esperan. Como se mencionó anteriormente, solo se pueden instalar imágenes del sistema firmadas por Google u OEM. Cuando le pregunté a Iliyan sobre la posibilidad de extender DSU para admitir un ecosistema de sistemas Android alternativos, dijo que es técnicamente posible hacerlo, ya que DSU es simplemente un canal para entregar imágenes del sistema. Cualquier OEM puede usarlo como lo desee, siempre y cuando el resultado final sea compatible con Android . Google no ha creado una alternativa al sistema OTA aquí, y DSU no está destinado a ser utilizado para un verdadero arranque dual. De todos modos, el trabajo que Google ha realizado en Treble está haciendo que Android sea más modular, por lo que no me sorprendería si el arranque dual nativo se hiciera realidad en el futuro.