Cómo reducir el tamaño inalámbrico

En esta página, se describen los cambios que se agregaron a AOSP para reducir los cambios innecesarios de archivos entre compilaciones. Los implementadores de dispositivos que mantienen sus propios sistemas de compilación pueden usar esta información como guía. para reducir el tamaño de sus actualizaciones inalámbricas.

En ocasiones, las actualizaciones inalámbricas de Android contienen archivos modificados que no corresponden a cambios de código. En realidad, son artefactos del sistema de compilación. Esto puede ocurrir cuando el mismo código, compilado en diferentes en diferentes directorios o en diferentes máquinas produce una gran cantidad de cambios archivos. Estos archivos excesivos aumentan el tamaño de un parche inalámbrico y dificultan la determinación qué código cambió.

Para que el contenido de una OTA sea más transparente, AOSP incluye cambios de sistema de compilación diseñados para reducir el tamaño de los parches inalámbricos. Se realizaron cambios innecesarios de archivos entre compilaciones y solo los archivos relacionados con parches se incluyen en las actualizaciones OTA. AOSP también incluye Herramienta de diferencias de compilación, que filtra las opciones comunes relacionadas con compilaciones cambios en los archivos para proporcionar una diferencia más clara del archivo de compilación y un herramienta de asignación de bloques, que ayuda a mantener la asignación de bloques coherentes.

Un sistema de compilación puede crear parches innecesariamente grandes de varias maneras. Para mitigar esto, en En Android 8.0 y versiones posteriores, se implementaron nuevas funciones para reducir el tamaño del parche para cada diferencia del archivo Entre las mejoras que se redujeron los tamaños de los paquetes de actualizaciones OTA, se incluyen las siguientes:

  • El uso de ZSTD, un algoritmo de compresión sin pérdida de uso genérico para en actualizaciones de dispositivos que no sean A/B. ZSTD se puede personalizar para valores mayores las proporciones de compresión aumentando el nivel de compresión. El nivel de compresión se establece durante OTA de generación de demanda y se puede establecer pasando la marca --vabc_compression_param=zstd,$COMPRESSION_LEVEL
  • Aumentar el tamaño de la ventana de compresión que se usa durante la actualización inalámbrica El tamaño máximo de ventana de compresión Para ello, se puede personalizar el parámetro de compilación en el archivo .mk de un dispositivo. Esta variable se establece como PRODUCT_VIRTUAL_AB_COMPRESSION_FACTOR := 262144 .
  • Uso de la recompresión Puffin, una herramienta de aplicación de parches determinista para la desinflación. , que controla las funciones de compresión y diferenciación para la generación de actualizaciones A/B OTA.
  • Los cambios en el uso de la herramienta de generación delta, como la forma bsdiff para comprimir parches. En Android 9 y versiones posteriores, la La herramienta bsdiff selecciona el algoritmo de compresión que le daría obtener los mejores resultados de compresión para un parche.
  • Mejoras en la update_engine se consumió menos memoria al aplicar parches para las actualizaciones A/B de los dispositivos.

En las siguientes secciones, se analizan varios problemas que afectan los tamaños de las actualizaciones OTA, y ejemplos de implementación en el AOSP.

Orden de archivos

Problema: Los sistemas de archivos no garantizan un orden de archivos cuando se les solicita una lista de archivos. en un directorio, aunque suele ser lo mismo para la misma confirmación de la compra. Herramientas como ls ordena los resultados de forma predeterminada, pero la función comodín que usan los comandos como ya que find y make no ordenan. Antes de usar estas herramientas, debes ordenar los resultados.

Solución: Cuando usas herramientas como find y make con la función comodín, ordena el resultado de estos comandos antes de usarlos de ellos. Cuando uses $(wildcard) o $(shell find) en Android.mk, ordénalos también. Algunas herramientas, como Java, ordenan las entradas, por lo que Antes de ordenar los archivos, verifica que la herramienta que estás usando aún no lo haya hecho.

Ejemplos: Muchas instancias se corrigieron en el sistema de compilación principal con la macro all-*-files-under integrada, que incluye all-cpp-files-under (ya que varias definiciones se distribuyeron en otros archivos makefile). Para obtener más detalles, consulta lo siguiente:

