La partición dinámica se implementa utilizando el módulo dm-linear device-mapper en el kernel de Linux. La super
contiene metadatos que enumeran los nombres y rangos de bloques de cada partición dinámica dentro de super
. Durante init
de la primera etapa, estos metadatos se analizan y validan, y se crean dispositivos de bloques virtuales para representar cada partición dinámica.
Al aplicar una OTA, las particiones dinámicas se crean, cambian de tamaño o eliminan automáticamente según sea necesario. Para los dispositivos A/B, hay dos copias de los metadatos y los cambios se aplican solo a la copia que representa la ranura de destino.
Debido a que las particiones dinámicas se implementan en el espacio de usuario, las particiones que necesita el gestor de arranque no se pueden hacer dinámicas. Por ejemplo, el gestor de arranque lee boot
, dtbo
y vbmeta
, por lo que deben permanecer como particiones físicas.
Cada partición dinámica puede pertenecer a un grupo de actualización . Estos grupos limitan el espacio máximo que pueden consumir las particiones de ese grupo. Por ejemplo, system
y vendor
pueden pertenecer a un grupo que restringe el tamaño total del system
y vendor
.
Implementar particiones dinámicas en nuevos dispositivos
Esta sección detalla cómo implementar particiones dinámicas en dispositivos nuevos que se inician con Android 10 y superior. Para actualizar dispositivos existentes, consulte Actualización de dispositivos Android .
Cambios de partición
Para dispositivos que se inician con Android 10, cree una partición llamada super
. La super
maneja las ranuras A/B internamente, por lo que los dispositivos A/B no necesitan particiones super_a
y super_b
separadas. Todas las particiones AOSP de solo lectura que no utiliza el gestor de arranque deben ser dinámicas y deben eliminarse de la tabla de particiones GUID (GPT). Las particiones específicas del proveedor no tienen que ser dinámicas y pueden colocarse en el GPT.
Para estimar el tamaño de super
, agregue los tamaños de las particiones que se eliminan del GPT. Para dispositivos A/B, esto debe incluir el tamaño de ambas ranuras. La Figura 1 muestra una tabla de particiones de ejemplo antes y después de la conversión a particiones dinámicas.
![Diseño de la tabla de particiones](https://source.android.google.cn/static/docs/core/ota/images/dynamic_partitions_table.png?authuser=5&hl=es)
Las particiones dinámicas admitidas son:
- Sistema
- Proveedor
- Producto
- Extensión del sistema
- ODM
Para dispositivos que se inician con Android 10, la opción de línea de comando del kernel androidboot.super_partition
debe estar vacía para que el comando sysprop ro.boot.super_partition
esté vacío.
Alineación de particiones
El módulo asignador de dispositivos puede funcionar con menos eficiencia si la super
no está alineada correctamente. La super
DEBE estar alineada con el tamaño mínimo de solicitud de E/S determinado por la capa de bloque. De forma predeterminada, el sistema de compilación (a través de lpmake
, que genera la imagen de la super
), asume que una alineación de 1 MiB es suficiente para cada partición dinámica. Sin embargo, los proveedores deben asegurarse de que la super
esté alineada correctamente.
Puede determinar el tamaño mínimo de solicitud de un dispositivo de bloque inspeccionando sysfs
. Por ejemplo:
# ls -l /dev/block/by-name/super lrwxrwxrwx 1 root root 16 1970-04-05 01:41 /dev/block/by-name/super -> /dev/block/sda17 # cat /sys/block/sda/queue/minimum_io_size 786432
Puede verificar la alineación de super
de manera similar:
# cat /sys/block/sda/sda17/alignment_offset
El desplazamiento de alineación DEBE ser 0.
Cambios en la configuración del dispositivo
Para habilitar la partición dinámica, agregue la siguiente marca en device.mk
:
PRODUCT_USE_DYNAMIC_PARTITIONS := true
Cambios de configuración de la placa
Debes establecer el tamaño de la super
:
BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>
En dispositivos A/B, el sistema de compilación genera un error si el tamaño total de las imágenes de partición dinámica es más de la mitad del tamaño de la super
.
Puede configurar la lista de particiones dinámicas de la siguiente manera. Para dispositivos que utilizan grupos de actualización, enumere los grupos en la variable BOARD_SUPER_PARTITION_GROUPS
. Cada nombre de grupo tiene entonces una variable BOARD_ group _SIZE
y BOARD_ group _PARTITION_LIST
. Para dispositivos A/B, el tamaño máximo de un grupo debe cubrir solo una ranura, ya que los nombres de los grupos tienen sufijos de ranura internamente.
Aquí hay un dispositivo de ejemplo que coloca todas las particiones en un grupo llamado example_dynamic_partitions
:
BOARD_SUPER_PARTITION_GROUPS := example_dynamic_partitions BOARD_EXAMPLE_DYNAMIC_PARTITIONS_SIZE := 6442450944 BOARD_EXAMPLE_DYNAMIC_PARTITIONS_PARTITION_LIST := system vendor product
A continuación se muestra un dispositivo de ejemplo que coloca los servicios del sistema y del producto en group_foo
, y vendor
, product
y odm
en group_bar
:
BOARD_SUPER_PARTITION_GROUPS := group_foo group_bar BOARD_GROUP_FOO_SIZE := 4831838208 BOARD_GROUP_FOO_PARTITION_LIST := system product_services BOARD_GROUP_BAR_SIZE := 1610612736 BOARD_GROUP_BAR_PARTITION_LIST := vendor product odm
- Para dispositivos de lanzamiento Virtual A/B, la suma de los tamaños máximos de todos los grupos debe ser como máximo:
BOARD_SUPER_PARTITION_SIZE
- gastos generales
Consulte Implementación de Virtual A/B . - Para dispositivos de lanzamiento A/B, la suma de los tamaños máximos de todos los grupos debe ser:
BOARD_SUPER_PARTITION_SIZE
/ 2 - gastos generales - Para dispositivos que no son A/B y dispositivos A/B modernizados, la suma de los tamaños máximos de todos los grupos debe ser:
BOARD_SUPER_PARTITION_SIZE
- gastos generales - En el momento de la compilación, la suma de los tamaños de las imágenes de cada partición en un grupo de actualización no debe exceder el tamaño máximo del grupo.
- Se requieren gastos generales en el cálculo para tener en cuenta los metadatos, las alineaciones, etc. Una sobrecarga razonable es de 4 MiB, pero puede elegir una sobrecarga mayor según lo necesite el dispositivo.
Tamaño de particiones dinámicas
Antes de las particiones dinámicas, los tamaños de las particiones se sobreasignaban para garantizar que tuvieran suficiente espacio para futuras actualizaciones. El tamaño real se tomó tal cual y la mayoría de las particiones de sólo lectura tenían cierta cantidad de espacio libre en su sistema de archivos. En las particiones dinámicas, ese espacio libre no se puede utilizar y podría usarse para hacer crecer las particiones durante una OTA. Es fundamental asegurarse de que las particiones no desperdicien espacio y se asignen al tamaño mínimo posible.
Para imágenes ext4 de solo lectura, el sistema de compilación asigna automáticamente el tamaño mínimo si no se especifica ningún tamaño de partición codificada. El sistema de compilación se ajusta a la imagen para que el sistema de archivos tenga el menor espacio posible sin utilizar. Esto garantiza que el dispositivo no desperdicie espacio que pueda usarse para OTA.
Además, las imágenes ext4 se pueden comprimir aún más habilitando la deduplicación a nivel de bloque. Para habilitar esto, use la siguiente configuración:
BOARD_EXT4_SHARE_DUP_BLOCKS := true
Si no es deseable la asignación automática del tamaño mínimo de una partición, existen dos formas de controlar el tamaño de la partición. Puede especificar una cantidad mínima de espacio libre con BOARD_ partition IMAGE_PARTITION_RESERVED_SIZE
, o puede especificar BOARD_ partition IMAGE_PARTITION_SIZE
para forzar las particiones dinámicas a un tamaño específico. Ninguno de estos se recomienda a menos que sea necesario.
Por ejemplo:
BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800
Esto obliga al sistema de archivos en product.img
a tener 50 MiB de espacio no utilizado.
Cambios del sistema como raíz
Los dispositivos que se inician con Android 10 no deben utilizar el sistema como raíz.
Los dispositivos con particiones dinámicas (ya sea que se inicien con particiones dinámicas o las actualicen) no deben usar el sistema como raíz. El kernel de Linux no puede interpretar la super
y, por lo tanto, no puede montar system
. system
ahora está montado mediante init
de primera etapa, que reside en el disco RAM.
No configure BOARD_BUILD_SYSTEM_ROOT_IMAGE
. En Android 10, el indicador BOARD_BUILD_SYSTEM_ROOT_IMAGE
solo se usa para diferenciar si el sistema está montado por el kernel o por el init
de primera etapa en ramdisk.
Establecer BOARD_BUILD_SYSTEM_ROOT_IMAGE
en true
provoca un error de compilación cuando PRODUCT_USE_DYNAMIC_PARTITIONS
también es true
.
Cuando BOARD_USES_RECOVERY_AS_BOOT
se establece en verdadero, la imagen de recuperación se crea como boot.img y contiene el disco ram de recuperación. Anteriormente, el gestor de arranque usaba el parámetro de línea de comando del kernel skip_initramfs
para decidir en qué modo arrancar. Para dispositivos con Android 10, el gestor de arranque NO DEBE pasar skip_initramfs
a la línea de comandos del kernel. En su lugar, el gestor de arranque debe pasar androidboot.force_normal_boot=1
para omitir la recuperación e iniciar Android normal. Los dispositivos que se inician con Android 12 o posterior deben usar bootconfig para pasar androidboot.force_normal_boot=1
.
Cambios de configuración de AVB
Cuando se utiliza Android Verified Boot 2.0 , si el dispositivo no utiliza descriptores de partición encadenados , no es necesario ningún cambio. Sin embargo, si se utilizan particiones encadenadas y una de las particiones verificadas es dinámica, entonces son necesarios cambios.
A continuación se muestra una configuración de ejemplo para un dispositivo que encadena vbmeta
para el system
y las particiones vendor
.
BOARD_AVB_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_SYSTEM_ALGORITHM := SHA256_RSA2048 BOARD_AVB_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_SYSTEM_ROLLBACK_INDEX_LOCATION := 1 BOARD_AVB_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VENDOR_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VENDOR_ROLLBACK_INDEX_LOCATION := 1
Con esta configuración, el gestor de arranque espera encontrar un pie de página vbmeta al final del system
y de las particiones vendor
. Debido a que estas particiones ya no son visibles para el gestor de arranque (residen en super
), se necesitan dos cambios.
- Agregue las particiones
vbmeta_system
yvbmeta_vendor
a la tabla de particiones del dispositivo. Para dispositivos A/B, agreguevbmeta_system_a
,vbmeta_system_b
,vbmeta_vendor_a
yvbmeta_vendor_b
. Si agrega una o más de estas particiones, deben tener el mismo tamaño que la particiónvbmeta
. - Cambie el nombre de los indicadores de configuración agregando
VBMETA_
y especifique a qué particiones se extiende el encadenamiento:BOARD_AVB_VBMETA_SYSTEM := system BOARD_AVB_VBMETA_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VBMETA_SYSTEM_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX_LOCATION := 1 BOARD_AVB_VBMETA_VENDOR := vendor BOARD_AVB_VBMETA_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VBMETA_VENDOR_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX_LOCATION := 1
Un dispositivo puede estar usando una, ambas o ninguna de estas particiones. Los cambios sólo son necesarios cuando se encadena a una partición lógica.
Cambios en el gestor de arranque AVB
Si el gestor de arranque tiene libavb integrado, incluya los siguientes parches:
- 818cf56740775446285466eda984acdd4baeac0 — "libavb: solo consulta los GUID de partición cuando la línea cmdline los necesita".
- 5abd6bc2578968d24406d834471adfd995a0c2e9 — "Permitir que la partición del sistema esté ausente"
- 9ba3b6613b4e5130fa01a11d984c6b5f0eb3af05 — "Reparar AvbSlotVerifyData->cmdline podría ser NULL"
Si utiliza particiones encadenadas, incluya un parche adicional:
- 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: admite blobs vbmeta al comienzo de la partición".
Cambios en la línea de comando del kernel
Se debe agregar un nuevo parámetro, androidboot.boot_devices
, a la línea de comando del kernel. Esto lo utiliza init
para habilitar los enlaces /dev/block/by-name
. Debería ser el componente de ruta del dispositivo al enlace simbólico de nombre subyacente creado por ueventd
, es decir, /dev/block/platform/ device-path /by-name/ partition-name
. Los dispositivos que se inician con Android 12 o posterior deben usar bootconfig para pasar androidboot.boot_devices
a init
.
Por ejemplo, si el enlace simbólico por nombre de la superpartición es /dev/block/platform/ soc/100000.ufshc /by-name/super
, puede agregar el parámetro de línea de comando en el archivo BoardConfig.mk de la siguiente manera:
BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshcPuede agregar el parámetro bootconfig en el archivo BoardConfig.mk de la siguiente manera:
BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc
cambios fstab
El árbol de dispositivos y las superposiciones del árbol de dispositivos no deben contener entradas fstab. Utilice un archivo fstab que será parte del disco ram.
Se deben realizar cambios en el archivo fstab para particiones lógicas:
- El campo fs_mgr flags debe incluir el indicador
logical
y el indicadorfirst_stage_mount
, introducido en Android 10, que indica que se va a montar una partición en la primera etapa. - Una partición puede especificar
avb= vbmeta partition name
como un indicadorfs_mgr
y luego la particiónvbmeta
especificada se inicializa medianteinit
de primera etapa antes de intentar montar cualquier dispositivo. - El campo
dev
debe ser el nombre de la partición.
Las siguientes entradas de fstab configuran el sistema, el proveedor y el producto como particiones lógicas siguiendo las reglas anteriores.
#<dev> <mnt_point> <type> <mnt_flags options> <fs_mgr_flags> system /system ext4 ro,barrier=1 wait,slotselect,avb=vbmeta,logical,first_stage_mount vendor /vendor ext4 ro,barrier=1 wait,slotselect,avb,logical,first_stage_mount product /product ext4 ro,barrier=1 wait,slotselect,avb,logical,first_stage_mount
Copie el archivo fstab en el disco RAM de la primera etapa.
Cambios en SELinux
El dispositivo de bloque de superpartición debe estar marcado con la etiqueta super_block_device
. Por ejemplo, si el enlace simbólico por nombre de la superpartición es /dev/block/platform/ soc/100000.ufshc /by-name/super
, agregue la siguiente línea a file_contexts
:
/dev/block/platform/soc/10000\.ufshc/by-name/super u:object_r:super_block_device:s0
arranque rápido
El gestor de arranque (o cualquier herramienta de actualización que no sea del espacio de usuario) no comprende las particiones dinámicas, por lo que no puede actualizarlas. Para solucionar esto, los dispositivos deben utilizar una implementación en el espacio de usuario del protocolo fastboot, llamada fastbootd.
Para obtener más información sobre cómo implementar fastbootd, consulte Mover Fastboot al espacio de usuario .
remontar adb
Para los desarrolladores que utilizan compilaciones eng o userdebug, adb remount
es extremadamente útil para una iteración rápida. Las particiones dinámicas plantean un problema para adb remount
porque ya no hay espacio libre dentro de cada sistema de archivos. Para solucionar esto, los dispositivos pueden habilitar superposiciones. Siempre que haya espacio libre dentro de la superpartición, adb remount
crea automáticamente una partición dinámica temporal y utiliza superposiciones para las escrituras. La partición temporal se llama scratch
, así que no utilice este nombre para otras particiones.
Para obtener más información sobre cómo habilitar overlayfs, consulte el archivo README de overlayfs en AOSP.
Actualizar dispositivos Android
Si actualiza un dispositivo a Android 10 y desea incluir compatibilidad con particiones dinámicas en la OTA, no necesita cambiar la tabla de particiones integrada. Se requiere alguna configuración adicional.
Cambios en la configuración del dispositivo
Para actualizar la partición dinámica, agregue las siguientes opciones en device.mk
:
PRODUCT_USE_DYNAMIC_PARTITIONS := true PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true
Cambios de configuración de la placa
Debes configurar las siguientes variables del tablero:
- Establezca
BOARD_SUPER_PARTITION_BLOCK_DEVICES
en la lista de dispositivos de bloque utilizados para almacenar extensiones de particiones dinámicas. Esta es la lista de nombres de particiones físicas existentes en el dispositivo. - Establezca
BOARD_SUPER_PARTITION_ partition _DEVICE_SIZE
en los tamaños de cada dispositivo de bloque enBOARD_SUPER_PARTITION_BLOCK_DEVICES
, respectivamente. Esta es la lista de tamaños de particiones físicas existentes en el dispositivo. Suele serBOARD_ partition IMAGE_PARTITION_SIZE
en configuraciones de placa existentes. - Desarmar
BOARD_ partition IMAGE_PARTITION_SIZE
existente para todas las particiones enBOARD_SUPER_PARTITION_BLOCK_DEVICES
. - Establezca
BOARD_SUPER_PARTITION_SIZE
en la suma deBOARD_SUPER_PARTITION_ partition _DEVICE_SIZE
. - Establezca
BOARD_SUPER_PARTITION_METADATA_DEVICE
en el dispositivo de bloque donde se almacenan los metadatos de la partición dinámica. Debe ser uno deBOARD_SUPER_PARTITION_BLOCK_DEVICES
. Generalmente, esto está configurado ensystem
. - Establezca
BOARD_SUPER_PARTITION_GROUPS
,BOARD_ group _SIZE
yBOARD_ group _PARTITION_LIST
, respectivamente. Consulte Cambios de configuración de la placa en dispositivos nuevos para obtener más detalles.
Por ejemplo, si el dispositivo ya tiene particiones de sistema y de proveedor y desea convertirlas en particiones dinámicas y agregar una nueva partición de producto durante la actualización, establezca esta configuración de placa:
BOARD_SUPER_PARTITION_BLOCK_DEVICES := system vendor BOARD_SUPER_PARTITION_METADATA_DEVICE := system # Rename BOARD_SYSTEMIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE. BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE := <size-in-bytes> # Rename BOARD_VENDORIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE := <size-in-bytes> # This is BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE + BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE BOARD_SUPER_PARTITION_SIZE := <size-in-bytes> # Configuration for dynamic partitions. For example: BOARD_SUPER_PARTITION_GROUPS := group_foo BOARD_GROUP_FOO_SIZE := <size-in-bytes> BOARD_GROUP_FOO_PARTITION_LIST := system vendor product
Cambios en SELinux
Los dispositivos del bloque de superpartición deben estar marcados con el atributo super_block_device_type
. Por ejemplo, si el dispositivo ya tiene particiones system
y vendor
, desea usarlas como dispositivos de bloque para almacenar extensiones de particiones dinámicas, y sus enlaces simbólicos por nombre están marcados como system_block_device
:
/dev/block/platform/soc/10000\.ufshc/by-name/system u:object_r:system_block_device:s0 /dev/block/platform/soc/10000\.ufshc/by-name/vendor u:object_r:system_block_device:s0
Luego, agregue la siguiente línea a device.te
:
typeattribute system_block_device super_block_device_type;
Para otras configuraciones, consulte Implementación de particiones dinámicas en dispositivos nuevos .
Para obtener más información sobre las actualizaciones de actualización, consulte OTA para dispositivos A/B sin particiones dinámicas .
Imágenes de fábrica
Para un dispositivo que se inicia con soporte para particiones dinámicas, evite utilizar el arranque rápido en el espacio de usuario para actualizar las imágenes de fábrica, ya que el arranque en el espacio de usuario es más lento que otros métodos de actualización.
Para solucionar este problema, make dist
ahora crea una imagen super.img
adicional que se puede actualizar directamente a la superpartición. Empaqueta automáticamente el contenido de las particiones lógicas, lo que significa que contiene system.img
, vendor.img
, etc., además de los metadatos de la super
. Esta imagen se puede enviar directamente a la super
sin necesidad de herramientas adicionales ni de usar fastbootd. Después de la compilación, super.img
se coloca en ${ANDROID_PRODUCT_OUT}
.
Para dispositivos A/B que se inician con particiones dinámicas, super.img
contiene imágenes en la ranura A. Después de mostrar la superimagen directamente, marque la ranura A como de arranque antes de reiniciar el dispositivo.
Para dispositivos modernizados, make dist
crea un conjunto de imágenes super_*.img
que se pueden actualizar directamente a las particiones físicas correspondientes. Por ejemplo, make dist
compilaciones super_system.img
y super_vendor.img
cuando BOARD_SUPER_PARTITION_BLOCK_DEVICES
sea el proveedor del sistema. Estas imágenes se colocan en la carpeta OTA en target_files.zip
.
Ajuste del dispositivo de almacenamiento del mapeador de dispositivos
La partición dinámica admite una serie de objetos asignadores de dispositivos no deterministas. Es posible que no todas se creen instancias como se esperaba, por lo que debe realizar un seguimiento de todos los montajes y actualizar las propiedades de Android de todas las particiones asociadas con sus dispositivos de almacenamiento subyacentes.
Un mecanismo dentro de init
rastrea los montajes y actualiza asincrónicamente las propiedades de Android. No se garantiza que la cantidad de tiempo que esto lleva esté dentro de un período específico, por lo que debe proporcionar suficiente tiempo para que reaccionen todos on property
. Las propiedades son dev.mnt.blk. <partition>
donde <partition>
es root
, system
, data
o vendor
, por ejemplo. Cada propiedad está asociada con el nombre del dispositivo de almacenamiento base, como se muestra en estos ejemplos:
taimen:/ % getprop | grep dev.mnt.blk [dev.mnt.blk.data]: [sda] [dev.mnt.blk.firmware]: [sde] [dev.mnt.blk.metadata]: [sde] [dev.mnt.blk.persist]: [sda] [dev.mnt.blk.root]: [dm-0] [dev.mnt.blk.vendor]: [dm-1] blueline:/ $ getprop | grep dev.mnt.blk [dev.mnt.blk.data]: [dm-4] [dev.mnt.blk.metadata]: [sda] [dev.mnt.blk.mnt.scratch]: [sda] [dev.mnt.blk.mnt.vendor.persist]: [sdf] [dev.mnt.blk.product]: [dm-2] [dev.mnt.blk.root]: [dm-0] [dev.mnt.blk.system_ext]: [dm-3] [dev.mnt.blk.vendor]: [dm-1] [dev.mnt.blk.vendor.firmware_mnt]: [sda]
El lenguaje init.rc
permite expandir las propiedades de Android como parte de las reglas, y la plataforma puede ajustar los dispositivos de almacenamiento según sea necesario con comandos como estos:
write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb 128 write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb 128
Una vez que comienza el procesamiento del comando en la segunda etapa init
, el epoll loop
se activa y los valores comienzan a actualizarse. Sin embargo, debido a que los desencadenadores de propiedades no están activos hasta late- init
, no se pueden usar en las etapas de arranque iniciales para manejar root
, system
o vendor
. Puede esperar que el valor predeterminado read_ahead_kb
del kernel sea suficiente hasta que los scripts init.rc
puedan anularse en early-fs
(cuando se inician varios demonios e instalaciones). Por lo tanto, Google recomienda utilizar la función on property
, junto con una propiedad controlada por init.rc
como sys.read_ahead_kb
, para controlar el tiempo de las operaciones y evitar condiciones de carrera, como en estos ejemplos:
on property:dev.mnt.blk.root=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.system=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.system}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.vendor=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.vendor}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.product=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.system_ext}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.oem=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.oem}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.data=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on early-fs: setprop sys.read_ahead_kb ${ro.read_ahead_kb.boot:-2048} on property:sys.boot_completed=1 setprop sys.read_ahead_kb ${ro.read_ahead_kb.bootcomplete:-128}