Se usó la API de Cloud Translation para traducir esta página.

Creación de paquetes OTA

Puede usar la herramienta ota_from_target_files proporcionada en build/make/tools/releasetools para crear paquetes OTA completos e incrementales para dispositivos que usan actualizaciones del sistema A/B o actualizaciones del sistema que no son A/B . La herramienta toma como entrada el archivo target-files.zip producido por el sistema de compilación de Android.

Para dispositivos con Android 11 o superior, puede crear un paquete OTA para varios dispositivos con diferentes SKU. Hacerlo requiere configurar los dispositivos de destino para usar huellas digitales dinámicas y actualizar los metadatos de OTA para incluir el nombre del dispositivo y la huella digital en las entradas de condiciones previas y posteriores.

Android 8.0 dejó de usar paquetes OTA basados en archivos para dispositivos que no son A/B, que en su lugar deben usar paquetes OTA basados en bloques . Para generar paquetes OTA basados en bloques o dispositivos con Android 7.x o anterior, pase la opción --block al parámetro ota_from_target_files .

Creación de actualizaciones completas

Una actualización completa es un paquete OTA que contiene el estado final completo del dispositivo (sistema, arranque y particiones de recuperación). Siempre que el dispositivo sea capaz de recibir y aplicar el paquete, el paquete puede instalar la compilación independientemente del estado actual del dispositivo. Por ejemplo, los siguientes comandos utilizan herramientas de lanzamiento para crear el archivo target-files.zip para el dispositivo tardis .

. build/envsetup.sh && lunch tardis-eng
mkdir dist_output
make dist DIST_DIR=dist_output

make dist crea un paquete OTA completo (en $OUT ). El archivo .zip resultante contiene todo lo necesario para construir paquetes OTA para el dispositivo tardis . También puede compilar ota_from_target_files como un binario de python y llamarlo para compilar paquetes completos o incrementales.

ota_from_target_files dist_output/tardis-target_files.zip ota_update.zip

La ruta ota_from_target_files se configura en $PATH y el binario de python resultante se encuentra en el directorio out/ .

ota_update.zip ahora está listo para enviarse a los dispositivos de prueba (todo está firmado con la clave de prueba). Para los dispositivos de los usuarios, genere y use sus propias claves privadas como se detalla en Firma de compilaciones para el lanzamiento .

Creación de actualizaciones incrementales

Una actualización incremental es un paquete OTA que contiene parches binarios para los datos que ya están en el dispositivo. Los paquetes con actualizaciones incrementales suelen ser más pequeños, ya que no necesitan incluir archivos sin cambios. Además, como los archivos modificados suelen ser muy similares a sus versiones anteriores, el paquete solo necesita incluir una codificación de las diferencias entre los dos archivos.

Puede instalar un paquete de actualización incremental solo en dispositivos que tengan la compilación de origen utilizada para construir el paquete. Para crear una actualización incremental, necesita el archivo target_files.zip de la compilación anterior ( desde la que desea actualizar), así como el archivo target_files.zip de la nueva compilación. Por ejemplo, los siguientes comandos usan herramientas de lanzamiento para crear una actualización incremental para el dispositivo tardis .

ota_from_target_files -i PREVIOUS-tardis-target_files.zip dist_output/tardis-target_files.zip incremental_ota_update.zip

Esta compilación es muy similar a la compilación anterior y el paquete de actualización incremental ( incremental_ota_update.zip ) es mucho más pequeño que la actualización completa correspondiente (alrededor de 1 MB en lugar de 60 MB).

Distribuya un paquete incremental solo a dispositivos que ejecuten exactamente la misma compilación anterior utilizada como punto de partida del paquete incremental. Debes flashear las imágenes en PREVIOUS-tardis-target_files.zip o PREVIOUS-tardis-img.zip (ambas creadas con make dist , para ser flasheadas con fastboot update ), en lugar de las que se encuentran en el directorio PRODUCT_OUT (creadas con make , que será flasheado con fastboot flashall ). Intentar instalar el paquete incremental en un dispositivo con otra compilación da como resultado un error de instalación. Cuando falla la instalación, el dispositivo permanece en el mismo estado de funcionamiento (ejecutando el sistema anterior); el paquete verifica el estado anterior de todos los archivos que actualiza antes de tocarlos, por lo que el dispositivo no se queda varado en un estado medio actualizado.

Para obtener la mejor experiencia de usuario, ofrezca una actualización completa cada 3 o 4 actualizaciones incrementales. Esto ayuda a los usuarios a ponerse al día con la última versión y evitar una larga secuencia de instalación de actualizaciones incrementales.

Creación de paquetes OTA para múltiples SKU

Android 11 o superior admite el uso de un solo paquete OTA para múltiples dispositivos con diferentes SKU. Hacerlo requiere configurar los dispositivos de destino para usar huellas digitales dinámicas y actualizar los metadatos de OTA (usando herramientas de OTA) para incluir el nombre del dispositivo y la huella digital en las entradas de condición previa y posterior.

Acerca de los SKU

