Sviluppo del file manifest del dispositivo

Quando sviluppano e rilasciano nuovi dispositivi, i fornitori possono definire e dichiarare la versione FCM di destinazione nel manifest del dispositivo (DM). Quando aggiornano l'immagine del fornitore per i dispositivi meno recenti, i fornitori possono scegliere di implementare nuove versioni HAL e incrementare la versione FCM di destinazione.

Sviluppare nuovi dispositivi

Quando definisci la versione FCM di destinazione del dispositivo per i nuovi dispositivi:

1. Lascia DEVICE_MANIFEST_FILE e PRODUCT_ENFORCE_VINTF_MANIFEST non definiti.
2. Implementa gli HAL per la versione FCM di destinazione.
3. Scrivi il file manifest del dispositivo corretto.
4. Scrivi la versione FCM di destinazione nel file manifest del dispositivo.
5. Imposta DEVICE_MANIFEST_FILE.
6. Imposta PRODUCT_ENFORCE_VINTF_MANIFEST su true.

Rilasciare nuovi dispositivi

Quando viene rilasciato un nuovo dispositivo, la sua versione FCM target iniziale deve essere determinata e dichiarata nel manifest del dispositivo come attributo "target-level" nell'elemento <manifest> di primo livello.

Ad esempio, i dispositivi lanciati con Android 9 devono avere la versione FCM di destinazione uguale a 3 (la versione più recente disponibile al momento). Per dichiarare questa funzionalità nel manifest del dispositivo:

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

Esegui l'upgrade dell'immagine del fornitore

Quando aggiornano l'immagine del fornitore per un dispositivo precedente, i fornitori possono scegliere di implementare nuove versioni HAL e incrementare la versione FCM di destinazione.

Esegui l'upgrade degli HAL

Durante l'upgrade di un'immagine fornitore, i fornitori possono implementare nuove versioni HAL a condizione che il nome HAL, il nome dell'interfaccia e il nome dell'istanza siano gli stessi. Per esempio:

• I dispositivi Google Pixel 2 e Pixel 2 XL sono stati rilasciati con la versione FCM di destinazione 2, che implementava l'HAL audio 2.0 richiesto android.hardware.audio@2.0::IDeviceFactory/default.
• Per l'HAL audio 4.0 rilasciato con Android 9, i dispositivi Google Pixel 2 e Pixel 2 XL possono utilizzare un OTA completo per eseguire l'upgrade all'HAL 4.0, che implementa android.hardware.audio@4.0::IDeviceFactory/default.
• Anche se compatibility_matrix.2.xml specifica solo audio 2.0, il requisito relativo a un'immagine fornitore con versione FCM di destinazione 2 è stato allentato perché il framework Android 9 (versione FCM 3) considera audio 4.0 una sostituzione di audio 2.0 HAL in termini di funzionalità.

Per riassumere, dato che compatibility_matrix.2.xml richiede audio 2.0 e compatibility_matrix.3.xml richiede audio 4.0, i requisiti sono i seguenti:

Esegui l'upgrade della versione FCM di destinazione

Durante l'upgrade di un'immagine del fornitore, i fornitori possono anche incrementare la versione FCM di destinazione per specificare la versione FCM di destinazione con cui l'immagine del fornitore aggiornata può funzionare. Per aumentare la versione FCM di destinazione di un dispositivo, i fornitori devono:

1. Implementa tutte le nuove versioni HAL richieste per la versione FCM di destinazione.
2. Modifica le versioni HAL nel file manifest del dispositivo.
3. Modifica la versione FCM di destinazione nel file manifest del dispositivo.
4. Rimuovi le versioni HAL deprecate.

Ad esempio, i dispositivi Google Pixel e Pixel XL sono stati lanciati con Android 7.0, quindi la versione FCM di destinazione deve essere almeno legacy. Tuttavia, il manifest del dispositivo dichiara la versione 2 di FCM perché l'immagine del fornitore è stata aggiornata in conformità con compatibility_matrix.2.xml:

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

Se i fornitori non implementano tutte le nuove versioni HAL richieste o non rimuovono le versioni HAL obsolete, non è possibile eseguire l'upgrade della versione FCM di destinazione.

Ad esempio, i dispositivi Google Pixel 2 e Pixel 2 XL hanno come target la versione 2 di FCM. Sebbene implementino alcune HAL richieste da compatibility_matrix.3.xml (come audio 4.0, salute 2.0 e così via), non rimuovono android.hardware.radio.deprecated@1.0, che è deprecato nella versione 3 di FCM (Android 9). Pertanto, questi dispositivi non possono eseguire l'upgrade della versione di destinazione di FCM alla versione 3.

Imposizione dei requisiti del kernel durante l'aggiornamento OTA

Aggiornamento dei dispositivi da Android 9 o versioni precedenti

Sui dispositivi con Android 9 o versioni precedenti, assicurati che le seguenti CL siano cherry-picked:

• CL 722283
• CL 722284
• CL 722345

Queste modifiche introducono il flag di build PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS e lasciano il flag non impostato per i dispositivi lanciati con Android 9 o versioni precedenti.

• Quando esegui l'aggiornamento ad Android 10, i client OTA sui dispositivi con Android 9 o versioni precedenti non controllano correttamente i requisiti del kernel nel pacchetto OTA. Queste modifiche sono necessarie per eliminare i requisiti del kernel dal pacchetto OTA generato.
• Quando esegui l'aggiornamento ad Android 11, è facoltativo impostare il flag di build PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS per verificare la compatibilità VINTF durante la generazione del pacchetto di aggiornamento.

Per ulteriori informazioni su questo flag di build, vedi Aggiornamento dei dispositivi da Android 10.

Aggiornamento dei dispositivi da Android 10

Android 10 introduce un nuovo flag di build, PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS. Per i dispositivi lanciati con Android 10, questo flag viene impostato automaticamente su true. Quando il flag è impostato su true, uno script estrae la versione del kernel e le configurazioni del kernel dall'immagine del kernel installata.

• Quando esegui l'aggiornamento ad Android 10, il pacchetto di aggiornamento OTA contiene la versione e la configurazione del kernel. I client OTA sui dispositivi con Android 10 leggono queste informazioni per verificare la compatibilità.
• Quando esegui l'aggiornamento ad Android 11, la generazione del pacchetto OTA legge la versione e la configurazione del kernel per verificarne la compatibilità.

Se lo script non riesce a estrarre queste informazioni per l'immagine del kernel, esegui una delle seguenti operazioni:

• Modifica lo script per supportare il formato del kernel e contribuisci ad AOSP.
• Imposta BOARD_KERNEL_VERSION sulla versione del kernel e BOARD_KERNEL_CONFIG_FILE sul percorso del file di configurazione del kernel creato .config. Entrambe le variabili devono essere aggiornate quando viene aggiornata l'immagine del kernel.
• In alternativa, imposta PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS su false per saltare il controllo dei requisiti del kernel. Questa operazione è sconsigliata perché qualsiasi incompatibilità è nascosta e viene rilevata solo durante l'esecuzione dei test VTS dopo l'aggiornamento.

Puoi visualizzare il codice sorgente dello script di estrazione delle informazioni del kernel extract_kernel.py.