Dinamik bölümleri uygulama

Dinamik bölümlendirme, Linux çekirdeğindeki dm-linear device-mapper 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şamada init bu meta veriler ayrıştırılıp doğrulanır ve her dinamik bölümü temsil etmek için sanal blok cihazlar oluşturulur.

OTA uygulandığında dinamik bölümler otomatik olarak oluşturulur, yeniden boyutlandırılır veya gerektiğinde silinir. A/B cihazlarda meta verilerin iki kopyası bulunur ve değişiklikler yalnızca hedef yuvanın kopyasına uygulanır.

Dinamik bölümler kullanıcı alanında uygulandığından, önyükleyici tarafından gereken 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, söz konusu gruptaki bölümlerin kullanabileceği maksimum alanı sınırlar. Örneğin, system ve vendor, system ve vendor'nin 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 kullanıma sunulan yeni cihazlarda dinamik bölümlerin nasıl uygulanacağı ayrıntılı olarak açıklanmaktadır. Mevcut cihazları güncellemek için Android cihazları yükseltme 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ü, A/B yuvalarını dahili olarak işler. 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 ö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 alanın boyutunu içermelidir. Şekil 1'de, dinamik bölümlere dönüştürmeden önce ve sonraki örnek bir bölüm tablosu gösterilmektedir.

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

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

  • Sistem
  • Satıcı
  • Ürün
  • System Ext
  • ODM

Android 10 ile kullanıma sunulan cihazlarda, sysprop komutunun ro.boot.super_partition 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 hizalanmamışsa device-mapper modülü daha az verimli çalışabilir. super bölümü, blok katmanı tarafından belirlenen minimum G/Ç isteği boyutuna göre hizalanmalıdır. Varsayılan olarak, derleme sistemi (lpmake aracılığıyla, super bölüm görüntüsünü oluşturur) her dinamik bölüm için 1 MiB hizalamanın yeterli olduğunu varsayar. Ancak tedarikçiler, super bölümünün düzgün şekilde hizalandığından emin olmalıdır.

Bir blok cihazı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ün hizalamasını da 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 öğesine aşağıdaki işareti ekleyin: 

PRODUCT_USE_DYNAMIC_PARTITIONS := true

Jamboard yapılandırma değişiklikleri

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

BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

A/B cihazlarda, derleme sistemi dinamik bölüm resimlerinin toplam boyutu super bölüm boyutunun yarısından fazlaysa 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 BOARD_group_SIZE ve BOARD_group_PARTITION_LIST değişkeni bulunur. A/B cihazlarda, grup adlarına dahili olarak yuva son eki eklendiğinden bir grubun maksimum boyutu yalnızca bir yuvayı kapsamalıdır.

Aşağıda, tüm bölümleri example_dynamic_partitions adlı bir gruba yerleştiren bir cihaz örneği verilmiştir: 

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'yi group_bar'ye yerleştiren bir cihaz örneği: 

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ında, 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 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 - ek yük
  • A/B olmayan cihazlar ve A/B'ye dönüştürülen cihazlar için tüm grupların maksimum boyutlarının toplamı şu olmalıdır:
    BOARD_SUPER_PARTITION_SIZE - ek yük
  • 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 gerekir. 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, gelecekteki güncellemeler için yeterli alan olduğundan emin olmak amacıyla bölüm boyutları fazla ayrılıyordu. Gerçek boyut olduğu gibi alınmış ve salt okunur bölümlerin çoğunun dosya sisteminde bir miktar boş alan bulunmuştur. 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ına yol açmadığından ve mümkün olan en küçük boyuta ayrıldığından emin olmak çok önemlidir.

Salt okunur ext4 resimler için, sabit kodlanmış bir bölüm boyutu belirtilmemişse derleme sistemi otomatik olarak minimum boyutu ayırır. Derleme sistemi, dosya sisteminde mümkün olduğunca az kullanılmayan alan olacak şekilde görüntüyü yerleştirir. Bu sayede cihaz, OTA'lar için kullanılabilecek alanı boşa harcamaz.

Ayrıca, ext4 görüntüleri blok düzeyinde 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

Bölüm 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 miktarını belirtebilir veya dinamik bölümleri belirli bir boyuta zorlamak için BOARD_partitionIMAGE_PARTITION_SIZE değerini belirtebilirsiniz. Gerekli olmadığı sürece bu yöntemlerin ikisi de önerilmez.