El formato de un SKU es una variación de los valores de parámetros de compilación combinados y, por lo general, es un subconjunto no declarado de los parámetros build_fingerprint actuales. Los OEM pueden usar cualquier combinación de parámetros de compilación aprobados por CDD para un SKU y, al mismo tiempo, usar una sola imagen para esos SKU. Por ejemplo, el siguiente SKU tiene múltiples variaciones:

SKU = <product><device><modifierA><modifierB><modifierC>

modifierA es el nivel del dispositivo (como Pro, Premium o Plus)
modifierB es la variación de hardware (como la radio)
modifierC es la región, que puede ser general (como NA, EMEA o CHN) o específica de un país o idioma (como JPN, ENG o CHN)

Muchos OEM usan una sola imagen para múltiples SKU, luego derivan el nombre del producto final y la huella digital del dispositivo en tiempo de ejecución después de que se inicia el dispositivo. Este proceso simplifica el proceso de desarrollo de la plataforma, lo que permite que los dispositivos con personalizaciones menores pero diferentes nombres de productos compartan imágenes comunes (como tardis y tardispro ).

Uso de huellas dactilares dinámicas

Una huella digital es una concatenación definida de parámetros de compilación , como ro.product.brand , ro.product.name y ro.product.device . La huella digital de un dispositivo se deriva de la huella digital de la partición del sistema y se usa como un identificador único de las imágenes (y bytes) que se ejecutan en el dispositivo. Para crear una huella digital dinámica , use la lógica dinámica en el archivo build.prop del dispositivo para obtener el valor de las variables del cargador de arranque en el momento del arranque del dispositivo, luego use esos datos para crear una huella digital dinámica para ese dispositivo.

Por ejemplo, para usar huellas dactilares dinámicas para dispositivos tardis y tardispro , actualice los siguientes archivos como se muestra a continuación.

Actualice el odm/etc/build_std.prop para que contenga la siguiente línea.
```
ro.odm.product.device=tardis
```
Actualice el odm/etc/build_pro.prop para que contenga la siguiente línea.
```
ro.odm.product.device=tardispro
```

Actualice el odm/etc/build.prop para que contenga las siguientes líneas.

ro.odm.product.device=tardis
import /odm/etc/build_${ro.boot.product.hardware.sku}.prop

Estas líneas establecen dinámicamente el nombre del dispositivo, la huella digital y los valores ro.build.fingerprint en función del valor de la propiedad del cargador de arranque ro.boot.product.hardware.sku (que es de solo lectura).

Actualización de metadatos de paquetes OTA

Un paquete OTA contiene un archivo de metadatos ( META-INF/com/android/metadata ) que describe el paquete, incluidas las condiciones previas y posteriores del paquete OTA. Por ejemplo, el siguiente código es el archivo de metadatos para un paquete OTA dirigido al dispositivo tardis .

post-build=google/tardis/tardis:11/RP1A.200521.001/6516341:userdebug/dev-keys
post-build-incremental=6516341
post-sdk-level=30
post-security-patch-level=2020-07-05
post-timestamp=1590026334
pre-build=google/tardis/tardis:11/RP1A.200519.002.A1/6515794:userdebug/dev-keys
pre-build-incremental=6515794
pre-device=tardis

Los valores pre-device , pre-build-incremental y pre-build definen el estado que debe tener un dispositivo antes de que se pueda instalar el paquete OTA. Los valores post-build-incremental y post-build definen el estado que se espera que tenga un dispositivo después de que se instale el paquete OTA. Los valores de los campos pre- y post- se derivan de las siguientes propiedades de compilación correspondientes.

El valor pre-device se deriva de la propiedad de compilación ro.product.device .
Los valores incrementales pre-build-incremental y post-build-incremental se derivan de la propiedad de compilación ro.build.version.incremental .
Los valores pre-build y post-build se derivan de la propiedad de compilación ro.build.fingerprint .

En los dispositivos que ejecutan Android 11 o superior, puede usar el indicador --boot_variable_file en las herramientas OTA para especificar una ruta a un archivo que contiene los valores de las variables de tiempo de ejecución utilizadas para crear la huella digital dinámica del dispositivo. Luego, los datos se usan para actualizar los metadatos de OTA para incluir el nombre del dispositivo y la huella digital en las condiciones pre- y post- (usando el carácter de canalización | como delimitador). El indicador --boot_variable_file tiene la siguiente sintaxis y descripción.

Sintaxis: --boot_variable_file <path>
Descripción: especifica una ruta a un archivo que contiene los posibles valores de las propiedades ro.boot.* . Se utiliza para calcular las posibles huellas dactilares en tiempo de ejecución cuando la declaración de importación anula algunas propiedades ro.product.* . El archivo espera una propiedad por línea donde cada línea tiene el siguiente formato: prop_name=value1,value2 .

Por ejemplo, cuando la propiedad es ro.boot.product.hardware.sku=std,pro , los metadatos OTA para dispositivos tardis y tardispro son los que se muestran a continuación.

post-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-device=tardis|tardispro

Para admitir esta funcionalidad en dispositivos que ejecutan Android 10, consulte la implementación de referencia . Esta lista de cambios analiza condicionalmente las declaraciones de import en el archivo build.prop , lo que permite que las anulaciones de propiedades se reconozcan y se reflejen en los metadatos OTA finales.