No Android 10, o sistema de arquivos raiz não é mais
incluído em ramdisk.img
e, em vez disso, integrado
system.img
(ou seja, system.img
é sempre criado como
se BOARD_BUILD_SYSTEM_ROOT_IMAGE
estiver definido). Dispositivos
com o Android 10:
- Usar um layout de sistema como partição raiz (aplicado automaticamente pelo criar sem opções para mudar o comportamento).
- É necessário usar um ramdisk, que é necessário para dm linear.
- É preciso definir
BOARD_BUILD_SYSTEM_ROOT_IMAGE
comofalse
. Esta configuração é usada apenas para diferenciar dispositivos que usam ramdisk e dispositivos que não usam ramdisk e montamsystem.img
diretamente).
O significado de uma configuração de sistema como raiz é diferente no Android 9 e
Android 10 Em um sistema Android 9, como raiz,
definida, BOARD_BUILD_SYSTEM_ROOT_IMAGE
é definida como
true
, que força o build a mesclar o sistema de arquivos raiz na
system.img
e, em seguida, ativar system.img
como o arquivo raiz.
do Compute Engine (rootfs). Esta configuração é obrigatória para dispositivos
lançados com o Android 9, mas é opcional para dispositivos que passam por upgrade para
Android 9 e para dispositivos com versões anteriores do Android. Em um ambiente
10 configuração do sistema como raiz, o build sempre
mescla $TARGET_SYSTEM_OUT
e $TARGET_ROOT_OUT
em
system.img
essa configuração é o comportamento padrão para todos os dispositivos
com o Android 10.
O Android 10 faz mais mudanças no suporte partições dinâmicas, um sistema de particionamento de espaço do usuário que permite atualizações over the air (OTA) para criar, redimensionar ou destruir partições. Como parte dessa mudança, o Linux o kernel não consegue mais montar a partição lógica do sistema em dispositivos em execução Android 10, portanto, essa operação é processada pela primeira inicialização do estágio.
As seções a seguir descrevem os requisitos do sistema como raiz para OTAs somente do sistema, orientações sobre como atualizar dispositivos para usar o sistema como raiz (incluindo alterações de layout de partição e requisitos de kernel dm-verity). Para detalhes sobre as mudanças no ramdisk, consulte Ramdisk Partições.
Sobre OTAs somente no sistema
OTAs somente do sistema, que permitem que as versões do Android sejam atualizadas
system.img
e product.img
sem mudar as outras
as partições precisam de um layout
de sistema como partição raiz. Todos os dispositivos com Android
10 precisa usar um layout de sistema como partição raiz para
ativar OTAs somente no sistema.
- Dispositivos A/B, que montam a partição
system
como rootfs. já usam o sistema como raiz e não exigem alterações para dar suporte a OTAs do sistema. - Dispositivos não A/B, que montam a partição
system
em/system
precisa ser atualizado para usar um layout de partição raiz para dar suporte a atualizações OTA do sistema.
Para detalhes sobre dispositivos A/B e não A/B, consulte Atualizações do Sistema A/B (Contínuas).
Usar sobreposição de fornecedor (<=AOSP 14)
A sobreposição de fornecedor permite sobrepor mudanças no vendor
na inicialização do dispositivo. Uma sobreposição de fornecedor é um conjunto de módulos de fornecedor em
da partição product
que são sobrepostas no vendor
partição quando o dispositivo é inicializado, substituindo e adicionando aos módulos existentes.
Quando o dispositivo é inicializado, o processo init
conclui a primeira
montagem de cenário e lê as propriedades padrão. Depois, pesquisa
/product/vendor_overlay/<target_vendor_version>
e suportes
cada subdiretório no diretório de partição vendor
correspondente,
se as seguintes condições forem atendidas:
/vendor/<overlay_dir>
já existe./product/vendor_overlay/<target_vendor_version>/<overlay_dir>
tem o mesmo contexto de arquivo que/vendor/<overlay_dir>
.init
tem permissão para ser montado no contexto do arquivo de/vendor/<overlay_dir>
.
Implementar a sobreposição de fornecedores
Instalar os arquivos de sobreposição de fornecedores em
/product/vendor_overlay/<target_vendor_version>
: Esses arquivos
sobrepor a partição vendor
quando o dispositivo for inicializado, substituindo os arquivos
com o mesmo nome e adicionar novos arquivos. A sobreposição do fornecedor não pode remover os arquivos
da partição vendor
.
Os arquivos de sobreposição do fornecedor precisam ter o mesmo contexto de arquivo que os arquivos de destino
que eles vão substituir na partição vendor
. Por padrão, os arquivos na pasta
Diretório /product/vendor_overlay/<target_vendor_version>
têm o contexto vendor_file
. Se houver incompatibilidades de contexto de arquivo
entre os arquivos de sobreposição do fornecedor e os arquivos que eles substituem, especifique no
sepolicy específica do dispositivo. O contexto do arquivo é definido no nível do diretório. Se o
o contexto do arquivo de um diretório de sobreposição de fornecedor não corresponde ao diretório de destino,
e o contexto de arquivo correto não for especificado na sepolicy específica do dispositivo,
que o diretório de sobreposição do fornecedor não seja sobreposto ao diretório de destino.
Para usar a sobreposição de fornecedor, o kernel precisa ativar a OverlayFS configurando
CONFIG_OVERLAY_FS=y
: Além disso, o kernel deve ser mesclado
kernel comum 4.4 ou posterior ou corrigido com "overlayfs:
override_creds=off option bypass creator_cred"
.
Exemplo de implementação de sobreposição do fornecedor
Este procedimento demonstra a implementação de uma sobreposição de fornecedor que se sobrepõe à
diretórios /vendor/lib/*
, /vendor/etc/*
e
/vendor/app/*
-
Adicione arquivos de fornecedores pré-criados no
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
-
Instale os arquivos de fornecedor pré-criados no
product/vendor_overlay
pol.device/google/device/device.mk
:PRODUCT_COPY_FILES += \ $(call find-copy-subdir-files,*,device/google/device/vendor_overlay,$(TARGET_COPY_OUT_PRODUCT)/vendor_overlay)
-
Defina contextos de arquivo se os arquivos de partição
vendor
de destino tenham contextos diferentes devendor_file
. Devido ao/vendor/lib/*
usa o contextovendor_file
, esse não inclua esse diretório.Adicione o seguinte 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
-
Permitir que o processo
init
monte a sobreposição do fornecedor no arquivo contextos diferentes devendor_file
. Como oinit
processo já tem permissão para montar no contextovendor_file
, este exemplo não define a política paravendor_file
.Adicione o seguinte a
device/google/device-sepolicy/public/init.te
:allow init vendor_configs_file:dir mounton; allow init vendor_app_file:dir mounton;
Validar sobreposição do fornecedor
Para validar a configuração da sobreposição do fornecedor, adicione arquivos ao
/product/vendor_overlay/<target_vendor_version>/<overlay_dir>
e verificar se os arquivos estão sobrepostos nos arquivos
/vendor/<overlay_dir>
.
Para builds userdebug
, há um módulo de teste para Atest:
$ atest -v fs_mgr_vendor_overlay_test
Atualizar para sistema como raiz
Para atualizar dispositivos não A/B para usar o sistema como raiz, atualize o
de particionamento para boot.img
e system.img
, definido
até o dm-verity e remova todas as dependências de inicialização da raiz específica do dispositivo.
do Google Cloud.
Atualizar partições
Ao contrário de dispositivos A/B que reutilizam /boot
como o
recovery,
Os dispositivos não A/B precisam manter a partição /recovery
separados porque não têm a partição de slot de fallback (por exemplo,
de boot_a
a boot_b
). Se /recovery
for
removido em um dispositivo não A/B e semelhante ao esquema A/B, o modo de recuperação
pode ser interrompido durante uma atualização com falha na partição /boot
. Para
Por isso, a partição /recovery
precisa ser uma
separada de /boot
para dispositivos não A/B, o que implica
que a imagem de recuperação continue a ser atualizada de forma adiada (que
é o mesmo que em dispositivos com Android 8.1.0 ou versões anteriores).
A tabela a seguir lista as diferenças da partição de imagens para dispositivos não A/B antes e depois do Android 9.
Imagem | Ramdisk (antes das 9) | Sistema como raiz (após 9) |
---|---|---|
boot.img |
Contém um kernel e um ramdisk.img :
ramdisk.img -/ - init.rc - init - etc -> /system/etc - system/ (mount point) - vendor/ (mount point) - odm/ (mount point) ... |
Contém apenas um kernel de inicialização normal. |
recovery.img |
Contém um kernel de recuperação e um código de recuperação
ramdisk.img : |
|
system.img |
Contém o seguinte:
system.img -/ - bin/ - etc - vendor -> /vendor - ... |
Contém o conteúdo mesclado do original system.img e
ramdisk.img :
system.img -/ - init.rc - init - etc -> /system/etc - system/ - bin/ - etc/ - vendor -> /vendor - ... - vendor/ (mount point) - odm/ (mount point) ... |
As partições não mudam. tanto no ramdisk quanto no uso do sistema como raiz o seguinte esquema de partição:
/boot
/system
/system
/recovery
/vendor
etc.
Configurar dm-verity
No sistema como raiz, o kernel precisa ativar system.img
em
/
(ponto de montagem) com
dm-verity. O AOSP oferece suporte aos seguintes dm-verity:
implementações para system.img
.
vboot 1.0
Para a vboot 1.0, o kernel precisa analisar
Específico para Android
metadados em
/system
e converter para
dm-verity params para configurar o dm-verity (requer
esses patches de kernel).
O exemplo a seguir mostra as configurações relacionadas a dm-verity para sistema como raiz em
linha de comando do 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
Para vboot 2.0
(AVB), é necessário que o carregador de inicialização se integre
external/avb/libavb, que analisa o
Descritor de hashtree para /system
, converte
para
dm-verity params e transmite os parâmetros para o
pela linha de comando do kernel. (Descritores de hashtree de /system
pode estar no /vbmeta
ou no próprio /system
.
O vboot 2.0 requer os seguintes patches de kernel:
- https://android-review.googlesource.com/#/c/kernel/common/+/158491/
- patches do kernel 4.4, patches do kernel 4.9 etc.
O exemplo a seguir mostra as configurações relacionadas a dm-verity para sistema como raiz em linha de comando do 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"
Usar pastas raiz específicas do dispositivo
Com o sistema como raiz, depois da imagem genérica do sistema
(GSI) é atualizada no dispositivo (e antes da execução).
testes do conjunto de testes de fornecedor), todos
Pastas raiz específicas do dispositivo adicionadas com BOARD_ROOT_EXTRA_FOLDERS
sumiram porque todo o conteúdo do diretório raiz foi substituído por
a GSI do sistema como raiz. A remoção dessas pastas pode fazer com que o dispositivo
se tornar não inicializável se existir uma dependência nas pastas raiz específicas do dispositivo
Por exemplo, são usados como pontos de montagem.
Para evitar esse problema, não use BOARD_ROOT_EXTRA_FOLDERS
para
adicionar pastas raiz específicas do dispositivo. Se for necessário especificar o suporte específico do dispositivo
pontos, use /mnt/vendor/<mount point>
(adicionado a esses
listas de mudanças). Esses pontos de montagem
específicos do fornecedor podem ser
especificados diretamente na árvore de dispositivos fstab
(para o estágio
mount) e o arquivo /vendor/etc/fstab.{ro.hardware}
sem
configuração adicional (já que o fs_mgr
as cria em
/mnt/vendor/*
automaticamente).