Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Creación de paquetes OTA

Se puede utilizar el ota_from_target_files herramienta proporcionada en la build/make/tools/releasetools para construir paquetes de OTA completas e incrementales para los dispositivos que utilizan las actualizaciones del sistema A / B o actualizaciones del sistema no-A / B . La herramienta toma el target-files.zip archivo producido por el sistema de construcción de Android como entrada.

Para dispositivos con Android 11 o superior, puede crear un paquete OTA para varios dispositivos con diferentes SKU. Para ello se requiere la configuración de los dispositivos de destino para usar las huellas digitales dinámicas y la actualización de los metadatos OTA para incluir el nombre del dispositivo y la huella digital en las entradas de pre y postcondition.

Android 8.0 obsoleta paquetes OTA basadas en archivos para dispositivos / B no A, que en cambio deben utilizar paquetes de OTA basadas en bloques . Para generar paquetes o dispositivos OTA basadas en bloques que ejecutan Android 7.x o bajar, pasar el --block opción al ota_from_target_files parámetro.

Construyendo actualizaciones completas

Una actualización completa es un paquete de OTA que contiene todo el estado final del dispositivo (sistema, bota, 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 liberación para construir el target-files.zip Archivo de la tardis dispositivo.

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

make dist construye un paquete completo OTA (en $OUT ). La resultante .zip archivo contiene todo lo necesario para construir paquetes de OTA para el tardis dispositivo. También es posible construir los ota_from_target_files como un binario pitón y lo llaman para construir paquetes, ya sea completa o incremental.

ota_from_target_files dist_output/tardis-target_files.zip ota_update.zip

El ota_from_target_files ruta se establece en $PATH , y el binario resultante pitón está situado en el out/ directorio.

ota_update.zip ya está listo para ser enviado a los dispositivos de prueba (todo lo que se firma con la clave de prueba). Para los dispositivos de usuario, generar y utilizar sus propias claves privadas, como se detalla en la firma construye para su liberación .

Construyendo actualizaciones incrementales

Una actualización incremental es un paquete que contiene OTA parches binarios a 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 construir una actualización incremental, se necesita el target_files.zip archivo de la construcción anterior (la que desee actualizar a), así como la target_files.zip archivo de la nueva construcción. Por ejemplo, los siguientes comandos utilizan herramientas de liberación para construir una actualización incremental para la tardis dispositivo.

ota_from_target files -i PREVIOUS-tardis-target_files.zip dist_output/tardis-target_files.zip incremental_ota_update.zip

Esta construcción es muy similar a la estructura anterior, y el paquete de actualización incremental ( incremental_ota_update.zip ) es mucho menor que la actualización completa correspondiente (aproximadamente 1 MB en lugar de 60 MB).

Distribuya un paquete incremental solo a los dispositivos que ejecuten exactamente la misma compilación anterior que se utilizó como punto de partida del paquete incremental. Debe parpadear las imágenes en PREVIOUS-tardis-target_files.zip o PREVIOUS-tardis-img.zip (ambos construidos con make dist , a ser flasheado con fastboot update ), en lugar de las que están en la PRODUCT_OUT directorio (construido con el make , el cual será indicado con fastboot flashall ). Intentar instalar el paquete incremental en un dispositivo con alguna otra compilación da como resultado un error de instalación. Cuando la instalación falla, 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 en un estado medio actualizado.

Para obtener la mejor experiencia de usuario, ofrezca una actualización completa por 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 varios SKU

Android 11 o superior admite el uso de un solo 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 OTA (usando herramientas 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 combinados de parámetros de construcción valores y es típicamente un subconjunto no declarada de los actuales build_fingerprint parámetros. Los OEM pueden usar cualquier combinación de parámetros de construcció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 de dispositivo (por ejemplo, Pro, Premium o Plus)
  • modifierB es la variación de hardware (como radio)
  • modifierC es la región, que puede ser general (tales como NA, EMEA, o CHN) o específica de idioma del país o (como JPN, ENG, o CHN)

Muchos fabricantes de equipos originales utilizan una sola imagen para varios SKU y luego obtienen el nombre del producto final y la huella digital del dispositivo en tiempo de ejecución después de que el dispositivo se inicia. Este proceso se simplifica el proceso de desarrollo de la plataforma, permitiendo a los dispositivos con personalizaciones menores pero con diferentes nombres de productos para compartir imágenes comunes (como el tardis y tardispro ).

Usando huellas digitales dinámicas

Una huella digital es una concatenación definido de parámetros de construcción tales 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 utiliza como un identificador único de las imágenes (y bytes) que se ejecutan en el dispositivo. Para crear una dinámica de huellas digitales, la lógica dinámica en el uso del dispositivo build.prop archivo para obtener el valor de las variables del gestor de arranque en el arranque del dispositivo, a continuación, utilizar esos datos para crear una huella digital dinámico para ese dispositivo.

Por ejemplo, para utilizar las huellas digitales dinámicos para tardis y tardispro dispositivos, actualizar los siguientes archivos como se muestra a continuación.

  • Actualizar el odm/etc/build_std.prop archivo deberá contener la siguiente línea.

    ro.odm.product.device=tardis
    
  • Actualizar el odm/etc/build_pro.prop archivo deberá contener la siguiente línea.

    ro.odm.product.device=tardispro
    
  • Actualizar el odm/etc/build.prop archivo para contener 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, huella digital, y ro.build.fingerprint valores basados en el valor de la ro.boot.product.hardware.sku propiedad cargador de arranque (que es de sólo lectura).

Actualización de metadatos de paquetes OTA

Paquete de una OTA contiene un archivo de metadatos ( META-INF/com/android/metadata ) que describe el paquete, incluyendo la condición previa y condición posterior del paquete de OTA. Por ejemplo, el código siguiente es el archivo de metadatos para un paquete de OTA dirigidas a la tardis dispositivo.

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

El pre-device , pre-build-incremental , y pre-build valores definen el estado de un dispositivo debe tener antes de que el paquete de OTA puede instalar. Los post-build-incremental y post-build valores definen el estado se espera un dispositivo a tener después de las instalaciones de paquetes de OTA. Los valores de pre- y post- campos se derivan de los siguientes correspondientes propiedades de construcción.

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

En dispositivos con Android 11 o superior, se puede utilizar el --boot_variable_file bandera de herramientas de OTA para especificar una ruta de acceso a un archivo que contiene los valores de las variables de tiempo de ejecución utilizados en la creación de huellas digitales dinámico del dispositivo. Los datos se utiliza entonces para actualizar los metadatos OTA para incluir el nombre del dispositivo y la huella digital en los pre- y post- condiciones (utilizando el caracter | como delimitador). El --boot_variable_file bandera tiene la siguiente sintaxis y la descripción.

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

Por ejemplo, cuando la propiedad es ro.boot.product.hardware.sku=std,pro , los metadatos OTA para tardis y tardispro dispositivos es como se muestra 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 soportar esta funcionalidad en dispositivos con Android 10, consulte la implementación de referencia . Esta lista de cambios analiza condicionalmente las import declaraciones en el build.prop archivo, lo que permite modificaciones de propiedades a ser reconocidas y reflejadas en los metadatos OTA final.