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 aumentare 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 drop-in

Tutte le librerie condivise modificate devono essere sostituzioni drop-in compatibili con i binari 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 alterate se tali strutture sono esposte ai loro utenti.
  • La condizione preliminare delle funzioni non deve essere rafforzata.
  • Le funzioni devono fornire funzionalità equivalenti.
  • La post-condizione delle funzioni non deve essere indebolita.

Classificazioni dei moduli estese

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

Nota : le funzionalità vengono utilizzate qui al posto 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 in DA-Module e DX-Module :

  • I moduli Defining-only-AOSP (DA-Module) 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 venditore riscrive le funzioni in libcrypto.so con le istruzioni SIMD (senza aggiungere nuove funzioni), allora il libcrypto.so modificato sarà un modulo DA.
  • I Defining-Extension Modules (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à 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à un DX-Lib.

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

  • Utilizzando solo i 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 UA-Module.
  • L'utilizzo dei moduli di estensione (UX-Module) si basa 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 suo libexif.so modificato e il suo libjpeg.so modificato utilizza la funzione appena aggiunta da libexif.so , il suo libjpeg.so modificato sarà un modulo UX.

Le definizioni e gli usi 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 dovrebbero 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à ei 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 alle librerie condivise modificate in caso di conflitto di 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.