Immagine di sistema condivisa di Android

Questa pagina presenta diversi meccanismi che gli OEM di dispositivi Android possono utilizzare per avere la propria immagine di sistema condivisa (SSI) nelle linee di prodotti. Propone inoltre una procedura per basare un'SSI di proprietà dell'OEM su un'immagine di sistema generica (GSI) creata con AOSP.

Sfondo

Con Project Treble, Android monolitico è stato suddiviso in due parti: la parte specifica dell'hardware (l'implementazione del fornitore) e la parte generica del sistema operativo (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 controllo delle versioni, chiamata interfaccia fornitore (VINTF), è definita e applicata in entrambe le partizioni. Utilizzando questo sistema di partizionamento, puoi modificare la partizione di sistema senza modificare la partizione del fornitore e viceversa.

Motivazione

Il codice del framework rilasciato in AOSP è conforme all'architettura Treble e mantiene la compatibilità con le versioni precedenti delle implementazioni dei fornitori. Ad esempio, un'immagine di sistema generica creata a partire dalle 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 di consumo viene modificata dai fornitori di SoC e dagli OEM. (Vedi Ciclo di vita di una release di Android.) Queste modifiche ed estensioni apportate al framework non sono state scritte per mantenere la compatibilità retroattiva, il che si è tradotto in una maggiore complessità e costi più elevati in un upgrade del sistema operativo. Le modifiche e le modifiche specifiche del dispositivo aumentano il costo e la complessità dell'upgrade 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 che 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 ridurre significativamente la complessità e il costo degli aggiornamenti del sistema operativo Android. Per i passaggi specifici necessari per creare un'impressione secondaria servita, consulta la sezione Passaggi suggeriti per l'impressione secondaria servita basata su GSI e tieni presente che non devi utilizzare tutti e quattro i passaggi. I passaggi che scegli (ad esempio solo il passaggio 1) dipendono dalla tua implementazione.

Panoramica di 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'unica SSI o un numero ridotto di SSI da utilizzare in più SKU di dispositivi. Quando viene rilasciata una nuova versione del sistema operativo Android, gli OEM investono una sola volta nell'aggiornamento delle proprie SSI all'ultima versione di Android. Possono riutilizzare gli 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à e le modifiche personalizzate di cui un OEM ha bisogno. I meccanismi e le best practice forniti in questa pagina sono destinati agli OEM per raggiungere questi obiettivi chiave:

• Riutilizza l'SSI su più SKU di dispositivi.
• Aggiorna il sistema Android con le estensioni modulari per semplificare gli upgrade del sistema operativo.

L'idea di base di separare i componenti specifici del prodotto nella partizione del prodotto è simile all'idea di 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. Tieni presente che, per quanto riguarda SSI, il termine "componenti" descrive tutte le risorse, i file binari, i testi, le librerie e così via installati nelle immagini, che essenzialmente diventano partizioni.

Partizioni intorno a SSI

La Figura 1 mostra le partizioni intorno a SSI e le interfacce con controllo delle versioni tra le partizioni e le policy sulle interfacce. Questa sezione spiega in dettaglio ciascuna delle partizioni e delle interfacce.

Figura 1. Partizioni e interfacce intorno a SSI

Immagini e partizioni

Le informazioni in questa sezione distinguono i termini immagine e partizione.

• Un'immagine è un software concettuale che può essere aggiornato in modo indipendente.
• Una partizione è una posizione di archiviazione fisica che può essere aggiornata in modo indipendente.

Le sezioni della Figura 1 sono definite come segue:

• SSI:l'SSI è l'immagine comune a un OEM e può esistere su più dispositivi. Non ha componenti specifici per l'hardware o per il prodotto. Tutto ciò che è presente in un determinato SSI è, per definizione, condiviso tra tutti i dispositivi che lo utilizzano. L'SSI è composto da una singola immagine /system o da una partizione /system e /system_ext, come mostrato nella Figura 1.

  • La partizione /system contiene componenti basati su AOSP, mentre /system_ext, se implementata, contiene estensioni e componenti del fornitore di OEM e SoC strettamente accoppiati ai componenti AOSP. Ad esempio, una libreria del framework Java OEM che fornisce API personalizzate per le app dell'OEM si adatta meglio alla partizione /system_ext rispetto alla partizione /system. I contenuti per le partizioni /system e /system_ext sono creati a partire da origini Android modificate dall'OEM.

  • La partizione /system_ext è facoltativa, ma è utile utilizzarla per qualsiasi funzionalità ed estensione personalizzata strettamente accoppiata a componenti basati su AOSP. Questa distinzione ti aiuta a identificare le modifiche da apportare per spostare questi componenti dalla partizione /system_ext alla partizione /product in un determinato periodo di tempo.

• Prodotto:una raccolta di componenti specifici per prodotto o dispositivo che rappresentano personalizzazioni ed estensioni OEM del sistema operativo Android. Inserisci i componenti specifici del SoC nella partizione /vendor. I fornitori di SoC possono anche utilizzare la partizione /product per i componenti appropriati, ad esempio quelli indipendenti dal SoC. Ad esempio, se un fornitore di SoC fornisce un componente indipendente dal SoC ai propri clienti OEM (che è facoltativo da spedire con il prodotto), può inserire questo componente nell'immagine del prodotto. La posizione di un componente non è determinata dalla sua proprietà, ma dal suo scopo.

• Fornitore:una raccolta di componenti specifici per il SoC.

• ODM:una raccolta di componenti specifici per la scheda non forniti dal SoC. In genere, il fornitore del SoC è proprietario dell'immagine del fornitore, mentre il produttore del dispositivo è proprietario dell'immagine ODM. Quando non è presente una partizione /odm separata, le immagini del fornitore del SoC e dell'ODM vengono unite nella partizione /vendor.

Interfacce tra le immagini

Esistono due interfacce principali per le immagini di fornitori e prodotti relative a SSI:

• Interfaccia fornitore (VINTF): VINTF è l'interfaccia per i componenti che si trovano nelle immagini del fornitore e dell'ODM. I componenti nelle immagini del prodotto e del sistema possono interagire con le immagini del fornitore e dell'ODM solo tramite questa interfaccia. Ad esempio, un'immagine fornitore non può dipendere da una parte privata dell'immagine di sistema e viceversa. Questa operazione è definita originariamente in Project Treble, che suddivide le immagini in partizioni di sistema e fornitore. L'interfaccia è descritta utilizzando i seguenti meccanismi:

  • HIDL (Passthrough HAL è disponibile solo per i moduli system e system_ext)
  • AIDL stabile
  • Configurazioni
    • API System Properties
    • API dello schema del file di configurazione
  • VNDK
  • API SDK Android
  • Libreria Java SDK

• 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 un SSI. L'interfaccia del prodotto richiede le stesse interfacce stabili di VINTF. Tuttavia, solo le API VNDK e Android SDK sono applicate per i dispositivi lanciati con Android 11 (e versioni successive).

Attivare l'isolamento del sottosistema di sistema 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 facoltativa. È il posto per i componenti non AOSP che hanno un accoppiamento stretto con i componenti definiti da AOSP nella partizione /system. Si presume che la partizione /system_ext sia l'estensione specifica dell'OEM della partizione /system, senza un'interfaccia definita tra le due partizioni. I componenti nella partizione /system_ext possono effettuare chiamate API private nella partizione /system, mentre i componenti nella partizione /system possono effettuare chiamate API private nella partizione /system_ext.

Poiché le due partizioni sono strettamente accoppiate, vengono entrambe aggiornate insieme al rilascio di una nuova versione di Android. Una partizione /system_ext creata per la release precedente di Android non deve essere compatibile con la partizione /system nella release successiva di Android.

Per installare un modulo nella partizione /system_ext, aggiungi system_ext_specific: true al file Android.bp. Per i dispositivi che non hanno una partizione /system_ext, installa questi moduli nella sottodirectory ./system_ext della partizione /system.

Cronologia

Ecco alcuni dati storici sulla partizione /system_ext. L'obiettivo di progettazione era inserire tutti i componenti specifici dell'OEM, indipendentemente dal fatto che siano comuni, nella partizione /product. Tuttavia, spostarli tutti contemporaneamente non era fattibile, soprattutto quando alcuni componenti erano strettamente accoppiati alla partizione /system. Per spostare un componente strettamente accoppiato nella partizione /product, è necessario estendere l'interfaccia del prodotto. Ciò spesso richiedeva un refactoring approfondito del componente stesso, il che richiedeva molto tempo e impegno. La partizione /system_ext è nata come spazio per ospitare temporaneamente i componenti che non sono pronti per essere spostati nella partizione /product. L'obiettivo dell'SSI era quello di eliminare alla fine 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 upgrade è dedicata ai componenti nelle partizioni /system e /system_ext. Quando l'immagine di sistema viene creata da origini il più simili possibile a quelle di AOSP, puoi concentrare l'impegno di upgrade sull'immagine system_ext.

Separa i 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 limitazioni all'utilizzo dei componenti di sistema che la partizione /product rispettava in Android 9. A partire da Android 10, la partizione /product deve essere separata dalla partizione /system e deve utilizzare interfacce stabili delle partizioni /system e /system_ext.

Lo scopo principale della partizione /system_ext è estendere le funzionalità del sistema, piuttosto che installare moduli di prodotto in bundle, come descritto nella sezione /system_ext partition. Per farlo, separa i moduli specifici del prodotto e spostali nella partizione /product. Il disaccoppiamento dei moduli specifici del prodotto rende /system_ext comune ai dispositivi. Per maggiori dettagli, vedi Rendere comune la partizione /system_ext.

Per separare la partizione /product dai componenti di sistema, la partizione /product deve avere lo stesso criterio di applicazione della partizione /vendor che è già stata 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 saperne di più, consulta la sezione Applicazione delle interfacce di partizione dei prodotti.

• Interfacce native:i moduli nativi nella partizione /product devono essere separati dalle altre partizioni. Le uniche dipendenze consentite dai moduli prodotto sono alcune librerie VNDK (inclusa LLNDK) della partizione /system. Le librerie JNI da cui dipendono le app prodotto devono essere librerie NDK.
• Interfacce Java:i moduli Java (app) nella partizione /product non possono utilizzare API nascoste perché sono instabili. Questi moduli devono utilizzare solo API pubbliche e API di sistema della partizione /system e librerie SDK Java nella partizione /system o /system_ext. Puoi definire librerie Java SDK per le API personalizzate.

Passaggi suggeriti per l'SSI basata su GSI

Figura 2. Partizioni suggerite per l'SSI basata su GSI

Un'immagine di sistema generica (GSI) è l'immagine di sistema creata direttamente da AOSP. Viene utilizzata 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 con la versione richiesta di Android.

Gli OEM possono anche utilizzare GSI per creare la propria SSI. Come spiegato in Immagini e partizioni, SSI è costituita dall'immagine di sistema per i componenti definiti da AOSP e dall'immagine system_ext per i componenti definiti dall'OEM. Quando GSI viene utilizzata come immagine system, l'OEM può concentrarsi sull'immagine system_ext per l'upgrade.

Questa sezione fornisce una guida agli OEM che vogliono modularizzare le proprie personalizzazioni nelle partizioni /system_ext e /product utilizzando un'immagine di sistema AOSP o quasi AOSP. Se gli OEM creano l'immagine di sistema dalle sorgenti AOSP, possono sostituire l'immagine di sistema che creano con la GSI fornita da AOSP. Tuttavia, gli OEM non devono raggiungere il passaggio finale (utilizzare GSI così com'è) in una sola volta.

