Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Regole di corrispondenza

Le due coppie di matrici e manifest di compatibilità devono essere riconciliate al momento dell'aggiornamento OTA per verificare che il framework e l'implementazione del fornitore possano lavorare l'una con l'altra. Questa verifica ha esito positivo su una corrispondenza tra la matrice di compatibilità del framework e il manifest del dispositivo, nonché tra il manifest del framework e la matrice di compatibilità del dispositivo. Le seguenti sezioni descrivono in dettaglio le regole di corrispondenza utilizzate da vari componenti.

Corrispondenze della versione della matrice di compatibilità del framework

Per abbinare un manifest del dispositivo a una matrice di compatibilità del framework, la versione di Shipping FCM specificata da manifest.target-level deve essere esattamente uguale alla versione FCM specificata da compatibility-matrix.level . Altrimenti non c'è partita.

Quando viene richiesta la matrice di compatibilità del framework con libvintf , questa corrispondenza ha sempre successo poiché libvintf apre il manifest del dispositivo, recupera la versione di spedizione FCM e restituisce la matrice di compatibilità del framework in quella versione di spedizione FCM (oltre ad alcuni HAL opzionali da matrici di compatibilità con FCM superiore le versioni).

Partite HAL

La regola di corrispondenza HAL identifica le versioni degli elementi hal in un file manifest che sono considerate supportate dal proprietario della matrice di compatibilità corrispondente.

  • Più elementi <hal> vengono valutati con una singola relazione AND .
  • Più elementi <version> all'interno dello stesso <hal> hanno la relazione OR . Se ne vengono specificate due o più, è necessario implementare solo una delle versioni. (Vedi l' esempio DRM di seguito.)
  • Più elementi <instance> e <regex-instance> all'interno dello stesso <hal> vengono valutati con una singola relazione AND . (Vedi l' esempio DRM di seguito.)

Esempio : corrispondenza HAL riuscita per il modulo videocamera

Per un HAL alla versione 2.5, la regola di corrispondenza è la seguente:

Matrice Manifest corrispondente
2.5 2.5-2.∞. Stenografia per 2.5-5.
2.5-7 2.5-2.∞. Indica quanto segue:
  • 2.5 è la versione minima richiesta, il che significa che un manifest che fornisce HAL 2.0-2.4 non è compatibile.
  • 2.7 è la versione massima che potrebbe essere richiesta, il che significa che il proprietario della matrice di compatibilità (framework o dispositivo) non richiederà versioni oltre la 2.7. Il proprietario del manifest corrispondente può comunque pubblicare la versione 2.10 (come esempio) quando viene richiesta la 2.7. Il proprietario della matrice di compatibilità sa solo che il servizio richiesto è compatibile con l'API versione 2.7.
  • -7 è solo informativo e non influisce sul processo di aggiornamento OTA.
Pertanto, un dispositivo con un HAL alla versione 2.10 nel suo file manifest rimane compatibile con un framework che indica camera: 2.5-7 nella sua matrice di compatibilità.

Esempio: corrispondenza HAL riuscita per il modulo DRM

La matrice di compatibilità del framework indica le seguenti informazioni sulla versione per DRM HAL:

<hal>
    <name>android.hardware.drm
    <version>1.0</version>
    <version>3.1-2</version>
    <interface>
        <name>IDrmFactory</name>
        <instance>default</instance>
        <instance>specific</instance>
    </interface>
</hal>
<hal>
    <name>android.hardware.drm
    <version>2.0</version>
    <interface>
        <name>ICryptoFactory</name>
        <instance>default</instance>
        <regex-instance>[a-z]+/[0-9]+</regex-instance>
    </interface>
</hal>

Un fornitore deve implementare UNA delle seguenti istanze; o

android.hardware.drm@1.x::IDrmFactory/default          // where x >= 0
android.hardware.drm@1.x::IDrmFactory/specific         // where x >= 0
O
android.hardware.drm@3.y::IDrmFactory/default          // where y >= 1
android.hardware.drm@3.y::IDrmFactory/specific         // where y >= 1

E deve anche implementare tutte queste istanze:

android.hardware.drm@2.z::ICryptoFactory/default       // where z >= 0
android.hardware.drm@2.z::ICryptoFactory/${INSTANCE}
            // where z >= 0 and ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

Corrispondenze del kernel

La sezione <kernel> della matrice di compatibilità del framework descrive i requisiti del framework del kernel Linux sul dispositivo. Queste informazioni sono pensate per essere abbinate al momento OTA con le informazioni sul kernel che vengono riportate dall'oggetto VINTF del dispositivo.

