I produttori di dispositivi Android modificano il codice sorgente delle librerie AOSP per per vari motivi. Alcuni fornitori reimplementano le funzioni nelle librerie AOSP migliorare le prestazioni mentre altri fornitori aggiungono nuovi hook, nuove API o nuove le funzionalità alle librerie AOSP. Questa sezione fornisce le linee guida per l'estensione delle librerie AOSP in modo da non interrompere CTS/VTS.
Sostituzione tramite consegna immediata
Tutte le librerie condivise modificate devono essere compatibili con binari, sostituzioni drop-in della controparte AOSP. Tutti quelli esistenti Gli utenti AOSP devono essere in grado di utilizzare la libreria condivisa modificata senza e ricompilazioni. 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 condizione preliminare delle funzioni non deve essere rafforzata.
- Le funzioni devono fornire funzionalità equivalenti.
- Non è necessario indebolire la condizione di post-condizione delle funzioni.
Classificazioni dei moduli estesi
Classificare i moduli in base alle funzionalità che definiscono e usa.
Nota: qui viene utilizzata la funzionalità. anziché API/ABI perché è possibile aggiungere funzionalità senza modificare qualsiasi API/ABI.
A seconda delle funzionalità definite in un modulo, i moduli possono essere classificati in Modulo DA e Modulo DX:
-
Definizione dei moduli solo AOSP (modulo DA) non definisce nuovi
che non appartenevano alla controparte AOSP.
- Esempio 1. Una libreria AOSP non modificata e intatta è Modulo DA.
- Esempio 2. Se un fornitore riscrive le funzioni in
libcrypto.socon istruzioni SIMD (senza aggiungere nuovi ), illibcrypto.somodificato sarà un Modulo DA.
-
Definizione dei moduli di estensione (modulo DX) definisce nuovi
o non hanno una controparte AOSP.
- Esempio 1. Se un fornitore aggiunge una funzione helper a
libjpeg.soper accedere ad alcuni dati interni, poi la modificalibjpeg.sosarà un DX-Lib e la funzione appena aggiunta sarà la parte estesa della biblioteca. - Esempio 2. Se un fornitore definisce una libreria non AOSP denominata
libfoo.so, quindilibfoo.sosarà un DX-Lib.
- Esempio 1. Se un fornitore aggiunge una funzione helper a
A seconda delle funzionalità utilizzate da un modulo, i moduli possono essere classificati in UA-Module e UX-Module.
-
L'utilizzo dei moduli AOSP solo (UA-Module) utilizza solo le funzionalità AOSP
nelle loro implementazioni. Non si basano su estensioni non AOSP.
- Esempio 1. Una libreria AOSP non modificata e intatta è Modulo UA.
- Esempio 2. Se una libreria condivisa modificata
libjpeg.sosi basa solo su altre API AOSP, allora sarà un modulo UA.
-
L'utilizzo dei moduli di estensione (modulo UX) si basa su alcune
funzionalità nelle loro implementazioni.
- Esempio 1. Se un elemento
libjpeg.somodificato si basa su in un'altra libreria non AOSP denominatalibjpeg_turbo2.so,libjpeg.somodificato sarà un modulo UX. - Esempio 2. Se un fornitore aggiunge una nuova funzione a un
libexif.soe le suelibjpeg.somodificate utilizzano i valori funzione appena aggiunta dalibexif.so, poi le relative modifichelibjpeg.sosarà un modulo UX.
- Esempio 1. Se un elemento
Definizioni e utilizzi sono indipendenti tra loro:
| Funzionalità utilizzate | |||
|---|---|---|---|
| Solo AOSP (UA) | Estensioni (UX) | ||
| Funzionalità definite | Solo AOSP (DA) | DAUA | DAUX |
| Esteso (DX) | DXUA | DXUX | |
Meccanismo di estensione VNDK
I moduli dei fornitori che si basano su funzionalità estese non funzioneranno perché La libreria AOSP con lo stesso nome non ha la funzionalità estesa. Se i moduli dei fornitori dipendono direttamente o indirettamente da funzionalità estese, i fornitori devono copiare le librerie condivise DAUX, DXUA e DXUX sul fornitore (i processi del fornitore cercano sempre . Tuttavia, le librerie LL-NDK non devono essere copiate, quindi il fornitore i moduli non devono fare affidamento sulle funzionalità estese definite dal librerie LL-NDK.
Le librerie condivise DAUA possono rimanere nella partizione di sistema se la libreria AOSP corrispondente può fornire le stesse funzionalità e lo stesso fornitore continuano a funzionare quando la partizione di sistema viene sovrascritta da un immagine di sistema (GSI).
La sostituzione tramite passaggio è importante perché le librerie VNDK non modificate il GSI si collegherà alle librerie condivise modificate in caso di conflitto di nomi. Se Le librerie AOSP vengono modificate in modo incompatibile con API/ABI, le librerie in GSI potrebbero non riuscire a collegarsi o provocare comportamenti indefiniti.