Preguntas frecuentes

¿Google ha utilizado OTA A/B en algún dispositivo?

Sí. El nombre comercial de las actualizaciones A/B es actualizaciones continuas . Los teléfonos Pixel y Pixel XL de octubre de 2016 se enviaron con A/B, y todos los Chromebook usan la misma implementación update_engine de A/B. La implementación del código de la plataforma necesaria es pública en Android 7.1 y versiones posteriores.

¿Por qué las OTA A/B son mejores?

Las OTA A/B brindan una mejor experiencia de usuario al tomar actualizaciones. Las mediciones de las actualizaciones de seguridad mensuales muestran que esta función ya ha demostrado ser un éxito: a partir de mayo de 2017, el 95 % de los propietarios de Pixel están ejecutando la última actualización de seguridad después de un mes en comparación con el 87 % de los usuarios de Nexus, y los usuarios de Pixel actualizan antes que los usuarios de Nexus. Las fallas en la actualización de bloques durante una OTA ya no resultan en un dispositivo que no arranca; hasta que la nueva imagen del sistema se haya iniciado correctamente, Android conserva la capacidad de volver a la imagen anterior del sistema en funcionamiento.

¿Cómo afectó A/B a los tamaños de partición de píxeles de 2016?

La siguiente tabla contiene detalles sobre la configuración A/B de envío frente a la configuración no A/B probada internamente:

Tamaños de partición de píxeles A/B No-A/B
cargador de arranque 50*2 50
Bota 32*2 32
Recuperación 0 32
Cache 0 100
Radio 70*2 70
Vendedor 300*2 300
Sistema 2048*2 4096
Total 5000 4680

Las actualizaciones A/B requieren un aumento de solo 320 MiB en flash, con un ahorro de 32 MiB al eliminar la partición de recuperación y otros 100 MiB preservados al eliminar la partición de caché. Esto equilibra el costo de las particiones B para el gestor de arranque, la partición de arranque y la partición de radio. La partición del proveedor se duplicó en tamaño (la gran mayoría del aumento de tamaño). La imagen del sistema A/B de Pixel tiene la mitad del tamaño de la imagen original del sistema que no es A/B.

Para las variantes Pixel A/B y no A/B probadas internamente (solo se envió A/B), el espacio utilizado difirió solo en 320 MiB. En un dispositivo de 32 GiB, esto es un poco menos del 1 %. Para un dispositivo de 16 GiB, esto sería menos del 2 %, y para un dispositivo de 8 GiB, casi el 4 % (suponiendo que los tres dispositivos tuvieran la misma imagen del sistema).

¿Por qué no usaste SquashFS?

Experimentamos con SquashFS pero no pudimos lograr el rendimiento deseado para un dispositivo de gama alta. No usamos ni recomendamos SquashFS para dispositivos portátiles.

Más específicamente, SquashFS proporcionó un ahorro de tamaño de alrededor del 50 % en la partición del sistema, pero la gran mayoría de los archivos que se comprimieron bien fueron los archivos .odex precompilados. Esos archivos tenían índices de compresión muy altos (cerca del 80 %), pero el índice de compresión para el resto de la partición del sistema era mucho más bajo. Además, SquashFS en Android 7.0 planteó los siguientes problemas de rendimiento:

  • Pixel tiene un flash muy rápido en comparación con los dispositivos anteriores, pero no una gran cantidad de ciclos de CPU libres, por lo que leer menos bytes del flash pero necesitar más CPU para E/S era un cuello de botella potencial.
  • Los cambios de E/S que funcionan bien en un punto de referencia artificial que se ejecuta en un sistema descargado a veces no funcionan bien en casos de uso del mundo real bajo carga del mundo real (como criptografía en Nexus 6).
  • La evaluación comparativa mostró regresiones del 85% en algunos lugares.

A medida que SquashFS madura y agrega funciones para reducir el impacto de la CPU (como una lista blanca de archivos de acceso común que no deben comprimirse), continuaremos evaluándolo y ofreciendo recomendaciones a los fabricantes de dispositivos.

¿Cómo redujo a la mitad el tamaño de la partición del sistema sin SquashFS?

