Dinamik bölümlendirme 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şama init sırasında bu meta veriler ayrıştırılır ve doğrulanır ve her bir dinamik bölümü temsil edecek şekilde 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 bootloader'ın 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 ile 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ünün A/B yuvaları dahili olarak işlediği için 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 cihazlarda bu, her iki yuvayı 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 çekirdek komut satırı seçeneği androidboot.super_partition boş olmalıdır.

Bölüm hizası

super bölümü düzgün şekilde hizalanmamışsa device-mapper modülü daha az verimli çalışabilir. super bölümünün, blok katmanı tarafından belirlenen minimum G/Ç istek boyutuna hizalanması ZORUNLUDUR. 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 inceleyerek 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 uzaklığı 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 görebilirsiniz: 

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 başlatma cihazları için tüm grupların maksimum boyutlarının toplamı en fazla şu kadar olmalıdır:
    BOARD_SUPER_PARTITION_SIZE - ek yük
    Sanal A/B'yi Uygulama bölümüne bakın.
  • 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 maliyet
  • 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'dir 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ümlerin çoğunun dosya sisteminde bir miktar boş alan vardı. Dinamik bölümlerdeki 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

Salt okunur ext4 görüntülerinde, sabit kodlu bölüm boyutu belirtilmediyse derleme sistemi minimum boyutu otomatik olarak ayırır. Derleme sistemi görüntüyü sığdırır, böylece dosya sisteminde kullanılmayan alan mümkün olduğunca az olur. Bu, cihazın OTA'lar için kullanılabilecek alanı harcamasını önler.

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ümün minimum boyutunun otomatik olarak ayrılması istenmiyorsa bölüm boyutunu kontrol etmenin iki yolu vardır. BOARD_partitionIMAGE_PARTITION_RESERVED_SIZE ile minimum boş alan 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 sunulsun veya sonradan eklensin) 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 özelliğini ayarlamayı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 değerinin true olarak ayarlanması, PRODUCT_USE_DYNAMIC_PARTITIONS aynı zamanda 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 çekirdek komut satırı parametresini kullanıyordu. Android 10 cihazlarda önyükleme aracı, 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 zincirini kullanan bir cihaza ilişkin örnek yapılandırmayı aşağıda görebilirsiniz. 

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

Bootloader, bu yapılandırmayla system ve vendor bölümlerinin sonunda bir vbmeta altbilgi 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 bayraklarını yeniden adlandırın ve zincirlemenin 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 veya ikisini birden kullanıyor olabilir ya da hiçbirini kullanmıyor olabilir. Yalnızca mantıksal bir bölümlendirmeye zincir oluştururken değişiklik yapılması gerekir.

AVB bootloader değişiklikleri

Bootloader'da libavb yerleşikse aşağıdaki yamaları ekleyin:

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

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

Ç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ıyı etkinleştirmek için kullanılır. Bu, ueventd tarafından oluşturulan temel ad sembolü bağlantısının cihaz yolu bileşeni (yani /dev/block/platform/device-path/by-name/partition-name) olmalıdır. Android 12 veya sonraki sürümlerle başlatılan cihazlar androidboot.boot_devices eklentisini init uygulamasına 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şiklik 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ümlendirme, avb=vbmeta partition name öğesini fs_mgr işareti olarak belirtebilir ve ardından belirtilen vbmeta bölümü, herhangi bir cihaz eklenmeye ç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'e 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

hızlı önyükleme

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

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

adb remount

adb remount, eng veya userdebug derlemelerini kullanan geliştiriciler için hızlı iterasyon açısından son derece yararlı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 yer paylaşımlı fişleri 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ümlendirme desteğini dahil etmek 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, BOARD_SUPER_PARTITION_BLOCK_DEVICES'deki her blok cihazın boyutlarına göre ayarlayın. Bu, cihazdaki mevcut fiziksel bölümlerin boyutlarının listesidir. Bu değer, mevcut kart yapılandırmalarında genellikle BOARD_partitionIMAGE_PARTITION_SIZE değerindedir.
  • 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 toplamına 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 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 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 cihazlara dinamik bölümleri uygulama bölümünü 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 ayarı 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, güçlendirme cihazları için doğrudan ilgili fiziksel bölümlere yansıtılabilecek bir super_*.img görüntü grubu 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 görüntüler, target_files.zip konumundaki OTA klasörüne yerleştirilir.

Cihaz haritalayıcı depolama 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 sürenin belirli bir dönem içinde olacağı garanti edilmez. Bu nedenle, tüm on property tetikleyicilerinin tepki vermesi için yeterli süre sağlamanız gerekir. Örneğin <partition>, root, system, data veya vendor olduğu dev.mnt.blk.<partition> mülklerdir. 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 olduğu gibi operasyonların zamanlamasını yönetmek ve yarış koşullarını önlemek için on property özelliğini sys.read_ahead_kb gibi init.rc kontrollü bir özellik ile 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}