Реализация динамических разделов

Динамическое секционирование реализовано с помощью модуля dm-linear device-mapper в ядре Linux. super содержит метаданные, в которых перечислены имена и диапазоны блоков каждого динамического раздела в super . Во время первого этапа init эти метаданные анализируются и проверяются, и создаются виртуальные блочные устройства для представления каждого динамического раздела.

При применении OTA динамические разделы автоматически создаются, изменяются или удаляются по мере необходимости. Для устройств A/B существует две копии метаданных, и изменения применяются только к копии, представляющей целевой слот.

Поскольку динамические разделы реализованы в пользовательском пространстве, разделы, необходимые загрузчику, не могут быть сделаны динамическими. Например, boot , dtbo и vbmeta читаются загрузчиком и поэтому должны оставаться физическими разделами.

Каждый динамический раздел может принадлежать группе обновлений . Эти группы ограничивают максимальное пространство, которое могут занимать разделы в этой группе. Например, system и vendor могут принадлежать к группе, которая ограничивает общий размер system и vendor .

Реализация динамических разделов на новых устройствах

В этом разделе подробно описано, как реализовать динамические разделы на новых устройствах, запускаемых с Android 10 и более поздних версий. Чтобы обновить существующие устройства, см. Обновление устройств Android .

Изменения раздела

Для устройств, запускаемых с Android 10, создайте раздел под названием super . super обрабатывает слоты A/B внутри себя, поэтому устройствам A/B не нужны отдельные разделы super_a и super_b . Все разделы AOSP только для чтения, которые не используются загрузчиком, должны быть динамическими и должны быть удалены из таблицы разделов GUID (GPT). Разделы, зависящие от поставщика, не обязательно должны быть динамическими и могут быть помещены в GPT.

Примечание. Избегайте размещения userdata или любого другого постоянного раздела для чтения и записи внутри super .

Чтобы оценить размер super , добавьте размеры разделов, удаляемых из GPT. Для устройств A/B сюда следует включать размер обоих слотов. На рис. 1 показан пример таблицы разделов до и после преобразования в динамические разделы.

Рис. 1. Новая структура таблицы физических разделов при преобразовании в динамические разделы.

Поддерживаемые динамические разделы:

• Система
• Продавец
• Продукт
• Системный доб.
• ОДМ

Для устройств, запускаемых с Android 10, параметр командной строки ядра androidboot.super_partition должен быть пустым, чтобы команда sysprop ro.boot.super_partition была пустой.

Выравнивание разделов

Модуль сопоставления устройств может работать менее эффективно, если super не выровнен должным образом. super ДОЛЖЕН быть выровнен по минимальному размеру запроса ввода-вывода , определенному уровнем блока. По умолчанию система сборки (через lpmake , которая генерирует образ super ) предполагает, что выравнивания в 1 МБ достаточно для каждого динамического раздела. Однако поставщики должны убедиться, что super правильно выровнен.

Вы можете определить минимальный размер запроса блочного устройства, проверив sysfs . Например:

# 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

Вы можете проверить выравнивание super аналогичным образом:

# cat /sys/block/sda/sda17/alignment_offset

Смещение выравнивания ДОЛЖНО быть равно 0.

Изменения конфигурации устройства

Чтобы включить динамическое секционирование, добавьте следующий флаг в device.mk :

PRODUCT_USE_DYNAMIC_PARTITIONS := true

Изменения конфигурации платы

Вам необходимо установить размер super :

BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

На устройствах A/B система сборки выдает ошибку, если общий размер образов динамических разделов превышает половину размера super .

Вы можете настроить список динамических разделов следующим образом. Для устройств, использующих группы обновлений, перечислите группы в переменной BOARD_SUPER_PARTITION_GROUPS . Каждое имя группы затем имеет переменную BOARD_ group _SIZE и BOARD_ group _PARTITION_LIST . Для устройств A/B максимальный размер группы должен охватывать только один слот, поскольку имена групп имеют внутренний суффикс слота.

