27 Mart 2025'ten itibaren AOSP'yi derlemek ve AOSP'ye katkıda bulunmak için aosp-main yerine android-latest-release kullanmanızı öneririz. Daha fazla bilgi için AOSP'de yapılan değişiklikler başlıklı makaleyi inceleyin.

Bu sayfa, Cloud Translation API ile çevrilmiştir.

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

Android 10, kablosuz (OTA) güncellemeleri sırasında bölümler oluşturabilen, yeniden boyutlandırabilen ve yok edebilen bir kullanıcı alanı bölümleme sistemi olan dinamik bölümleri destekler.

Bu sayfada, OTA istemcilerinin, dinamik bölüm desteği olmadan kullanıma sunulan A/B cihazlarda güncelleme sırasında dinamik bölümleri nasıl yeniden boyutlandırdığı ve Android 10'a nasıl yükselttiği açıklanmaktadır.

Arka plan

Bir A/B cihazı dinamik bölümleri destekleyecek şekilde güncellenirken cihazdaki GUID bölüm tablosu (GPT) korunur. Bu nedenle cihazda super bölümü yoktur. Meta veriler system_a ve system_b konumlarında depolanır ancak BOARD_SUPER_PARTITION_METADATA_DEVICE değiştirilerek özelleştirilebilir.

Her blok cihazda iki meta veri yuvası bulunur. Her blok cihazda yalnızca bir meta veri yuvası kullanılır. Örneğin, system_a konumundaki Meta veri 0 ve system_b konumundaki Meta veri 1 sırasıyla A ve B yuvalarındaki bölümlere karşılık gelir. Çalışma zamanında hangi yuvanın güncellendiği önemli değildir.

