Puoi utilizzare il formato file APEX per pacchettizzare e installare moduli del sistema operativo Android di livello inferiore. Consente di creare e gestire in maniera indipendente di componenti come librerie e servizi nativi, HAL implementazioni, firmware, file di configurazione ecc.
Gli APEX del fornitore vengono installati automaticamente dal sistema di build in /vendor
e attivato in fase di runtime da apexd
, proprio come gli APEX in altri
partizioni di Compute Engine.
Casi d'uso
Modularizzazione delle immagini dei fornitori
Gli APEX facilitano il naturale raggruppamento e la modularizzazione delle caratteristiche le implementazioni delle immagini dei fornitori.
Quando le immagini del fornitore vengono create come combinazione di fornitori creati in modo indipendente APEX, i produttori di dispositivi possono selezionare e scegliere facilmente le implementazioni richieste dai fornitori sul loro dispositivo. I produttori possono anche creare una l'APEX del nuovo fornitore se nessuno degli APEX forniti soddisfa le sue esigenze o se hardware personalizzato completamente nuovo.
Ad esempio, un OEM potrebbe scegliere di comporre il proprio dispositivo con il Wi-Fi AOSP. implementazione APEX, l'APEX di implementazione Bluetooth SoC e un OEM personalizzato APEX per l'implementazione della telefonia.
Senza gli APEX del fornitore, un'implementazione con così tante dipendenze tra e componenti del fornitore richiedono un coordinamento e un monitoraggio accurati. Includendo tutti (inclusi file di configurazione e librerie aggiuntive) negli APEX con interfacce chiaramente definite in ogni punto di comunicazione tra funzionalità, i vari componenti diventano intercambiabili.
Iterazione sviluppatore
Gli APEX del fornitore aiutano gli sviluppatori a eseguire l'iterazione più velocemente durante lo sviluppo dei moduli dei fornitori raggruppando un'intera implementazione di funzionalità, come l'HAL Wi-Fi, all'interno di un fornitore APEX Gli sviluppatori possono quindi creare l'APEX del fornitore ed eseguirne il push singolarmente per testarlo delle modifiche, anziché ricreare l'intera immagine del fornitore.
Ciò semplifica e accelera il ciclo di iterazione per gli sviluppatori che lavorare principalmente in un'area delle caratteristiche e voler eseguire l'iterazione solo su quella caratteristica geografica specifica.
Anche il naturale raggruppamento di un'area di caratteristiche in un APEX semplifica il processo di creazione, push e test delle modifiche per quell'area delle caratteristiche. Ad esempio: la reinstallazione di un APEX aggiorna automaticamente tutti i file di configurazione o le librerie in bundle incluso nell'APEX.
Il raggruppamento di un'area di caratteristiche in un APEX semplifica anche il debug o il ripristino quando vengono osservate prestazioni scadenti del dispositivo. Ad esempio, se la telefonia non funziona bene in una nuova build, gli sviluppatori potrebbero provare a installare una di implementazione di APEX su un dispositivo (senza dover eseguire il flashing di una build completa) per vedere se si ripristinano le buone prestazioni.
Flusso di lavoro di esempio:
# Build the entire device and flash. OR, obtain an already-flashed device.
source build/envsetup.sh && lunch oem_device-userdebug
m
fastboot flashall -w
# Test the device.
... testing ...
# Check previous behavior using a vendor APEX from one week ago, downloaded from
# your continuous integration build.
... download command ...
adb install <path to downloaded APEX>
adb reboot
... testing ...
# Edit and rebuild just the APEX to change and test behavior.
... edit APEX source contents ...
m <apex module name>
adb install out/<path to built APEX>
adb reboot
... testing ...
Esempi
Nozioni di base
Consulta la pagina principale Formato file APEX per l'APEX generico informazioni, tra cui i requisiti dei dispositivi, i dettagli dei formati dei file e i passaggi per l'installazione.
In Android.bp
, l'impostazione della proprietà vendor: true
rende un modulo APEX un
il fornitore APEX.
apex {
..
vendor: true,
..
}
Programmi binari e librerie condivise
Un APEX include dipendenze transitive all'interno del payload APEX, a meno che non hanno interfacce stabili.
Le interfacce native stabili per le dipendenze APEX del fornitore includono cc_library
con
stubs
, ndk_library
o llndk_library
. Queste dipendenze sono escluse
la pacchettizzazione e le dipendenze vengono registrate nel manifest APEX. Il file manifest è
elaborati da linkerconfig
in modo che le dipendenze native esterne
disponibili in fase di runtime.
A differenza degli APEX nella partizione /system
, gli APEX dei fornitori sono generalmente legati a una
una versione VNDK specifica. Le librerie VNDK garantiscono la stabilità ABI all'interno del
di release, in modo da poter trattare le librerie VNDK come stabili e ridurre le dimensioni del
gli APEX escludendoli dagli APEX utilizzando lo use_vndk_as_stable
proprietà.
Nello snippet seguente, l'APEX conterrà sia il file binario (my_service
) che
e delle sue dipendenze non stabili (*.so
file). Non conterrà librerie VNDK,
anche quando my_service
viene creato con librerie VNDK come libbase
. Invece, all'indirizzo
il runtime my_service
userà libbase
delle librerie VNDK fornite dalla
di un sistema operativo completo.
apex {
..
vendor: true,
use_vndk_as_stable: true,
binaries: ["my_service"],
..
}
Nello snippet seguente, l'APEX conterrà la libreria condivisa
my_standalone_lib
e qualsiasi delle sue dipendenze non stabili (come descritto sopra).
apex {
..
vendor: true,
use_vndk_as_stable: true,
native_shared_libs: ["my_standalone_lib"],
..
}
Implementazioni HAL
Per definire un'implementazione HAL, fornisci i file binari e le librerie corrispondenti all'interno dell'APEX di un fornitore, come nei seguenti esempi:
Per incapsulare completamente l'implementazione HAL, l'APEX deve anche specificare qualsiasi frammenti VINTF e script di inizializzazione pertinenti.
Frammenti VINTF
I frammenti VINTF possono essere forniti dall'APEX di un fornitore quando i frammenti si trovano in
etc/vintf
dell'APEX.
Utilizza la proprietà prebuilts
per incorporare i frammenti VINTF nell'APEX.
apex {
..
vendor: true,
prebuilts: ["fragment.xml"],
..
}
prebuilt_etc {
name: "fragment.xml",
src: "fragment.xml",
sub_dir: "vintf",
}
Script di inizializzazione
Gli APEX possono includere script di inizializzazione in due modi: (A) mediante un file di testo predefinito all'interno
Payload APEX o (B) un normale script di inizializzazione in /vendor/etc
. Puoi impostare entrambi
per lo stesso APEX.
Script di inizializzazione in APEX:
prebuilt_etc {
name: "myinit.rc",
src: "myinit.rc"
}
apex {
..
vendor: true,
prebuilts: ["myinit.rc"],
..
}
Gli script di inizializzazione all'interno degli APEX possono avere solo definizioni di service
. Script di inizializzazione
negli APEX del fornitore possono avere anche istruzioni on <property>
.
Fai attenzione quando usi istruzioni on
. Poiché gli script di inizializzazione negli APEX vengono
analizzati ed eseguiti dopo l'attivazione degli APEX, alcuni eventi o proprietà
non possono essere utilizzate. Utilizza apex.all.ready=true
per attivare le azioni il prima possibile.
Firmware
Esempio:
Incorpora il firmware nell'APEX di un fornitore con il tipo di modulo prebuilt_firmware
, come
.
prebuilt_firmware {
name: "my.bin",
src: "path_to_prebuilt_firmware",
vendor: true,
}
apex {
..
vendor: true,
prebuilts: ["my.bin"], // installed inside APEX as /etc/firmware/my.bin
..
}
prebuilt_firmware
moduli sono installati in <apex name>/etc/firmware
dell'APEX. ueventd
scansiona /apex/*/etc/firmware
directory per
trovare i moduli firmware.
Il file_contexts
dell'APEX deve etichettare tutte le voci di payload del firmware
adeguata per garantire che ueventd
sia accessibile in fase di runtime.
in genere è sufficiente l'etichetta vendor_file
. Ad esempio:
(/.*)? u:object_r:vendor_file:s0
Moduli del kernel
Incorpora i moduli kernel in un APEX del fornitore come moduli predefiniti, come segue.
prebuilt_etc {
name: "my.ko",
src: "my.ko",
vendor: true,
sub_dir: "modules"
}
apex {
..
vendor: true,
prebuilts: ["my.ko"], // installed inside APEX as /etc/modules/my.ko
..
}
Il file_contexts
dell'APEX deve etichettare qualsiasi voce di payload del modulo kernel
correttamente. Ad esempio:
/etc/modules(/.*)? u:object_r:vendor_kernel_modules:s0
I moduli del kernel devono essere installati in modo esplicito. Lo script di inizializzazione dell'esempio seguente
nella partizione del fornitore mostra l'installazione tramite insmod
:
my_init.rc
:
on early-boot
insmod /apex/myapex/etc/modules/my.ko
..
Overlay di risorse di runtime
Esempio:
Incorporano overlay di risorse di runtime nell'APEX di un fornitore
utilizzando la proprietà rros
.
runtime_resource_overlay {
name: "my_rro",
soc_specific: true,
}
apex {
..
vendor: true,
rros: ["my_rro"], // installed inside APEX as /overlay/my_rro.apk
..
}
Altri file di configurazione
Gli APEX del fornitore supportano vari altri file di configurazione che in genere si trovano sul la partizione è preconfigurata all'interno degli APEX del fornitore e se ne stanno aggiungendo altre.
Esempi:
- XML di dichiarazione delle funzionalità
- I sensori includono XML integrato nell'APEX di un fornitore di sensori HAL
- File di configurazione di input
- Il touchscreen è configurato preparati in un APEX del fornitore che utilizza solo la configurazione
Funzionalità di sviluppo extra
Selezione APEX all'avvio
Esempio:
Gli sviluppatori possono anche installare più versioni degli APEX dei fornitori che condividono
con lo stesso nome e la stessa chiave APEX e poi scegliere la versione da attivare durante ogni
utilizzando sysprop permanenti. Per alcuni casi d'uso degli sviluppatori,
più semplice rispetto all'installazione di una nuova copia dell'APEX utilizzando adb install
.
Esempi di casi d'uso:
- Installa tre versioni dell'APEX del fornitore dell'HAL per le reti Wi-Fi: i team addetti al QA possono eseguire operazioni manuali o test automatici usando una versione, quindi riavvia in un'altra versione eseguire nuovamente i test e confrontare i risultati finali.
- Installa due versioni dell'APEX del fornitore HAL per la videocamera, attuale e sperimentale: i dogfood possono utilizzare la versione sperimentale senza scaricano e installano un file aggiuntivo in modo che possano tornare facilmente alla versione precedente.
Durante l'avvio, apexd
cerca i sysprop che seguono un formato specifico per
attivare la versione APEX corretta.
I formati previsti per la chiave di proprietà sono:
- Configurazione di avvio
- Utilizzato per impostare il valore predefinito, in
BoardConfig.mk
. androidboot.vendor.apex.<apex name>
- Utilizzato per impostare il valore predefinito, in
- sysprop permanente
- Consente di modificare il valore predefinito, impostato su un dispositivo già avviato.
- Esegue l'override del valore bootconfig, se presente.
persist.vendor.apex.<apex name>
Il valore della proprietà deve essere il nome file dell'APEX, che deve essere è stata attivata.
// Default version.
apex {
name: "com.oem.camera.hal.my_apex_default",
vendor: true,
..
}
// Non-default version.
apex {
name: "com.oem.camera.hal.my_apex_experimental",
vendor: true,
..
}
Anche la versione predefinita deve essere configurata utilizzando bootconfig in
BoardConfig.mk
:
# Example for APEX "com.oem.camera.hal" with the default above:
BOARD_BOOTCONFIG += \
androidboot.vendor.apex.com.oem.camera.hal=com.oem.camera.hal.my_apex_default
Dopo l'avvio del dispositivo, modifica la versione attivata impostando il valore sysprop permanente:
$ adb root;
$ adb shell setprop \
persist.vendor.apex.com.oem.camera.hal \
com.oem.camera.hal.my_apex_experimental;
$ adb reboot;
Se il dispositivo supporta l'aggiornamento di bootconfig dopo il flashing (ad esempio tramite comandi fastboot
oem
), e la modifica della proprietà bootconfig per l'istanza con installazione multipla
APEX cambia anche la versione attivata all'avvio.
Per i dispositivi di riferimento virtuali basati su Cuttlefish:
puoi utilizzare il comando --extra_bootconfig_args
per impostare la proprietà bootconfig
direttamente durante l'avvio. Ad esempio:
launch_cvd --noresume \
--extra_bootconfig_args "androidboot.vendor.apex.com.oem.camera.hal:=com.oem.camera.hal.my_apex_experimental";