Dinamik Bölümleri Uygulama

Dinamik bölümleme, Linux çekirdeğindeki dm-doğrusal 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 etmek için sanal blok aygıtları oluşturulur.

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

Dinamik bölümler kullanıcı alanında uygulandığından, önyükleyici tarafından ihtiyaç duyulan 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 kalmalıdır.

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 vendor kısıtlayan bir gruba ait olabilir.

Yeni cihazlarda dinamik bölümlerin uygulanması

Bu bölüm, Android 10 ve sonraki sürümlerle başlatılan yeni cihazlarda dinamik bölümlerin nasıl uygulanacağını açıklar. Mevcut cihazları güncellemek için Android cihazlarını yükseltme bölümüne bakın.

Bölümleme değişiklikleri

Android 10 ile başlatılan cihazlar için super adlı bir bölüm oluşturun. super bölüm, A/B yuvalarını dahili olarak işler, bu nedenle A/B cihazlarının ayrı super_a ve super_b bölümlerine ihtiyacı yoktur. Önyükleyici tarafından kullanılmayan tüm salt okunur AOSP bölümleri dinamik olmalı ve GUID Bölüm Tablosu'ndan (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 silinmekte olan bölümlerin boyutlarını ekleyin. A/B cihazları için bu, her iki yuvanın boyutunu içermelidir. Şekil 1 , dinamik bölümlere dönüştürmeden önce ve sonra örnek bir bölüm tablosunu göstermektedir.

Bölme 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 Dahili
  • 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 hizalama

super bölüm düzgün şekilde hizalanmazsa, aygıt eşleyici modülü daha az verimli çalışabilir. super bölüm, blok katmanı tarafından belirlenen minimum G/Ç istek boyutuna hizalanmalıdır ZORUNLU. Varsayılan olarak, yapı 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 düzgün bir şekilde hizalandığından emin olmalıdır.

sysfs inceleyerek bir blok aygıtının minimum istek boyutunu 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 aşağıdaki bayrağı ekleyin:

PRODUCT_USE_DYNAMIC_PARTITIONS := true

Kart yapılandırma değişiklikleri

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

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 yapı sistemi bir hata verir.

Dinamik bölümlerin listesini aşağıdaki gibi yapılandırabilirsiniz. Güncelleme gruplarını kullanan cihazlar için, BOARD_SUPER_PARTITION_GROUPS değişkenindeki grupları listeleyin. 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 yuva sonuna eklendiğinden, bir grubun maksimum boyutu yalnızca bir yuvayı kapsamalıdır.

İşte tüm bölümleri example_dynamic_partitions adlı bir gruba yerleştiren örnek bir cihaz:

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

Aşağıda, sistem ve ürün hizmetlerini group_foo içine ve vendor , product ve odm group_bar içine yerleştiren örnek bir cihaz verilmiştir:

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 şu olmalıdır:
    BOARD_SUPER_PARTITION_SIZE - ek yük
    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 - havai
  • 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 - ek yük
  • Derleme zamanı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ı ve benzerlerini hesaba katmak için hesaplamada ek yük gereklidir. Makul bir ek yük 4 MiB'dir, ancak cihazın gerektirdiği şekilde daha büyük bir ek yük seçebilirsiniz.

Dinamik bölümleri boyutlandırma

Dinamik bölümlerden önce, gelecekteki güncellemeler için yeterli alana sahip olmalarını sağlamak için bölüm boyutları aşırı tahsis edildi. Gerçek boyut olduğu gibi alındı ​​ve salt okunur bölümlerin çoğunda dosya sistemlerinde bir miktar boş alan vardı. Dinamik bölümlerde, bu boş alan kullanılamaz ve bir 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 minimum 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 yapı sistemi minimum boyutu otomatik olarak tahsis eder. Derleme sistemi, dosya sisteminde mümkün olduğunca az kullanılmayan alana sahip olacak ş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 fazla sıkıştırılabilir. Bunu etkinleştirmek için aşağıdaki yapılandırmayı kullanın:

BOARD_EXT4_SHARE_DUP_BLOCKS := true

Bir bölümün minimum boyutunun otomatik olarak ayrılması istenmiyorsa, bölüm boyutunu denetlemenin iki yolu vardır. BOARD_ partition IMAGE_PARTITION_RESERVED_SIZE ile minimum miktarda boş alan belirtebilir 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 dosya sistemini 50 MiB kullanılmayan alana sahip olmaya zorlar.

Kök olarak sistem değişiklikleri

Android 10 ile başlatılan cihazlar, sistemi kök olarak kullanmamalıdır.

Dinamik bölümlere sahip aygıtlar (ister dinamik bölümlerle başlatılsın ya da dinamik bölümlere uyarlansın) sistem-root olarak kullanmamalıdır. Linux çekirdeği super bölümü yorumlayamaz ve bu nedenle system kendisini bağlayamaz. system şimdi ramdisk'te bulunan ilk aşama init tarafından monte edilmiştir.

