Aktualizacje OTA dla urządzeń A/B bez partycji dynamicznych

Android 10 obsługuje dynamiczne partycje, czyli partycjonowanie przestrzeni użytkownika. który może tworzyć, niszczyć i zmieniać rozmiar partycji podczas aktualizacji OTA.

Na tej stronie opisano, jak klienci OTA zmieniają rozmiar partycji dynamicznych podczas aktualizacji na urządzeniach A/B, które zostały uruchomione bez obsługi partycji dynamicznych, oraz jak klienci OTA przechodzą na Androida 10.

Tło

Podczas aktualizacji urządzenia A/B pod kątem obsługi partycji dynamicznych Tabela partycji GUID (GPT) jest zachowywana na urządzeniu, więc nie jest super partycja na urządzeniu. Metadane są przechowywane w miejscach system_a i system_b, ale można je dostosować, zmieniając wartość parametru BOARD_SUPER_PARTITION_METADATA_DEVICE.

Każde z urządzeń blokujących ma 2 przedziały metadanych. Tylko jedna używany jest boks metadanych w każdym urządzeniu blokowym. Na przykład: Metadane 0 mają wartość 0 system_a i metadane 1 o system_b odpowiadają partycjom odpowiednio w przedziałach A i B. Na nie ma znaczenia, który boks jest aktualizowany.

Na tej stronie przedziały metadanych są nazywane Metadane S (źródło) i metadane T (cel). Analogicznie do partycji odnosi się na system_s, vendor_t itd.

Więcej informacji o konfiguracjach systemów kompilacji znajdziesz w artykule Aktualizowanie urządzeń.

Więcej informacji o przynależności partycji do pliku update grup, patrz Płyta pokładowa zmian konfiguracji nowych urządzeń.

Przykład metadanych na urządzeniu:

  • Fizyczne urządzenie blokujące system_a
    • Metadane 0
      • Grupa foo_a
        • Partycja logiczna (dynamiczna) system_a
        • Partycja logiczna (dynamiczna) product_services_a
        • Inne partycje zaktualizowane przez Foo
      • Grupa bar_a
        • Partycja logiczna (dynamiczna) vendor_a
        • Partycja logiczna (dynamiczna)product_a
        • Inne partycje zaktualizowane przez Bar
    • Metadane 1 (nieużywane)
  • Urządzenie blokujące (system_b)
    • Metadane 0 (nieużywane)
    • Metadane 1
      • Grupa foo_b
        • Partycja logiczna (dynamiczna)system_b
        • Partycja logiczna (dynamiczna) product_services_b
        • Inne partycje zaktualizowane przez Foo
      • Grupa bar_b
        • Logiczna (dynamiczna) partycjavendor_b
        • Partycja logiczna (dynamiczna)product_b
        • Inne partycje zaktualizowane przez słupek

Możesz użyć narzędzia lpdump na tej stronie: system/extras/partition_tools, aby skopiować metadane na Twoim urządzeniu. Na przykład: 

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

Ulepsz aktualizację

Na urządzeniach z Androidem 9 lub starszym klient OTA na urządzeniu nie obsługuje mapowania dynamicznych partycji przed aktualizacją. An tworzony jest dodatkowy zestaw poprawek, aby można było zastosować mapowanie bezpośrednio na istniejące partycje fizyczne.

Generator OTA tworzy końcowy plik super.img, który zawiera zawartość wszystkich partycji dynamicznych, a następnie dzieli obraz na wiele obrazów dopasowanych do rozmiarów urządzeń blokowych odpowiadające systemowi, dostawcy itd. Te obrazy mają nazwy super_system.img, super_vendor.img itd. Klient OTA stosuje te obrazy do partycji fizycznych, a nie do partycji logicznych (dynamicznych).

Ponieważ klient OTA nie wie, jak mapować partycje dynamiczne, wszystkie kroki po instalacji są automatycznie wyłączane w przypadku tych partycji podczas generowania pakietu aktualizacji. Zobacz Konfigurowanie konfiguracji po instalacji .

Proces aktualizacji jest taki sam jak w Androidzie 9.

Przed aktualizacją:

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

Po aktualizacji: 

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

Przyszłe aktualizacje po modernizacji

Po aktualizacji klient OTA jest aktualizowany tak, aby działał na partycjach dynamicznych. Zakresy partycji źródłowych nigdy nie obejmują w docelowych partycjach fizycznych.

