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 dowiesz się, jak klienty OTA zmieniają rozmiar partycji dynamicznych podczas aktualizacji urządzeń A/B wprowadzonych bez obsługi partycji dynamicznych i w jaki sposób klienty 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 system_a i system_b, ale może to być dostosowane przez zmianę 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 tworzeniu konfiguracji systemu znajdziesz w artykule Uaktualnianie 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:

  • 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 słupek
    • 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
      • Pasek grupy_b
        • Partycja logiczna (dynamiczna) vendor_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. nie obsługuje mapowania partycji dynamicznych 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, zamiast niż zastosowanie obrazów do partycji logicznych (dynamicznych).

Klient OTA nie wie, jak zmapować partycje dynamiczne, wszystkie kroki po instalacji są automatycznie wyłączone na tych partycjach po wygenerowaniu 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. Zainicjuj metadane partycji super.
    1. Utwórz nowe metadane M na podstawie metadanych S (metadanych źródłowych). Jeśli na przykład metadane S używają ciągu [system_s, vendor_s, product_s] jako blokuj na urządzeniach mobilnych, nowe metadane M używają zapisu [system_t, vendor_t, product_t] jako zablokowanie urządzenia. W wersji M wszystkie grupy i partycje są odrzucane.
    2. Dodaj grupy docelowe i partycje według Pole dynamic_partition_metadata w aktualizacji pliku manifestu. Rozmiar każdej partycji można znaleźć tutaj: 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 zmapuj partycje źródłowe w narzędziu mapującym urządzenia jako tylko do odczytu. Jest to konieczne w przypadku instalowania z nieoficjalnych źródeł, 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. Aktualizacja jest podobny do aktualizacji. Zobacz Przekształcanie aktualizacji .

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

  • Gniazdo A jest aktywnym gniazdem.
  • 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 modernizacji, super_system.img w wersji fizycznej system_b, super_vendor.img w wersji fizycznej vendor_b oraz super_product.img na wersji fizycznej product_b. Fizyczne urządzenie blokujące system_b zawiera prawidłowy metadanych do mapowania logicznego system_b, vendor_b i product_b podczas uruchamiania.

Generowanie pakietów aktualizacji

Przyrostowa aktualizacja OTA

Przy tworzeniu przyrostowych aktualizacji OTA dla starszych urządzeń zależy od tego, czy kompilacja podstawowa określa PRODUCT_USE_DYNAMIC_PARTITIONS i PRODUCT_RETROFIT_DYNAMIC_PARTITIONS

  • Jeśli kompilacja podstawowa nie definiuje zmiennych, jest to na temat modernizacji. Pakiet aktualizacji zawiera podział 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). krok po instalacji można włączyć.

Pełna aktualizacja 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 generowane z dodatkowym argumentem --retrofit_dynamic_partitions na Skrypt ota_from_target_files.
    • Możesz go zastosować do wszystkich kompilacji.
  • $(PRODUCT)-ota-$(TAG).zip zawiera obrazy logiczne dla: aktualizacje.
    • Zastosuj to tylko do kompilacji z partycjami dynamicznymi . Poniżej znajdziesz szczegółowe informacje na temat egzekwowania tych zasad.

Odrzucaj niezaktualizowane aktualizacje w starych kompilacji

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 na Androida 9 nie może rozróżnić między zmodyfikowanym pakietem OTA a zwykły pełny pakiet OTA, dzięki czemu klient nie odrzuci całego 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ę.