Questa pagina è stata tradotta dall'API Cloud Translation.

Sviluppo del manifest del dispositivo

Durante lo sviluppo e il rilascio di nuovi dispositivi, i fornitori possono definire e dichiarare versione FCM di destinazione nel file manifest del dispositivo (DM). Quando esegui l'upgrade dell'immagine del fornitore per i vecchi dispositivi, i fornitori possono scegliere di implementare nuove versioni dell'HAL e incrementare la versione FCM di destinazione.

Sviluppare nuovi dispositivi

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

Esci da DEVICE_MANIFEST_FILE e PRODUCT_ENFORCE_VINTF_MANIFEST non definito.
Implementa gli HAL per la versione FCM di destinazione.
Scrivi il file manifest del dispositivo corretto.
Scrivi la versione FCM di destinazione nel file manifest del dispositivo.
Imposta DEVICE_MANIFEST_FILE.
Imposta PRODUCT_ENFORCE_VINTF_MANIFEST su true.

Rilascia nuovi dispositivi

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

Ad esempio, i dispositivi che vengono lanciati con Android 9 devono avere una versione target di FCM uguale alla 3 (la versione superiore disponibile al momento). Per dichiararlo nel file manifest del dispositivo:

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

Esegui l'upgrade dell'immagine del fornitore

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

Esegui l'upgrade degli HAL

Durante l'upgrade di un'immagine del fornitore, i fornitori possono implementare nuove versioni dell'HAL purché il nome dell'HAL, il nome dell'interfaccia e quello dell'istanza siano uguali. Per esempio:

Dispositivi Google Pixel 2 e Pixel 2 XL rilasciati con la versione FCM target 2, che ha implementato 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 OTA completa per l'upgrade all'HAL 4.0, che implementa android.hardware.audio@4.0::IDeviceFactory/default.
Anche se il compatibility_matrix.2.xml specifica l'audio 2.0 solo il requisito per l'immagine del fornitore con versione 2 di FCM di destinazione è 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à.

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

Versione FCM (sistema)	Versione FCM di destinazione (fornitore)	Requisiti
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

Esegui l'upgrade della versione FCM di destinazione

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

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

Ad esempio, i dispositivi Google Pixel e Pixel XL lanciati con Android 7.0 quindi la versione di FCM di destinazione deve essere almeno precedente. Tuttavia, il dispositivo dichiara la versione 2 di FCM di destinazione perché l'immagine del fornitore ha è stato aggiornato in modo che sia conforme alle norme 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 li rimuovono versioni HAL ritirate, non è possibile eseguire l'upgrade della versione FCM di destinazione.

Ad esempio, i dispositivi Google Pixel 2 e Pixel 2 XL hanno la versione FCM target 2. Anche se implementano alcuni HAL richiesti compatibility_matrix.3.xml (ad esempio audio 4.0, integrità 2.0 e così via), non rimuovono android.hardware.radio.deprecated@1.0, ritirato alla versione 3 di FCM (Android 9). Pertanto, questi dispositivi non possono eseguire l'upgrade della versione FCM target alla 3.

Obbligo di requisiti del kernel durante l'aggiornamento OTA

Aggiornamento di dispositivi da Android 9 o versioni precedenti

Sui dispositivi con Android 9 o versioni precedenti, assicurati che le seguenti CL siano la scelta migliore:

Queste modifiche introducono il flag build PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS e lascia il flag non impostato per i dispositivi avviati con Android 9 o in basso.

Quando esegui l'aggiornamento ad Android 10: Client OTA su dispositivi con Android 9 o inferiore non controllano correttamente i requisiti del kernel nel pacchetto OTA. Queste modifiche sono necessarie per eliminare i requisiti del kernel dall'OTA generata pacchetto.
Quando esegui l'aggiornamento ad Android 11, è facoltativo impostare il valore Flag di build PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS per controllare VINTF la compatibilità quando viene generato il pacchetto di aggiornamento.

Per ulteriori informazioni su questo flag di build, consulta Aggiornare i dispositivi da Android 10.

Aggiornamento dei dispositivi da Android 10

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

Quando esegui l'aggiornamento ad Android 10, il pacchetto di aggiornamento OTA contiene la versione e la configurazione del kernel. Client OTA su dispositivi con Android 10 leggi queste informazioni per verificare la compatibilità.
In caso di aggiornamento ad Android 11, generazione del pacchetto OTA legge la versione e la configurazione del kernel per verificare la compatibilità.

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

Modifica lo script in modo che supporti il formato del kernel e contribuisci ad AOSP.
Imposta BOARD_KERNEL_VERSION sulla versione del kernel e BOARD_KERNEL_CONFIG_FILE al percorso del kernel creato di configurazione .config. Entrambe le variabili devono essere aggiornate quando l'immagine del kernel viene aggiornata.
In alternativa, imposta Da PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS a false per saltare il controllo dei requisiti del kernel. Questa azione è sconsigliata perché le incompatibilità sono nascoste e vengono scoperte solo quando si eseguono test VTS dopo l'aggiornamento.

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