BOARD_BUILD_SYSTEM_ROOT_IMAGE ayarlamayı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ı monte edildiğini ayırt etmek için kullanılır.

BOARD_BUILD_SYSTEM_ROOT_IMAGE değerini true olarak ayarlamak, PRODUCT_USES_DYNAMIC_PARTITIONS da true olduğunda bir derleme hatasına neden olur.

BOARD_USES_RECOVERY_AS_BOOT true 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 cihazlar için önyükleyici, kernel komut satırına skip_initramfs . Bunun yerine, bootloader, kurtarma işlemini atlamak ve normal Android'i başlatmak için androidboot.force_normal_boot=1 . Android 12 veya sonraki sürümlerle başlatılan cihazlar, androidboot.force_normal_boot=1 'i geçmek için bootconfig kullanmalıdır.

AVB yapılandırma değişiklikleri

Android Verified Boot 2.0 kullanırken, cihaz zincirleme bölüm tanımlayıcıları kullanmıyorsa, herhangi bir değişiklik gerekli değildir. Ancak zincirleme bölümler kullanılıyorsa ve doğrulanmış bölümlerden biri dinamikse, değişiklikler gereklidir.

İşte system ve vendor bölümleri için vbmeta zincirleyen bir aygıt için örnek bir yapılandırma.

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 bir vbmeta altbilgisi bulmayı bekler. Bu bölümler artık önyükleyici tarafından görülmediğinden ( super içinde bulunurlar), iki değişiklik gereklidir.

  • Aygıtın bölüm tablosuna vbmeta_system ve vbmeta_vendor bölümleri ekleyin. A/B aygıtları için vbmeta_system_a , vbmeta_system_b , vbmeta_vendor_a ve vbmeta_vendor_b . Bu bölümlerden bir veya daha fazlasını ekliyorsanız, bunlar vbmeta aynı boyutta olmalıdır.
  • VBMETA_ ekleyerek yapılandırma bayraklarını yeniden adlandırın ve zincirlemenin hangi bölümlere uzandığı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 veya her ikisini kullanıyor olabilir veya hiçbirini kullanıyor olabilir. Değişiklikler yalnızca mantıksal bir bölüme zincirleme yapılırken gereklidir.

AVB önyükleyici değişiklikleri

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

Zincirleme bölümler kullanıyorsanız, ek bir yama ekleyin:

  • 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: Bölümün başlangıcında vbmeta blobları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ğlantılarını etkinleştirmek için kullanılır. Bu, ueventd tarafından oluşturulan temel ada göre sembolik bağlantının aygıt 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 aygıtlar, androidboot.boot_devices öğesini init öğesine geçirmek için androidboot.boot_devices kullanmalıdır.

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

BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshc
Bootconfig parametresini BoardConfig.mk dosyasına aşağıdaki gibi ekleyebilirsiniz:
BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc

fstab değişiklikleri

Aygıt ağacı ve aygıt ağacı kaplamaları, fstab girdileri içermemelidir. Ramdiskin parçası olacak bir fstab dosyası kullanın.

Mantıksal bölümler için fstab dosyasında değişiklikler yapılmalıdır:

  • fs_mgr bayrakları alanı, logical bayrağı ve Android 10'da tanıtılan ve bir bölümün ilk aşamada monte edileceğini belirten first_stage_mount bayrağını içermelidir.
  • Bir bölüm, bir 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şama ramdisk'e kopyalayın.

SELinux değişiklikleri

Süper bölüm blok aygıtı super_block_device etiketiyle işaretlenmelidir. Örneğin, simge bağlantısına göre süper bölümün adı /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 herhangi bir kullanıcı alanı olmayan yanıp sönme aracı) dinamik bölümleri anlamaz, bu nedenle onları flash edemez. Bunu ele almak için cihazlar, fastbootd adı verilen fastboot protokolünün bir kullanıcı alanı uygulamasını kullanmalıdır.

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

adb yeniden monte

eng veya userdebug derlemelerini kullanan geliştiriciler için adb remount , hızlı yineleme için son derece kullanışlıdır. Dinamik bölümler, her dosya sisteminde artık boş alan olmadığından adb remount için bir sorun teşkil eder. Bunu ele almak için cihazlar bindirmeleri etkinleştirebilir. Süper bölüm içinde boş alan olduğu sürece, adb remount remount otomatik olarak geçici bir dinamik bölüm oluşturur ve yazma işlemleri için overlayfs kullanır. Geçici bölüm, scratch olarak adlandırılır, bu nedenle diğer bölümler için bu adı kullanmayın.

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

Android cihazları yükseltme

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ırma gereklidir.

Cihaz yapılandırma değişiklikleri

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

PRODUCT_USE_DYNAMIC_PARTITIONS := true
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true

