Desarrollo de manifiesto de dispositivo

Al desarrollar y lanzar nuevos dispositivos, los proveedores pueden definir y declarar la versión de FCM de destino en el manifiesto del dispositivo (DM). Al actualizar la imagen del proveedor para dispositivos antiguos, los proveedores pueden optar por implementar nuevas versiones de HAL e incrementar la versión de destino de FCM.

Desarrollando nuevos dispositivos

Al definir la versión de FCM de destino del dispositivo para dispositivos nuevos:

  1. Deje DEVICE_MANIFEST_FILE y PRODUCT_ENFORCE_VINTF_MANIFEST sin definir.
  2. Implementar HAL para la versión FCM de destino.
  3. Escriba el archivo de manifiesto del dispositivo correcto.
  4. Escriba la versión de Target FCM en el archivo de manifiesto del dispositivo.
  5. Establezca DEVICE_MANIFEST_FILE .
  6. Establezca PRODUCT_ENFORCE_VINTF_MANIFEST en true .

Lanzamiento de nuevos dispositivos

Cuando se lanza un nuevo dispositivo, su versión inicial de FCM de destino debe determinarse y declararse en el manifiesto del dispositivo como el atributo " target-level " en el elemento <manifest> de nivel superior.

Por ejemplo, los dispositivos que se inician con Android 9 deben tener la versión Target FCM igual a 3 (la versión superior disponible en este momento). Para declarar esto en el manifiesto del dispositivo:

<manifest version="1.0" type="device" target-level="3">
    <!-- ... -->
</manifest>

Actualización de la imagen del proveedor

Al actualizar la imagen del proveedor para un dispositivo antiguo, los proveedores pueden optar por implementar nuevas versiones de HAL e incrementar la versión de FCM de destino.

Actualización de HAL

Durante una actualización de la imagen del proveedor, los proveedores pueden implementar nuevas versiones de HAL siempre que el nombre de HAL, el nombre de la interfaz y el nombre de la instancia sean los mismos. Por ejemplo:

  • Los dispositivos Google Pixel 2 y Pixel 2 XL se lanzaron con Target FCM versión 2, que implementó el audio 2.0 HAL requerido android.hardware.audio@2.0::IDeviceFactory/default .
  • Para el audio 4.0 HAL que se lanzó con Android 9, los dispositivos Google Pixel 2 y Pixel 2 XL pueden usar una OTA completa para actualizar a 4.0 HAL, que implementa android.hardware.audio@4.0::IDeviceFactory/default .
  • Aunque compatibility_matrix.2.xml especifica audio 2.0 únicamente, el requisito de una imagen de proveedor con Target FCM versión 2 se ha relajado porque el marco de trabajo de Android 9 (FCM versión 3) considera que el audio 4.0 es un reemplazo del audio 2.0 HAL en términos de funcionalidad. .

En resumen, dado que compatibility_matrix.2.xml requiere audio 2.0 y compatibility_matrix.3.xml requiere audio 4.0, los requisitos son los siguientes:

Versión FCM (Sistema) Versión de FCM de destino (proveedor) Requisitos
2 (8.1) 2 (8.1) Audio 2.0
3 (9) 2 (8.1) Audio 2.0 o 4.0
3 (9) 3 (9) Audio 4.0

Actualización de la versión de Target FCM

Durante una actualización de la imagen del proveedor, los proveedores también pueden incrementar la versión de FCM de destino para especificar la versión de FCM de destino con la que puede funcionar la imagen de proveedor actualizada. Para aumentar la versión FCM de destino de un dispositivo, los proveedores deben:

  1. Implementar todas las nuevas versiones HAL requeridas para la versión Target FCM.
  2. Modifique las versiones de HAL en el archivo de manifiesto del dispositivo.
  3. Modifique la versión de Target FCM en el archivo de manifiesto del dispositivo.
  4. Elimine las versiones HAL obsoletas.

Por ejemplo, los dispositivos Google Pixel y Pixel XL se lanzaron con Android 7.0, por lo que su versión Target FCM debe ser al menos heredada. Sin embargo, el manifiesto del dispositivo declara Target FCM versión 2 porque la imagen del proveedor se actualizó para cumplir con compatibility_matrix.2.xml :

<manifest version="1.0" type="device" target-level="2">

Si los proveedores no implementan todas las nuevas versiones HAL requeridas o no eliminan las versiones HAL obsoletas, la versión FCM de destino no se puede actualizar.

Por ejemplo, los dispositivos Google Pixel 2 y Pixel 2 XL tienen Target FCM versión 2. Si bien implementan algunos HAL requeridos por compatibility_matrix.3.xml (como audio 4.0, salud 2.0, etc.), no eliminan android.hardware.radio.deprecated@1.0 , que está obsoleto en FCM Versión 3 (Android 9). Por lo tanto, estos dispositivos no pueden actualizar la versión Target FCM a 3.

Exigir requisitos del kernel durante OTA

Actualización de dispositivos desde Android 9 o inferior

En dispositivos con Android 9 o inferior, asegúrese de seleccionar las siguientes CL:

Estos cambios introducen el indicador de compilación PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS y ​​dejan el indicador sin configurar para dispositivos lanzados con Android 9 o inferior.

  • Al actualizar a Android 10, los clientes OTA en dispositivos con Android 9 o versiones anteriores no verifican correctamente los requisitos del kernel en el paquete OTA. Estos cambios son necesarios para eliminar los requisitos del kernel del paquete OTA generado.
  • Al actualizar a Android 11, es opcional configurar el indicador de compilación PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS para verificar la compatibilidad de VINTF cuando se genera el paquete de actualización.

Para obtener más información sobre este indicador de compilación, consulte Actualización de dispositivos desde Android 10 .

Actualización de dispositivos desde Android 10

Android 10 presenta un nuevo indicador de compilación, PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS . Para dispositivos lanzados con Android 10, esta marca se establece automáticamente en true . Cuando el indicador se establece en true , un script extrae la versión del kernel y las configuraciones del kernel de la imagen del kernel instalada.

  • Al actualizar a Android 10, el paquete de actualización OTA contiene la versión y la configuración del kernel. Los clientes OTA en dispositivos con Android 10 leen esta información para verificar la compatibilidad.
  • Al actualizar a Android 11, la generación de paquetes OTA lee la versión y la configuración del kernel para verificar la compatibilidad.

Si el script no puede extraer esta información para la imagen del kernel, realice una de las siguientes acciones:

  • Edite el script para que admita el formato de su kernel y contribuya a AOSP.
  • Establezca BOARD_KERNEL_VERSION en la versión del kernel y BOARD_KERNEL_CONFIG_FILE en la ruta del archivo de configuración del kernel compilado .config . Ambas variables deben actualizarse cuando se actualiza la imagen del kernel.
  • Alternativamente, configure PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS en false para omitir la verificación de los requisitos del kernel. Esto no se recomienda porque cualquier incompatibilidad está oculta y solo se descubre cuando se ejecutan pruebas VTS después de la actualización.

Puede ver el código fuente del script de extracción de información del kernel extract_kernel.py .