Aktualizuj przepływ za pomocą zwykłego pakietu aktualizacji

  1. Inicjalizowanie metadanych partycji super.
    1. Utwórz nowe metadane M na podstawie metadanych S (źródłowe metadane). Jeśli na przykład metadane S używają wartości [system_s, vendor_s, product_s] jako urządzeń do blokowania, nowe metadane M używają wartości [system_t, vendor_t, product_t] jako urządzeń do blokowania. W wersji M wszystkie grupy i partycje są odrzucane.
    2. Dodaj grupy docelowe i partycje zgodnie z polem dynamic_partition_metadata w zaktualizowanym pliku manifestu. Rozmiar każdej partycji można znaleźć tutaj: new_partition_info
    3. Zapisz M do metadanych T.
    4. Mapuj dodane partycje w Device Mapper jako partycje do zapisu.
  2. Zastosuj aktualizację na urządzeniach blokujących.
    1. W razie potrzeby mapuj partycje źródłowe w mapierze urządzenia jako tylko do odczytu. Jest to konieczne do sideloadowania, ponieważ partycje źródłowe nie są mapowane przed aktualizacją.
    2. Zastosuj aktualizację pełną lub delta do wszystkich urządzeń blokowych w docelowym boksie.
    3. Podłącz partycje, aby uruchomić skrypt po instalacji, a następnie: odłącz partycje.
  3. Usuń mapowanie partycji docelowych.

Aktualizowanie przepływu za pomocą pakietu aktualizacji modernizacji

Jeśli pakiet aktualizacji retrofitowy jest stosowany na urządzeniu, które już włącza partycje dynamiczne, klient OTA zastosuje podział super.img bezpośrednio na urządzeniach blokujących. Proces aktualizacji jest podobny do procesu aktualizacji wstecznej. Więcej informacji znajdziesz w artykule Wdrożenie aktualizacji.

Załóżmy na przykład, że:

  • Slot A to aktywny slot.
  • system_a zawiera aktywne metadane w boksie 0.
  • system_a, vendor_a i product_a są używane jako urządzenia blokujące.

Gdy klient OTA otrzyma pakiet aktualizacji wstecznej, zostanie on zastosowany: super_system.img na fizycznym urządzeniu system_b, super_vendor.img na fizycznym urządzeniu vendor_b i super_product.img na fizycznym urządzeniu product_b. Fizyczne urządzenie blokujące system_b zawiera prawidłowe metadane umożliwiające mapowanie logicznych urządzeń system_b, vendor_b i product_b podczas uruchamiania.

Generowanie pakietów aktualizacji

Przyrostowa OTA

Podczas generowania przyrostowych aktualizacji OTA dla urządzeń z dodatkowymi funkcjami aktualizacje zależą od tego, czy kompilacja podstawowa definiuje PRODUCT_USE_DYNAMIC_PARTITIONS i PRODUCT_RETROFIT_DYNAMIC_PARTITIONS.

  • Jeśli kompilacja podstawowa nie definiuje zmiennych, jest to na temat modernizacji. Pakiet aktualizacji zawiera podzielony plik super.img i wyłącza krok po instalacji.
  • Jeśli kompilacja podstawowa definiuje zmienne, jest to równoznaczne z typową aktualizację z partycjami dynamicznymi. Pakiet aktualizacji zawiera obrazy partycji logicznych (dynamicznych). Można włączyć etap instalacji.

Pełna OTA

Dla urządzeń modernizowanych są wygenerowane 2 pełne pakiety OTA.

  • $(PRODUCT)-ota-retrofit-$(TAG).zip zawsze zawiera podziel super.img i wyłącza krok po instalacji w celu zmodernizowania aktualizacji.
    • Jest generowany za pomocą dodatkowego argumentu --retrofit_dynamic_partitions w skrypcie ota_from_target_files.
    • Możesz go zastosować do wszystkich kompilacji.
  • $(PRODUCT)-ota-$(TAG).zip zawiera obrazy logiczne dla: aktualizacje.
    • Stosuj to tylko do wersji z włączonymi partycjami dynamicznymi. Poniżej znajdziesz szczegółowe informacje na temat egzekwowania tych zasad.

Odrzuć aktualizację bez możliwości wstecznej kompatybilności w starszych kompilacjach

Zastosuj zwykły pełny pakiet OTA tylko do kompilacji z włączone partycje dynamiczne. Jeśli serwer OTA jest skonfigurowany nieprawidłowo i przekazuje te pakiety na urządzenia z Androidem 9 lub powoduje, że urządzenia się nie uruchamiają. Klient OTA w Androidzie 9 i starszych nie jest w stanie odróżnić pakietu OTA z retrofittingiem od zwykłego pełnego pakietu OTA, więc nie odrzuci pełnego pakietu.

Aby uniemożliwić urządzeniu zaakceptowanie pełnego pakietu OTA, możesz: wymagaj wykonania czynności po instalacji, aby sprawdzić istniejące urządzenie konfiguracji. Na przykład:

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 \

Gdy zwykły pakiet OTA jest stosowany na urządzeniu bez dynamicznego włączone partycje, klient OTA działa check_dynamic_partitions jako kroku po instalacji, odrzuci aktualizację.