Android 10, kablosuz (OTA) güncellemeler sırasında bölüm oluşturabilen, yeniden boyutlandırabilen ve bölüm silebilir bir kullanıcı alanı bölümlendirme sistemi olan dinamik bölümleri destekler.
Bu sayfada, dinamik bölüm desteği olmadan kullanıma sunulan A/B cihazları için güncelleme sırasında OTA istemcilerinin dinamik bölümleri nasıl yeniden boyutlandırdığı ve OTA istemcilerinin Android 10'a nasıl yükseltildiği açıklanmaktadır.
Arka plan
A/B cihazın dinamik bölümleri desteklemesi için güncellenmesi sırasında cihazdaki GUID bölüm tablosu (GPT) korunur. Bu nedenle cihazda super
bölümü olmaz. Meta veriler system_a
ve system_b
adresinde depolanır ancak bu, BOARD_SUPER_PARTITION_METADATA_DEVICE
değiştirilerek özelleştirilebilir.
Blok cihazların her birinde iki meta veri yuvası bulunur. Her blok cihazda yalnızca bir meta veri yuvası kullanılır. Örneğin, system_a
adresindeki Meta Veri 0 ve system_b
konumundaki Meta Veri 1, sırasıyla A ve B alanlarındaki bölümlere karşılık gelir. Çalışma zamanında hangi alanın güncellendiği önemli değildir.
Bu sayfada meta veri yuvaları Meta Veri S (kaynak) ve Meta Veri T (hedef) olarak adlandırılır. Benzer şekilde, bölümler system_s
, vendor_t
vb. olarak adlandırılır.
Derleme sistemi yapılandırmaları hakkında daha fazla bilgi için Cihazları yükseltme başlıklı makaleyi inceleyin.
Bölümlerin güncelleme gruplarına nasıl ait olduğu hakkında daha fazla bilgi edinmek için yeni cihazlardaki Kart yapılandırma değişiklikleri bölümüne bakın.
Cihazdaki meta verilere örnek olarak şunlar verilebilir:
- Fiziksel engelleme cihazı
system_a
- Meta veri 0
- Grup
foo_a
- Mantıksal (dinamik) bölüm
system_a
- Mantıksal (dinamik) bölüm
product_services_a
- Foo tarafından güncellenen diğer bölümler
- Mantıksal (dinamik) bölüm
- Grup
bar_a
- Mantıksal (dinamik) bölüm
vendor_a
- Mantıksal (dinamik) bölümlendirme
product_a
- Bar tarafından güncellenen diğer bölümler
- Mantıksal (dinamik) bölüm
- Grup
- Meta veri 1 (kullanılmıyor)
- Meta veri 0
- Fiziksel engelleme cihazı
system_b
- Meta veri 0 (kullanılmaz)
- Meta veri 1
- Grup foo_b
- Mantıksal (dinamik) bölümlendirme
system_b
- Mantıksal (dinamik) bölüm
product_services_b
- Foo tarafından güncellenen diğer bölümler
- Mantıksal (dinamik) bölümlendirme
- Grup bar_b
- Mantıksal (dinamik) bölüm
vendor_b
- Mantıksal (dinamik) bölüm
product_b
- Bar tarafından güncellenen diğer bölümler
- Mantıksal (dinamik) bölüm
- Grup foo_b
Cihazınızdaki meta verileri dökmek için system/extras/partition_tools
altındaki lpdump
aracını kullanabilirsiniz. Örnek:
lpdump --slot 0 /dev/block/by-name/system_a
lpdump --slot 1 /dev/block/by-name/system_b
Güncellemeyi sonradan uygulama
Android 9 ve önceki sürümlerin yüklü olduğu cihazlardaki OTA istemcisi, güncellemeden önce dinamik bölümlerin eşlenmesini desteklemez. Eşlemenin doğrudan mevcut fiziksel bölümlere uygulanabilmesi için ek bir yamalar grubu oluşturulur.
OTA oluşturucu, tüm dinamik bölümlerin içeriğini içeren nihai super.img
dosyasını oluşturur, ardından resmi sistem, tedarikçi vb.'ye karşılık gelen fiziksel blok cihazlarının boyutlarına uygun birden fazla resme böler. Bu resimler super_system.img
, super_vendor.img
vb. şeklinde adlandırılır.
OTA istemcisi, bu resimleri mantıksal (dinamik) bölümlere uygulamak yerine fiziksel bölümlere uygular.
OTA istemcisi dinamik bölümleri nasıl eşleyeceğini bilmediği için güncelleme paketi oluşturulduğunda bu bölümler için tüm yükleme sonrası adımlar otomatik olarak devre dışı bırakılır. Daha fazla bilgi için Yükleme sonrası yapılandırmayı inceleyin.
Güncelleme akışı, Android 9 ile aynıdır.
Güncellemeden önce:
ro.boot.dynamic_partitions= ro.boot.dynamic_partitions_retrofit=
Güncelleme sonrasında:
ro.boot.dynamic_partitions=true ro.boot.dynamic_partitions_retrofit=true
Düzeltme sonrası yapılacak güncellemeler
Sonraki güncellemeden sonra OTA istemcisi, dinamik bölümlerle çalışacak şekilde güncellenir. Kaynak bölümlerin kapsamları hiçbir zaman hedef fiziksel bölümlere yayılmaz.
Normal güncelleme paketi kullanarak akışı güncelleme
super
bölüm meta verilerini başlatın.-
Meta Veri S'den (kaynak meta veri) yeni meta veri M oluşturun.
Örneğin, S meta verisi engelleme cihazları olarak [
system_s
,vendor_s
,product_s
] kullanıyorsa yeni M meta verisi, engelleme cihazları olarak [system_t
,vendor_t
,product_t
] kullanır. M'de tüm gruplar ve bölümler atılır. -
Hedef grupları ve bölümleri, güncelleme manifestindeki
dynamic_partition_metadata
alanına göre ekleyin. Her bölümün boyutununew_partition_info
bölümünde bulabilirsiniz. - M'yi T meta verilerine yazın.
- Eklenen bölümleri cihaz eşleyicide yazılabilir olarak eşleyin.
-
Meta Veri S'den (kaynak meta veri) yeni meta veri M oluşturun.
Örneğin, S meta verisi engelleme cihazları olarak [
- Güncellemeyi engellenen cihazlara uygulayın.
- Gerekirse cihaz eşleştiricideki kaynak bölümlerini salt okunur olarak eşleyin. Kaynak bölümleri güncellemeden önce eşlenmediği için bu, yan yükleme için gereklidir.
- Hedef yuvasındaki tüm engelleme cihazlarına tam veya delta güncellemesi uygulayın.
- Yükleme sonrası komut dosyasını çalıştırmak için bölümleri monte edin ve ardından bölümlerin montesini kaldırın.
- Hedef bölümlerin eşlemesini kaldırın.
Akışı, geriye dönük düzenleme güncelleme paketi kullanarak güncelleme
Retrofit güncelleme paketi, dinamik bölümleri zaten etkinleştirmiş bir cihaza uygulanırsa OTA istemcisi, bölünmüş super.img
dosyasını doğrudan blok cihazlara uygular. Güncelleme akışı, sonradan yapılan güncellemeye benzer. Ayrıntılar için Güncellemeyi eski cihazlara uygulama başlıklı makaleyi inceleyin.
Örneğin, aşağıdakileri varsayalım:
- A yuvası etkin yuvadır.
-
system_a
, 0. yuvada etkin meta verileri içerir. -
system_a
,vendor_a
veproduct_a
engelleme cihazı olarak kullanılır.
OTA istemcisi, bir geriye dönük güncelleme paketi aldığında bu paket, fiziksel system_b
'te super_system.img
, fiziksel vendor_b
'te super_vendor.img
ve fiziksel product_b
'te super_product.img
olarak uygulanır.
Fiziksel blok cihaz system_b
, system_b
, vendor_b
ve product_b
mantıksal birimlerini önyükleme sırasında eşlemek için doğru meta verileri içerir.
Güncelleme paketleri oluşturma
Artımlı OTA
Geri dönüşüm cihazları için artımlı OTA'lar oluşturulurken güncellemeler, temel derlemenin PRODUCT_USE_DYNAMIC_PARTITIONS
ve PRODUCT_RETROFIT_DYNAMIC_PARTITIONS
'yi tanımlayıp tanımlamadığına bağlıdır.
-
Temel derleme değişkenleri tanımlamıyorsa bu, sonradan ekleme güncellemesidir. Güncelleme paketi, bölünmüş
super.img
dosyasını içerir ve yükleme sonrası adımı devre dışı bırakır. - Temel derleme değişkenleri tanımlıyorsa bu, dinamik bölümler içeren tipik bir güncellemeyle aynıdır. Güncelleme paketi, mantıksal (dinamik) bölümlerin resimlerini içerir. Yükleme sonrası adım etkinleştirilebilir.
Tam OTA
Geri dönüşüm cihazları için iki tam OTA paketi oluşturulur.
-
$(PRODUCT)-ota-retrofit-$(TAG).zip
her zamansuper.img
bölünmüş içerir ve güncellemeyi sonradan uygulamak için yükleme sonrası adımı devre dışı bırakır.-
Komut dosyası için
ota_from_target_files
ek bir bağımsız değişkenle oluşturulur.--retrofit_dynamic_partitions
- Tüm derlemelere uygulanabilir.
-
Komut dosyası için
-
$(PRODUCT)-ota-$(TAG).zip
, gelecekteki güncellemeler için mantıksal görüntüler içeriyor.- Bunu yalnızca dinamik bölümlerin etkinleştirildiği derlemelere uygulayın. Bu politikanın uygulanmasıyla ilgili ayrıntıları aşağıda bulabilirsiniz.
Eski derlemelerde geriye dönük olmayan güncellemeleri reddetme
Normal tam OTA paketini yalnızca dinamik bölümlerin etkinleştirildiği derlemelere uygulayın. OTA sunucusu yanlış yapılandırılmışsa ve bu paketleri Android 9 veya daha eski sürümleri çalıştıran cihazlara gönderirse cihazlar başlatılamaz. Android 9 ve önceki sürümlerdeki OTA istemcisi, geriye dönük OTA paketi ile normal tam OTA paketi arasındaki farkı söyleyemez. Bu nedenle istemci, paketin tamamını reddetmez.
Cihazın tüm OTA paketini kabul etmesini önlemek için mevcut cihaz yapılandırmasını kontrol etmek üzere yükleme sonrası bir adım uygulanmasını zorunlu tutabilirsiniz. Örnek:
device/device_name/dynamic_partitions/check_dynamic_partitions
#!/system/bin/sh DP_PROPERTY_NAME="ro.boot.dynamic_partitions" DP_RETROFIT_PROPERTY_NAME="ro.boot.dynamic_partitions_retrofit" DP_PROPERTY=$(getprop ${DP_PROPERTY_NAME}) DP_RETROFIT_PROPERTY=$(getprop ${DP_RETROFIT_PROPERTY_NAME}) if [ "${DP_PROPERTY}" != "true" ] || [ "${DP_RETROFIT_PROPERTY}" != "true" ] ; then echo "Error: applied non-retrofit update on build without dynamic" \ "partitions." echo "${DP_PROPERTY_NAME}=${DP_PROPERTY}" echo "${DP_RETROFIT_PROPERTY_NAME}=${DP_RETROFIT_PROPERTY}" exit 1 fi
device/device_name/dynamic_partitions/Android.mk
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE:= check_dynamic_partitions LOCAL_MODULE_TAGS := optional LOCAL_MODULE_CLASS := EXECUTABLES LOCAL_SRC_FILES := check_dynamic_partitions LOCAL_PRODUCT_MODULE := true include $(BUILD_PREBUILT)
device/device_name/device.mk
PRODUCT_PACKAGES += check_dynamic_partitions # OPTIONAL=false so that the error in check_dynamic_partitions will be # propagated to OTA client. AB_OTA_POSTINSTALL_CONFIG += \ RUN_POSTINSTALL_product=true \ POSTINSTALL_PATH_product=bin/check_dynamic_partitions \ FILESYSTEM_TYPE_product=ext4 \ POSTINSTALL_OPTIONAL_product=false \
Dinamik bölümlerin etkinleştirilmediği bir cihaza normal OTA paketi uygulandığında, OTA istemcisi yükleme sonrası adım olarak check_dynamic_partitions
öğesini çalıştırır ve güncellemeyi reddeder.