Layout di partizione

In Android 10, il file system radice non è più incluso in ramdisk.img, che viene invece unito system.img (ossia, system.img viene sempre creato come se è stato impostato BOARD_BUILD_SYSTEM_ROOT_IMAGE). Dispositivi lancio con Android 10:

  • Utilizza un layout di partizione system-as-root (applicato automaticamente dal build senza opzioni per modificarne il comportamento).
  • Devi utilizzare un ramdisk, obbligatorio per dm-linear.
  • BOARD_BUILD_SYSTEM_ROOT_IMAGE deve essere impostato su false. Questa impostazione viene utilizzata solo per distinguere i dispositivi che usano un ramdisk e i dispositivi che non usano un ramdisk (ma montano system.img direttamente).

Il significato di una configurazione system-as-root è diverso tra Android 9 e Android 10. In un sistema Android 9 come root configurazione, BOARD_BUILD_SYSTEM_ROOT_IMAGE è impostato su true, che forza l'unione del file system radice nella build system.img quindi monta system.img come file principale (rootfs). Questa configurazione è obbligatoria per i dispositivi l'avvio con Android 9, ma è facoltativo per i dispositivi che eseguono l'upgrade a Android 9 e per dispositivi con versioni precedenti di Android. Su un dispositivo Android configurazione system-as-root, la build unisce $TARGET_SYSTEM_OUT e $TARGET_ROOT_OUT in system.img; questa configurazione è il comportamento predefinito per tutti i dispositivi con Android 10.

Android 10 apporta ulteriori modifiche al supporto partizioni dinamiche, un sistema di partizionamento dello spazio utente che consente gli aggiornamenti over-the-air (OTA) per per creare, ridimensionare o distruggere le partizioni. Nell'ambito di questa modifica, il kernel non può più montare la partizione del sistema logica sui dispositivi in esecuzione Android 10, quindi questa operazione viene gestita dal primo init dello stage.

Le seguenti sezioni descrivono i requisiti system-as-root per OTA solo per sistemi, forniscono indicazioni su come aggiornare i dispositivi in modo che utilizzino system-as-root (incluse le modifiche al layout delle partizioni e i requisiti del kernel dm-verity). Per sulle modifiche a ramdisk, vedi Disco rame Partizioni.

Informazioni sulle OTA riservate al sistema

OTA disponibili solo per il sistema, che consentono l'aggiornamento delle release di Android system.img e product.img senza modificare l'altro richiedono un layout di partizione system-as-root. Tutti i dispositivi con Android 10 devono utilizzare un layout di partizione system-as-root attivare le agenzie di viaggi online solo a livello di sistema.

  • I dispositivi A/B, che montano la partizione system come rootf, utilizzano già system-as-root e non richiedono modifiche per supportare le OTA del sistema.
  • I dispositivi non A/B, che montano la partizione system su /system, deve essere aggiornato per utilizzare un layout di partizione system-as-root per supportare le OTA del sistema.

Per maggiori dettagli sui dispositivi A/B e non A/B, consulta Aggiornamenti di sistema A/B (senza interruzioni).

Utilizza overlay del fornitore (<=AOSP 14)

L'overlay del fornitore ti consente di sovrapporre le modifiche a vendor al momento dell'avvio del dispositivo. Un overlay del fornitore è un insieme di moduli del fornitore la partizione product che viene sovrapposta a vendor all'avvio del dispositivo, sostituendo e aggiungendo ai moduli esistenti.

All'avvio del dispositivo, il processo init completa il primo montaggio dello stage e legge le proprietà predefinite. Poi cerca /product/vendor_overlay/<target_vendor_version> e supporti ogni sottodirectory nella directory di partizione vendor corrispondente, se vengono soddisfatte le seguenti condizioni:

  • /vendor/<overlay_dir> esiste.
  • /product/vendor_overlay/<target_vendor_version>/<overlay_dir> ha lo stesso contesto dei file di /vendor/<overlay_dir>.
  • init può essere montato nel contesto del file di /vendor/<overlay_dir>.

Implementa l'overlay del fornitore

Installa i file di overlay del fornitore in /product/vendor_overlay/<target_vendor_version>. Questi file sovrapponi la partizione vendor all'avvio del dispositivo, sostituendo i file con lo stesso nome e aggiungere nuovi file. L'overlay del fornitore non può rimuovere i file dalla partizione vendor.