Passaggio 1: Eredita generic_system.mk per l'immagine di sistema dell'OEM (GSI OEM)

Ereditando generic_system.mk (che in Android 11 si chiamava mainline_system.mk e che è stato rinominato in generic_system.mk in AOSP), l'immagine di sistema (GSI OEM) include tutti i file della GSI AOSP. Questi file possono essere modificati dagli OEM, in modo che la GSI OEM possa contenere i file proprietari dell'OEM oltre ai file GSI AOSP. Tuttavia, gli OEM non possono modificare il file generic_system.mk stesso.

Figura 3. Ereditare generic_system.mk per l'immagine di sistema dell'OEM

Passaggio 2: L'immagine GSI OEM deve avere lo stesso elenco di file dell'immagine GSI AOSP

In questa fase, la GSI OEM non può avere file aggiuntivi. I file proprietari dell'OEM devono essere spostati nelle partizioni system_ext o product.

Figura 4. Spostamento dei file aggiunti al di fuori della GSI OEM

Passaggio 3: Definisci una lista consentita per limitare i file modificati nella GSI OEM

Per controllare i file modificati, gli OEM possono utilizzare lo strumento compare_images e confrontare la GSI AOSP con la GSI OEM. Ottieni la GSI AOSP dalla destinazione di lunch AOSP generic_system_*.

