Dinamik bölümleri uygulama

Dinamik bölümlendirme, Linux çekirdeğinde dm-linear cihaz 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 veriler içerir. İlk aşamada init bu meta veriler ayrıştırılır ve doğrulanır. Ayrıca her dinamik bölümü temsil etmek için sanal blok cihazlar oluşturulur.

OTA uygulanırken dinamik bölümler otomatik olarak oluşturulur, yeniden boyutlandırılır veya gerektiğinde silinir. A/B cihazlarda 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ükleyicinin ihtiyaç duyduğu bölümler dinamik hale getirilemez. Örneğin, boot, dtbo ve vbmeta önyükleme yükleyici tarafından okunur ve bu nedenle fiziksel bölüm olarak kalmalıdır.

Her dinamik bölüm bir güncelleme grubuna ait olabilir. Bu gruplar, gruptaki bölümlerin kullanabileceği maksimum alanı sınırlar. Örneğin, system ve vendor, system ve vendor'un 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ümlerin yüklü olduğu yeni cihazlarda dinamik bölümlerin nasıl uygulanacağı ayrıntılı olarak açıklanmaktadır. Mevcut cihazları güncellemek için Android cihazları güncelleme başlıklı makaleyi inceleyin.

Bölüm değişiklikleri

Android 10 ile kullanıma sunulan cihazlar için super adlı bir bölüm oluşturun. super bölümünde A/B yuvaları dahili olarak yönetilir. Bu nedenle, A/B cihazları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 tablosundan (GPT) kaldırılmalıdır. Tedarikçiye özgü 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 alanın boyutunu da içermelidir. Şekil 1'de, dinamik bölümlere dönüştürülmeden önce ve sonra örnek bir bölüm tablosu gösterilmektedir.

Bölüm tablosu düzeni
Şekil 1. Dinamik bölümlere dönüştürme işlemi sırasında yeni fiziksel bölüm tablosu düzeni

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

  • Sistem
  • Satıcı
  • Ürün
  • Sistem Uzatma
  • ODM

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

Bölüm hizası

Bölüm düzgün hizalanmamışsa device-mapper modülü daha az verimli çalışabilir.super super bölümü, blok katmanı tarafından belirlenen minimum G/Ç istek boyutuna hizalanmalıdır. Derleme sistemi (super bölüm resmini oluşturan lpmake aracılığıyla), varsayılan olarak her dinamik bölüm için 1 MiB'lik bir uyumun yeterli olduğunu varsayar. Ancak tedarikçiler, super bölümünün doğru şekilde hizalandığından emin olmalıdır.

sysfs değerini inceleyerek bir blok cihazın minimum istek boyutunu belirleyebilirsiniz. Örnek: 

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

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

Hizalama ofseti 0 OLMALIDIR.

Cihaz yapılandırmasında değişiklik

Dinamik bölümlemeyi etkinleştirmek için device.mk bölümüne aşağıdaki işareti ekleyin: 

PRODUCT_USE_DYNAMIC_PARTITIONS := true

Tahta yapılandırmasında yapılan değişiklikler

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

BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

A/B cihazlarda, dinamik bölüm resimlerinin toplam boyutu super bölüm boyutunun yarısından fazlaysa derleme sistemi hata verir.

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. Her grup adında bir BOARD_group_SIZE ve BOARD_group_PARTITION_LIST değişkeni bulunur. A/B cihazlarda grup adları dahili olarak slot son ekiyle belirtildiği için 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ı aşağıda 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'i group_bar içine yerleştiren örnek bir cihazı aşağıda görebilirsiniz: 

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 lansman cihazları için tüm grupların maksimum boyutlarının toplamı en fazla şu olmalıdır:
    BOARD_SUPER_PARTITION_SIZE - genel maliyet
    Sanal A/B'yi uygulama başlıklı makaleyi inceleyin.
  • A/B lansman cihazları için tüm grupların maksimum boyutlarının toplamı şu olmalıdır:
    BOARD_SUPER_PARTITION_SIZE / 2 - genel giderler
  • A/B olmayan cihazlar ve sonradan A/B yapılandırılmış cihazlar için tüm grupların maksimum boyutlarının toplamı şu olmalıdır:
    BOARD_SUPER_PARTITION_SIZE - genel giderler
  • Derleme sırasında, bir güncelleme grubundaki her bölümün resimlerinin 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 yedek 4 MiB'tir ancak cihazın ihtiyacına göre daha büyük bir yedek seçebilirsiniz.

Dinamik bölümlerin boyutunu ayarlama