Una matrice può includere più sezioni <kernel> , ognuna con un attributo di version diverso usando il formato:

${ver}.${major_rev}.${kernel_minor_rev}

L'OTA considera solo la sezione <kernel> con gli stessi ${ver} e ${major_rev} del kernel del dispositivo (cioè version="${ver}.${major_rev}.${matrix_minor_rev}") ; le altre sezioni vengono ignorate. Inoltre, la revisione minore dal kernel deve essere un valore dalla matrice di compatibilità ( ${kernel_minor_rev} >= ${matrix_minor_rev} ;). Se nessuna sezione <kernel> soddisfa questi requisiti, è una non corrispondenza.

Se la sezione <kernel> corrisponde, il processo continua tentando di abbinare gli elementi di config con /proc/config.gz . Per ogni elemento di configurazione nella matrice di compatibilità, cerca /proc/config.gz per vedere se la configurazione è presente. Quando un elemento di configurazione è impostato su n nella matrice di compatibilità per la sezione <kernel> corrispondente, deve essere assente da /proc/config.gz . Infine, un elemento di configurazione non nella matrice di compatibilità può o non può essere presente in /proc/config.gz .

Esempi di partite:

  • <value type="string">bar</value> corrisponde a "bar" . Le virgolette sono omesse nella matrice di compatibilità ma sono presenti in /proc/config.gz .
  • <value type="int">4096</value> corrisponde a 4096 o 0x1000 o 0X1000 .
  • <value type="int">0x1000</value> corrisponde a 4096 o 0x1000 o 0X1000 .
  • <value type="int">0X1000</value> corrisponde a 4096 o 0x1000 o 0X1000 .
  • <value type="tristate">y</value> corrisponde a y .
  • <value type="tristate">m</value> corrisponde a m .
  • <value type="tristate">n</value> significa che l'elemento di configurazione NON deve esistere in /proc/config.gz .
  • <value type="range">1-0x3</value> corrisponde a 1 , 2 o 3 o equivalente esadecimale.

Esempio: corretta corrispondenza del kernel

Una matrice di compatibilità del framework contiene le seguenti informazioni sul kernel:

<kernel version="4.14.42">
   <config>
      <key>CONFIG_TRI</key>
      <value type="tristate">y</value>
   </config>
   <config>
      <key>CONFIG_NOEXIST</key>
      <value type="tristate">n</value>
   </config>
   <config>
      <key>CONFIG_DEC</key>
      <value type="int">4096</value>
   </config>
   <config>
      <key>CONFIG_HEX</key>
      <value type="int">0XDEAD</value>
   </config>
   <config>
      <key>CONFIG_STR</key>
      <value type="string">str</value>
   </config>
   <config>
      <key>CONFIG_EMPTY</key>
      <value type="string"></value>
   </config>
</kernel>

La versione del kernel viene prima abbinata. Se un dispositivo in uname() riporta:

  • 4.9.84 (nessuna corrispondenza con la matrice a meno che non ci sia una sezione del kernel separata con <kernel version="4.9.x"> , dove x <= 84 )
  • 4.14.41 (nessuna corrispondenza con la matrice, più piccola della version )
  • 4.14.42 (abbina a matrice)
  • 4.14.43 (abbina a matrice)
  • 4.1.22 (nessuna corrispondenza con la matrice a meno che non ci sia una sezione del kernel separata con <kernel version="4.1.x"> dove x <= 22 )

Dopo aver selezionato la sezione <kernel> appropriata, per ogni elemento <config> con valore diverso da n , ci aspettiamo che la voce corrispondente sia presente in /proc/config.gz ; per ogni elemento <config> con valore n , prevediamo che la voce corrispondente non sia presente in /proc/config.gz . Ci aspettiamo che il contenuto di <value> corrisponda esattamente al testo dopo il segno di uguale (comprese le virgolette), fino al carattere di nuova riga o # , con spazi bianchi iniziali e finali troncati.

La seguente configurazione del kernel è un esempio di corrispondenza corretta:

# comments don't matter
CONFIG_TRI=y
# CONFIG_NOEXIST shouldn't exist
CONFIG_DEC = 4096 # trailing comments and whitespaces are fine
CONFIG_HEX=57005  # 0XDEAD == 57005
CONFIG_STR="str"
CONFIG_EMPTY=""   # empty string must have quotes
CONFIG_EXTRA="extra config items are fine too"

La seguente configurazione del kernel è un esempio di corrispondenza non riuscita:

CONFIG_TRI="y"   # mismatch: quotes
CONFIG_NOEXIST=y # mismatch: CONFIG_NOEXIST exists
CONFIG_HEX=0x0   # mismatch; value doesn't match
CONFIG_DEC=""    # mismatch; type mismatch (expect int)
CONFIG_EMPTY=1   # mismatch; expects ""
# mismatch: CONFIG_STR is missing

Partite politiche SE

La politica SE richiede le seguenti corrispondenze:

  • <sepolicy-version> definisce un intervallo chiuso di versioni minori per ogni versione principale. La versione sepolicy segnalata dal dispositivo deve rientrare in uno di questi intervalli per essere compatibile con il framework. Le regole di corrispondenza sono simili alle versioni HAL; è una corrispondenza se la versione sepolicy è superiore o uguale alla versione minima per l'intervallo. La versione massima è puramente informativa.
  • <kernel-sepolicy-version> ovvero versione policydb. Deve essere inferiore a security_policyvers() segnalato dal dispositivo.

Esempio: corrispondenza della politica SE riuscita

La matrice di compatibilità del framework indica le seguenti informazioni sepolicy:

<sepolicy>
    <kernel-sepolicy-version>30</kernel-sepolicy-version>
    <sepolicy-version>25.0</sepolicy-version>
    <sepolicy-version>26.0-3</sepolicy-version>
</sepolicy>

Sul dispositivo:

  • Il valore restituito da security_policyvers() deve essere maggiore o uguale a 30. Altrimenti non è una corrispondenza. Per esempio:
    • Se un dispositivo restituisce 29, non è una corrispondenza.
    • Se un dispositivo restituisce 31, è una corrispondenza.
  • La versione della politica SE deve essere una tra 25.0-∞ o 26.0-∞. Altrimenti non è una partita. (Il " -3 " dopo " 26.0 " è puramente informativo.)

La versione AVB corrisponde

La versione AVB contiene una versione MAJOR e una versione MINOR, con il formato MAJOR.MINOR (ad es. 1.0, 2.1). Per i dettagli, consultare Versioning e compatibilità . La versione AVB ha le seguenti proprietà di sistema:

  • ro.boot.vbmeta.avb_version è la versione di libavb nel bootloader
  • ro.boot.avb_version è la versione di libavb nel sistema operativo Android ( init/fs_mgr )

La proprietà di sistema appare solo quando è stato usato il libavb corrispondente per verificare i metadati di AVB (e restituisce OK). È assente se si è verificato un errore di verifica (o non si è verificata alcuna verifica).

Una corrispondenza di compatibilità confronta quanto segue:

  • sysprop ro.boot.vbmeta.avb_version con avb.vbmeta-version dalla matrice di compatibilità del framework;
    • ro.boot.vbmeta.avb_version.MAJOR == avb.vbmeta-version.MAJOR
    • ro.boot.vbmeta.avb_version.MINOR >= avb.vbmeta-version.MINOR
  • sysprop ro.boot.avb_version con avb.vbmeta-version dalla matrice di compatibilità del framework.
    • ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
    • ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

Il bootloader o il sistema operativo Android potrebbero contenere due copie delle librerie libavb , ognuna con una versione MAJOR diversa per i dispositivi di aggiornamento e i dispositivi di avvio. In questo caso, la stessa immagine di sistema non firmata può essere condivisa ma le immagini di sistema firmate finali sono diverse (con avb.vbmeta-version diversa):

Figura 1. La versione di AVB corrisponde ( /system è P, tutte le altre partizioni sono O).


Figura 2. Corrispondenze della versione AVB (tutte le partizioni sono P).

Esempio: corrispondenza della versione AVB riuscita

La matrice di compatibilità del framework indica le seguenti informazioni AVB:

<avb>
    <vbmeta-version>2.1</vbmeta-version>
</avb>

Sul dispositivo:

ro.boot.avb_version              == 1.0 &&
ro.boot.vbmeta.avb_version       == 2.1  mismatch 
ro.boot.avb_version              == 2.1 &&
ro.boot.vbmeta.avb_version       == 3.0  mismatch 
ro.boot.avb_version              == 2.1 &&
ro.boot.vbmeta.avb_version       == 2.3  match 
ro.boot.avb_version              == 2.3 &&
ro.boot.vbmeta.avb_version       == 2.1  match 

Versione AVB corrispondente durante OTA

Per i dispositivi avviati con Android 9 o versioni precedenti, durante OTA, i requisiti della versione AVB nella matrice di compatibilità del framework vengono confrontati con la versione AVB corrente sul dispositivo. Se la versione AVB ha un aggiornamento della versione principale durante un OTA (ad esempio, da 0,0 a 1,0), il controllo in OTA non riflette la compatibilità dopo l'OTA.