Las aplicaciones se almacenan en archivos .apk, que en realidad son archivos ZIP. Cada archivo .apk contiene uno o más archivos .dex que contienen el código de bytes Dalvik portátil. Un archivo .odex (.dex optimizado) vive por separado del archivo .apk y puede contener código de máquina específico para el dispositivo. Si hay un archivo .odex disponible, Android puede ejecutar aplicaciones a velocidades compiladas con anticipación sin tener que esperar a que se compile el código cada vez que se inicia la aplicación. Un archivo .odex no es estrictamente necesario: Android puede ejecutar el código .dex directamente a través de la interpretación o la compilación Just-In-Time (JIT), pero un archivo .odex proporciona la mejor combinación de velocidad de lanzamiento y velocidad de tiempo de ejecución si el espacio está disponible.

Ejemplo: Para los archivos instalados.txt de un Nexus 6P con Android 7.1 con un tamaño total de imagen del sistema de 2628MiB (2755792836 bytes), el desglose de los mayores contribuyentes al tamaño general de la imagen del sistema por tipo de archivo es el siguiente:

.odex 1391770312 bytes 50,5%
.apk 846878259 bytes 30,7%
.so (código C/C++ nativo) 202162479 bytes 7,3%
Archivos .oat/imágenes .art 163892188 bytes 5,9%
fuentes 38952361 bytes 1,4%
datos de la configuración regional de la UCI 27468687 bytes 0,9%

Estas cifras también son similares para otros dispositivos, por lo que en los dispositivos Nexus/Pixel, los archivos .odex ocupan aproximadamente la mitad de la partición del sistema. Esto significaba que podíamos seguir usando ext4 pero escribir los archivos .odex en la partición B de fábrica y luego copiarlos en /data en el primer arranque. El almacenamiento real que se usa con ext4 A/B es idéntico al de SquashFS A/B, porque si hubiéramos usado SquashFS, habríamos enviado los archivos .odex preoptados en system_a en lugar de system_b.

¿Copiar archivos .odex a /data no significa que el espacio guardado en /system se pierde en /data?

No exactamente. En Pixel, la mayor parte del espacio que ocupan los archivos .odex es para aplicaciones, que normalmente existen en /data . Estas aplicaciones aceptan actualizaciones de Google Play, por lo que los archivos .apk y .odex en la imagen del sistema no se usan durante la mayor parte de la vida útil del dispositivo. Dichos archivos se pueden excluir por completo y reemplazar por pequeños archivos .odex controlados por perfiles cuando el usuario realmente usa cada aplicación (por lo que no requieren espacio para las aplicaciones que el usuario no usa). Para obtener más información, consulte la charla de Google I/O 2016 La evolución del arte .

La comparación es difícil por algunas razones clave:

  • Las aplicaciones actualizadas por Google Play siempre han tenido sus archivos .odex en /data tan pronto como reciben su primera actualización.
  • Las aplicaciones que el usuario no ejecuta no necesitan ningún archivo .odex.
  • La compilación basada en perfiles genera archivos .odex más pequeños que la compilación anticipada (porque la primera solo optimiza el código crítico para el rendimiento).

Para obtener detalles sobre las opciones de ajuste disponibles para los OEM, consulte Configuración de ART .

¿No hay dos copias de los archivos .odex en /data?

Es un poco más complicado... Después de escribir la nueva imagen del sistema, la nueva versión de dex2oat se ejecuta contra los nuevos archivos .dex para generar los nuevos archivos .odex. Esto ocurre mientras el sistema antiguo aún se está ejecutando, por lo que los archivos .odex antiguo y nuevo están en /data al mismo tiempo.

El código en OtaDexoptService ( frameworks/base/+/master/services/core/java/com/android/server/pm/OtaDexoptService.java ) llama a getAvailableSpace antes de optimizar cada paquete para evitar sobrellenar /data . Tenga en cuenta que disponible aquí sigue siendo conservador: es la cantidad de espacio que queda antes de alcanzar el umbral de espacio bajo del sistema habitual (medido como un porcentaje y un recuento de bytes). Entonces, si /data está lleno, no habrá dos copias de cada archivo .odex. El mismo código también tiene un BULK_DELETE_THRESHOLD: si el dispositivo se acerca tanto al espacio disponible (como se acaba de describir), se eliminan los archivos .odex que pertenecen a las aplicaciones que no se usan. Ese es otro caso sin dos copias de cada archivo .odex.