Dinamik bölümlerden önce, gelecekteki güncellemeler için yeterli alana sahip olmalarını sağlamak amacıyla bölüm boyutları fazladan ayrılıyordu. Gerçek boyut olduğu gibi alındı ve salt okunur bölümlerinin çoğunun 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ölmelerin yer israf etmediğinden ve mümkün olan en küçük boyuta ayrıldığından emin olmak

Kodlanmış bir bölüm boyutu belirtilmezse salt okunur ext4 resimleri için derleme sistemi otomatik olarak minimum boyutu ayırır. Derleme sistemi, dosyanın mümkün olduğunca az kullanılmayan alana sahip olması için resmi sığdırır. Bu sayede cihaz, OTA'lar için kullanılabilecek alanı boşa harcamaz.

Ayrıca, blok düzeyinde tekilleştirme etkinleştirilerek ext4 resimleri 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

Bir bölüme minimum boyutun otomatik olarak atanması istenmiyorsa bölüm boyutunu kontrol etmenin iki yolu vardır. BOARD_partitionIMAGE_PARTITION_RESERVED_SIZE ile minimum boş alan miktarını belirtebilir veya dinamik bölümleri belirli bir boyuta zorlamak için BOARD_partitionIMAGE_PARTITION_SIZE belirtebilirsiniz. Gerekli olmadıkça bunların hiçbiri önerilmez.

Örnek: 

BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800

Bu işlem, product.img dosya sisteminin 50 MiB kullanılmayan alana sahip olmasını zorunlu kılar.

Kök olarak sistem değişiklikleri

Android 10 ile kullanıma sunulan cihazlar, kök olarak sistem kullanmamalıdır.

Dinamik bölümlere sahip cihazlar (dinamik bölümlerle kullanıma sunulur veya dinamik bölümlere sonradan eklenir) kök olarak sistem kullanmamalıdır. Linux çekirdeği super bölümünü yorumlayamadığı için system'i bağlayamıyor. system artık ramdisk'te bulunan ilk aşama init tarafından monte edilir.

BOARD_BUILD_SYSTEM_ROOT_IMAGE ayarını yapmayın. Android 10'da BOARD_BUILD_SYSTEM_ROOT_IMAGE işaretçisi 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'ü true olarak ayarlamak, PRODUCT_USE_DYNAMIC_PARTITIONS de true olduğunda derleme hatasına neden olur.

BOARD_USES_RECOVERY_AS_BOOT doğru olarak ayarlandığında, kurtarma görüntüsü, kurtarma işleminin ramdisk'ini içeren boot.img olarak oluşturulur. Daha önce önyükleyici, hangi modda başlatılacağına karar vermek için skip_initramfs kernel komut satırı parametresini kullanıyordu. Android 10 cihazlarda, önyükleme skip_initramfs değerini çekirdek komut satırına İLETMEMELİDİR. Bunun yerine, önyükleyici, kurtarma işlemini atlayıp normal Android'i başlatmak için androidboot.force_normal_boot=1 değerini iletmelidir. Android 12 veya sonraki sürümlerle kullanıma sunulan cihazlar, androidboot.force_normal_boot=1 değerini iletmek için bootconfig kullanmalıdır.

AVB yapılandırma değişiklikleri

Android Doğrulanmış Başlatma 2.0 kullanılırken cihazda zincirlenmiş bölüm tanımlayıcısı kullanılmıyorsa değişiklik gerekmez. Ancak zincirlenmiş bölümler kullanılıyorsa ve doğrulanmış bölümlerden biri dinamikse değişiklik yapılması gerekir.

system ve vendor bölümleri için vbmeta'ü zincirleyen bir cihazın örnek yapılandırmasını aşağıda 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ükleme yükleyici, system ve vendor bölümlerinin sonunda bir vbmeta altbilgisi bulmayı bekler. Bu bölümler artık önyükleme yü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ümünü ekleyin. A/B cihazları için vbmeta_system_a, vbmeta_system_b, vbmeta_vendor_a ve vbmeta_vendor_b değerlerini ekleyin. Bu bölümlerden bir veya daha fazlasını ekleyecekseniz bunlar vbmeta bölümüyle aynı boyutta olmalıdır.
  • VBMETA_ ekleyerek yapılandırma işaretlerini yeniden adlandırın ve dizmenin hangi bölümleri kapsadığı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 cihaz bu bölümlerden birini, ikisini birden veya hiçbirini kullanabilir. Değişiklikler yalnızca mantıksal bir bölüme zincirleme yaparken gerekir.

AVB bootloader değişiklikleri

