Dinamik bölümleri uygulama

Dinamik bölümleme, Linux çekirdeğindeki dm-linear aygıt eşleyici modülü kullanılarak uygulanır. super bölüm, super içindeki her dinamik bölümün adlarını ve blok aralıklarını listeleyen meta verileri içerir. İlk aşama init sırasında bu meta veriler ayrıştırılır ve doğrulanır ve her dinamik bölümü temsil edecek sanal blok aygıtları oluşturulur.

Bir OTA uygulanırken dinamik bölümler gerektiğinde otomatik olarak oluşturulur, yeniden boyutlandırılır veya silinir. A/B aygıtları için meta verinin iki kopyası vardır ve değişiklikler yalnızca hedef alanı temsil eden kopyaya uygulanır.

Dinamik bölümler kullanıcı alanında uygulandığından, önyükleyicinin ihtiyaç duyduğu bölümler dinamik hale getirilemez. Örneğin, boot , dtbo ve vbmeta önyükleyici tarafından okunur ve bu nedenle fiziksel bölümler olarak kalmaları gerekir.

Her dinamik bölüm bir güncelleme grubuna ait olabilir. Bu gruplar, o gruptaki bölümlerin tüketebileceği maksimum alanı sınırlar. Örneğin, system ve vendor system ve vendor toplam boyutunu kısıtlayan bir gruba ait olabilir.

Yeni cihazlarda dinamik bölümleri uygulama

Bu bölümde, Android 10 ve sonraki sürümlerle başlatılan yeni cihazlarda dinamik bölümlerin nasıl uygulanacağı ayrıntılı olarak açıklanmaktadır. Mevcut cihazları güncellemek için bkz. Android cihazları yükseltme .

Bölüm değişiklikleri

Android 10 ile başlatılan cihazlar için super adında bir bölüm oluşturun. super bölüm A/B yuvalarını dahili olarak yönetir, böylece A/B aygıtlarının ayrı super_a ve super_b bölümlerine ihtiyacı olmaz. Önyükleyici tarafından kullanılmayan tüm salt okunur AOSP bölümleri dinamik olmalı ve GUID Bölüm Tablosundan (GPT) kaldırılmalıdır. Satıcıya özel bölümlerin dinamik olması gerekmez ve GPT'ye yerleştirilebilir.

super boyutunu tahmin etmek için GPT'den silinen bölümlerin boyutlarını ekleyin. A/B cihazları için bu, her iki yuvanın boyutunu da içermelidir. Şekil 1, dinamik bölümlere dönüştürmeden önce ve sonra örnek bir bölüm tablosunu göstermektedir.

Bölüm tablosu düzeni
Şekil 1. Dinamik bölümlere dönüştürürken yeni fiziksel bölüm tablosu düzeni

Desteklenen dinamik bölümler şunlardır:

  • Sistem
  • SATICI
  • Ürün
  • Sistem Harici
  • ODM

Android 10 ile başlatılan cihazlarda, sysprop ro.boot.super_partition komutunun boş olması için çekirdek komut satırı seçeneği androidboot.super_partition boş olmalıdır.

Bölüm hizalaması

super bölüm düzgün şekilde hizalanmazsa cihaz eşleyici modülü daha az verimli çalışabilir. super bölümün, blok katmanı tarafından belirlenen minimum G/Ç istek boyutuna göre hizalanması ZORUNLUDUR. Varsayılan olarak derleme sistemi ( super bölüm görüntüsünü oluşturan lpmake aracılığıyla), her dinamik bölüm için 1 MiB hizalamanın yeterli olduğunu varsayar. Ancak satıcılar super bölümün doğru şekilde hizalandığından emin olmalıdır.

Bir blok aygıtının minimum istek boyutunu sysfs inceleyerek belirleyebilirsiniz. Örneğin:

# 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 bölümün hizalamasını benzer şekilde doğrulayabilirsiniz:

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

Hizalama ofseti 0 OLMALIDIR.

Cihaz yapılandırma değişiklikleri

Dinamik bölümlemeyi etkinleştirmek için, device.mk dosyasına aşağıdaki bayrağı ekleyin:

PRODUCT_USE_DYNAMIC_PARTITIONS := true

Kart konfigürasyonu değişiklikleri

super bölümün boyutunu ayarlamanız gerekir:

BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

A/B aygıtlarında, dinamik bölüm görüntülerinin toplam boyutu super bölüm boyutunun yarısından fazlaysa derleme sistemi bir hata atar.