En el peor de los casos, cuando /data está completamente lleno, la actualización espera hasta que el dispositivo se haya reiniciado en el nuevo sistema y ya no necesite los archivos .odex del sistema anterior. PackageManager maneja esto: ( frameworks/base/+/master/services/core/java/com/android/server/pm/PackageManagerService.java#7215 ). Después de que el nuevo sistema haya arrancado con éxito, installd ( frameworks/native/+/master/cmds/installd/dexopt.cpp#2422 ) puede eliminar los archivos .odex que usaba el sistema anterior, devolviendo el dispositivo al estado estable. donde solo hay una copia.

Entonces, si bien es posible que /data contenga dos copias de todos los archivos .odex, (a) esto es temporal y (b) solo ocurre si tiene suficiente espacio libre en /data todos modos. Excepto durante una actualización, solo hay una copia. Y como parte de las características generales de robustez de ART, nunca llenará /data con archivos .odex de todos modos (porque eso también sería un problema en un sistema que no sea A/B).

¿Toda esta escritura/copia no aumenta el desgaste del flash?

Solo se reescribe una pequeña parte de la memoria flash: una actualización completa del sistema Pixel escribe alrededor de 2,3 GiB. (Las aplicaciones también se vuelven a compilar, pero eso también se aplica a las que no son A/B). Tradicionalmente, las OTA completas basadas en bloques escribieron una cantidad similar de datos, por lo que las tasas de uso de flash deberían ser similares.

¿Flashear dos particiones del sistema aumenta el tiempo de flasheo de fábrica?

No. Pixel no aumentó el tamaño de la imagen del sistema (simplemente dividió el espacio en dos particiones).

¿Mantener los archivos .odex en B no hace que el reinicio después del restablecimiento de datos de fábrica sea lento?

Sí. Si realmente usó un dispositivo, tomó una OTA y realizó un restablecimiento de datos de fábrica, el primer reinicio será más lento de lo que sería de otra manera (1m40s vs 40s en un Pixel XL) porque los archivos .odex se habrán perdido de B después de la primera OTA, por lo que no se puede copiar a /data . Esa es la compensación.

El restablecimiento de datos de fábrica debería ser una operación rara en comparación con el arranque normal, por lo que el tiempo necesario es menos importante. (Esto no afecta a los usuarios o revisores que obtienen su dispositivo de fábrica, porque en ese caso la partición B está disponible). El uso del compilador JIT significa que no necesitamos volver a compilar todo , por lo que no es tan malo como usted. podría pensar. También es posible marcar aplicaciones que requieren compilación anticipada usando coreApp="true" en el manifiesto: ( frameworks/base/+/master/packages/SystemUI/AndroidManifest.xml#23 ). system_server lo usa actualmente porque no está permitido JIT por razones de seguridad.

¿Mantener los archivos .odex en /data en lugar de /system hace que el reinicio después de una OTA sea lento?

No. Como se explicó anteriormente, el nuevo dex2oat se ejecuta mientras la imagen del sistema anterior todavía se está ejecutando para generar los archivos que necesitará el nuevo sistema. La actualización no se considera disponible hasta que se haya realizado ese trabajo.

¿Podemos (debemos) enviar un dispositivo A/B de 32 GiB? 16GiB? 8GiB?

32GiB funciona bien como se demostró en Pixel, y 320MiB de 16GiB significa una reducción del 2%. Del mismo modo, 320MiB de 8GiB una reducción del 4%. Obviamente, A/B no sería la opción recomendada en dispositivos con 4 GiB, ya que la sobrecarga de 320 MiB es casi el 10 % del espacio total disponible.

¿AVB2.0 requiere A/B OTA?

No. Android Verified Boot siempre ha requerido actualizaciones basadas en bloques, pero no necesariamente actualizaciones A/B.

¿Las OTA A/B requieren AVB2.0?

No.

¿Las OTA A/B rompen la protección de reversión de AVB2.0?

No. Hay cierta confusión aquí porque si un sistema A/B no se inicia en la nueva imagen del sistema (después de una cantidad de reintentos determinada por su gestor de arranque) volverá automáticamente a la imagen del sistema "anterior". Sin embargo, el punto clave aquí es que "anterior" en el sentido A/B sigue siendo en realidad la imagen del sistema "actual". Tan pronto como el dispositivo inicia con éxito una nueva imagen, la protección de reversión se activa y garantiza que no pueda volver atrás. Pero hasta que haya arrancado con éxito la nueva imagen, la protección de reversión no considera que sea la imagen del sistema actual.

Si está instalando una actualización mientras el sistema está funcionando, ¿no es lento?

Con las actualizaciones que no son A/B, el objetivo es instalar la actualización lo más rápido posible porque el usuario está esperando y no puede usar su dispositivo mientras se aplica la actualización. Con las actualizaciones A/B, ocurre lo contrario; Debido a que el usuario todavía está usando su dispositivo, el objetivo es el menor impacto posible, por lo que la actualización es deliberadamente lenta. A través de la lógica en el cliente de actualización del sistema Java (que para Google es GmsCore, el paquete central proporcionado por GMS), Android también intenta elegir un momento en el que los usuarios no estén usando sus dispositivos en absoluto. La plataforma admite pausar/reanudar la actualización, y el cliente puede usar eso para pausar la actualización si el usuario comienza a usar el dispositivo y reanudarla cuando el dispositivo esté inactivo nuevamente.

Hay dos fases al tomar una OTA, que se muestran claramente en la interfaz de usuario como Paso 1 de 2 y Paso 2 de 2 debajo de la barra de progreso. El paso 1 corresponde con la escritura de los bloques de datos, mientras que el paso 2 es la compilación previa de los archivos .dex. Estas dos fases son bastante diferentes en términos de impacto en el rendimiento. La primera fase es E/S simple. Esto requiere pocos recursos (RAM, CPU, E/S) porque solo está copiando bloques lentamente.

La segunda fase ejecuta dex2oat para precompilar la nueva imagen del sistema. Obviamente, esto tiene límites menos claros en sus requisitos porque compila aplicaciones reales. Y obviamente hay mucho más trabajo involucrado en compilar una aplicación grande y compleja que una aplicación pequeña y simple; mientras que en la fase 1 no hay bloques de disco que sean más grandes o más complejos que otros.

El proceso es similar a cuando Google Play instala una actualización de la aplicación en segundo plano antes de mostrar la notificación de actualización de las 5 aplicaciones , como se ha hecho durante años.

¿Qué sucede si un usuario realmente está esperando la actualización?

La implementación actual en GmsCore no distingue entre actualizaciones en segundo plano y actualizaciones iniciadas por el usuario, pero podría hacerlo en el futuro. En el caso de que el usuario solicite explícitamente que se instale la actualización o esté viendo la pantalla de progreso de la actualización, priorizaremos el trabajo de actualización suponiendo que está esperando activamente a que finalice.

¿Qué sucede si no se aplica una actualización?

Con las actualizaciones que no son A/B, si una actualización no se aplicaba, el usuario generalmente se quedaba con un dispositivo inutilizable. La única excepción era si la falla ocurría antes de que se iniciara una aplicación (porque el paquete no se pudo verificar, por ejemplo). Con las actualizaciones A/B, el hecho de no aplicar una actualización no afecta el sistema que se está ejecutando actualmente. La actualización simplemente se puede volver a intentar más tarde.

¿Qué sistemas en un chip (SoC) admiten A/B?

Al 15-03-2017, tenemos la siguiente información:

Android 7.x y anteriores Android 8.x y posterior
Qualcomm Dependiendo de las solicitudes del OEM Todos los conjuntos de chips obtendrán soporte
mediatek Dependiendo de las solicitudes del OEM Todos los conjuntos de chips obtendrán soporte

Para obtener detalles sobre los horarios, consulte con sus contactos de SoC. Para los SoC que no aparecen en la lista anterior, comuníquese directamente con su SoC.