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 dinamik bölümün adlarını ve blok aralıklarını listeleyen meta verileri içerir. İlk aşama init
sırasında bu meta veriler ayrıştırılır ve doğrulanır ve her dinamik bölümü temsil edecek sanal blok aygıtları oluşturulur.
Bir OTA uygulanırken dinamik bölümler gerektiğinde otomatik olarak oluşturulur, yeniden boyutlandırılır veya silinir. A/B aygıtları için meta verinin 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ükleyicinin ihtiyaç duyduğu 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 kalmaları gerekir.
Her dinamik bölüm bir güncelleme grubuna ait olabilir. Bu gruplar, o gruptaki bölümlerin tüketebileceği maksimum alanı sınırlar. Örneğin, system
ve vendor
system
ve vendor
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 başlatılan yeni cihazlarda dinamik bölümlerin nasıl uygulanacağı ayrıntılı olarak açıklanmaktadır. 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
adında bir bölüm oluşturun. super
bölüm A/B yuvalarını dahili olarak yönetir, böylece A/B aygıtlarının ayrı super_a
ve super_b
bölümlerine ihtiyacı olmaz. Ö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. Satıcıya ö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 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.
Desteklenen dinamik bölümler şunlardır:
- Sistem
- SATICI
- Ürün
- Sistem Harici
- ODM
Android 10 ile başlatılan cihazlarda, sysprop ro.boot.super_partition
komutunun boş olması için çekirdek komut satırı seçeneği androidboot.super_partition
boş olmalıdır.
Bölüm hizalaması
super
bölüm düzgün şekilde hizalanmazsa cihaz eşleyici modülü daha az verimli çalışabilir. super
bölümün, blok katmanı tarafından belirlenen minimum G/Ç istek boyutuna göre hizalanması ZORUNLUDUR. Varsayılan olarak derleme sistemi ( super
bölüm görüntüsünü oluşturan lpmake
aracılığıyla), her dinamik bölüm için 1 MiB hizalamanın yeterli olduğunu varsayar. Ancak satıcılar super
bölümün doğru ş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 yapılandırma 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
Kart konfigürasyonu değişiklikleri
super
bölümün boyutunu ayarlamanız gerekir:
BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>
A/B aygıtlarında, dinamik bölüm görüntülerinin toplam boyutu super
bölüm boyutunun yarısından fazlaysa 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 grupları BOARD_SUPER_PARTITION_GROUPS
değişkeninde listeleyin. Bu durumda her grup adında bir BOARD_ group _SIZE
ve BOARD_ group _PARTITION_LIST
değişkeni bulunur. A/B aygıtları için, grup adları dahili olarak yuvaya eklendiğinden, 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ı burada 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
ise group_bar
yerleştiren örnek bir cihazı burada bulabilirsiniz:
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 olmalıdır:
BOARD_SUPER_PARTITION_SIZE
- genel gider
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 sonradan takılan A/B cihazları için tüm grupların maksimum boyutlarının toplamı şu şekilde olmalıdır:
BOARD_SUPER_PARTITION_SIZE
- genel gider - 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 gereklidir. 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, bölüm boyutları gelecekteki güncellemeler için yeterli alana sahip olduklarından emin olmak amacıyla aşırı tahsis ediliyordu. 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 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 düşük boyuta ayrılmasını sağlamak çok önemlidir.
Salt okunur ext4 görüntüleri için, sabit kodlanmış bölüm boyutu belirtilmemişse derleme sistemi otomatik olarak minimum boyutu tahsis eder. Derleme sistemi, dosya sisteminde mümkün olduğunca az kullanılmayan alan kalacak şekilde görüntüye uyar. Bu, cihazın OTA'lar için kullanılabilecek alanı boşa harcamamasını sağlar.
Ek olarak ext4 görüntüleri, blok düzeyinde veri tekilleştirme etkinleştirilerek daha 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
Minimum bölüm 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 belirtebilirsiniz 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
dosyasındaki dosya sistemini 50 MiB kullanılmayan alana sahip olmaya zorlar.
Kök olarak sistem değişiklikleri
Android 10 ile başlatılan cihazların kök olarak sistem kullanmaması gerekir.
Dinamik bölümlere sahip cihazlar (ister dinamik bölümlerle başlatılsın ister sonradan donatılsın) kök olarak sistemi kullanmamalıdır. Linux çekirdeği super
bölümü yorumlayamaz ve dolayısıyla system
kendisini bağlayamaz. system
artık ramdisk'te bulunan birinci aşama init
tarafından bağlanıyor.
BOARD_BUILD_SYSTEM_ROOT_IMAGE
ayarını yapmayı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ı bağlandığını ayırt etmek için kullanılır.
BOARD_BUILD_SYSTEM_ROOT_IMAGE
öğesini true
olarak ayarlamak, PRODUCT_USE_DYNAMIC_PARTITIONS
da true
olduğunda derleme hatasına neden olur.
BOARD_USES_RECOVERY_AS_BOOT
doğru olarak ayarlandığında kurtarma görüntüsü, kurtarmanın ramdiskini içeren boot.img olarak oluşturulur. Önceden, önyükleyici hangi moda önyükleme yapılacağına karar vermek için skip_initramfs
çekirdek komut satırı parametresini kullanıyordu. Android 10 cihazlarda, önyükleyicinin skip_initramfs
çekirdek komut satırına GETİRMEMESİ GEREKİR. Bunun yerine, önyükleyicinin kurtarmayı atlamak ve normal Android'i başlatmak için androidboot.force_normal_boot=1
değerini iletmesi gerekir. Android 12 veya sonraki sürümlerle başlatılan cihazların, androidboot.force_normal_boot=1
iletmek için bootconfig kullanması gerekir.
AVB yapılandırma değişiklikleri
Android Verified Boot 2.0 kullanırken, cihaz zincirleme bölüm tanımlayıcılarını kullanmıyorsa herhangi bir değişiklik yapılmasına gerek yoktur. Ancak zincirleme bölümler kullanılıyorsa ve doğrulanan bölümlerden biri dinamikse, değişiklik yapılması gerekir.
system
ve vendor
bölümleri için vbmeta
zincirleyen bir aygıtın örnek yapılandırmasını burada 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ükleyici, system
ve vendor
bölümlerinin sonunda vbmeta altbilgisini bulmayı bekler. Bu bölümler artık önyü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
vevbmeta_vendor
bölümlerini ekleyin. A/B cihazları içinvbmeta_system_a
,vbmeta_system_b
,vbmeta_vendor_a
vevbmeta_vendor_b
ekleyin. Bu bölümlerden bir veya daha fazlası ekleniyorsa bunlarvbmeta
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ü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 kullanıyor olabilir. Yalnızca mantıksal bir bölüme zincirleme yapılırken değişiklik yapılması gerekir.
AVB önyükleyici değişiklikleri
Önyükleyicide libavb gömülüyse aşağıdaki yamaları ekleyin:
- 818cf56740775446285466eda984acedd4baeac0 — "libavb: Bölüm GUID'lerini yalnızca cmdline ihtiyaç duyduğunda sorgulayın."
- 5abd6bc2578968d24406d834471adfd995a0c2e9 — "Sistem bölümünün bulunmamasına izin ver"
- 9ba3b6613b4e5130fa01a11d984c6b5f0eb3af05 — "AvbSlotVerifyData->cmdline'ın NULL olabileceğini düzeltin"
Zincirlenmiş bölümler kullanıyorsanız ek bir yama ekleyin:
- 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: Bölümün başlangıcında vbmeta blob'larını destekleyin."
Çekirdek komut satırı değişiklikleri
Çekirdek komut satırına yeni bir parametre olan androidboot.boot_devices
eklenmelidir. Bu, init
tarafından /dev/block/by-name
sembolik bağları etkinleştirmek için kullanılır. ueventd
tarafından oluşturulan temel isme 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 başlatılan cihazların, androidboot.boot_devices
init
öğesine iletmek için bootconfig kullanması gerekir.
Örneğin, süper bölüm adı 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.ufshcBootconfig 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ı 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 tanıtılan ve ilk aşamada bir bölümün monte edileceğini belirten
logical
bayrağı vefirst_stage_mount
bayrağını içermelidir. - Bir bölüm,
fs_mgr
bayrağı olarakavb= vbmeta partition name
belirtebilir ve ardından belirtilenvbmeta
bölümü, herhangi bir aygıtı bağlamaya çalışmadan önce ilk aşamainit
tarafından başlatılır. -
dev
alanı bölüm adı olmalıdır.
Aşağıdaki fstab girişleri, sistemi, satıcıyı ve ürünü yukarıdaki kurallara göre mantıksal bölümler olarak ayarlar.
#<dev> <mnt_point> <type> <mnt_flags options> <fs_mgr_flags> system /system ext4 ro,barrier=1 wait,slotselect,avb=vbmeta,logical,first_stage_mount vendor /vendor ext4 ro,barrier=1 wait,slotselect,avb,logical,first_stage_mount product /product ext4 ro,barrier=1 wait,slotselect,avb,logical,first_stage_mount
Fstab dosyasını ilk aşamadaki ramdiske kopyalayın.
SELinux değişiklikleri
Süper bölüm blok aygıtı super_block_device
etiketiyle işaretlenmelidir. Örneğin, süper bölümün isme göre sembolik bağlantısı /dev/block/platform/ soc/100000.ufshc /by-name/super
ise, file_contexts
aşağıdaki satırı ekleyin:
/dev/block/platform/soc/10000\.ufshc/by-name/super u:object_r:super_block_device:s0
hızlı önyükleme
Önyükleyici (veya kullanıcı alanı olmayan herhangi bir flaşlama aracı) dinamik bölümleri anlamadığından onları flaş edemez. Bu sorunu çözmek için cihazların fastbootd adı verilen fastboot protokolünün kullanıcı alanı uygulamasını kullanması gerekir.
Fastbootd'un nasıl uygulanacağı hakkında daha fazla bilgi için bkz. Fastboot'u Kullanıcı Alanına Taşıma .
adb yeniden montajı
Eng veya userdebug yapılarını kullanan geliştiriciler için adb remount
, hızlı yineleme açısından son derece kullanışlıdır. Dinamik bölümler, her dosya sisteminde artık boş alan olmadığından adb remount
için sorun oluşturur. Bu sorunu çözmek için cihazlar katmanları 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 kaplamaları kullanır. Geçici bölümün adı scratch
, dolayısıyla bu adı diğer bölümler için kullanmayın.
Kaplamaların nasıl etkinleştirileceği hakkında daha fazla bilgi için AOSP'deki kaplamalar README'ye bakın.
Android cihazlarını 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ırmalar gereklidir.
Cihaz yapılandırma değişiklikleri
Dinamik bölümlemeyi güçlendirmek için, aşağıdaki bayrakları device.mk
dosyasına ekleyin:
PRODUCT_USE_DYNAMIC_PARTITIONS := true PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true
Kart konfigürasyonu değişiklikleri
Aşağıdaki pano değişkenlerini ayarlamanız gerekir:
-
BOARD_SUPER_PARTITION_BLOCK_DEVICES
dinamik bölümlerin kapsamları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ıylaBOARD_SUPER_PARTITION_BLOCK_DEVICES
içindeki her blok aygıtının boyutlarına ayarlayın. Bu, cihazdaki mevcut fiziksel bölümlerin boyutlarının listesidir. Bu genellikle mevcut kart yapılandırmalarındaBOARD_ partition IMAGE_PARTITION_SIZE
şeklindedir. -
BOARD_SUPER_PARTITION_BLOCK_DEVICES
içindeki tüm bölümler için mevcutBOARD_ partition IMAGE_PARTITION_SIZE
kaldırın. -
BOARD_SUPER_PARTITION_SIZE
değeriniBOARD_SUPER_PARTITION_ partition _DEVICE_SIZE
toplamına ayarlayın. -
BOARD_SUPER_PARTITION_METADATA_DEVICE
öğesini dinamik bölüm meta verilerinin depolandığı blok cihazı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
veBOARD_ group _PARTITION_LIST
ayarlayın. Ayrıntılar için Yeni cihazlardaki kart yapılandırma değişikliklerine bakın.
Örneğin, cihazda halihazırda 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 istersiniz ve bunların isme 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 cihazlarda dinamik bölümlerin uygulanması .
Güçlendirme güncellemeleri hakkında daha fazla bilgi için Dinamik Bölümleri Olmayan A/B Cihazları için OTA'ya bakın.
Fabrika görüntüleri
Dinamik bölüm desteğiyle başlatılan bir cihaz için, kullanıcı alanına önyükleme yapmak diğer flaşlama yöntemlerine göre daha yavaş olduğundan, fabrika görüntülerini flaşlamak için kullanıcı alanı fastboot'unu kullanmaktan kaçının.
Bu sorunu çözmek için make dist
artık doğrudan süper bölüme aktarılabilen ek bir super.img
görüntüsü oluşturuyor. Mantıksal bölümlerin içeriğini otomatik olarak bir araya getirir; bu, super
bölüm meta verilerine ek olarak system.img
, vendor.img
vb. öğeleri içerdiği anlamına gelir. Bu görüntü herhangi bir ek araç kullanmadan veya fastbootd kullanılmadan doğrudan super
bölüme aktarılabilir. Derlemeden sonra super.img
${ANDROID_PRODUCT_OUT}
içine yerleştirilir.
Dinamik bölümlerle başlatılan A/B aygıtları için super.img
A yuvasındaki görüntüleri içerir. Süper görüntüyü doğrudan flashladıktan sonra, cihazı yeniden başlatmadan önce A yuvasını önyüklenebilir olarak işaretleyin.
Cihazları yenilemek 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, BOARD_SUPER_PARTITION_BLOCK_DEVICES
sistem satıcısı olduğunda make dist
build super_system.img
ve super_vendor.img
. Bu görüntüler target_files.zip
dosyasındaki OTA klasörüne yerleştirilir.
Cihaz eşleyici depolama cihazı ayarlama
Dinamik bölümleme, bir dizi belirleyici 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ı izlemeniz ve ilişkili tüm bölümlerin Android özelliklerini, temel depolama aygıtlarıyla birlikte güncellemeniz gerekir.
init
içindeki bir mekanizma montajları izler ve Android özelliklerini eşzamansız olarak günceller. Bunun için gereken sürenin belirli bir süre içinde olacağı garanti edilmez; bu nedenle, on property
tüm tetikleyicilerin tepki vermesi için yeterli süre sağlamanız gerekir. Ö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 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ın bir parçası olarak genişletilmesine olanak tanır ve depolama aygıtları, aşağıdaki gibi komutlarla gerektiği şekilde platform tarafından ayarlanabilir:
write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb 128 write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb 128
İkinci aşamada init
komut işleme başladığında, epoll loop
aktif 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
işlemek için kullanılamazlar. init.rc
betikleri early-fs
(çeşitli arka plan programları ve tesisler başladığında) geçersiz kılınıncaya kadar çekirdek varsayılan read_ahead_kb
yeterli olmasını bekleyebilirsiniz. Bu nedenle Google, aşağıdaki örneklerde olduğu gibi, operasyonların zamanlaması ile ilgilenmek ve yarış koşullarını önlemek için on property
özelliğini sys.read_ahead_kb
gibi init.rc
kontrollü bir özellikle 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}