Fornitore APEX

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_libe 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:

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>
  • 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";