Önyükleyiciye libavb yerleştirilmişse aşağıdaki yamaları ekleyin:

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

  • 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: Support vbmeta blobs in beginning of partition."

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

Çekirdek komut satırına androidboot.boot_devices adlı yeni bir parametre eklenmelidir. Bu, init tarafından /dev/block/by-name sembolik bağlantılarını etkinleştirmek için kullanılır. ueventd tarafından oluşturulan temel adla bağlantılı simge bağlantısı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 kullanıma sunulan cihazlar, androidboot.boot_devices'ü init'a aktarmak için bootconfig'i kullanmalıdır.

Örneğin, adla süper bölüm sembolik bağlantısı /dev/block/platform/soc/100000.ufshc/by-name/super ise komut satırı parametresini BoardConfig.mk dosyasına 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

Cihaz ağacı ve cihaz ağacı yer paylaşımları 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şiklikler yapılmalıdır:

  • fs_mgr flags alanında logical işareti ve Android 10'da kullanıma sunulan first_stage_mount işareti bulunmalıdır. Bu işaret, bir bölümün ilk aşamada monte edileceğini belirtir.
  • Bir bölüm, avb=vbmeta partition name değerini fs_mgr işaretçisi olarak belirtebilir. Ardından, belirtilen vbmeta bölümü, herhangi bir cihazı bağlamaya çalışmadan önce ilk aşama init tarafından başlatılır.
  • dev alanı, bölüm adıdır.

Aşağıdaki fstab girişleri, sistem, tedarikçi 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'ine kopyalayın.

SELinux değişiklikleri

Süper bölüm blok cihazı super_block_device etiketiyle işaretlenmelidir. Örneğin, adla süper bölüm simge bağlantısı /dev/block/platform/soc/100000.ufshc/by-name/super ise file_contexts dosyasına aşağıdaki satırı ekleyin: 

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

fastbootd

Önyükleme yükleyici (veya kullanıcı alanı dışındaki herhangi bir önyükleme aracı), dinamik bölümleri anlayamadığından bunları önyükleyemez. Bu sorunu gidermek için cihazların, fastboot protokolünün kullanıcı alanındaki bir uygulamasını (fastbootd) kullanması gerekir.

fastbootd'nin nasıl uygulanacağı hakkında daha fazla bilgi için Fastboot'u kullanıcı alanına taşıma başlıklı makaleyi inceleyin.

adb remount

eng veya userdebug derlemeleri kullanan geliştiriciler için adb remount hızlı iterasyon için son derece faydalıdır. Dinamik bölümler, her dosya sisteminde artık boş yer olmadığı için adb remount için sorun teşkil eder. Bu sorunu gidermek için cihazlar overlayfs'i etkinleştirebilir. Süper bölümde 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 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.

Overlayfs'in nasıl etkinleştirileceği hakkında daha fazla bilgi için AOSP'deki overlayfs README dosyasını inceleyin.

Android cihazları yükseltme

Bir cihazı Android 10'a yükseltirseniz ve OTA'ya dinamik bölüm desteği eklemek isterseniz yerleşik bölüm tablosunu değiştirmeniz gerekmez. Ek yapılandırma gerekebilir.

Cihaz yapılandırmasında değişiklik

Dinamik bölümlemeyi sonradan eklemek için device.mk dosyasına aşağıdaki işaretleri ekleyin: 

PRODUCT_USE_DYNAMIC_PARTITIONS := true
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true

Tahta yapılandırmasında yapılan değişiklikler

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

  • BOARD_SUPER_PARTITION_BLOCK_DEVICES değerini, dinamik bölüm kapsamlarını depolamak için kullanılan blok cihazlarının listesine ayarlayın. Bu, cihazdaki mevcut fiziksel bölümlerin adlarının listesidir.
  • BOARD_SUPER_PARTITION_partition_DEVICE_SIZE değerini sırasıyla BOARD_SUPER_PARTITION_BLOCK_DEVICES'teki her blok cihazın boyutuna ayarlayın. Bu, cihazdaki mevcut fiziksel bölümlerin boyutlarının listesidir. Bu genellikle mevcut kart yapılandırmalarında BOARD_partitionIMAGE_PARTITION_SIZE şeklindedir.
  • BOARD_SUPER_PARTITION_BLOCK_DEVICES'daki tüm bölümler için mevcut BOARD_partitionIMAGE_PARTITION_SIZE ayarını kaldırın.
  • BOARD_SUPER_PARTITION_SIZE değerini BOARD_SUPER_PARTITION_partition_DEVICE_SIZE değerlerinin toplamı olarak ayarlayın.
  • BOARD_SUPER_PARTITION_METADATA_DEVICE değerini, dinamik bölüm meta verilerinin depolandığı blok cihaz olarak ayarlayın. Aşağıdakilerden biri olmalıdır: BOARD_SUPER_PARTITION_BLOCK_DEVICES. Bu değer genellikle system olarak ayarlanır.
  • Sırasıyla BOARD_SUPER_PARTITION_GROUPS, BOARD_group_SIZE ve BOARD_group_PARTITION_LIST değerlerini ayarlayın. Ayrıntılar için Yeni cihazlarda anakart yapılandırmasında yapılan değişiklikler başlıklı makaleyi inceleyin.