Directorio de compilación

Problema: Cambiar el directorio en el que se compilan los elementos puede causar la binarios diferentes. La mayoría de las rutas de acceso en la compilación de Android son relativas __FILE__ en C/C++ no es un problema. Sin embargo, los símbolos de depuración codifican el de ruta de acceso de forma predeterminada, y .note.gnu.build-id se genera a partir de la generación de hash del binario eliminado previamente, por lo que cambiará si cambian los símbolos de depuración.

Solución: El AOSP ahora hace relativas las rutas de depuración. Para obtener más información, consulta CL: https://android.googlesource.com/platform/build/+/6a66a887baadc9eb3d0d60e26f748b8453e27a02.

Marcas de tiempo

Problema: Las marcas de tiempo en el resultado de la compilación generan cambios innecesarios en los archivos. Es probable que esto suceda en las siguientes ubicaciones:

  • Macros __DATE__/__TIME__/__TIMESTAMP__ en código C o C++.
  • Marcas de tiempo incorporadas en archivos basados en ZIP.

Soluciones/ejemplos: Para quitar marcas de tiempo del resultado de la compilación, usa el instrucciones que se proporcionan a continuación en __DATE__/__TIME__/__TIMESTAMP__ en C/C++ y Marcas de tiempo incorporadas en archivos.

__DATE__/__TIME__/__TIMESTAMP__ en C/C++

Estas macros siempre producen resultados diferentes para compilaciones diferentes, así que no las uses. Aquí hay algunas opciones para eliminar estas macros:

Marcas de tiempo incorporadas en archivos (zip, jar)

Android 7.0 solucionó el problema de marcas de tiempo incorporadas en archivos zip agregando -X para todos los usos del comando zip. Esto quitó el UID/GID del y la marca de tiempo extendida de Unix del archivo ZIP.

Una nueva herramienta, ziptime (ubicada en /platform/build/+/main/tools/ziptime/) restablece las marcas de tiempo normales en los encabezados ZIP. Para obtener más información, consulta la README.

La herramienta signapk establece marcas de tiempo para los archivos APK que pueden variar según el la zona horaria del servidor. Para obtener más información, consulta la CL. https://android.googlesource.com/platform/build/+/6c41036bcf35fe39162b50d27533f0f3bfab3028.

La herramienta signapk establece marcas de tiempo para los archivos APK que pueden variar según el la zona horaria del servidor. Para obtener más información, consulta la CL. https://android.googlesource.com/platform/build/+/6c41036bcf35fe39162b50d27533f0f3bfab3028.

Cadenas de la versión

Problema: Las cadenas de la versión del APK a menudo incluían el elemento BUILD_NUMBER. a sus versiones codificadas. Incluso si nada más cambia en un APK, como resultado, el APK seguirán siendo diferentes.

Solución: Quita el número de compilación de la string de versión del APK.

Ejemplos:

Habilita el procesamiento de verity en el dispositivo

Si dm-verity esté habilitada en el dispositivo, las herramientas inalámbricas tomarán automáticamente tu configuración de verity habilitar el procesamiento de verity en el dispositivo. Esto permite que los bloques de verity se calculen en Android en lugar de almacenarse como bytes sin procesar en tu paquete inalámbrico. Los bloques de verity pueden usar aproximadamente 16 MB para una partición de 2 GB.

Sin embargo, el procesamiento de la veridad en el dispositivo puede llevar mucho tiempo. En específico, la capa Forward El código de corrección de errores puede tardar mucho tiempo. En los dispositivos Pixel, suele tardar hasta 10 minutos. En dispositivos de gama baja, podría tardar más. Si quieres inhabilitar la verity en el dispositivo pero aún habilitar dm-verity, puedes hacerlo pasando --disable_fec_computation a la herramienta de ota_from_target_files cuando generar una actualización OTA. Esta marca inhabilita el cálculo de verity en el dispositivo durante las actualizaciones OTA. Reduce el tiempo de instalación inalámbrica, pero aumenta el tamaño del paquete inalámbrico. Si tu dispositivo no tienen dm-verity habilitado, pasar esta marca no tiene ningún efecto.