Eseguendo periodicamente lo strumento compare_images con il parametro allowlist, puoi monitorare le differenze al di fuori dell'elenco consentito. In questo modo non sono necessarie modifiche aggiuntive alla GSI OEM.

Figura 5. Definisci una lista consentita per ridurre l'elenco dei file modificati nella GSI OEM

Passaggio 4: L'immagine GSI OEM deve avere gli stessi binari dell'immagine GSI AOSP

La pulizia della lista consentita consente agli OEM di utilizzare la GSI AOSP come immagine di sistema per i propri prodotti. Per ripulire la lista consentita, gli OEM possono abbandonare le modifiche nella GSI OEM o trasferirle a AOSP in modo che la GSI AOSP includa le modifiche.

Figura 6. Fare in modo che la GSI OEM abbia gli stessi binari della GSI AOSP

Definisci l'SSI per gli OEM

Proteggere la partizione /system al momento della creazione

Per evitare modifiche specifiche del prodotto nella partizione /system e definire la GSI OEM, gli OEM possono utilizzare una macro makefile chiamata require-artifacts-in-path per impedire qualsiasi dichiarazione di moduli di sistema dopo la chiamata della macro. Consulta l'esempio Crea makefile e attiva il 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 la GSI OEM comune a tutti i prodotti dell'OEM. Questa procedura serve a definire la GSI OEM e può essere indipendente dai passaggi per la GSI AOSP.