Вот пример устройства, которое помещает все разделы в группу под названием 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

Вот пример устройства, которое помещает сервисы системы и продукта в group_foo , а vendor , product и odm в 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

Примечание. Избегайте выбора имен, которые могут конфликтовать с переменными сборки, например super и super_partition . Для удобства чтения выберите такие имена, как foo_dp , foo_dynamic_partitions , foo_dp_group , super_foo или group_foo (где foo — это имя стороны, которая обновляет данную группу). Например, group_OEM или group_VENDOR .

Примечание. На вашем устройстве может быть одна или несколько групп обновлений.

• Для устройств запуска Virtual A/B сумма максимальных размеров всех групп не должна превышать:
  BOARD_SUPER_PARTITION_SIZE — накладные расходы
  См. Реализация Virtual A/B .
• Для устройств запуска A/B сумма максимальных размеров всех групп должна составлять:
  BOARD_SUPER_PARTITION_SIZE /2 — накладные расходы
• Для устройств, отличных от A/B, и модернизированных устройств A/B сумма максимальных размеров всех групп должна составлять:
  BOARD_SUPER_PARTITION_SIZE — накладные расходы
• Во время сборки сумма размеров образов каждого раздела в группе обновления не должна превышать максимальный размер группы.
• При вычислениях требуются накладные расходы для учета метаданных, выравниваний и т. д. Разумные накладные расходы составляют 4 МБ, но вы можете выбрать более крупные накладные расходы, если это необходимо устройству.

Размер динамических разделов

До появления динамических разделов размеры разделов выделялись слишком много, чтобы обеспечить достаточно места для будущих обновлений. Фактический размер был взят как есть, и большинство разделов, доступных только для чтения, имели некоторое количество свободного места в файловой системе. В динамических разделах это свободное пространство непригодно для использования и может быть использовано для увеличения разделов во время OTA. Крайне важно убедиться, что разделы не тратят зря пространство и им выделяется минимально возможный размер.

Для образов ext4, доступных только для чтения, система сборки автоматически выделяет минимальный размер, если не указан жестко закодированный размер раздела. Система сборки подгоняет образ так, чтобы в файловой системе оставалось как можно меньше неиспользуемого пространства. Это гарантирует, что устройство не будет тратить место, которое можно использовать для OTA.

Кроме того, образы ext4 можно дополнительно сжать, включив дедупликацию на уровне блоков. Чтобы включить это, используйте следующую конфигурацию:

BOARD_EXT4_SHARE_DUP_BLOCKS := true

Если автоматическое выделение минимального размера раздела нежелательно, существует два способа управления размером раздела. Вы можете указать минимальный объем свободного места с помощью BOARD_ partition IMAGE_PARTITION_RESERVED_SIZE или указать BOARD_ partition IMAGE_PARTITION_SIZE чтобы принудительно установить динамические разделы определенного размера. Ни один из этих способов не рекомендуется без необходимости.

Например:

BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800

Это приводит к тому, что файловая система в product.img будет иметь 50 МБ неиспользуемого пространства.

Примечание. Система сборки лучше всего подходит только для образов файловой системы ext4 и только для образов, созданных в результате сборки. Для готовых изображений или изображений, использующих другие файловые системы, важно вручную убедиться, что файловая система не тратит зря дисковое пространство.

Изменения в системе как root

Устройства, запускаемые с Android 10, не должны использовать систему с правами root.

Устройства с динамическими разделами (независимо от того, запускаются ли они с динамическими разделами или модифицируются ими) не должны использовать систему с правами root. Ядро Linux не может интерпретировать super и поэтому не может смонтировать саму system . system теперь монтируется с помощью init первого этапа, который находится на виртуальном диске.