I file overlay del fornitore devono avere lo stesso contesto dei file dei file di destinazione sostituiscono nella partizione vendor. Per impostazione predefinita, i file nel Directory /product/vendor_overlay/<target_vendor_version> abbiamo il contesto vendor_file. Il contesto dei file non corrisponde tra i file overlay del fornitore e i file che sostituiscono, specifica che specifiche del dispositivo. Il contesto del file è impostato a livello di directory. Se il contesto del file di una directory overlay del fornitore non corrisponde alla directory di destinazione e il contesto del file corretto non sia specificato nel criterio di sicurezza specifico per dispositivo. la directory overlay del fornitore non è sovrapposta alla directory di destinazione.

Per utilizzare l'overlay del fornitore, il kernel deve abilitare OverlayFS impostando CONFIG_OVERLAY_FS=y. Inoltre, il kernel deve essere unito kernel comune 4.4 o successivo, o con patch applicata con "overlayfs: override_creds=off option bypass creator_cred".

Esempio di implementazione dell'overlay del fornitore

Questa procedura illustra l'implementazione di un overlay del fornitore che si sovrappone alla directory /vendor/lib/*, /vendor/etc/* e /vendor/app/*.

  1. Aggiungi file predefiniti del fornitore device/<vendor>/<target>/vendor_overlay/<target_vendor_version>/:

    device/google/device/vendor_overlay/28/lib/libfoo.so
