Questa pagina presenta diversi meccanismi che gli OEM di dispositivi Android possono utilizzare per avere la propria immagine di sistema condivisa (SSI) tra le linee di prodotti. Propone inoltre una procedura per basare un SSI di proprietà dell'OEM su un'immagine di sistema generica (GSI) creata da AOSP.
Sfondo
Con Project Treble , Android monolitico è stato diviso in due parti: la parte specifica dell'hardware (l'implementazione del fornitore) e la parte del sistema operativo generico (il framework del sistema operativo Android). Il software per ciascuno è installato in una partizione separata: la partizione del fornitore per il software specifico dell'hardware e la partizione di sistema per il software del sistema operativo generico. Un'interfaccia con versione, denominata interfaccia del fornitore ( VINTF ), viene definita e applicata tra le due partizioni. Utilizzando questo sistema di partizionamento, è possibile modificare la partizione di sistema senza modificare la partizione del fornitore e viceversa.
Motivazione
Il codice del framework rilasciato in AOSP è stato compatibile con l'architettura Treble e ha mantenuto la compatibilità con le implementazioni dei fornitori precedenti. Ad esempio, un'immagine di sistema generica creata da origini AOSP di Android 10 può essere eseguita su qualsiasi dispositivo compatibile con Treble che esegue Android 8 o versioni successive. La versione di Android fornita sui dispositivi consumer viene modificata dai fornitori di SoC e dagli OEM. (Vedi Durata di una versione Android .) Queste modifiche ed estensioni apportate al framework non sono state scritte per mantenere la compatibilità con le versioni precedenti, il che si è tradotto in una maggiore complessità e costi più elevati in un aggiornamento del sistema operativo. Cambiamenti e modifiche specifici del dispositivo aumentano il costo e la complessità dell'aggiornamento di una versione del sistema operativo Android.
Prima di Android 11 non esisteva un'architettura chiara che consentisse ai partner di creare estensioni modulari al framework del sistema operativo Android. Questo documento descrive i passaggi che i fornitori di SoC e gli OEM possono eseguire per creare un SSI. Ciò significa un'unica immagine, creata dalle origini del framework del sistema operativo Android per il riutilizzo su più dispositivi, per mantenere la compatibilità con le versioni precedenti con le implementazioni dei fornitori e per fornire una significativa riduzione della complessità e dei costi degli aggiornamenti del sistema operativo Android. Per i passaggi specifici necessari per creare un SSI, consulta la sezione Passaggi suggeriti per SSI basato su GSI e tieni presente che non è necessario utilizzare tutti e quattro i passaggi. I passaggi che scegli (solo il Passaggio 1, ad esempio) dipendono dalla tua implementazione.
Panoramica SSI
Con SSI, i componenti software specifici del prodotto e le estensioni OEM vengono inseriti in una nuova partizione /product . I componenti nella partizione /product utilizzano un'interfaccia stabile e ben definita per interagire con i componenti nella partizione /system . Gli OEM possono scegliere di creare un SSI o di avere un numero limitato di SSI da utilizzare su più SKU di dispositivi. Quando viene rilasciata una nuova versione del sistema operativo Android, gli OEM investono solo una volta nell'aggiornamento dei propri SSI all'ultima versione di Android. Possono riutilizzare le SSI per aggiornare più dispositivi senza aggiornare la partizione /product .
Tieni presente che gli OEM e i fornitori di SoC creano SSI che includono tutte le funzionalità personalizzate e le modifiche di cui un OEM ha bisogno. I meccanismi e le migliori pratiche forniti in questa pagina sono destinati agli OEM da utilizzare per raggiungere questi obiettivi chiave:
- Riutilizza l'SSI su più SKU del dispositivo.
- Aggiorna il sistema Android con le estensioni modulari per semplificare gli aggiornamenti del sistema operativo.
L'idea centrale di separare i componenti specifici del prodotto nella partizione del prodotto è simile all'idea Treble di separare i componenti specifici del SoC nella partizione del fornitore. Un'interfaccia del prodotto (simile a VINTF ) consente la comunicazione tra SSI e la partizione del prodotto. Si noti che rispetto a SSI, il termine "componenti" descrive tutte le risorse, i file binari, i testi, le librerie e così via che vengono installati nelle immagini, che diventano essenzialmente partizioni.
Partizioni attorno all'SSI
La Figura 1 mostra le partizioni attorno a SSI e le interfacce con versione tra le partizioni e le policy sulle interfacce. Questa sezione spiega dettagliatamente ciascuna partizione e interfaccia.
Figura 1. Partizioni e interfacce attorno a SSI
Immagini e partizioni
Le informazioni contenute in questa sezione distinguono tra i termini immagine e partizione .
- Un'immagine è una parte concettuale di software che può essere aggiornata in modo indipendente.
- Una partizione è una posizione di archiviazione fisica che può essere aggiornata in modo indipendente.
Le sezioni nella Figura 1 sono definite come segue:
SSI: SSI è l'immagine comune a un OEM e può esistere su più dispositivi. Non ha componenti specifici dell'hardware o del prodotto. Tutto in un dato SSI è, per definizione, condiviso tra tutti i dispositivi che utilizzano quell'SSI. L'SSI è composto da una singola immagine
/systemo da una partizione/systeme/system_ext, come illustrato nella Figura 1.La partizione
/systemcontiene componenti basati su AOSP, mentre/system_ext, quando implementato, contiene estensioni e componenti dei fornitori OEM e SoC strettamente associati ai componenti AOSP. Ad esempio, una libreria framework Java OEM che fornisce API personalizzate per le app dell'OEM si adatta meglio alla partizione/system_extche alla partizione/system. Il contenuto delle partizioni/systeme/system_extè creato da origini Android modificate dall'OEM.La partizione
/system_extè facoltativa, ma è utile utilizzarla per eventuali funzionalità ed estensioni personalizzate strettamente associate ai componenti basati su AOSP. Questa distinzione ti aiuta a identificare le modifiche che devi apportare, per spostare tali componenti dalla partizione/system_extalla partizione/productin un periodo di tempo.
Prodotto: una raccolta di componenti specifici del prodotto o del dispositivo che rappresentano personalizzazioni OEM ed estensioni del sistema operativo Android. Inserisci i componenti specifici del SoC nella partizione
/vendor. I fornitori di SoC possono anche utilizzare la partizione/productper i componenti appropriati, come quelli indipendenti dal SoC. Ad esempio, se un fornitore di SoC fornisce ai propri clienti OEM un componente indipendente dal SoC (che è facoltativo da spedire con il prodotto), il fornitore di SoC può inserire quel componente nell'immagine del prodotto. La posizione di un componente non è determinata dalla sua proprietà , è dettata dal suo scopo .Venditore : una raccolta di componenti specifici del SoC.
ODM: una raccolta di componenti specifici della scheda che non sono forniti dal SoC. In genere il fornitore del SoC possiede l'immagine del fornitore, mentre il produttore del dispositivo possiede l'immagine dell'ODM. Quando non è presente una partizione
/odmseparata, sia il fornitore del SoC che le immagini ODM vengono uniti nella partizione/vendor.
Interfacce tra immagini
Esistono due interfacce principali per le immagini del fornitore e del prodotto attorno a SSI:
Vendor Interface (VINTF) : VINTF è l'interfaccia per i componenti che risiedono nel fornitore e nelle immagini ODM. I componenti nelle immagini del prodotto e del sistema possono interagire solo con le immagini del fornitore e dell'ODM tramite questa interfaccia. Ad esempio, l'immagine di un fornitore non può dipendere da una parte privata dell'immagine di sistema e viceversa. Questo è originariamente definito in Project Treble, che divide le immagini in partizioni di sistema e fornitore. L'interfaccia viene descritta utilizzando i seguenti meccanismi:
- HIDL (Passthrough HAL è disponibile solo per i moduli
systemesystem_ext) - AIDL stabile
- Configurazioni
- API delle proprietà di sistema
- API dello schema del file di configurazione
- VNDK
- API dell'SDK Android
- Libreria SDK Java
- HIDL (Passthrough HAL è disponibile solo per i moduli
Interfacce del prodotto : l'interfaccia del prodotto è l'interfaccia tra SSI e l'immagine del prodotto. La definizione di un'interfaccia stabile disaccoppia i componenti del prodotto dai componenti del sistema in una SSI. L'interfaccia del prodotto richiede le stesse interfacce stabili di VINTF. Tuttavia, solo le API VNDK e Android SDK vengono applicate ai dispositivi avviati con Android 11 (e versioni successive).
Abilitare SSI in Android 11
Questa sezione spiega come utilizzare le nuove funzionalità implementate per supportare SSI in Android 11.
La partizione /system_ext
La partizione /system_ext è stata introdotta in Android 11 come partizione opzionale. (È il posto per i componenti non AOSP che hanno uno stretto accoppiamento con i componenti definiti da AOSP nella partizione /system .) Si presuppone che la partizione /system_ext sia l'estensione specifica dell'OEM alla partizione /system , senza un'interfaccia definita attraverso le due partizioni. I componenti nella partizione /system_ext possono effettuare chiamate API private nella partizione /system e i componenti nella partizione /system possono effettuare chiamate API private nella partizione /system_ext .
Poiché le due partizioni sono strettamente accoppiate, entrambe le partizioni vengono aggiornate insieme quando viene rilasciata una nuova versione di Android. Non è necessario che una partizione /system_ext creata per la versione precedente di Android sia compatibile con la partizione /system nella successiva versione di Android.
Per installare un modulo nella partizione /system_ext , aggiungi system_ext_specific: true al file Android.bp . Per i dispositivi che non dispongono di una partizione /system_ext , installare tali moduli nella sottodirectory ./system_ext nella partizione /system .
Storia
Ecco un po' di storia della partizione /system_ext . L'obiettivo della progettazione era posizionare tutti i componenti specifici dell'OEM, indipendentemente dal fatto che siano comuni, nella partizione /product . Tuttavia, spostarli tutti in una volta non era fattibile, soprattutto quando alcuni componenti erano strettamente collegati alla partizione /system . Per spostare un componente strettamente accoppiato nella partizione /product , l'interfaccia del prodotto deve essere estesa. Ciò spesso richiedeva un ampio refactoring del componente stesso, il che richiede molto tempo e fatica. La partizione /system_ext è stata avviata come luogo in cui ospitare temporaneamente i componenti che non sono pronti per essere spostati nella partizione /product . L'obiettivo dell'SSI era eliminare definitivamente la partizione /system_ext .
Tuttavia, la partizione /system_ext è utile per mantenere la partizione /system il più vicino possibile ad AOSP. Con SSI, la maggior parte dello sforzo di aggiornamento viene speso sui componenti nelle partizioni /system e /system_ext . Quando l'immagine di sistema viene creata da origini quanto più simili possibile a quelle di AOSP, è possibile concentrare l'attività di aggiornamento sull'immagine system_ext .
Separazione dei componenti dalle partizioni /system e /system_ext nella partizione /product
Android 9 ha introdotto una partizione /product accoppiata alla partizione /system . I moduli nella partizione /product utilizzano le risorse di sistema senza alcuna restrizione e viceversa. Per rendere possibile SSI in Android 10, i componenti del prodotto sono suddivisi nelle partizioni /system_ext e /product . La partizione /system_ext non deve rispettare le restrizioni sull'utilizzo dei componenti di sistema che la partizione /product aveva in Android 9. A partire da Android 10, la partizione /product deve essere separata dalla partizione /system e deve utilizzare interfacce stabili da le partizioni /system e /system_ext .
Lo scopo principale della partizione /system_ext è estendere le funzionalità del sistema, piuttosto che installare moduli del prodotto in bundle, come descritto nella sezione /system_ext partition . Per fare ciò, separa i moduli specifici del prodotto e spostali nella partizione /product . La separazione dei moduli specifici del prodotto rende /system_ext comune ai dispositivi. (Per maggiori dettagli, vedere Rendere comune la partizione /system_ext .)
Per separare la partizione /product dai componenti di sistema, la partizione /product deve avere la stessa politica di applicazione della partizione /vendor già separata con Project Treble.
A partire da Android 11, le interfacce native e Java per la partizione /product vengono applicate come descritto di seguito. Per ulteriori informazioni, consulta Applicazione delle interfacce di partizione del prodotto .
- Interfacce native : i moduli nativi nella partizione
/productdevono essere separati dalle altre partizioni. Le uniche dipendenze consentite dai moduli del prodotto sono alcune librerie VNDK (inclusa LLNDK) dalla partizione/system. Le librerie JNI da cui dipendono le app del prodotto devono essere librerie NDK. - Interfacce Java : i moduli Java (app) nella partizione
/productnon possono utilizzare API nascoste perché sono instabili. Questi moduli devono utilizzare solo API pubbliche e API di sistema dalla partizione/systeme le librerie SDK Java nella partizione/systemo/system_ext. È possibile definire librerie Java SDK per API personalizzate.
Passaggi suggeriti per l'SSI basato su GSI
Figura 2. Partizioni suggerite per SSI basato su GSI
Un'immagine di sistema generica (GSI) è l'immagine di sistema creata direttamente da AOSP. Viene utilizzato per i test di conformità Treble (ad esempio, CTS-on-GSI) e come piattaforma di riferimento che gli sviluppatori di app possono utilizzare per testare la compatibilità delle loro app quando non dispongono di un dispositivo reale che esegue la versione richiesta di Android.
Gli OEM possono anche utilizzare GSI per creare il proprio SSI. Come spiegato in Immagini e partizioni , SSI è costituito dall'immagine di sistema per i componenti definiti da AOSP e dall'immagine system_ext per i componenti definiti dall'OEM. Quando GSI viene utilizzato come immagine system , l'OEM può concentrarsi sull'immagine system_ext per l'aggiornamento.
Questa sezione fornisce una guida agli OEM che desiderano modularizzare le proprie personalizzazioni nelle partizioni /system_ext e /product mentre utilizzano un'immagine di sistema AOSP o quasi AOSP. Se gli OEM creano l'immagine di sistema da origini AOSP, possono sostituire l'immagine di sistema creata con il GSI fornito da AOSP. Tuttavia, gli OEM non hanno bisogno di raggiungere il passaggio finale (usando GSI così com'è) tutto in una volta.
Passaggio 1. Ereditarietà di generic_system.mk per l'immagine di sistema dell'OEM (OEM GSI)
Ereditando generic_system.mk (denominato mainline_system.mk in Android 11 e rinominato in generic_system.mk in AOSP), l'immagine di sistema (OEM GSI) include tutti i file di cui dispone AOSP GSI. Questi file possono essere modificati dagli OEM, in modo che OEM GSI possa contenere i file proprietari OEM oltre ai file AOSP GSI. Tuttavia, agli OEM non è consentito modificare il file generic_system.mk stesso.
Figura 3. Eredità di generic_system.mk per l'immagine di sistema dell'OEM
Passaggio 2. Fare in modo che il GSI OEM abbia lo stesso elenco di file del GSI AOSP
L'OEM GSI non può avere file aggiuntivi in questa fase. I file proprietari dell'OEM devono essere spostati nelle partizioni system_ext o product .
Figura 4. Spostamento dei file aggiunti fuori dal GSI OEM
Passaggio 3. Definizione di una lista consentita per limitare i file modificati nell'OEM GSI
Per verificare i file modificati, gli OEM possono utilizzare lo strumento compare_images e confrontare il GSI AOSP con il GSI OEM. Ottieni il GSI AOSP dalla destinazione del pranzo AOSP generic_system_* .
Eseguendo periodicamente lo strumento compare_images con il parametro allowlist , è possibile monitorare le differenze al di fuori dell'elenco consentito. Ciò impedisce la necessità di ulteriori modifiche al GSI OEM.
Figura 5. Definire una lista consentita per ridurre l'elenco dei file modificati nel GSI OEM
Passaggio 4. Fare in modo che il GSI OEM abbia gli stessi file binari del GSI AOSP
La pulizia della lista consentita consente agli OEM di utilizzare AOSP GSI come immagine di sistema per i propri prodotti. Per ripulire la lista consentita, gli OEM possono abbandonare le modifiche apportate all'OEM GSI oppure eseguire l'upstream delle modifiche ad AOSP in modo che AOSP GSI le includa.
Figura 6. Fare in modo che il GSI OEM abbia gli stessi file binari del GSI AOSP
Definizione di SSI per gli OEM
Proteggi la partizione /system in fase di compilazione
Per evitare eventuali modifiche specifiche del prodotto nella partizione /system e definire l'OEM GSI, gli OEM possono utilizzare una macro makefile denominata require-artifacts-in-path per impedire qualsiasi dichiarazione di moduli di sistema dopo la chiamata della macro. Consulta l'esempio di creazione del makefile e attivazione del controllo del percorso dell'artefatto .
Gli OEM possono definire un elenco per consentire l'installazione temporanea di moduli specifici del prodotto nella partizione /system . Tuttavia, l'elenco deve essere vuoto per rendere il GSI OEM comune a tutti i prodotti OEM. Questo processo serve per definire il GSI OEM e può essere indipendente dai passaggi per il GSI AOSP .
Applicare le interfacce del prodotto
Per garantire che la partizione /product sia disaggregata, gli OEM possono garantire che i propri dispositivi applichino le interfacce del prodotto impostando PRODUCT_PRODUCT_VNDK_VERSION:= current per i moduli nativi e PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true per i moduli Java. Queste variabili vengono impostate automaticamente se il PRODUCT_SHIPPING_API_LEVEL del dispositivo è maggiore o uguale a 30 . Per informazioni dettagliate, vedere Applicazione delle interfacce di partizione del prodotto .
Rendere comune la partizione /system_ext
La partizione /system_ext potrebbe differire tra i dispositivi, poiché può contenere moduli specifici del dispositivo e raggruppati nel sistema. Poiché SSI è costituito dalle partizioni /system e /system_ext , le differenze nella partizione /system_ext impediscono agli OEM di definire un SSI. Gli OEM possono avere il proprio SSI e condividerlo tra più dispositivi rimuovendo eventuali differenze e rendendo comune la partizione /system_ext .
Questa sezione fornisce consigli per rendere comune la partizione /system_ext .
Esporre le API nascoste nella partizione di sistema
Molte applicazioni specifiche del prodotto non possono essere installate nella partizione del prodotto perché utilizzano API nascoste, che non sono consentite nella partizione del prodotto. Per spostare le applicazioni specifiche del dispositivo nella partizione del prodotto, rimuovere l'uso delle API nascoste.
Il modo migliore per rimuovere le API nascoste dalle applicazioni è trovare le API pubbliche o di sistema alternative per sostituirle. Se non sono presenti API per sostituire le API nascoste, gli OEM possono contribuire ad AOSP per definire le nuove API di sistema per i propri dispositivi.
In alternativa, gli OEM possono definire API personalizzate creando la propria libreria Java SDK nella partizione /system_ext . Può utilizzare API nascoste nella partizione di sistema e fornire le API alle applicazioni nella partizione del prodotto o del fornitore. Gli OEM devono congelare le API rivolte al prodotto per garantire la compatibilità con le versioni precedenti.
Includi il superset di tutti gli APK e salta l'installazione di alcuni pacchetti per ciascun dispositivo
Alcuni pacchetti forniti in bundle con il sistema non sono comuni su tutti i dispositivi. Disaggregare questi moduli APK per spostarli nel prodotto o nella partizione del fornitore può essere difficile. Come soluzione provvisoria, gli OEM possono fare in modo che SSI includa tutti i moduli, quindi filtrare quelli indesiderati utilizzando una proprietà SKU ( ro.boot.hardware.sku ). Per utilizzare il filtro, gli OEM sovrappongono le risorse del framework config_disableApkUnlessMatchedSku_skus_list e config_disableApksUnlessMatchedSku_apk_list .
Per impostazioni più precise, dichiara un ricevitore di trasmissione che disabiliti i pacchetti non necessari. Il ricevitore broadcast chiama setApplicationEnabledSetting per disabilitare il pacchetto quando riceve il messaggio ACTION_BOOT_COMPLETED .
Definire RRO invece di utilizzare la sovrapposizione di risorse statiche
Una sovrapposizione di risorse statiche manipola i pacchetti sovrapposti. Tuttavia, può impedire la definizione di un SSI, quindi assicurarsi che le proprietà per RRO siano attivate e impostate correttamente. Impostando le proprietà come segue, gli OEM possono avere tutti gli overlay generati automaticamente come RRO.
PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty
Se è necessaria una configurazione dettagliata, definire manualmente un RRO invece di fare affidamento su uno generato automaticamente. Per informazioni dettagliate, consulta Runtime Resource Overlays (RRO) . Gli OEM possono anche definire RRO condizionali che dipendono dalle proprietà del sistema utilizzando gli attributi android:requiredSystemPropertyName e android:requiredSystemPropertyValue .
Domande frequenti (FAQ)
Posso definire più SSI?
Dipende dalla comunanza e dalle caratteristiche dei dispositivi (o del gruppo di dispositivi). Gli OEM possono provare a rendere comune la partizione system_ext , come descritto in Rendere comune la partizione system_ext . Se un gruppo di dispositivi presenta molte differenze, è meglio definire più SSI.
Posso modificare generic_system.mk ( mainline_system.mk ) per un GSI OEM?
No. Ma gli OEM possono definire un nuovo makefile per un GSI OEM che eredita il file generic_system.mk e utilizzare invece il nuovo makefile. Per un esempio, consulta Applicazione delle interfacce di partizione del prodotto .
Posso rimuovere i moduli da generic_system.mk che sono in conflitto con la mia implementazione?
No. GSI dispone di un set minimo di moduli avviabili e testabili. Se ritieni che un modulo non sia essenziale, segnala un bug per aggiornare il file generic_system.mk in AOSP.