Örneğin: 

BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800

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

System-as-root değişiklikleri

Android 10 ile kullanıma sunulan cihazlar, sistemin root olarak kullanıldığı bir yapılandırmaya sahip olmamalıdır.

Dinamik bölümlerle başlatılan veya dinamik bölümlerin sonradan eklendiği cihazlarda sistem kök olarak kullanılmamalıdır. Linux çekirdeği super bölümünü yorumlayamadığı için system bölümünü bağlayamıyor. system artık ramdisk'te bulunan init ilk aşaması tarafından monte ediliyor.

BOARD_BUILD_SYSTEM_ROOT_IMAGE ayarlamayın. Android 10'da BOARD_BUILD_SYSTEM_ROOT_IMAGE işareti 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_USE_DYNAMIC_PARTITIONS değeri de true olduğunda derleme hatasına neden olur.

BOARD_USES_RECOVERY_AS_BOOT true olarak ayarlandığında kurtarma görüntüsü, kurtarmanın ramdisk'ini içeren boot.img olarak oluşturulur. Daha önce, önyükleyici hangi modda önyükleme yapılacağına karar vermek için skip_initramfs çekirdek komut satırı parametresini kullanıyordu. Android 10 cihazlarda önyükleyici, çekirdek komut satırına skip_initramfs iletmemelidir. Bunun yerine, önyükleyici, kurtarma modunu atlayıp normal Android'i başlatmak için androidboot.force_normal_boot=1 değerini iletmelidir. Android 12 veya sonraki sürümlerle piyasaya sürülen cihazlar, androidboot.force_normal_boot=1'yı geçmek için bootconfig'i kullanmalıdır.

AVB yapılandırma değişiklikleri

Android Doğrulanmış Başlatma 2.0 kullanılırken cihaz zincirleme bölüm tanımlayıcıları kullanmıyorsa herhangi bir değişiklik yapılması gerekmez. Ancak zincirleme 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 zincirleme kullanan 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ırmada, ö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ülemediğinden (super içinde yer alırlar) 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 vbmeta bölümüyle aynı boyutta olmalıdır.
  • VBMETA_ ekleyerek yapılandırma işaretlerini yeniden adlandırın ve zincirlemenin hangi bölümlere kadar 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 cihaz bu bölümlerden birini, ikisini veya hiçbirini kullanmıyor olabilir. Değişiklikler yalnızca mantıksal bir bölüme zincirleme yaparken gereklidir.

AVB bootloader değişiklikleri

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

Zincirleme bölümler kullanılıyorsa 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 yeni bir parametre (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 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 değerini init değerine iletmek 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 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 ş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 kullanıma sunulan logical işaretini ve bir bölümün ilk aşamada bağlanacağını belirten first_stage_mount işaretini içermelidir.
  • Bir bölüm, avb=vbmeta partition name olarak bir fs_mgr işareti 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ı olmalıdır.

Aşağıdaki fstab girişleri, yukarıdaki kurallara göre sistemi, satıcıyı ve ürünü 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, ada göre süper bölümleme sembolik 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ükleyici (veya kullanıcı alanı dışındaki herhangi bir yanıp sönme aracı) dinamik bölümleri anlamadığından bunları yanıp söndüremez. Bu sorunu gidermek için cihazların fastbootd adlı fastboot protokolünün kullanıcı alanı uygulamasını kullanması gerekir.

fastbootd'yi uygulama hakkında daha fazla bilgi için Moving Fastboot to User Space (Fastboot'u Kullanıcı Alanına Taşıma) başlıklı makaleyi inceleyin.

adb remount

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

overlayfs'yi etkinleştirme hakkında daha fazla bilgi için AOSP'deki overlayfs README dosyasına bakın.

Android cihazları yükseltme

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

Cihaz yapılandırma değişiklikleri

Dinamik bölümlemeyi geriye dönük olarak uygulamak için device.mk bölümüne aşağıdaki işaretleri ekleyin: 

PRODUCT_USE_DYNAMIC_PARTITIONS := true
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true

