Estensioni VNDK

I produttori di dispositivi Android modificano il codice sorgente delle librerie AOSP per diversi motivi. Alcuni fornitori reimplementano le funzioni nelle librerie AOSP per migliorare il rendimento, mentre altri aggiungono nuovi hook, nuove API o nuove funzionalità alle librerie AOSP. Questa sezione fornisce linee guida per estendere le librerie AOSP in modo da non violare CTS/VTS.

Sostituzione plug-in

Tutte le librerie condivise modificate devono essere compatibili a livello di codice macchina, sostituzione dirette della controparte AOSP. Tutti gli utenti AOSP esistenti devono essere in grado di utilizzare la libreria condivisa modificata senza ricompilarli. Questo requisito implica quanto segue:

  • Le funzioni AOSP non devono essere rimosse.
  • Le strutture non devono essere alterate se sono esposte ai loro utenti.
  • La precondizione delle funzioni non deve essere rafforzata.
  • Le funzioni devono fornire funzionalità equivalenti.
  • La condizione post-rispetto delle funzioni non deve essere indebolita.

Classificazioni dei moduli estesi

Classifica i moduli in base alle funzionalità che definiscono e utilizzano.

Nota: qui viene utilizzata la dicitura Funzionalità invece di API/ABI perché è possibile aggiungere funzionalità senza modificare alcuna API/ABI.

A seconda delle funzionalità definite in un modulo, i moduli possono essere classificati come DA-Module e DX-Module:

  • I moduli DA (Defining-only-AOSP) non definiscono nuove funzionalità non presenti nella controparte AOSP.
    • Esempio 1. Una libreria AOSP intatta e non modificata è un modulo DA.
    • Esempio 2. Se un fornitore riscrivi le funzioni in libcrypto.so con istruzioni SIMD (senza aggiungere nuove funzioni), libcrypto.so modificato sarà un modulo DA.
  • I moduli di estensione della definizione (DX-Module) definiscono nuove funzionalità o non hanno una controparte AOSP.
    • Esempio 1. Se un fornitore aggiunge una funzione di supporto a libjpeg.so per accedere ad alcuni dati interni, il libjpeg.so modificato sarà una DX-Lib e la funzione appena aggiunta sarà la parte estesa della libreria.
    • Esempio 2. Se un fornitore definisce una libreria non AOSP denominata libfoo.so, libfoo.so sarà una DX-Lib.

A seconda delle funzionalità utilizzate da un modulo, i moduli possono essere classificati come moduli UA e moduli UX.

  • I moduli che utilizzano solo AOSP (UA-Module) utilizzano solo le funzionalità AOSP nelle loro implementazioni. Non si basano su estensioni non AOSP.
    • Esempio 1. Una libreria AOSP intatta e non modificata è un modulo UA.
    • Esempio 2. Se una libreria condivisa modificata libjpeg.so si basa solo su altre API AOSP, si tratta di un modulo UA.
  • I moduli di utilizzo delle estensioni (UX-Module) si basano su alcune funzionalità non AOSP nelle loro implementazioni.
    • Esempio 1. Se un libjpeg.so modificato si basa su un'altra libreria non AOSP denominata libjpeg_turbo2.so, il libjpeg.so modificato sarà un modulo UX.
    • Esempio 2. Se un fornitore aggiunge una nuova funzione al proprio libexif.so modificato e il libjpeg.so modificato utilizza la funzione appena aggiunta di libexif.so, il libjpeg.so modificato sarà un modulo UX.

Le definizioni e gli utilizzi sono indipendenti l'uno dall'altro:

Funzionalità utilizzate
Solo AOSP (UA) Esteso (UX)
Funzionalità definite Solo AOSP (DA) DAUA DAUX
Esteso (DX) DXUA DXUX

Meccanismo di estensione VNDK

I moduli del fornitore che si basano su funzionalità estese non funzioneranno perché la libreria AOSP con lo stesso nome non dispone della funzionalità estesa. Se i moduli del fornitore dipendono direttamente o indirettamente da funzionalità estese, i fornitori devono copiare le librerie condivise DAUX, DXUA e DXUX nella partizione del fornitore (i processi del fornitore cercano sempre prima le librerie condivise nella partizione del fornitore). Tuttavia, le librerie LL-NDK non devono essere copiate, pertanto i moduli del fornitore non devono fare affidamento sulle funzionalità estese definite dalle librerie LL-NDK modificate.

Le librerie condivise DAUA possono rimanere nella partizione di sistema se la libreria AOSP corrispondente può fornire la stessa funzionalità e i moduli del fornitore continuano a funzionare quando la partizione di sistema viene sovrascritta da un'immagine di sistema generica (GSI).

La sostituzione plug-in è importante perché le librerie VNDK non modificate nel GSI si collegheranno alle librerie condivise modificate in caso di collisione dei nomi. Se le librerie AOSP vengono modificate in modo incompatibile con l'API/l'ABI, il collegamento delle librerie AOSP nel GSI potrebbe non riuscire o causare comportamenti non definiti.