Applicare le interfacce dei prodotti

Per garantire che la partizione /product sia separata, gli OEM possono assicurarsi che i loro dispositivi applichino le interfacce di 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, consulta Applicazione delle interfacce di partizione dei prodotti.

Rendi comune la partizione /system_ext

La partizione /system_ext potrebbe variare a seconda dei dispositivi, perché può contenere moduli specifici del dispositivo e inclusi nel sistema. Poiché l'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 app specifiche per prodotto non possono essere installate nella partizione del prodotto perché utilizzano API nascoste, che sono vietate nella partizione del prodotto. Per spostare le app specifiche per il dispositivo nella partizione del prodotto, rimuovi l'utilizzo di API nascoste.

Il modo migliore per rimuovere le API nascoste dalle app è 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 può fornire le API alle app nella partizione del prodotto o del fornitore. Gli OEM devono congelare le API rivolte al prodotto per la compatibilità con le versioni precedenti.

Includi il superset di tutti gli APK e salta l'installazione di alcuni pacchetti per ogni dispositivo

Alcuni pacchetti inclusi nel sistema non sono comuni a tutti i dispositivi. Separare questi moduli APK per spostarli nella partizione del prodotto o del fornitore può essere difficile. Come soluzione provvisoria, gli OEM possono fare in modo che l'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 broadcast receiver che disattiva i pacchetti non necessari. Il ricevitore di trasmissione chiama setApplicationEnabledSetting per disattivare il pacchetto quando riceve il messaggio ACTION_BOOT_COMPLETED.

Definisci RRO anziché utilizzare l'overlay statico delle risorse

Una risorsa statica sovrapposta manipola i pacchetti sovrapposti. Tuttavia, può ostacolare la definizione di un'inclusione lato server, quindi assicurati che le proprietà per l'ottimizzazione della risposta rapida siano attive e impostate correttamente. Impostando le proprietà come segue, gli OEM possono avere tutte le sovrapposizioni generate automaticamente come RRO.

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

Se è necessaria una configurazione dettagliata, definisci manualmente un RRO anziché affidarti a uno generato automaticamente. Per informazioni dettagliate, vedi Overlay delle risorse di runtime (RRO). Gli OEM possono anche definire RRO condizionali che dipendono dalle proprietà di sistema utilizzando gli attributi android:requiredSystemPropertyName e android:requiredSystemPropertyValue.

Domande frequenti

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 una GSI OEM?

No. Tuttavia, gli OEM possono definire un nuovo makefile per una GSI OEM che eredita il file generic_system.mk e utilizzare il nuovo makefile. Per un esempio, consulta Imposizione delle interfacce di partizione dei prodotti.

Posso rimuovere da generic_system.mk i moduli in conflitto con la mia implementazione?

No. GSI ha un insieme 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.