Не устанавливайте BOARD_BUILD_SYSTEM_ROOT_IMAGE . В Android 10 флаг BOARD_BUILD_SYSTEM_ROOT_IMAGE используется только для того, чтобы различать, монтируется ли система ядром или init первого этапа на виртуальном диске.

Установка для BOARD_BUILD_SYSTEM_ROOT_IMAGE значения true приводит к ошибке сборки, если PRODUCT_USE_DYNAMIC_PARTITIONS также имеет true .

Если для BOARD_USES_RECOVERY_AS_BOOT установлено значение true, образ восстановления создается как boot.img, содержащий виртуальный диск восстановления. Раньше загрузчик использовал параметр командной строки ядра skip_initramfs , чтобы решить, в каком режиме загружаться. Для устройств Android 10 загрузчик НЕ ДОЛЖЕН передавать skip_initramfs в командную строку ядра. Вместо этого загрузчик должен передать androidboot.force_normal_boot=1 чтобы пропустить восстановление и загрузить обычный Android. Устройства, запускаемые с Android 12 или более поздней версии, должны использовать bootconfig для передачи androidboot.force_normal_boot=1 .

Изменения конфигурации AVB

Внимание: для динамических разделов требуется проверенная загрузка Android (AVB) и они не будут работать с проверенной загрузкой 1.0.

Если при использовании Android Verified Boot 2.0 устройство не использует связанные дескрипторы разделов , никаких изменений не требуется. Однако если используются связанные разделы и один из проверенных разделов является динамическим, тогда необходимы изменения.

Вот пример конфигурации устройства, которое объединяет vbmeta для system и 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

При такой конфигурации загрузчик ожидает найти нижний колонтитул vbmeta в конце system и vendor разделов. Поскольку эти разделы больше не видны загрузчику (они находятся в super ), необходимо внести два изменения.

• Добавьте разделы vbmeta_system и vbmeta_vendor в таблицу разделов устройства. Для устройств A/B добавьте vbmeta_system_a , vbmeta_system_b , vbmeta_vendor_a и vbmeta_vendor_b . При добавлении одного или нескольких таких разделов они должны иметь тот же размер, что и раздел vbmeta .
• Переименуйте флаги конфигурации, добавив VBMETA_ , и укажите, на какие разделы распространяется цепочка:

  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

Устройство может использовать один, оба или ни один из этих разделов. Изменения необходимы только при привязке к логическому разделу.

Изменения загрузчика AVB

Если в загрузчик встроена библиотека libavb , включите следующие исправления:

• 818cf56740775446285466eda984acedd4baeac0 — «libavb: запрашивать GUID разделов только тогда, когда они нужны командной строке».
• 5abd6bc2578968d24406d834471adfd995a0c2e9 — «Разрешить отсутствие системного раздела»
• 9ba3b6613b4e5130fa01a11d984c6b5f0eb3af05 — «Исправить AvbSlotVerifyData->cmdline, который мог иметь значение NULL»

Если вы используете связанные разделы, включите дополнительный патч:

• 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — «libavb: поддержка больших объектов vbmeta в начале раздела».
  Примечание. Раньше реализовать get_size_of_partition в AvbOps было необязательно. После этого изменения это необходимо, и загрузчик должен реализовать эту функцию.

Изменения командной строки ядра

В командную строку ядра необходимо добавить новый параметр androidboot.boot_devices . Это используется init для включения символических ссылок /dev/block/by-name . Это должен быть компонент пути устройства к базовой символической ссылке по имени, созданной ueventd , то есть /dev/block/platform/ device-path /by-name/ partition-name . Устройства, запускаемые с Android 12 или более поздней версии, должны использовать bootconfig для передачи androidboot.boot_devices в init .

Например, если символическая ссылка по имени суперраздела — /dev/block/platform/ soc/100000.ufshc /by-name/super , вы можете добавить параметр командной строки в файл BoardConfig.mk следующим образом:

BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshc

Вы можете добавить параметр bootconfig в файл BoardConfig.mk следующим образом:

BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc

изменения в fstab

Дерево устройств и наложения дерева устройств не должны содержать записи fstab. Используйте файл fstab, который будет частью виртуального диска.

Изменения необходимо внести в файл fstab для логических разделов:

• Поле fs_mgr flags должно включать logical флаг и флаг first_stage_mount , представленный в Android 10, который указывает, что раздел должен быть смонтирован на первом этапе.
• Раздел может указать avb= vbmeta partition name в качестве флага fs_mgr , а затем указанный раздел vbmeta инициализируется на первом этапе init перед попыткой подключения каких-либо устройств.
• Поле dev должно содержать имя раздела.

Следующие записи fstab определяют систему, поставщика и продукт как логические разделы в соответствии с вышеуказанными правилами.

#<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

Примечание. Не включайте slotselect для устройств, отличных от A/B.

Скопируйте файл fstab на виртуальный диск первого этапа.

Изменения в SELinux

Блочное устройство суперраздела должно быть помечено меткой super_block_device . Например, если символическая ссылка по имени суперраздела — /dev/block/platform/ soc/100000.ufshc /by-name/super , добавьте следующую строку в file_contexts :

/dev/block/platform/soc/10000\.ufshc/by-name/super   u:object_r:super_block_device:s0

фастбутд

Загрузчик (или любой другой инструмент для прошивки, не относящийся к пользовательскому пространству) не понимает динамические разделы, поэтому не может их прошить. Чтобы решить эту проблему, устройства должны использовать реализацию протокола fastboot в пользовательском пространстве, называемую fastbootd.

Дополнительные сведения о том, как реализовать fastbootd, см. в разделе «Перемещение Fastboot в пространство пользователя» .

adb перемонтировать

Для разработчиков, использующих сборки eng или userdebug, adb remount чрезвычайно полезен для быстрой итерации. Динамические разделы создают проблему для adb remount , поскольку в каждой файловой системе больше нет свободного места. Чтобы решить эту проблему, устройства могут включить overlayfs. Пока в суперразделе есть свободное место, adb remount автоматически создает временный динамический раздел и использует overlayfs для записи. Временный раздел называется scratch , поэтому не используйте это имя для других разделов.

Дополнительную информацию о том, как включить overlayfs, см. в README overlayfs в AOSP.

Обновите Android-устройства

Если вы обновляете устройство до Android 10 и хотите включить поддержку динамических разделов в OTA, вам не нужно изменять встроенную таблицу разделов. Требуется некоторая дополнительная настройка.

Изменения конфигурации устройства

Чтобы модифицировать динамическое секционирование, добавьте следующие флаги в device.mk :

PRODUCT_USE_DYNAMIC_PARTITIONS := true
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true

Изменения конфигурации платы

Вам необходимо установить следующие переменные платы:

• Установите BOARD_SUPER_PARTITION_BLOCK_DEVICES в список блочных устройств, используемых для хранения экстентов динамических разделов. Это список имен существующих физических разделов на устройстве.
• Установите для BOARD_SUPER_PARTITION_ partition _DEVICE_SIZE размеры каждого блочного устройства в BOARD_SUPER_PARTITION_BLOCK_DEVICES соответственно. Это список размеров существующих физических разделов на устройстве. Обычно это BOARD_ partition IMAGE_PARTITION_SIZE в существующих конфигурациях платы.
• Отмените настройку существующего BOARD_ partition IMAGE_PARTITION_SIZE для всех разделов в BOARD_SUPER_PARTITION_BLOCK_DEVICES .
• Установите BOARD_SUPER_PARTITION_SIZE в сумму BOARD_SUPER_PARTITION_ partition _DEVICE_SIZE .
• Установите для BOARD_SUPER_PARTITION_METADATA_DEVICE блочное устройство, на котором хранятся метаданные динамического раздела. Это должен быть один из BOARD_SUPER_PARTITION_BLOCK_DEVICES . Обычно для этого параметра установлено значение system .
• Установите BOARD_SUPER_PARTITION_GROUPS , BOARD_ group _SIZE и BOARD_ group _PARTITION_LIST соответственно. Подробности см. в разделе Изменения конфигурации платы на новых устройствах .