Kart yapılandırma değişiklikleri

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

  • BOARD_SUPER_PARTITION_BLOCK_DEVICES öğesini dinamik bölümlerin kapsamlarını depolamak için kullanılan blok aygıtların 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, mevcut kart konfigürasyonlarında genellikle BOARD_ partition IMAGE_PARTITION_SIZE .
  • BOARD_SUPER_PARTITION_BLOCK_DEVICES içindeki tüm bölümler için mevcut BOARD_ partition IMAGE_PARTITION_SIZE BOARD_SUPER_PARTITION_BLOCK_DEVICES .
  • BOARD_SUPER_PARTITION_SIZE değerini BOARD_SUPER_PARTITION_ partition _DEVICE_SIZE toplamına ayarlayın.
  • BOARD_SUPER_PARTITION_METADATA_DEVICE dinamik bölüm meta verilerinin depolandığı blok cihaza ayarlayın. BOARD_SUPER_PARTITION_BLOCK_DEVICES 'den biri olmalıdır. Genellikle, bu system olarak ayarlanır.
  • BOARD_SUPER_PARTITION_GROUPS , BOARD_ group _SIZE ve BOARD_ group _PARTITION_LIST sırasıyla ayarlayın. Ayrıntılar için yeni cihazlarda Pano yapılandırma değişikliklerine bakın.

Örneğin, cihazda zaten 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 aygıtları, super_block_device_type özniteliği ile işaretlenmelidir. Örneğin, aygıtta zaten system ve vendor bölümleri varsa, bunları dinamik bölümlerin kapsamlarını depolamak için blok aygıtları olarak kullanmak istersiniz ve adlarına 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 aşağıdaki satırı ekleyin:

typeattribute system_block_device super_block_device_type;

Diğer yapılandırmalar için, bkz . Yeni aygıtlarda dinamik bölümleri uygulama .

Güçlendirme güncellemeleri hakkında daha fazla bilgi için bkz. Dinamik Bölümleri olmayan A/B Cihazları için OTA .

Fabrika görüntüleri

Dinamik bölümleme desteğiyle başlatılan bir aygıt için, kullanıcı alanına önyükleme diğer yanıp sönme yöntemlerinden daha yavaş olduğundan fabrika görüntülerini flaş etmek için userspace fastboot kullanmaktan kaçının.

Bunu ele almak için, make dist şimdi doğrudan süper bölüme aktarılabilen ek bir super.img görüntüsü oluşturur. Mantıksal bölümlerin içeriklerini otomatik olarak bir araya toplar, yani super bölüm meta verilerine ek olarak system.img , vendor.img ve benzerlerini içerir. Bu görüntü, herhangi bir ek alet kullanmadan veya fastbootd kullanılarak doğrudan super bölüme flash edilebilir. 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 yanıp söndükten sonra, cihazı yeniden başlatmadan önce A yuvasını önyüklenebilir olarak işaretleyin.

Güçlendirme cihazları make dist builds, doğrudan ilgili 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 derlemelerini super_system.img ve super_vendor.img yapın. Bu görüntüler, target_files.zip içindeki OTA klasörüne yerleştirilir.

Cihaz eşleyici depolama cihazı ayarı

Dinamik bölümleme, bir dizi belirleyici olmayan aygıt eşleyici nesnesini barındırır. Bunların tümü beklendiği gibi somutlaştırılamayabilir, bu nedenle tüm bağlamaları izlemeli ve ilgili tüm bölümlerin Android özelliklerini temel depolama aygıtlarıyla güncellemelisiniz.

init içindeki bir mekanizma, bağlamaları izler ve Android özelliklerini eşzamansız olarak günceller. Bunun belirli bir süre içinde olacağı garanti edilmez, bu nedenle tüm on property tetikleyicilerinin tepki vermesi için yeterli zaman sağlamanız gerekir. Özellikler dev.mnt.blk. <partition> burada örneğin <partition> root , system , data veya vendor . Her özellik, aşağıdaki örneklerde gösterildiği gibi, temel depolama aygıtı 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ğinde 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 komut işleme başladığında, init epoll loop aktif hale gelir ve değerler güncellenmeye başlar. Ancak, özellik tetikleyicileri geç init kadar etkin olmadıklarından, root , system veya vendor işlemek için ilk önyükleme aşamalarında kullanılamazlar. init.rc betikleri early-fs fs'de (çeşitli arka plan programları ve tesisler başladığında) geçersiz kılabilene kadar çekirdek varsayılanı read_ahead_kb yeterli olmasını bekleyebilirsiniz. Bu nedenle Google, işlemlerin zamanlamasını ele almak ve yarış koşullarını önlemek için aşağıdaki örneklerde olduğu gibi, sys.read_ahead_kb init.rc kontrol edilen bir özellikle birleştirilmiş on property özelliğini 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}