Dinamik bölümü olmayan A/B cihazları için OTA

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
      • 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
    • Meta veri 1 (kullanılmıyor)
  • 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
      • 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

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

  1. super bölüm meta verilerini başlatın.
    1. 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.
    2. Hedef grupları ve bölümleri, güncelleme manifestindeki dynamic_partition_metadata alanına göre ekleyin. Her bölümün boyutunu new_partition_info bölümünde bulabilirsiniz.
    3. M'yi T meta verilerine yazın.
    4. Eklenen bölümleri cihaz eşleyicide yazılabilir olarak eşleyin.
  2. Güncellemeyi engellenen cihazlara uygulayın.
    1. 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.
    2. Hedef yuvasındaki tüm engelleme cihazlarına tam veya delta güncellemesi uygulayın.
    3. 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.
  3. 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 ve product_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 zaman super.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.
  • $(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.