Dinamik bölümlerin listesini aşağıdaki gibi yapılandırabilirsiniz. Güncelleme gruplarını kullanan cihazlar için grupları BOARD_SUPER_PARTITION_GROUPS değişkeninde listeleyin. Bu durumda her grup adında bir BOARD_ group _SIZE ve BOARD_ group _PARTITION_LIST değişkeni bulunur. A/B aygıtları için, grup adları dahili olarak yuvaya eklendiğinden, bir grubun maksimum boyutu yalnızca bir yuvayı kapsamalıdır.

Tüm bölümleri example_dynamic_partitions adlı bir gruba yerleştiren örnek bir cihazı burada bulabilirsiniz:

BOARD_SUPER_PARTITION_GROUPS := example_dynamic_partitions
BOARD_EXAMPLE_DYNAMIC_PARTITIONS_SIZE := 6442450944
BOARD_EXAMPLE_DYNAMIC_PARTITIONS_PARTITION_LIST := system vendor product

Sistem ve ürün hizmetlerini group_foo , vendor , product ve odm ise group_bar yerleştiren örnek bir cihazı burada bulabilirsiniz:

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
  • Sanal A/B başlatma cihazları için tüm grupların maksimum boyutlarının toplamı en fazla olmalıdır:
    BOARD_SUPER_PARTITION_SIZE - genel gider
    Bkz. Sanal A/B'yi Uygulama .
  • A/B başlatma cihazları için tüm grupların maksimum boyutlarının toplamı şu şekilde olmalıdır:
    BOARD_SUPER_PARTITION_SIZE / 2 - genel gider
  • A/B olmayan cihazlar ve sonradan takılan A/B cihazları için tüm grupların maksimum boyutlarının toplamı şu şekilde olmalıdır:
    BOARD_SUPER_PARTITION_SIZE - genel gider
  • Oluşturma sırasında, bir güncelleme grubundaki her bölümün görüntülerinin boyutlarının toplamı, grubun maksimum boyutunu aşmamalıdır.
  • Meta verileri, hizalamaları vb. hesaba katmak için hesaplamada ek yük gereklidir. Makul bir ek yük 4 MiB'dir, ancak cihazın ihtiyacına göre daha büyük bir ek yük seçebilirsiniz.

Boyut dinamik bölümleri

Dinamik bölümlerden önce, bölüm boyutları gelecekteki güncellemeler için yeterli alana sahip olduklarından emin olmak amacıyla aşırı tahsis ediliyordu. Gerçek boyut olduğu gibi alındı ​​ve çoğu salt okunur bölümün dosya sisteminde bir miktar boş alan vardı. Dinamik bölümlerde bu boş alan kullanılamaz ve OTA sırasında bölümleri büyütmek için kullanılabilir. Bölümlerin yer israf etmemesini ve mümkün olan en düşük boyuta ayrılmasını sağlamak çok önemlidir.

Salt okunur ext4 görüntüleri için, sabit kodlanmış bölüm boyutu belirtilmemişse derleme sistemi otomatik olarak minimum boyutu tahsis eder. Derleme sistemi, dosya sisteminde mümkün olduğunca az kullanılmayan alan kalacak şekilde görüntüye uyar. Bu, cihazın OTA'lar için kullanılabilecek alanı boşa harcamamasını sağlar.

Ek olarak ext4 görüntüleri, blok düzeyinde veri tekilleştirme etkinleştirilerek daha da sıkıştırılabilir. Bunu etkinleştirmek için aşağıdaki yapılandırmayı kullanın:

BOARD_EXT4_SHARE_DUP_BLOCKS := true

Minimum bölüm boyutunun otomatik olarak tahsis edilmesi istenmiyorsa, bölüm boyutunu kontrol etmenin iki yolu vardır. BOARD_ partition IMAGE_PARTITION_RESERVED_SIZE ile minimum miktarda boş alan belirtebilirsiniz veya dinamik bölümleri belirli bir boyuta zorlamak için BOARD_ partition IMAGE_PARTITION_SIZE belirtebilirsiniz. Gerekmedikçe bunların hiçbiri önerilmez.

Örneğin:

BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800

Bu, product.img dosyasındaki dosya sistemini 50 MiB kullanılmayan alana sahip olmaya zorlar.

Kök olarak sistem değişiklikleri

Android 10 ile başlatılan cihazların kök olarak sistem kullanmaması gerekir.

Dinamik bölümlere sahip cihazlar (ister dinamik bölümlerle başlatılsın ister sonradan donatılsın) kök olarak sistemi kullanmamalıdır. Linux çekirdeği super bölümü yorumlayamaz ve dolayısıyla system kendisini bağlayamaz. system artık ramdisk'te bulunan birinci aşama init tarafından bağlanıyor.