device/google/device/vendor_overlay/28/lib/libbar.so
device/google/device/vendor_overlay/28/etc/baz.xml
device/google/device/vendor_overlay/28/app/qux.apk

  2. Installa i file predefiniti del fornitore product/vendor_overlay pollici device/google/device/device.mk:

    PRODUCT_COPY_FILES += \
    $(call find-copy-subdir-files,*,device/google/device/vendor_overlay,$(TARGET_COPY_OUT_PRODUCT)/vendor_overlay)

  3. Definisci i contesti dei file se i file di partizione vendor di destinazione contesti diversi da vendor_file. Poiché /vendor/lib/* utilizza il contesto vendor_file, questo esempio non include quella directory.

    Aggiungi quanto segue a device/google/device-sepolicy/private/file_contexts:

    /(product|system/product)/vendor_overlay/[0-9]+/etc(/.*)?   u:object_r:vendor_configs_file:s0
/(product|system/product)/vendor_overlay/[0-9]+/app(/.*)?   u:object_r:vendor_app_file:s0

  4. Consenti al processo init di montare l'overlay del fornitore sul file contesti diversi da vendor_file. Poiché init processo dispone già dell'autorizzazione per essere montato nel contesto vendor_file, in questo esempio non viene definito il criterio per vendor_file.

    Aggiungi quanto segue a device/google/device-sepolicy/public/init.te:

    allow init vendor_configs_file:dir mounton;
allow init vendor_app_file:dir mounton;

Convalida overlay del fornitore

Per convalidare la configurazione dell'overlay del fornitore, aggiungi i file in /product/vendor_overlay/<target_vendor_version>/<overlay_dir> e controllare se i file sono sovrapposti ai file in /vendor/<overlay_dir>.

Per le build userdebug, è disponibile un modulo di test per Atest:

$ atest -v fs_mgr_vendor_overlay_test

Aggiorna a system-as-root

Per aggiornare i dispositivi non A/B in modo che utilizzino system-as-root, devi aggiornare il schema di partizionamento per boot.img e system.img, impostato di dm-verity e rimuovere eventuali dipendenze di avvio dalla directory radice specifica del dispositivo cartelle.

Aggiorna partizioni

A differenza dei dispositivi A/B che ripropongono /boot come la partizione recovery, I dispositivi non A/B devono mantenere la partizione /recovery separati perché non hanno la partizione degli slot di fallback (ad esempio, dalle ore boot_a alle ore boot_b). Se /recovery è rimossa su un dispositivo non A/B e resa simile allo schema A/B, modalità di ripristino potrebbero interrompersi durante un aggiornamento non riuscito della partizione /boot. Per Per questo motivo, la partizione /recovery deve essere una separata da /boot per i dispositivi non A/B, il che implica che l'immagine di ripristino continui a essere aggiornata in modo differito (ovvero è lo stesso dei dispositivi con Android 8.1.0 o versioni precedenti).

La tabella seguente elenca le differenze di partizione delle immagini per i dispositivi non A/B prima e dopo Android 9.

Immagine Ramdisk (prima delle 9) System-as-root (dopo le ore 9)
boot.img Contiene un kernel e un ramdisk.img: 
ramdisk.img
  -/
    - init.rc
    - init
    - etc -> /system/etc
    - system/ (mount point)
    - vendor/ (mount point)
    - odm/ (mount point)
    ...
 Contiene solo un kernel di avvio normale.
recovery.img Contiene un kernel di ripristino e un ramdisk.img.
system.img Contiene quanto segue: 
system.img
  -/
    - bin/
    - etc
    - vendor -> /vendor
    - ...
 Contiene i contenuti uniti della versione originale di system.img e ramdisk.img: 
system.img
  -/
    - init.rc
    - init
    - etc -> /system/etc
    - system/
      - bin/
      - etc/
      - vendor -> /vendor
      - ...
    - vendor/ (mount point)
    - odm/ (mount point)
    ...

Le partizioni non cambiano; sia ramdisk che system-as-root il seguente schema di partizione:

  • /boot
  • /system
  • /system
  • /recovery
  • /vendor e così via.

Configura DM-Verity

In system-as-root, il kernel deve montare system.img in / (punto di montaggio) con versione dm. AOSP supporta la seguente verifica dm-verity implementazioni per system.img.

Vboot 1.0

Per vboot 1.0, il kernel deve analizzare Specifici per Android metadata su /system, quindi converti in Parametri dm-verity per configurare dm-verity (richiede queste patch del kernel). L'esempio seguente mostra le impostazioni relative a dm-verity per system-as-root in riga di comando del kernel: 

ro root=/dev/dm-0 rootwait skip_initramfs init=/init
dm="system none ro,0 1 android-verity /dev/sda34"
veritykeyid=id:7e4333f9bba00adfe0ede979e28ed1920492b40f

Vboot 2.0

Per vboot 2.0 (AVB), il bootloader deve integrare external/avb/libavb, che poi analizza il valore descrittore hashtree per /system, converte per parametri di verifica dm-verity e, infine, passa ai parametri tramite la riga di comando del kernel. (Descrittori Hashtree di /system potrebbe essere su /vbmeta o su /system stesso.

vboot 2.0 richiede le seguenti patch del kernel:

di Gemini Advanced.

L'esempio seguente mostra le impostazioni relative a dm-verity per system-as-root in riga di comando del kernel: 

ro root=/dev/dm-0 rootwait  skip_initramfs init=/init

dm="1 vroot none ro 1,0 5159992 verity 1
PARTUUID=00000016-0000-0000-0000-000000000000
PARTUUID=00000016-0000-0000-0000-000000000000 4096 4096 644999 644999
sha1 d80b4a8be3b58a8ab86fad1b498640892d4843a2
8d08feed2f55c418fb63447fec0d32b1b107e42c 10 restart_on_corruption
ignore_zero_blocks use_fec_from_device
PARTUUID=00000016-0000-0000-0000-000000000000 fec_roots 2 fec_blocks
650080 fec_start 650080"

Utilizza cartelle principali specifiche del dispositivo

Con system-as-root, dopo la generica immagine di sistema (GSI) viene lampeggiata sul dispositivo (e prima dell'esecuzione) Test Suite per i fornitori), qualsiasi cartelle principali specifiche del dispositivo aggiunte con BOARD_ROOT_EXTRA_FOLDERS perché l'intero contenuto della directory root è stato sostituito il GSI system-as-root. La rimozione di queste cartelle potrebbe causare diventano non avviabili se esiste una dipendenza dalle cartelle principali specifiche del dispositivo (ad esempio, vengono utilizzati come punti di montaggio).

Per evitare questo problema, non usare BOARD_ROOT_EXTRA_FOLDERS per Aggiungere cartelle principali specifiche del dispositivo. Se devi specificare un supporto specifico per il dispositivo usa /mnt/vendor/<mount point> (aggiunto in elenchi delle modifiche). Questi punti di montaggio specifici del fornitore possono specificati direttamente nella struttura di dispositivi fstab (per la prima fase montaggio) e il file /vendor/etc/fstab.{ro.hardware} senza configurazione aggiuntiva (poiché fs_mgr li crea in /mnt/vendor/* automaticamente).