Bu sayfada, meta veri yuvaları Meta Veri K (kaynak) ve Meta Veri H (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 ait olması hakkında daha fazla bilgi için yeni cihazlarda kart yapılandırma değişiklikleri başlıklı makaleyi inceleyin.

Cihazdaki meta verilere örnek:

Fiziksel blok 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üm product_a
    - Bard tarafından güncellenen diğer bölümler
- Meta veri 1 (kullanılmıyor)
Fiziksel blok cihaz system_b
- Meta veri 0 (kullanılmıyor)
- Meta veri 1
  - foo_b grubu
    - Mantıksal (dinamik) bölüm 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
    - Bard tarafından güncellenen diğer bölümler

Cihazınızdaki meta verileri boşaltmak için lpdump bölümündeki system/extras/partition_tools aracını kullanabilirsiniz. Örneğin:

lpdump --slot 0 /dev/block/by-name/system_a
lpdump --slot 1 /dev/block/by-name/system_b

Güncellemeyi uyarlama

Android 9 ve önceki sürümlerin yüklü olduğu cihazlarda, cihazdaki 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 yama grubu oluşturulur.

OTA oluşturucu, tüm dinamik bölümlerin içeriğini içeren son super.img dosyasını oluşturur. Ardından, resmi sistem, satıcı vb. ile ilgili fiziksel blok cihazların boyutlarına uygun birden fazla resme böler. Bu resimler super_system.img, super_vendor.img vb. olarak adlandırılır. OTA istemcisi, bu görüntüleri mantıksal (dinamik) bölümler için uygulamak yerine fiziksel bölümlere uygular.

OTA istemcisi dinamik bölümleri nasıl eşleyeceğini bilmediğinden, güncelleme paketi oluşturulduğunda bu bölümler için yükleme sonrası tüm adımlar otomatik olarak devre dışı bırakılır. Daha fazla bilgi için Yükleme sonrası yapılandırma bölümüne bakın.

Güncelleme akışı, Android 9'dakiyle aynıdır.

Güncellemeden önce:

ro.boot.dynamic_partitions=
ro.boot.dynamic_partitions_retrofit=

Güncellemeden sonra:

ro.boot.dynamic_partitions=true
ro.boot.dynamic_partitions_retrofit=true

Retrofit işleminden sonraki güncellemeler

Retrofit güncellemesinden sonra OTA istemcisi, dinamik bölümlerle çalışacak şekilde güncellenir. Kaynak bölümlerin kapsamları hiçbir zaman hedef fiziksel bölümleri kapsamaz.

Normal güncelleme paketi kullanılarak yapılan güncelleme akışı

super bölümü meta verilerini başlatın.
1. Meta Veri S'den (kaynak meta veriler) yeni meta veriler M oluşturun. Örneğin, meta veri S, engellenen cihazlar olarak [system_s, vendor_s, product_s] kullanıyorsa yeni meta veri M, engellenen cihazlar olarak [system_t, vendor_t, product_t] kullanır. M'de tüm gruplar ve bölümler atılır.
2. Güncelleme manifest dosyasındaki dynamic_partition_metadata alanına göre hedef gruplar ve bölümler ekleyin. Her bölümün boyutunu new_partition_info içinde bulabilirsiniz.
3. Write M to Metadata T.
4. Eklenen bölümleri, cihaz eşleyici üzerinde yazılabilir olarak eşleyin.
Güncellemeyi engellenen cihazlarda uygulayın.
1. Gerekirse cihaz eşleyicideki kaynak bölümleri salt okunur olarak eşleyin. Güncellemeden önce kaynak bölümler eşlenmediği için bu, yan yükleme için gereklidir.
2. Hedef yuvadaki tüm blok cihazlara tam veya delta güncelleme uygulayın.
3. Yükleme sonrası komut dosyasını çalıştırmak için bölümleri bağlayın, ardından bölümleri ayırın.
Hedef bölümlerin eşlemesini kaldırın.

Retrofit güncelleme paketi kullanarak güncelleme akışı

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 eklenen bir güncellemeye benzer. Ayrıntılar için Güncellemeyi geriye dönük olarak uygulama başlıklı makaleyi inceleyin.

Örneğin, aşağıdakileri varsayalım:

A yuvası etkin yuvadır.
system_a, 0. yuvadaki etkin meta verileri içerir.
system_a, vendor_a ve product_a, engelleme cihazı olarak kullanılır.

OTA istemcisi bir uyarlama güncelleme paketi aldığında fiziksel system_b üzerinde super_system.img'yı, fiziksel vendor_b üzerinde super_vendor.img'yi ve fiziksel product_b üzerinde super_product.img'i uygular. Fiziksel blok cihaz system_b, önyükleme sırasında mantıksal system_b, vendor_b ve product_b'yi eşlemek için doğru meta verileri içerir.

Güncelleme paketleri oluşturma

Artımlı OTA

Retrofit cihazlar için artımlı OTA'lar oluşturulurken güncellemeler, temel derlemenin PRODUCT_USE_DYNAMIC_PARTITIONS ve PRODUCT_RETROFIT_DYNAMIC_PARTITIONS tanımlayıp tanımlamadığına bağlıdır.

Temel derleme değişkenleri tanımlamıyorsa bu, geriye dönük bir güncellemedir. 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 normal bir güncellemeye eşdeğerdir. Güncelleme paketi, mantıksal (dinamik) bölümlerin görüntülerini içerir. Yükleme sonrası adım etkinleştirilebilir.

Tam OSA

Retrofit cihazlar için iki tam OTA paketi oluşturulur.

$(PRODUCT)-ota-retrofit-$(TAG).zip her zaman super.img bölmesini içerir ve geriye dönük güncelleme için yükleme sonrası adımı devre dışı bırakır.
- --retrofit_dynamic_partitions komut dosyasına ek bir bağımsız değişkenle --retrofit_dynamic_partitions oluşturulur.ota_from_target_files
- Tüm derlemelere uygulanabilir.
$(PRODUCT)-ota-$(TAG).zip, gelecekteki güncellemeler için mantıksal resimler içeriyor.
- Bu yalnızca dinamik bölümlerin etkinleştirildiği derlemeler için geçerlidir. Bunun uygulanmasıyla ilgili ayrıntıları aşağıda bulabilirsiniz.

Eski derlemelerde retrofite uygun olmayan güncellemeyi reddetme

Normal tam OTA paketini yalnızca dinamik bölümlerin etkin olduğu derlemelere uygulayın. OTA sunucusu yanlış yapılandırılırsa ve bu paketleri Android 9 veya daha eski bir sürümü çalıştıran cihazlara gönderirse cihazlar başlatılamaz. Android 9 ve önceki sürümlerdeki OTA istemcisi, retrofit OTA paketi ile normal tam OTA paketi arasındaki farkı anlayamaz. Bu nedenle istemci, tam paketi reddetmez.

Cihazın tam OTA paketini kabul etmesini önlemek için mevcut cihaz yapılandırmasını kontrol etmek üzere yükleme sonrası bir adım isteyebilirsiniz. Örneğin:

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 \

Normal OTA paketi, dinamik bölümlerin etkinleştirilmediği bir cihaza uygulandığında OTA istemcisi, check_dynamic_partitions'yı yükleme sonrası adım olarak çalıştırır ve güncellemeyi reddeder.