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

Android 10 obsługuje partycje dynamiczne, czyli system partycjonowania przestrzeni użytkownika, który może tworzyć, zmieniać rozmiar i usuwać partycje podczas aktualizacji bezprzewodowych (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 aktualizowania urządzenia A/B pod kątem obsługi partycji dynamicznych tabela partycji GUID (GPT) na urządzeniu jest zachowywana, więc na urządzeniu nie ma partycji super. Metadane są przechowywane w miejscach system_a i system_b, ale można je dostosować, zmieniając parametr BOARD_SUPER_PARTITION_METADATA_DEVICE.

Każde urządzenie blokowe ma 2 miejsca na metadane. W każdym urządzeniu blokującym używany jest tylko jeden slot metadanych. Na przykład metadane 0 w miejscu system_a i Metadane 1 w miejscu system_b odpowiadają partycjom odpowiednio w przedziałach A i B. Podczas wykonywania nie ma znaczenia, który slot jest aktualizowany.

Na tej stronie gniazda metadanych mają nazwy Metadata S (źródło) i Metadata T (docelnik). W analogiczny sposób partycje są nazywane system_s, vendor_t itd.

Więcej informacji o tworzeniu konfiguracji systemu znajdziesz w artykule Uaktualnianie urządzeń.

Więcej informacji o tym, jak partycje należą do grup aktualizacji, znajdziesz w artykule o zmianach konfiguracji tablicy dla nowych urządzeń.

Przykładem metadanych na urządzeniu jest:

  • 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 fizycznej blokady system_b
    • Metadane 0 (nieużywane)
    • Metadane 1
      • Grupa foo_b
        • Partycja logiczna (dynamiczna) system_b
        • Logiczna (dynamiczna) partycjaproduct_services_b
        • Inne partycje zaktualizowane przez Foo
      • Bar_b grupy
        • Partycja logiczna (dynamiczna) vendor_b
        • Partycja logiczna (dynamiczna)product_b
        • Inne partycje zaktualizowane przez Bar

Aby zdumpować metadane na urządzeniu, możesz użyć narzędzia lpdump, które znajduje się w sekcji system/extras/partition_tools. Na przykład: 

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

Wdrażanie aktualizacji wstecz

Na urządzeniach z Androidem 9 lub starszym klient OTA nie obsługuje mapowania dynamicznych partycji przed aktualizacją. Tworzony jest dodatkowy zestaw poprawek, aby można było zastosować mapowanie bezpośrednio do istniejących partycji fizycznych.

Generator OTA tworzy ostateczny plik super.img, który zawiera zawartość wszystkich partycji dynamicznych, a następnie dzieli obraz na wiele obrazów odpowiadających rozmiarom urządzeń blokowych odpowiadających systemowi, dostawcy itp. 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).

Klient OTA nie wie, jak mapować partycje dynamiczne, dlatego podczas generowania pakietu aktualizacji wszystkie kroki po instalacji na tych partycjach są automatycznie wyłączone. Więcej informacji znajdziesz w artykule Konfigurowanie 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 przeróbce

Po aktualizacji wstecznej klient OTA jest aktualizowany, aby obsługiwał partycje dynamiczne. Zakresy partycji źródłowych nigdy nie obejmują więcej niż jednej docelowej partycji fizycznej.

Proces aktualizacji przy użyciu 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 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 znajdziesz w new_partition_info.
    3. Zapisz M w metadanych T.
    4. Zmapuj dodane partycje w Kreatorze map urządzenia jako dostępne 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 w przypadku instalowania z zewnątrz, ponieważ partycje źródłowe nie są mapowane przed aktualizacją.
    2. Zastosuj pełną lub różnicową aktualizację do wszystkich urządzeń blokujących w docelowym slocie.
    3. Zamontuj partycje, aby uruchomić skrypt poinstalacyjny, a następnie odmontuj partycje.
  3. Odmapuj partycje docelowe.

Aktualizacja przepływu za pomocą pakietu aktualizacji wstecznej

Jeśli pakiet aktualizacji wstecznej jest stosowany na urządzeniu, które ma już włączone partycje dynamiczne, klient OTA stosuje podzielony plik super.img bezpośrednio na urządzeniach blokowych. 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 miejscu 0.
  • system_a, vendor_a i product_a są używane jako urządzenia blokujące.

Gdy klient OTA otrzyma pakiet aktualizacji aktualizacji, stosuje super_system.img w fizycznym systemie system_b, super_vendor.img w fizycznym vendor_b i super_product.img na fizycznym 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 w wersji podstawowej nie ma zmiennych, jest to aktualizacja wsteczna. 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 dla partycji logicznych (dynamicznych). Można włączyć etap instalacji.

Pełna aktualizacja OTA

W przypadku urządzeń z dodatkiem generowane są 2 pakiety OTA.

  • $(PRODUCT)-ota-retrofit-$(TAG).zip zawsze zawiera podział super.img i wyłącza krok po instalacji na potrzeby modernizacji aktualizacji.
    • Jest generowany za pomocą dodatkowego argumentu --retrofit_dynamic_partitions w skrypcie ota_from_target_files.
    • Można go zastosować do wszystkich wersji.
  • $(PRODUCT)-ota-$(TAG).zip zawiera logiczne obrazy na potrzeby przyszłych aktualizacji.
    • Stosuj to tylko do wersji z włączonymi partycjami dynamicznymi. Poniżej znajdziesz więcej informacji na temat egzekwowania tej zasady.

Odrzucaj niezaktualizowane aktualizacje w starych kompilacji

Zwykły pełny pakiet OTA należy zastosować tylko do wersji z włączonymi partycjami dynamicznymi. Jeśli serwer OTA jest nieprawidłowo skonfigurowany i przekazuje te pakiety na urządzenia z Androidem 9 lub starszym, urządzenia nie uruchomią się. 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 akceptowanie pełnego pakietu OTA, możesz wymagać wykonania czynności po instalacji w celu sprawdzenia dotychczasowej konfiguracji urządzenia. 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 włączonych partycji dynamicznych, klient OTA jest uruchamianycheck_dynamic_partitions jako krok po instalacji i odrzuca aktualizację.