BOARD_BUILD_SYSTEM_ROOT_IMAGE ayarını yapmayın. Android 10'da BOARD_BUILD_SYSTEM_ROOT_IMAGE bayrağı yalnızca sistemin çekirdek tarafından mı yoksa ramdisk'teki ilk aşama init tarafından mı bağlandığını ayırt etmek için kullanılır.

BOARD_BUILD_SYSTEM_ROOT_IMAGE öğesini true olarak ayarlamak, PRODUCT_USE_DYNAMIC_PARTITIONS da true olduğunda derleme hatasına neden olur.

BOARD_USES_RECOVERY_AS_BOOT doğru olarak ayarlandığında kurtarma görüntüsü, kurtarmanın ramdiskini içeren boot.img olarak oluşturulur. Önceden, önyükleyici hangi moda önyükleme yapılacağına karar vermek için skip_initramfs çekirdek komut satırı parametresini kullanıyordu. Android 10 cihazlarda, önyükleyicinin skip_initramfs çekirdek komut satırına GETİRMEMESİ GEREKİR. Bunun yerine, önyükleyicinin kurtarmayı atlamak ve normal Android'i başlatmak için androidboot.force_normal_boot=1 değerini iletmesi gerekir. Android 12 veya sonraki sürümlerle başlatılan cihazların, androidboot.force_normal_boot=1 iletmek için bootconfig kullanması gerekir.

AVB yapılandırma değişiklikleri

Android Verified Boot 2.0 kullanırken, cihaz zincirleme bölüm tanımlayıcılarını kullanmıyorsa herhangi bir değişiklik yapılmasına gerek yoktur. Ancak zincirleme bölümler kullanılıyorsa ve doğrulanan bölümlerden biri dinamikse, değişiklik yapılması gerekir.

system ve vendor bölümleri için vbmeta zincirleyen bir aygıtın örnek yapılandırmasını burada bulabilirsiniz.

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

Bu yapılandırmayla, önyükleyici, system ve vendor bölümlerinin sonunda vbmeta altbilgisini bulmayı bekler. Bu bölümler artık önyükleyici tarafından görülemediğinden ( super içinde bulunurlar), iki değişiklik yapılması gerekir.

  • Cihazın bölüm tablosuna vbmeta_system ve vbmeta_vendor bölümlerini ekleyin. A/B cihazları için vbmeta_system_a , vbmeta_system_b , vbmeta_vendor_a ve vbmeta_vendor_b ekleyin. Bu bölümlerden bir veya daha fazlası ekleniyorsa bunlar vbmeta bölümüyle aynı boyutta olmalıdır.
  • VBMETA_ ekleyerek yapılandırma bayraklarını yeniden adlandırın ve zincirlemenin hangi bölümlere uzanacağını belirtin:
    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

Bir aygıt bu bölümlerden birini, her ikisini veya hiçbirini kullanıyor olabilir. Yalnızca mantıksal bir bölüme zincirleme yapılırken değişiklik yapılması gerekir.

AVB önyükleyici değişiklikleri

Önyükleyicide libavb gömülüyse aşağıdaki yamaları ekleyin:

Zincirlenmiş bölümler kullanıyorsanız ek bir yama ekleyin:

  • 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: Bölümün başlangıcında vbmeta blob'larını destekleyin."

Çekirdek komut satırı değişiklikleri

Çekirdek komut satırına yeni bir parametre olan androidboot.boot_devices eklenmelidir. Bu, init tarafından /dev/block/by-name sembolik bağları etkinleştirmek için kullanılır. ueventd tarafından oluşturulan temel isme göre sembolik bağlantının cihaz yolu bileşeni olmalıdır, yani /dev/block/platform/ device-path /by-name/ partition-name . Android 12 veya sonraki sürümlerle başlatılan cihazların, androidboot.boot_devices init öğesine iletmek için bootconfig kullanması gerekir.

Örneğin, süper bölüm adı sembolik bağlantısı /dev/block/platform/ soc/100000.ufshc /by-name/super ise, BoardConfig.mk dosyasına komut satırı parametresini şu şekilde ekleyebilirsiniz:

BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshc
Bootconfig parametresini BoardConfig.mk dosyasına şu şekilde ekleyebilirsiniz:
BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc

fstab değişiklikleri

Cihaz ağacı ve cihaz ağacı katmanları fstab girişleri içermemelidir. Ramdisk'in parçası olacak bir fstab dosyası kullanın.

