Puedes usar la herramienta ota_from_target_files que se proporciona en build/make/tools/releasetools para compilar paquetes inalámbricos incrementales y completos 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 que produce el sistema de compilación de Android.
En el caso de los dispositivos que ejecutan Android 11 o versiones posteriores, puedes compilar un paquete inalámbrico para varios dispositivos con diferentes SKU. Para ello, debes configurar los dispositivos de destino de modo que usen huellas digitales dinámicas y actualizar los metadatos de OTA para incluir el nombre del dispositivo y la huella digital en las entradas previa y posterior a la condición.
Android 8.0 dio de baja los paquetes inalámbricos basados en archivos para los dispositivos que no son A/B, que deben usar paquetes inalámbricos basados en bloques. Para generar paquetes inalámbricos o dispositivos basados en bloques que ejecuten Android 7.x o versiones anteriores, pasa la opción --block al parámetro ota_from_target_files.
Crea actualizaciones completas
Una actualización completa es un paquete inalámbrico que contiene todo el estado final del dispositivo (particiones de sistema, inicio y recuperación). Siempre que el dispositivo sea capaz de recibir y aplicar el paquete, este podrá instalar la compilación independientemente del estado actual del dispositivo. Por ejemplo, los siguientes comandos usan herramientas de lanzamiento para compilar el archivo target-files.zip para el dispositivo tardis.
. build/envsetup.sh && lunch tardis-engmkdir dist_outputmake dist DIST_DIR=dist_output
make dist compila un paquete inalámbrico completo (en $OUT). El archivo .zip resultante contiene todo lo necesario para construir paquetes inalámbricos para el dispositivo tardis.
También puedes compilar el ota_from_target_files como un objeto 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 de acceso ota_from_target_files se configura en $PATH, y el objeto binario de Python resultante se encuentra en el directorio out/.
ota_update.zip ya está listo para enviarse a dispositivos de prueba (todo está firmado con la clave de prueba). En el caso de los dispositivos de los usuarios, genera y usa tus propias claves privadas como se detalla en Cómo firmar compilaciones para lanzamientos.
Cómo compilar actualizaciones incrementales
Una actualización incremental es un paquete inalámbrico que contiene parches binarios para 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, dado que 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.
Solo puedes instalar un paquete de actualización incremental en dispositivos que tengan la compilación de origen utilizada para construir el paquete. Para compilar una actualización incremental, necesitas el archivo target_files.zip de la compilación anterior (desde la que deseas actualizar) y el archivo target_files.zip de la compilación nueva. Por ejemplo, los siguientes comandos usan herramientas de lanzamiento para compilar 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).
Distribuye un paquete incremental solo a los dispositivos que ejecutan exactamente la misma compilación anterior usada como punto de partida del paquete incremental. Debes escribir en la memoria flash las imágenes en PREVIOUS-tardis-target_files.zip o PREVIOUS-tardis-img.zip (ambas compiladas con make dist, para escribirse en la memoria flash con fastboot update), en lugar de las del directorio PRODUCT_OUT (compiladas con make, que se escribirán en la memoria flash con fastboot flashall). Si intentas instalar el paquete incremental en un dispositivo con otra compilación, se producirá un error de instalación. Cuando falla la instalación, el dispositivo permanece en el mismo estado de trabajo (ejecutando el sistema anterior); el paquete verifica el estado previo de todos los archivos que actualiza antes de tocarlos, para que el dispositivo no quede varado en un estado semiactualizado.
Para obtener la mejor experiencia del usuario, ofrece una actualización completa por cada 3 o 4 actualizaciones incrementales. Esto ayuda a los usuarios a ponerse al día con la versión más reciente y evita una larga secuencia de instalación de actualizaciones incrementales.
Crea paquetes inalámbricos para varios SKU
Android 11 y las versiones posteriores admiten el uso de un solo paquete inalámbrico para varios dispositivos con diferentes SKU. Para ello, debes configurar los dispositivos de destino de modo que usen huellas digitales dinámicas y actualizar los metadatos inalámbricos (con herramientas inalámbricas) para incluir el nombre del dispositivo y la huella digital en las entradas previa y posterior a la condición.
Acerca de los SKU
El formato de un SKU es una variación de los valores combinados de los parámetros de compilación 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>
modifierAes el nivel del dispositivo (como Pro, Premium o Plus).modifierBes la variación de hardware (como la radio).modifierCes 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 varios SKU y, luego, derivan el nombre final del producto y la huella digital del dispositivo en el 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 con diferentes nombres de producto, compartan imágenes comunes (como tardis y tardispro).
Usa huellas digitales 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 identificador único de las imágenes (y bytes) que se ejecutan en el dispositivo. Para crear una huella digital dinámica, usa la lógica dinámica en el archivo build.prop del dispositivo para obtener el valor de las variables del bootloader en el momento de inicio del dispositivo y, luego, usa esos datos para crear una huella digital dinámica para ese dispositivo.
Por ejemplo, si quieres usar huellas digitales dinámicas para dispositivos tardis y tardispro, actualiza los siguientes archivos como se muestra a continuación.
Actualiza el archivo
odm/etc/build_std.proppara que contenga la siguiente línea.ro.odm.product.device=tardisActualiza el archivo
odm/etc/build_pro.proppara que contenga la siguiente línea.ro.odm.product.device=tardisproActualiza el archivo
odm/etc/build.proppara 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 de forma dinámica el nombre del dispositivo, la huella digital y los valores de ro.build.fingerprint según el valor de la propiedad del bootloader ro.boot.product.hardware.sku (que es de solo lectura).
Actualiza los metadatos de paquetes de OTA
Un paquete de OTA contiene un archivo de metadatos (META-INF/com/android/metadata) que describe el paquete, incluidas las condiciones previas y posteriores del paquete de OTA. Por ejemplo, el siguiente código es el archivo de metadatos para un paquete inalámbrico que se orienta 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 para que se pueda instalar el paquete inalámbrico. Los valores post-build-incremental y post-build definen el estado que se espera que tenga un dispositivo después de la instalación del paquete inalámbrico. Los valores de los campos pre- y post- derivan de las siguientes propiedades de compilación correspondientes.
- El valor
pre-devicederiva de la propiedad de compilaciónro.product.device. - Los valores
pre-build-incrementalypost-build-incrementalderivan de la propiedad de compilaciónro.build.version.incremental. - Los valores
pre-buildypost-buildderivan de la propiedad de compilaciónro.build.fingerprint.
En dispositivos que ejecutan Android 11 o versiones posteriores, puedes usar la marca --boot_variable_file en las herramientas inalámbricas para especificar una ruta de acceso a un archivo que contenga los valores de las variables de tiempo de ejecución usadas 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- (con el carácter de barra vertical | como delimitador). La marca --boot_variable_file tiene la siguiente sintaxis y descripción.
- Sintaxis:
--boot_variable_file <path> - Descripción: Especifica una ruta de acceso a un archivo que contiene los valores posibles de las propiedades de
ro.boot.*. Se usa para calcular las posibles huellas digitales del tiempo de ejecución cuando la sentencia de importación anula algunas propiedades dero.product.*. El archivo espera una propiedad por línea, en la que 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 los dispositivos tardis y tardispro 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 función en dispositivos que ejecutan Android 10, consulta la implementación de referencia.
Esta lista de cambios analiza condicionalmente las declaraciones import en el archivo build.prop, lo que permite que las anulaciones de propiedades se reconozcan y se reflejen en los metadatos finales de OTA.