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 bir dinamik bölümün adlarını ve blok aralıklarını listeleyen meta verileri içerir. Birinci 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 etmek için sanal blok aygıtları oluşturulur.

Bir OTA uygulanırken, dinamik bölümler otomatik olarak oluşturulur, yeniden boyutlandırılır veya gerektiğinde silinir. A/B cihazları için meta verilerin 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ü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 toplam system ve vendor boyutunu kısıtlayan bir gruba ait olabilir.

Yeni cihazlarda dinamik bölümler uygulayın

Bu bölüm, dinamik bölümlerin Android 10 ve sonraki sürümleriyle başlatılan yeni cihazlarda nasıl uygulanacağını ayrıntılarıyla açıklar. 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 adlı bir bölüm oluşturun. super bölüm, A/B yuvalarını dahili olarak yönetir, 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ölme Tablosundan (GPT) kaldırılmalıdır. Satıcıya özel bölümlerin dinamik olması gerekmez ve GPT'ye yerleştirilebilir.

Not: super içine userdata veya başka herhangi bir kalıcı okuma-yazma bölümü yerleştirmekten kaçının.

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.

Ş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şlayan 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 hizalanmamışsa, 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, oluşturma 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'lik bir 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.

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 konfigürasyon 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

Anakart konfigürasyon değişiklikleri

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

BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

A/B cihazları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 BOARD_SUPER_PARTITION_GROUPS değişkenindeki grupları listeleyin. Her grup adı daha sonra bir BOARD_ group _SIZE ve BOARD_ group _PARTITION_LIST değişkenine sahiptir. A/B cihazları için, bir grubun maksimum boyutu yalnızca bir yuvayı kapsamalıdır, çünkü grup adları dahili olarak yuva eklidir.

İş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

Not: super ve super_partition gibi derleme değişkenleriyle çakışabilecek adlar seçmekten kaçının. Okunabilirlik için foo_dp , foo_dynamic_partitions , foo_dp_group , super_foo veya group_foo gibi adlar seçin (burada foo, belirli bir grubu güncelleyen tarafın adıdır). Örneğin, group_OEM veya group_VENDOR .

Not: Cihazınızda bir veya daha fazla güncelleme grubu olabilir.

• Sanal A/B başlatma cihazları için, tüm grupların maksimum boyutlarının toplamı en fazla aşağıdaki gibi 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 - genel gider
• A/B olmayan cihazlar ve retrofit 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
• 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 gerekir. 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ı fazla tahsis edildi. 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 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 en küçük boyuta tahsis edilmesini sağlamak çok önemlidir.

Salt okunur ext4 görüntüleri için, herhangi bir sabit kodlanmış bölüm boyutu belirtilmezse yapı sistemi otomatik olarak minimum boyutu tahsis eder. Yapı sistemi, dosya sisteminde mümkün olduğunca az kullanılmayan alan kalacak şekilde görüntüyü sığdırır. 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 tahsis edilmesi istenmiyorsa, bölüm boyutunu kontrol etmenin 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.

Not: Derleme sistemi yalnızca ext4 dosya sistemi görüntülerine ve yalnızca yapı tarafından üretilen görüntülere en uygun olabilir . Önceden oluşturulmuş görüntüler veya diğer dosya sistemlerini kullanan görüntüler için, dosya sisteminin disk alanını boşa harcamadığından emin olmak önemlidir.

Kök olarak sistem değişiklikleri

Android 10 ile başlatılan cihazlar root olarak sistem kullanmamalıdır.

Dinamik bölümlere sahip aygıtlar (dinamik bölümlerle birlikte başlatılsın veya bunları güçlendirsin), kök olarak sistem kullanmamalıdır. Linux çekirdeği super bölümü yorumlayamaz ve bu nedenle system kendisini monte edemez. system şimdi ramdisk'te bulunan birinci 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 öğesinin true olarak ayarlanması, PRODUCT_USE_DYNAMIC_PARTITIONS de 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 kipe önyükleme yapılacağına karar vermek için skip_initramfs çekirdek komut satırı parametresini kullanıyordu. Android 10 aygıtları için önyükleyici, skip_initramfs çekirdek komut satırına GEÇİRMEMELİDİR. Bunun yerine, bootloader, kurtarmayı atlamak ve normal Android'i başlatmak için androidboot.force_normal_boot=1 geçmelidir. Android 12 veya sonraki sürümleriyle başlatılan cihazların androidboot.force_normal_boot=1 dosyasını geçmek için bootconfig kullanması gerekir.

AVB yapılandırma değişiklikleri

Dikkat: Dinamik bölümler, Android Verified Boot (AVB) gerektirir ve Verified Boot 1.0 ile çalışmaz.

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

Burada, system ve vendor bölümleri için vbmeta zincirleyen bir aygıt için örnek bir yapılandırma verilmiştir.

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ırma ile ö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.

• 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ını ekliyorsanız, bunlar vbmeta bölümüyle aynı boyutta olmalıdır.
• Yapılandırma işaretlerini VBMETA_ ekleyerek 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 kullanmı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 libavb gömülüyse, aşağıdaki yamaları ekleyin:

• 818cf56740775446285466eda984acedd4baeac0 — "libavb: Yalnızca cmdline ihtiyaç duyduğunda bölüm GUID'lerini sorgula."
• 5abd6bc2578968d24406d834471adfd995a0c2e9 — "Sistem bölümünün olmamasına izin ver"
• 9ba3b6613b4e5130fa01a11d984c6b5f0eb3af05 — "AvbSlotVerifyData->cmdline NULL olabilir düzeltildi"

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."
  Not: Önceden, AvbOps get_size_of_partition uygulamak isteğe bağlıydı. Bu değişiklikten sonra gereklidir ve önyükleyici bu işlevi uygulamalıdır.

Ç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, yani /dev/block/platform/ device-path /by-name/ partition-name oluşturulan temel ada göre sembolik bağlantının aygıt yolu bileşeni olmalıdır. Android 12 veya sonraki sürümleriyle başlatılan cihazların, androidboot.boot_devices init öğesine geçirmek için bootconfig kullanması gerekir.

Örneğin, süper bölüm by-name 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ı 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ı, logical bayrağı ve Android 10'da tanıtılan, birinci aşamada bir bölümün bağlanacağını 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ğlama girişiminde bulunmadan ö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

Not: A/B olmayan bir cihaz için slotselect dahil etmeyin.

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, ada göre süper bölüm sembolik bağlantısı /dev/block/platform/ soc/100000.ufshc /by-name/super , aşağıdaki satırı file_contexts 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 flash aracı) dinamik bölümleri anlamadığından, onları flash edemez. Bunu ele almak için cihazların, fastbootd adı verilen fastboot protokolünün bir kullanıcı alanı uygulamasını kullanması gerekir.

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 montajı

Eng veya userdebug yapılarını kullanan geliştiriciler için adb remount , hızlı yineleme için son derece yararlıdır. Dinamik bölümler, artık her dosya sisteminde boş alan olmadığı için adb remount için bir sorun oluşturur. Bunu ele almak için, cihazlar yer paylaşımlarını 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 overlayf'leri kullanır. Geçici bölüm, scratch olarak adlandırılır, bu nedenle bu adı diğer bölümler için kullanmayın.

Bindirmelerin nasıl etkinleştirileceği hakkında daha fazla bilgi için, AOSP'de bindirmeler README'ye bakın.

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

Cihaz konfigürasyon değişiklikleri

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

PRODUCT_USE_DYNAMIC_PARTITIONS := true
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true

Anakart konfigürasyon değişiklikleri

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

• BOARD_SUPER_PARTITION_BLOCK_DEVICES , dinamik bölümlerin uzantıları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 bir blok aygıtının boyutuna ayarlayın. Bu, cihazdaki mevcut fiziksel bölümlerin boyutlarının listesidir. Bu genellikle mevcut pano 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 öğesini BOARD_SUPER_PARTITION_ partition _DEVICE_SIZE olarak ayarlayın.
• BOARD_SUPER_PARTITION_METADATA_DEVICE , dinamik bölüm meta verilerinin depolandığı blok aygıtı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 olarak ayarlayın. Ayrıntılar için Yeni cihazlarda kart yapılandırması 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 cihazları, super_block_device_type özniteliği ile işaretlenmelidir. Örneğin, cihazın zaten system ve vendor bölümleri varsa, bunları dinamik bölümlerin uzantılarını depolamak için blok aygıtları olarak kullanmak istersiniz ve bunların ada 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 aygıtlarda dinamik bölümler uygulama .

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

Fabrika görüntüleri

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

Bunu ele almak için, make dist şimdi doğrudan süper bölüme flaşla gönderilebilen ek bir super.img görüntüsü oluşturuyor. Mantıksal bölümlerin içeriğini otomatik olarak paketler, yani super bölüm meta verilerine ek olarak system.img , vendor.img vb. içerir. Bu görüntü, herhangi bir ek araç kullanmadan veya fastbootd kullanmadan doğrudan super bölüme aktarılabilir. Derlemeden sonra super.img , ${ANDROID_PRODUCT_OUT} içine yerleştirilir.

Dinamik bölümlerle başlayan A/B cihazları 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 aygıtları 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, sistem satıcısı BOARD_SUPER_PARTITION_BLOCK_DEVICES olduğunda dist yapılarını super_system.img ve super_vendor.img make dist . 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 deterministik 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ı izlemeli ve ilgili tüm bölümlerin Android özelliklerini, temeldeki depolama cihazlarıyla güncellemelisiniz.

init içindeki bir mekanizma bağlamaları izler ve Android özelliklerini eşzamansız olarak günceller. Bunun için geçen sürenin belirli bir süre içinde olacağı garanti edilmez, bu nedenle tüm on property tetikleyicilerinin tepki vermesi için yeterli süre sağlamalısınız. Ö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 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 izin verir ve depolama aygıtları, aşağıdaki gibi komutlarla platform tarafından gerektiği gibi 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şama init komut işleme başladığında, epoll loop etkin 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 gerçekleştirmek için kullanılamazlar. init.rc betikleri early-fs geçersiz kılana kadar (çeşitli arka plan programları ve tesisler başladığında) çekirdek varsayılan read_ahead_kb yeterli olmasını bekleyebilirsiniz. Bu nedenle, Google, aşağıdaki örneklerde olduğu gibi, işlemlerin zamanlaması ile başa çıkmak ve yarış koşullarını önlemek için sys.read_ahead_kb gibi init.rc kontrollü bir özellik ile 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}