Mantıksal bölümler için fstab dosyasında değişiklik yapılması gerekir:

  • Fs_mgr flags alanı, Android 10'da tanıtılan ve ilk aşamada bir bölümün monte edileceğini belirten logical bayrağı ve first_stage_mount bayrağını içermelidir.
  • Bir bölüm, fs_mgr bayrağı olarak avb= vbmeta partition name belirtebilir ve ardından belirtilen vbmeta bölümü, herhangi bir aygıtı bağlamaya çalışmadan önce ilk aşama init tarafından başlatılır.
  • dev alanı bölüm adı olmalıdır.

Aşağıdaki fstab girişleri, sistemi, satıcıyı ve ürünü yukarıdaki kurallara göre mantıksal bölümler olarak ayarlar.

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

Fstab dosyasını ilk aşamadaki ramdiske kopyalayın.

SELinux değişiklikleri

Süper bölüm blok aygıtı super_block_device etiketiyle işaretlenmelidir. Örneğin, süper bölümün isme göre sembolik bağlantısı /dev/block/platform/ soc/100000.ufshc /by-name/super ise, file_contexts aşağıdaki satırı ekleyin:

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

hızlı önyükleme

Önyükleyici (veya kullanıcı alanı olmayan herhangi bir flaşlama aracı) dinamik bölümleri anlamadığından onları flaş edemez. Bu sorunu çözmek için cihazların fastbootd adı verilen fastboot protokolünün kullanıcı alanı uygulamasını kullanması gerekir.

Fastbootd'un nasıl uygulanacağı hakkında daha fazla bilgi için bkz. Fastboot'u Kullanıcı Alanına Taşıma .

adb yeniden montajı

Eng veya userdebug yapılarını kullanan geliştiriciler için adb remount , hızlı yineleme açısından son derece kullanışlıdır. Dinamik bölümler, her dosya sisteminde artık boş alan olmadığından adb remount için sorun oluşturur. Bu sorunu çözmek için cihazlar katmanları etkinleştirebilir. Süper bölüm içinde boş alan olduğu sürece, adb remount otomatik olarak geçici bir dinamik bölüm oluşturur ve yazma işlemleri için kaplamaları kullanır. Geçici bölümün adı scratch , dolayısıyla bu adı diğer bölümler için kullanmayın.

Kaplamaların nasıl etkinleştirileceği hakkında daha fazla bilgi için AOSP'deki kaplamalar README'ye bakın.

Android cihazlarını yükseltin

Bir cihazı Android 10'a yükseltirseniz ve OTA'ya dinamik bölüm desteği eklemek istiyorsanız yerleşik bölüm tablosunu değiştirmeniz gerekmez. Bazı ekstra yapılandırmalar gereklidir.

Cihaz yapılandırma değişiklikleri

Dinamik bölümlemeyi güçlendirmek için, aşağıdaki bayrakları device.mk dosyasına ekleyin:

PRODUCT_USE_DYNAMIC_PARTITIONS := true
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true

Kart konfigürasyonu değişiklikleri

Aşağıdaki pano değişkenlerini ayarlamanız gerekir:

  • BOARD_SUPER_PARTITION_BLOCK_DEVICES dinamik bölümlerin kapsamlarını depolamak için kullanılan blok aygıtları listesine ayarlayın. Bu, cihazdaki mevcut fiziksel bölümlerin adlarının listesidir.
  • BOARD_SUPER_PARTITION_ partition _DEVICE_SIZE sırasıyla BOARD_SUPER_PARTITION_BLOCK_DEVICES içindeki her blok aygıtının boyutlarına ayarlayın. Bu, cihazdaki mevcut fiziksel bölümlerin boyutlarının listesidir. Bu genellikle mevcut kart yapılandırmalarında BOARD_ partition IMAGE_PARTITION_SIZE şeklindedir.
  • BOARD_SUPER_PARTITION_BLOCK_DEVICES içindeki tüm bölümler için mevcut BOARD_ partition IMAGE_PARTITION_SIZE kaldırın.
  • BOARD_SUPER_PARTITION_SIZE değerini BOARD_SUPER_PARTITION_ partition _DEVICE_SIZE toplamına ayarlayın.
  • BOARD_SUPER_PARTITION_METADATA_DEVICE öğesini dinamik bölüm meta verilerinin depolandığı blok cihazına ayarlayın. BOARD_SUPER_PARTITION_BLOCK_DEVICES biri olmalıdır. Genellikle bu, system olarak ayarlanır.
  • Sırasıyla BOARD_SUPER_PARTITION_GROUPS , BOARD_ group _SIZE ve BOARD_ group _PARTITION_LIST ayarlayın. Ayrıntılar için Yeni cihazlardaki kart yapılandırma değişikliklerine bakın.