Например, если на устройстве уже есть системный раздел и раздел поставщика, и вы хотите преобразовать их в динамические разделы и добавить новый раздел продукта во время обновления, установите следующую конфигурацию платы:

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

Изменения в SELinux

Блочные устройства суперраздела должны быть отмечены атрибутом super_block_device_type . Например, если на устройстве уже есть system раздел и раздел vendor , вы хотите использовать их в качестве блочных устройств для хранения экстентов динамических разделов, а их символические ссылки по имени помечаются как 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

Затем добавьте следующую строку в device.te :

typeattribute system_block_device super_block_device_type;

Дополнительные сведения о других конфигурациях см. в разделе «Реализация динамических разделов на новых устройствах» .

Дополнительные сведения об обновлениях см. в разделе OTA для устройств A/B без динамических разделов .

Заводские изображения

Если устройство запускается с поддержкой динамических разделов, избегайте использования быстрой загрузки пользовательского пространства для прошивки заводских образов, поскольку загрузка в пользовательское пространство происходит медленнее, чем другие методы прошивки.

Чтобы решить эту проблему, make dist теперь создает дополнительный образ super.img , который можно записать непосредственно в суперраздел. Он автоматически объединяет содержимое логических разделов, то есть содержит system.img , vendor.img и т. д., в дополнение к метаданным super . Этот образ можно прошить непосредственно в super без каких-либо дополнительных инструментов или использования fastbootd. После сборки super.img помещается в ${ANDROID_PRODUCT_OUT} .

Для устройств A/B, которые запускаются с динамическими разделами, super.img содержит изображения в слоте A. После прошивки суперобраза напрямую отметьте слот А как загрузочный перед перезагрузкой устройства.

Для модифицированных устройств make dist создает набор образов super_*.img , которые можно записать непосредственно в соответствующие физические разделы. Например, make dist создает super_system.img и super_vendor.img если BOARD_SUPER_PARTITION_BLOCK_DEVICES является поставщиком системы. Эти изображения помещаются в папку OTA в target_files.zip .

Настройка устройства хранения данных устройства сопоставления

Динамическое секционирование вмещает ряд недетерминированных объектов-сопоставителей устройств. Не все они могут создаваться так, как ожидалось, поэтому необходимо отслеживать все подключения и обновлять свойства Android всех связанных разделов с их базовыми устройствами хранения.

Механизм внутри init отслеживает монтирование и асинхронно обновляет свойства Android. Время, которое это занимает, не обязательно попадает в определенный период, поэтому вы должны предоставить достаточно времени, чтобы все триггеры on property среагировали. Свойства: dev.mnt.blk. <partition> где <partition> — это, например, root , system , data vendor . Каждое свойство связано с именем базового устройства хранения, как показано в следующих примерах:

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]

Язык init.rc позволяет расширять свойства Android как часть правил, а устройства хранения могут настраиваться платформой по мере необходимости с помощью таких команд:

write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb 128
write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb 128

Как только обработка команды начинается на втором этапе init , epoll loop становится активным, и значения начинают обновляться. Однако, поскольку триггеры свойств не активны до поздней init , их нельзя использовать на начальных этапах загрузки для обработки root , system vendor . Вы можете ожидать, что стандартного read_ahead_kb ядра будет достаточно до тех пор, пока сценарии init.rc не смогут переопределить его в early-fs системы (когда запускаются различные демоны и средства). Поэтому Google рекомендует использовать функцию on property в сочетании со свойством, контролируемым init.rc , например sys.read_ahead_kb , для управления синхронизацией операций и предотвращения состояний гонки, как в этих примерах:

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}