Jamboard yapılandırma değişiklikleri

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

  • BOARD_SUPER_PARTITION_BLOCK_DEVICES değerini, dinamik bölümlerin kapsamlarını depolamak için kullanılan engellenen cihazları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 içindeki her bir blok cihazı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_partitionIMAGE_PARTITION_SIZE şeklindedir.
  • BOARD_SUPER_PARTITION_BLOCK_DEVICES içindeki 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ı olarak ayarlayın.
  • BOARD_SUPER_PARTITION_METADATA_DEVICE değerini, dinamik bölüm meta verilerinin depolandığı cihazı engelleyecek şekilde ayarlayın. Şunlardan 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 kart yapılandırması değişiklikleri başlıklı makaleye 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 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 istiyorsunuz ve adla sembolik bağlantıları system_block_device olarak işaretleniyor: 

/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.

Retrofit güncellemeleri hakkında daha fazla bilgi için Dinamik Bölümler Olmayan A/B Cihazlar İçin OTA başlıklı makaleyi inceleyin.

Fabrika görüntüleri

Dinamik bölümleri destekleyen bir cihazı kullanıma sunarken fabrika görüntülerini yüklemek için kullanıcı alanı fastboot'u kullanmaktan kaçının. Kullanıcı alanına önyükleme, diğer yükleme yöntemlerine göre daha yavaştır.

Bu sorunu gidermek için make dist artık doğrudan süper bölüme yüklenebilen ek bir super.img görüntü oluşturuyor. Mantıksal bölümlerin içeriklerini otomatik olarak paketler. Bu nedenle, super bölüm meta verilerine ek olarak system.img, vendor.img vb. içerir. Bu görüntü, ek araçlar olmadan veya fastbootd kullanmadan doğrudan super bölümüne yüklenebilir. Derlemeden sonra super.img, ${ANDROID_PRODUCT_OUT} içine yerleştirilir.

Dinamik bölümlerle kullanıma sunulan A/B cihazları için super.img, A alanındaki görüntüleri içerir. Super görüntüsü doğrudan yüklendikten sonra cihazı yeniden başlatmadan önce A yuvasını önyüklenebilir olarak işaretleyin.

Retrofit cihazlar için make dist, doğrudan ilgili fiziksel bölümlere yüklenebilen bir dizi super_*.img görüntüsü oluşturur. Örneğin, make dist, super_system.img ve super_vendor.img oluşturur. BOARD_SUPER_PARTITION_BLOCK_DEVICES, sistem satıcısıdır. Bu resimler, target_files.zip konumundaki OTA klasörüne yerleştirilir.

Cihaz eşleyici depolama cihazı ayarlama

Dinamik bölümleme, deterministik olmayan çeşitli device-mapper nesnelerini barındırır. Bunların tümü beklendiği gibi başlatılamayabilir. Bu nedenle, tüm bağlama işlemlerini izlemeniz ve ilişkili tüm bölümlerin Android özelliklerini temel alınan depolama cihazlarıyla güncellemeniz gerekir.

init içindeki bir mekanizma, bağlama işlemlerini izler ve Android özelliklerini eşzamansız olarak günceller. Bu işlemin belirli bir süre içinde tamamlanacağı garanti edilmez. Bu nedenle, tüm on property tetikleyicilerinin tepki vermesi için yeterli süre tanımalısınız. Özellikler dev.mnt.blk.<partition> şeklindedir. Örneğin, <partition>, root, system, data veya vendor olabilir. Her özellik, bu ö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 kapsamında genişletilmesine olanak tanır. Depolama cihazları, platform tarafından gerektiğinde aşağıdaki gibi komutlarla 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ıktan sonra epoll loop etkin hale gelir ve değerler güncellenmeye başlar. Ancak mülk tetikleyicileri init'nın sonlarına kadar etkin olmadığından root, system veya vendor'ü işlemek için ilk başlatma aşamalarında kullanılamazlar. init.rc komut dosyaları early-fs içinde geçersiz kılınana kadar (çeşitli arka plan programları ve tesisler başlatıldığında) çekirdek varsayılanı read_ahead_kb'nın yeterli olmasını bekleyebilirsiniz. Bu nedenle Google, işlemlerin zamanlamasını yönetmek ve yarış durumu sorunlarını önlemek için on property özelliğini sys.read_ahead_kb gibi init.rc tarafından kontrol edilen bir mülkle birlikte kullanmanızı önerir. Örneğin:

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}