Örneğin, cihazda halihazırda sistem ve satıcı bölümleri varsa ve bunları dinamik bölümlere dönüştürmek ve güncelleme sırasında yeni bir ürün bölümü eklemek istiyorsanız bu kart yapılandırmasını ayarlayın:

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 değişiklikleri

Süper bölüm blok cihazları super_block_device_type özelliğiyle işaretlenmelidir. Örneğin, cihazda zaten system ve vendor bölümleri varsa, bunları dinamik bölümlerin kapsamlarını depolamak için blok cihazlar olarak kullanmak istersiniz ve bunların isme göre sembolik bağlantıları system_block_device olarak işaretlenir:

/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

Ardından, device.te dosyasına aşağıdaki satırı ekleyin:

typeattribute system_block_device super_block_device_type;

Diğer yapılandırmalar için bkz. Yeni cihazlarda dinamik bölümlerin uygulanması .

Güçlendirme güncellemeleri hakkında daha fazla bilgi için Dinamik Bölümleri Olmayan A/B Cihazları için OTA'ya bakın.

Fabrika görüntüleri

Dinamik bölüm desteğiyle başlatılan bir cihaz için, kullanıcı alanına önyükleme yapmak diğer flaşlama yöntemlerine göre daha yavaş olduğundan, fabrika görüntülerini flaşlamak için kullanıcı alanı fastboot'unu kullanmaktan kaçının.

Bu sorunu çözmek için make dist artık doğrudan süper bölüme aktarılabilen ek bir super.img görüntüsü oluşturuyor. Mantıksal bölümlerin içeriğini otomatik olarak bir araya getirir; bu, super bölüm meta verilerine ek olarak system.img , vendor.img vb. öğeleri içerdiği anlamına gelir. Bu görüntü herhangi bir ek araç kullanmadan veya fastbootd kullanılmadan doğrudan super bölüme aktarılabilir. Derlemeden sonra super.img ${ANDROID_PRODUCT_OUT} içine yerleştirilir.

Dinamik bölümlerle başlatılan A/B aygıtları için super.img A yuvasındaki görüntüleri içerir. Süper görüntüyü doğrudan flashladıktan sonra, cihazı yeniden başlatmadan önce A yuvasını önyüklenebilir olarak işaretleyin.

Cihazları yenilemek için make dist , doğrudan karşılık gelen fiziksel bölümlere aktarılabilen bir dizi super_*.img görüntüsü oluşturur. Örneğin, BOARD_SUPER_PARTITION_BLOCK_DEVICES sistem satıcısı olduğunda make dist build super_system.img ve super_vendor.img . Bu görüntüler target_files.zip dosyasındaki OTA klasörüne yerleştirilir.

Cihaz eşleyici depolama cihazı ayarlama

Dinamik bölümleme, bir dizi belirleyici olmayan aygıt eşleyici nesnesini barındırır. Bunların tümü beklendiği gibi başlatılamayabilir; bu nedenle tüm bağlamaları izlemeniz ve ilişkili tüm bölümlerin Android özelliklerini, temel depolama aygıtlarıyla birlikte güncellemeniz gerekir.

init içindeki bir mekanizma montajları izler ve Android özelliklerini eşzamansız olarak günceller. Bunun için gereken sürenin belirli bir süre içinde olacağı garanti edilmez; bu nedenle, on property tüm tetikleyicilerin tepki vermesi için yeterli süre sağlamanız gerekir. Özellikler dev.mnt.blk. <partition> burada <partition> örneğin root , system , data veya vendor . Her özellik, aşağıdaki örneklerde gösterildiği gibi temel depolama cihazı adıyla ilişkilendirilir:

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 dili, Android özelliklerinin kuralların bir parçası olarak genişletilmesine olanak tanır ve depolama aygıtları, aşağıdaki gibi komutlarla gerektiği şekilde platform tarafından ayarlanabilir:

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

İkinci aşamada init komut işleme başladığında, epoll loop aktif hale gelir ve değerler güncellenmeye başlar. Ancak özellik tetikleyicileri geç init kadar etkin olmadığından, ilk önyükleme aşamalarında root , system veya vendor işlemek için kullanılamazlar. init.rc betikleri early-fs (çeşitli arka plan programları ve tesisler başladığında) geçersiz kılınıncaya kadar çekirdek varsayılan read_ahead_kb yeterli olmasını bekleyebilirsiniz. Bu nedenle Google, aşağıdaki örneklerde olduğu gibi, operasyonların zamanlaması ile ilgilenmek ve yarış koşullarını önlemek için on property özelliğini sys.read_ahead_kb gibi init.rc kontrollü bir özellikle birlikte kullanmanızı önerir:

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}