¡Android 11 vendrá con DSU Loader dentro de las Opciones de desarrollador que le permitirán descargar e instalar GSI compatibles automáticamente! ¡Sigue leyendo para más!
Un buen ecosistema de aplicaciones es uno de los pilares más importantes del éxito de un sistema operativo. Tanto Google como Apple reconocen el valor de tener buenas aplicaciones en sus plataformas, por lo que ambas empresas intentan equilibrar las necesidades de sus usuarios y los desarrolladores de aplicaciones. Los usuarios siguen presionando para que se realicen cambios en los sistemas operativos, y aunque la mayoría de las personas generalmente aprecian las nuevas funciones, estas los cambios no siempre son divertidos para los desarrolladores de aplicaciones, ya que pueden alterar gran parte de la funcionalidad principal y comportamiento. Para los desarrolladores que trabajan constantemente para mantener la relevancia de sus aplicaciones, lidiar con estos cambios se suma a su creciente lista de trabajo. Incluso si estos cambios no afectan directamente a sus aplicaciones, los desarrolladores aún deben asegurarse de que sus aplicaciones funcionen en la nueva actualización del sistema operativo. Google ha realizado muchos cambios a lo largo de los años para facilitar este proceso a los desarrolladores de aplicaciones de Android, y ahora, un nuevo característica en Android 11, llamada DSU Loader, hará que sea aún más fácil para los desarrolladores de aplicaciones probar sus aplicaciones en el nuevo Android versiones.
Comienza con Project Treble
Project Treble, introducido en Android 8.0, es un importante rediseño del sistema operativo Android. El objetivo de Project Treble era dividir el sistema operativo Android en dos grandes partes: el marco y la implementación del proveedor. ("proveedor" aquí se refiere al fabricante de cualquier componente de hardware patentado que se encuentra dentro de un dispositivo, generalmente refiriéndose al silicio). El marco del sistema operativo Android es el propio sistema operativo, incluidas todas las aplicaciones del sistema, la interfaz de usuario y sus componentes, y las API que se comparten entre los dispositivos Android. La implementación del proveedor contiene las HAL (capas de abstracción de hardware) del proveedor y el kernel de Linux y los módulos del kernel de Linux.
Dado que los OEM envían teléfonos inteligentes con muchos componentes de hardware diferentes de muchos proveedores diferentes, tienen que hacer mucho trabajo solo para poner el hardware en funcionamiento en una sola versión del sistema operativo Android. Luego, con cada nueva actualización del sistema operativo Android, tienen que trabajar aún más para asegurarse de que su hardware funcione con la nueva versión. Pero con Project Treble estandarizando la ABI (interfaz binaria de aplicaciones) entre el marco del sistema operativo Android y las HAL para una versión particular de Android, Los OEM de Android pueden comenzar a probar las actualizaciones de sus dispositivos sin necesidad de esperar a que los fabricantes de silicio y otros fabricantes de componentes actualicen su versión. el código. Este cambio se aceleró notablemente la forma en que se manejan las actualizaciones de Android.
Esa es la esencia de lo que Project Treble ha hecho para las actualizaciones de Android, pero lo que es más importante para la aplicación desarrolladores aquí es que Treble ha habilitado el uso de imágenes genéricas del sistema (GSI) para compatibilidad pruebas.
El surgimiento de las GSI
Para que los OEM prueben si han implementado Project Treble correctamente, Google exige que el OEM pueda iniciar una compilación limpia de Android desde AOSP en el dispositivo. Esta versión limpia de Android se llama Imagen genérica del sistema o GSI. Si el GSI arranca y la mayoría del hardware básico funciona correctamente, entonces el OEM sabe que su dispositivo cumple con los requisitos de Project Treble. El propósito inicial de los GSI era probar la compatibilidad de Treble, pero como hemos visto con la comunidad de desarrollo aquí en XDA-Developers, se pueden usar para otros propósitos. Vimos cómo los GSI esencialmente podría permitir que los dispositivos con UX de Android pesados disfruten de la última versión de Android con funciones de trabajo a los pocos días de una nueva versión. Pero Google visualiza otro propósito detrás de GSI: dar a los desarrolladores de aplicaciones la capacidad de probar sus aplicaciones en una nueva versión de Android en un dispositivo físico que ya poseen.
Con Android 10, Google lanzó sus propias compilaciones GSI para desarrolladores. Google consolidó la idea de que los desarrolladores de aplicaciones deberían usar un GSI para iniciar una versión limpia de Android en su propio hardware, lo que facilita la prueba del comportamiento de su aplicación en comparación con Android estándar. Por lo tanto, este método se agregó a las opciones existentes para probar la compatibilidad de la aplicación en Android de serie sin cambios en el comportamiento del OEM, siendo los otros usando un teléfono inteligente Pixel, usando el emulador oficial de Android dentro de Android Studio o implementando compilaciones de aplicaciones en una instancia de dispositivo en la nube.
A pesar de toda la conveniencia que trajeron los GSI, su instalación seguía siendo un proceso engorroso. Es posible que los desarrolladores de aplicaciones no se sientan cómodos con la actualización manual de una imagen del sistema en un dispositivo Android, ya que esto es algo con lo que normalmente solo los aficionados o los desarrolladores del sistema operativo Android están familiarizados. La instalación de un GSI requería actualizar una imagen del sistema a través de fastboot, lo que requiere deshabilitar Android Verified Boot y desbloquear el gestor de arranque. El desbloqueo del gestor de arranque, a su vez, requiere un borrado completo de los datos del usuario. Y como todos sabemos, no existe exactamente un solo proceso o guía para desbloquear el gestor de arranque de todos los dispositivos Android, por lo que no se puede encontrar coherencia. Por ejemplo, los dispositivos Samsung no tienen arranque rápido, mientras que los dispositivos Xiaomi te hacen saltar algunos obstáculos para desbloquear el gestor de arranque. Es un lío conveniente que tiene el potencial de desenredarse en algo más simple.
Aquí es donde entran las actualizaciones dinámicas del sistema.
Actualizaciones dinámicas del sistema simplemente instalando GSI
Google se dio cuenta de que el método actual de instalación de GSI no era una solución perfecta, por lo que comenzó a trabajar en una solución mejor. En Android 10, Google comenzó a probar las actualizaciones dinámicas del sistema, o ESD. DSU es una nueva forma de instalar temporalmente un GSI sin necesidad de usar comandos de arranque rápido para actualizar una imagen del sistema, sobrescribiendo la instalación original. Con DSU, puede iniciar en un GSI, probar su aplicación y luego reiniciar convenientemente en su instalación original que permaneció intacta.
La razón por la que DSU puede instalar un GSI sin tocar la instalación original es que crea nuevas imágenes del sistema y de partición de datos que se almacenan temporalmente en /data/gsi. Estas imágenes luego se montan durante el arranque en lugar del sistema original y las particiones de datos. Debido a que el teléfono necesita espacio de almacenamiento adicional para estas nuevas imágenes temporales, su teléfono debe tener "particiones lógicas" incorporadas, que son particiones de tamaño variable dinámicamente. Las particiones lógicas son un nuevo sistema de partición del espacio de usuario para Android, que es obligatorio para los dispositivos que se inician con Android 10. Si su dispositivo se lanzó con Android 10, entonces debería admitir la instalación de GSI a través de DSU.
En Android 10, todo lo que necesita hacer para instalar un GSI a través de DSU es cambiar una propiedad del sistema y luego iniciar el DynamicSystemUpdatesInstallationService enviando un intento con la ruta al GSI como un intento adicional.
Si bien este proceso puede parecer desconocido, es mucho más fácil y menos intrusivo en comparación con el uso de comandos fastboot y lidiar con la molestia de todo, incluida la instalación original, ser borrado Necesita algún conocimiento de ADB e intenciones de hacer uso de DSU, pero esto no debería ser un problema para la mayoría de los desarrolladores de aplicaciones. Aún así, no hay razón para que el proceso no pueda simplificarse aún más. Además, está el hecho de que la instalación de un GSI a través de DSU aún requiere que desbloquee el gestor de arranque, borrando todos los datos del usuario en el proceso. Con ese fin, Google ha implementado cambios para mejorar ambos aspectos de la instalación de GSI. En Android 11, eliminaron la necesidad de usar la línea de comandos para instalar un GSI. Por separado, también han hecho posible instalar un GSI sin desbloquear el gestor de arranque.
Cargador DSU en Android 11
DSU Loader es una nueva herramienta presente en las Opciones de desarrollador de Android 11 que le permite descargar y instalar el último GSI de Google sin necesidad de ingresar ningún comando fastboot o ADB. Simplemente toque la opción DSU Loader dentro de Configuración y aparecerá un cuadro de diálogo con una lista de GSI compatibles directamente desde Google. Estos GSI admitidos se basarán en su sistema operativo y arquitectura actuales, por lo que solo puede instalar GSI que sean más nuevos que la versión de su sistema operativo y que coincidan con su arquitectura SoC. Simplemente elija el GSI que desea instalar y se descargará de los servidores de Google y se instalará en segundo plano automáticamente.
Con DSU Loader, los desarrolladores nunca tendrán que tocar la línea de comando para instalar un GSI. Al menos, ese es el sueño, porque todavía queda un problema por resolver.
El camino a seguir
Actualmente, para instalar un GSI a través de DSU Loader, necesita un gestor de arranque desbloqueado. Si bien esto puede anular el propósito de toda la prueba, se supone que no debe ser así, y se nos dice que se solucionará. Google ha planeado que los usuarios puedan iniciar GSI firmados por Google a través de DSU sin necesidad de desbloquear el gestor de arranque. De hecho, Google exige que todos los dispositivos de lanzamiento de Android 10 incluyen las claves públicas de Android Verified Boot de GSI de Android 10, Android 11 y Android 12 firmados por Google. Incluir las claves públicas de AVB en el ramdisk del dispositivo garantizará que AVB no rechace el GSI que está intentando iniciar. Esta es la razón por la que el método actual implica desbloquear el cargador de arranque: al mostrar una imagen vbmeta vacía en la partición vbmeta, deshabilita AVB para que no rechace el GSI que está a punto de mostrar. Sin embargo, deshabilitar AVB es un gran riesgo de seguridad, ya que significa que cualquier modificación La partición system/boot/product/vendor se puede cargar en el dispositivo, razón por la cual Google quiere hacer fuera con ese requisito.
Entonces, ¿cuándo puede esperar iniciar un GSI a través de DSU sin tener que desbloquear el gestor de arranque o usar herramientas de línea de comandos? Con suerte, pronto, ya que Google nos mencionó que tenían algunos problemas que solucionar con las vistas previas iniciales para desarrolladores de Android 11 antes de que puedan hacer que todo funcione correctamente. En el futuro, uno puede esperar instalar futuros GSI de Developer Preview a través de DSU sin necesidad de desbloquear el gestor de arranque. Quizás cuando las vistas previas para desarrolladores de Android 12 estén disponibles, incluso podrá iniciarlo por completo usando DSU Loader en las opciones de desarrollador de Android 11. Para los desarrolladores de aplicaciones, esto significa que habrá otra forma de probar sus aplicaciones en hardware físico con una nueva versión de Android.