Herramientas de compilación coherentes

Problema: Las herramientas que generan archivos instalados deben ser coherentes (un siempre debería producir el mismo resultado).

Soluciones/ejemplos: Se requerían cambios en las siguientes herramientas de compilación:

Cómo usar la herramienta de diferencias de compilación

En los casos en los que no es posible eliminar los cambios en los archivos relacionados con la compilación, el AOSP incluye un herramienta de diferencias de compilación, target_files_diff.py para comparar dos paquetes de archivos. Esta herramienta realiza una diferencia recurrente entre dos sin incluir los cambios de archivo comunes relacionados con las compilaciones, como

  • Cambios esperados en el resultado de la compilación (por ejemplo, debido a un cambio en el número de compilación)
  • Cambios debido a problemas conocidos en el sistema de compilación actual.

Para usar la herramienta de diferencias de compilación, ejecuta el siguiente comando:

target_files_diff.py dir1 dir2

dir1 y dir2 son directorios base que contienen el destino extraído. archivos para cada compilación.

Mantén la coherencia de la asignación de bloques

Para un archivo determinado, si bien su contenido sigue siendo el mismo entre dos compilaciones, los bloques reales que contienen los datos pueden haber cambiado. Como resultado, el actualizador debe realizar operaciones de E/S innecesarias para mover los bloques y realizar una actualización inalámbrica.

En una actualización inalámbrica A/B virtual, las operaciones de E/S innecesarias pueden aumentar en gran medida el espacio de almacenamiento necesario para almacenar la instantánea de la copia en escritura. En una actualización inalámbrica que no es A/B, mover los bloques para obtener un La actualización OTA contribuye al tiempo de actualización, ya que hay más E/S debido a movimientos de bloqueo.

Para solucionar este problema, en Android 7.0, Google extendió la herramienta make_ext4fs a y mantener la coherencia de la asignación de bloques en todas las compilaciones La herramienta make_ext4fs acepta una marca opcional -d base_fs que intenta asignar archivos a los mismos bloques cuando se genera una imagen ext4. Puedes extraer los archivos de asignación de bloques (como los archivos de mapa base_fs) de los archivos de destino de una compilación anterior ZIP. Por cada ext4, hay un archivo .map en el archivo IMAGES (por ejemplo, IMAGES/system.map corresponde a la system). Esos base_fs archivos luego podrán registrarse y especificadas a través de PRODUCT_<partition>_BASE_FS_PATH, como en este ejemplo: 

  PRODUCT_SYSTEM_BASE_FS_PATH := path/to/base_fs_files/base_system.map
  PRODUCT_SYSTEM_EXT_BASE_FS_PATH := path/to/base_fs_files/base_system_ext.map
  PRODUCT_VENDOR_BASE_FS_PATH := path/to/base_fs_files/base_vendor.map
  PRODUCT_PRODUCT_BASE_FS_PATH := path/to/base_fs_files/base_product.map
  PRODUCT_ODM_BASE_FS_PATH := path/to/base_fs_files/base_odm.map

Si bien esto no ayuda a reducir el tamaño general del paquete inalámbrico, sí mejora reduciendo la cantidad de E/S. En el caso de las actualizaciones A/B virtuales, reduce drásticamente el la cantidad de espacio de almacenamiento necesaria para aplicar la OTA.

Evita actualizar apps

Además de minimizar las diferencias de compilación, puedes reducir el tamaño de las actualizaciones OTA excluyendo las actualizaciones para las apps que reciben actualizaciones a través de tiendas de aplicaciones. Los APK a menudo son una parte importante varias particiones en un dispositivo. Se incluyen las versiones más recientes de apps que se actualizan por app de almacenamiento OTA pueden tener un gran impacto en los paquetes OTA y proporcionar se beneficien. Para cuando los usuarios reciban un paquete inalámbrico, es posible que ya tengan la app actualizada. una versión aún más reciente, recibida directamente de las tiendas de aplicaciones.