Per mitigare il problema, un OEM può inserire una versione AVB falsa nel pacchetto OTA ( compatibility.zip ) per passare il controllo. Fare così:

  1. Cherry-pick i seguenti CL all'albero dei sorgenti di Android 9:
  2. Definire BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE per il dispositivo. Il suo valore dovrebbe essere uguale alla versione AVB precedente all'OTA, ovvero alla versione AVB del dispositivo al momento del lancio.
  3. Ricreare il pacchetto OTA.

Queste modifiche posizionano automaticamente BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE come compatibility-matrix.avb.vbmeta-version nei seguenti file:

  • /system/compatibility_matrix.xml (che non è utilizzato in Android 9) sul dispositivo
  • system_matrix.xml in compatibility.zip nel pacchetto OTA
Queste modifiche non influiscono su altre matrici di compatibilità del framework, incluso /system/etc/vintf/compatibility_matrix.xml . Dopo l'OTA, il nuovo valore in /system/etc/vintf/compatibility_matrix.xml viene invece utilizzato per i controlli di compatibilità.

La versione di VNDK corrisponde

La matrice di compatibilità del dispositivo dichiara la versione VNDK richiesta in compatibility-matrix.vendor-ndk.version . Se la matrice di compatibilità del dispositivo non ha un <vendor-ndk> , non sono richiesti requisiti e quindi viene sempre considerata una corrispondenza.

Se la matrice di compatibilità del dispositivo ha un <vendor-ndk> , viene <vendor-ndk> una voce <vendor-ndk> con una <version> corrispondente dal set di snapshot del fornitore VNDK fornito dal framework nel manifest del framework. Se tale voce non esiste, non c'è corrispondenza.

Se esiste una tale voce, l'insieme di librerie enumerate nella matrice di compatibilità dei dispositivi deve essere un sottoinsieme dell'insieme di librerie indicato nel manifest del framework; in caso contrario, la voce non è considerata una corrispondenza.

  • In un caso speciale, se nessuna matrice è elencata nella matrice di compatibilità del dispositivo, la voce viene sempre considerata una corrispondenza, poiché un set vuoto è un sottoinsieme di qualsiasi set.

Esempio: corrispondenza della versione VNDK riuscita

Se la matrice di compatibilità del dispositivo indica il seguente requisito su VNDK:

<!-- Example Device Compatibility Matrix -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>

Nel manifest del framework, viene considerata solo la voce con la versione 27.

<!-- Framework Manifest Example A -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
    <library>libfoo.so</library>
</vendor-ndk>

L'esempio A è una corrispondenza, perché VNDK versione 27 è nel manifest manifest e {libjpeg.so, libbase.so, libfoo.so} ⊇ {libjpeg.so, libbase.so} .

<!-- Framework Manifest Example B -->
<vendor-ndk>
    <version>26</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>
<vendor-ndk>
    <version>27</version>
    <library>libbase.so</library>
</vendor-ndk>

L'esempio B non è una corrispondenza. Anche se VNDK versione 27 è nel manifest del framework, libjpeg.so non è supportato dal framework in quella istantanea. VNDK versione 26 viene ignorata.

Corrispondenze della versione dell'SDK di sistema

La matrice di compatibilità del dispositivo dichiara un set di versione richiesta dell'SDK di sistema in compatibility-matrix.system-sdk.version . C'è una corrispondenza solo se il set è un sottoinsieme delle versioni fornite dell'SDK di sistema come dichiarato in manifest.system-sdk.version nel manifest del framework.

  • In un caso speciale, se nessuna versione dell'SDK di sistema è elencata nella matrice di compatibilità del dispositivo, viene sempre considerata una corrispondenza, poiché un set vuoto è un sottoinsieme di qualsiasi set.

Esempio: corrispondenza corretta della versione dell'SDK di sistema

Se la matrice di compatibilità dei dispositivi stabilisce i seguenti requisiti sull'SDK di sistema:

<!-- Example Device Compatibility Matrix -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

Quindi, il framework deve fornire le versioni 26 e 27 dell'SDK di sistema corrispondenti.

<!-- Framework Manifest Example A -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

L'esempio A è una corrispondenza.

<!-- Framework Manifest Example B -->
<system-sdk>
    <version>26</version>
    <version>27</version>
    <version>28</version>
</system-sdk>

L'esempio B è una corrispondenza.

<!-- Framework Manifest Example C -->
<system-sdk>
    <version>26</version>
</system-sdk>

L'esempio C non corrisponde, poiché non viene fornita la versione 27 dell'SDK di sistema.