Örneğin, cihazda zaten sistem ve tedarikçi 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 şu anakart 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 bloğu 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 cihaz olarak kullanmak istiyorsunuz ve adlarına göre sembolik bağlantıları system_block_device olarak işaretlenmiş: 

/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 Yeni cihazlarda dinamik bölümleri uygulama başlıklı makaleyi inceleyin.

Geri yükleme güncellemeleri hakkında daha fazla bilgi edinmek için Dinamik bölüm içermeyen A/B cihazlar için OTA başlıklı makaleyi inceleyin.

Fabrika görüntüleri

Dinamik bölüm desteğiyle kullanıma sunulan cihazlarda, kullanıcı alanına önyükleme yapmak diğer önyükleme yöntemlerinden daha yavaş olduğundan fabrika görüntülerini yüklemek için kullanıcı alanı hızlı önyükleme özelliğini kullanmaktan kaçının.

Bu sorunu gidermek için make dist artık doğrudan süper bölüme yazılabilen ek bir super.img resmi oluşturuyor. Mantıksal bölümlerin içeriğini otomatik olarak gruplandırır. Yani super bölüm meta verilerine ek olarak system.img, vendor.img vb. içerir. Bu resim, ek araç olmadan veya fastbootd kullanılarak doğrudan super bölümüne yazılabilir. Derleme işleminden sonra super.img, ${ANDROID_PRODUCT_OUT} içine yerleştirilir.

Dinamik bölümle başlatılan A/B cihazlarda super.img, A yuvasındaki resimleri içerir. Süper görüntüyü doğrudan yükledikten sonra, cihazı yeniden başlatmadan önce A yuvasını önyüklenebilir olarak işaretleyin.

make dist, geriye dönük donanım güncellemesi yapılan cihazlar için doğrudan ilgili fiziksel bölümlere yazılabilen bir dizi super_*.img resmi oluşturur. Örneğin, BOARD_SUPER_PARTITION_BLOCK_DEVICES sistem tedarikçisi olduğunda make dist, super_system.img ve super_vendor.img'yi oluşturur. Bu resimler, target_files.zip'teki OTA klasörüne yerleştirilir.

Cihaz eşleyici depolama alanı cihazı ayarı

Dinamik bölümleme, bir dizi nondeterministic device-mapper nesnesini barındırır. Bunların tümü beklendiği gibi oluşturulmayabilir. Bu nedenle, tüm bağlamaları izlemeniz ve ilişkili tüm bölümlerin Android özelliklerini temel depolama cihazlarıyla güncellemeniz gerekir.

init içindeki bir mekanizma, bağlamaları izler ve Android mülklerini eşzamansız olarak günceller. Bu işlemin belirli bir süre içinde gerçekleşmesi garanti edilmez. Bu nedenle, tüm on property tetikleyicilerinin tepki vermesi için yeterli süre tanımanız gerekir. Özellikler dev.mnt.blk.<partition> şeklindedir. Bu ifadede <partition>, root, system, data veya vendor olabilir. Her mülk, 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 mülklerinin kurallar kapsamında genişletilmesine olanak tanır. Depolama cihazları, platform tarafından aşağıdaki gibi komutlarla gerektiği şekilde 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 etkinleşir ve epoll loop değerleri güncellenmeye başlar. Ancak mülk tetikleyicileri init'ün sonlarına kadar etkin olmadığından root, system veya vendor ile ilgili işlemleri yapmak için ilk önyükleme aşamalarında kullanılamaz. init.rc komut dosyalarının early-fs'de geçersiz kılması (çeşitli daemon'lar ve tesisler başladığında) için çekirdek varsayılan read_ahead_kb değerinin yeterli olmasını bekleyebilirsiniz. Bu nedenle Google, aşağıdaki örneklerde gösterildiği gibi işlemleri zamanlamak ve yarış koşullarını önlemek için on property özelliğini sys.read_ahead_kb gibi init.rc kontrollü bir mülkle 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}