Estensioni VNDK

I produttori di dispositivi Android modificano il codice sorgente delle librerie AOSP per vari motivi. Alcuni fornitori reimplementano le funzioni nelle librerie AOSP per migliorare le prestazioni mentre altri fornitori 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 interrompere CTS/VTS.

Sostituzione immediata

Tutte le librerie condivise modificate devono essere compatibili con il sistema binario e devono essere sostitutivi della loro controparte AOSP. Tutti gli utenti AOSP esistenti devono essere in grado di utilizzare la libreria condivisa modificata senza ricompilazioni. Questo requisito implica quanto segue:

• Le funzioni AOSP non devono essere rimosse.
• Le strutture non devono essere modificate se tali strutture sono esposte ai loro utenti.
• Le precondizioni funzionali non devono essere rafforzate.
• Le funzioni devono fornire funzionalità equivalenti.
• La post-condizione delle funzioni non deve essere indebolita.

Classificazioni estese dei moduli

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

Nota : qui vengono utilizzate le funzionalità anziché API/ABI perché è possibile aggiungere funzionalità senza modificare alcuna API/ABI.

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

• I moduli AOSP di sola definizione (modulo DA) non definiscono nuove funzionalità che non erano nella controparte AOSP.
  • Esempio 1. Una libreria AOSP intatta e non modificata è un modulo DA.
  • Esempio 2. Se un fornitore riscrive le funzioni in libcrypto.so con istruzioni SIMD (senza aggiungere nuove funzioni), allora libcrypto.so modificato sarà un modulo DA.
• I moduli di estensione di definizione (modulo DX) 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à un 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 , allora libfoo.so sarà una DX-Lib.

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

• Utilizzando solo moduli 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, allora sarà un modulo UA.
• I moduli Using-Extension (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 , allora il libjpeg.so modificato sarà un modulo UX.
  • Esempio 2. Se un fornitore aggiunge una nuova funzione al proprio libexif.so modificato e il proprio libjpeg.so modificato utilizza la funzione appena aggiunta da libexif.so , il proprio libjpeg.so modificato sarà un modulo UX.

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

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, quindi i moduli del fornitore non devono fare affidamento sulle funzionalità estese definite dalle librerie LL-NDK modificate.

Le librerie condivise DAUA possono rimanere sulla 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 drop-in è importante perché le librerie VNDK non modificate nel GSI si collegheranno con le librerie condivise modificate in caso di collisione dei nomi. Se le librerie AOSP vengono modificate in modo incompatibile con API/ABI, le librerie AOSP nel GSI potrebbero non riuscire a collegarsi o provocare comportamenti indefiniti.