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
- Partycja logiczna (dynamiczna)
- Grupa
bar_a
- Partycja logiczna (dynamiczna)
vendor_a
- Partycja logiczna (dynamiczna)
product_a
- Inne partycje zaktualizowane przez słupek
- Partycja logiczna (dynamiczna)
- Grupa
- Metadane 1 (nieużywane)
- Metadane 0
- 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
- Partycja logiczna (dynamiczna)
- Pasek grupy_b
- Partycja logiczna (dynamiczna)
vendor_b
- Partycja logiczna (dynamiczna)
product_b
- Inne partycje zaktualizowane przez słupek
- Partycja logiczna (dynamiczna)
- Grupa foo_b
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
- Zainicjuj metadane partycji
super
.-
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. -
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
- Zapisz M w metadanych T.
- Zmapuj dodane partycje w Kreatorze map urządzenia jako dostępne do zapisu.
-
Utwórz nowe metadane M na podstawie metadanych S (metadanych źródłowych).
Jeśli na przykład metadane S używają ciągu [
- Zastosuj aktualizację na urządzeniach blokujących.
- 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ą.
- Zastosuj aktualizację pełną lub delta do wszystkich urządzeń blokowych w docelowym boksie.
- Podłącz partycje, aby uruchomić skrypt po instalacji, a następnie: odłącz partycje.
- 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
iproduct_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 podzielsuper.img
i wyłącza krok po instalacji w celu zmodernizowania aktualizacji.-
Jest generowane z dodatkowym argumentem
--retrofit_dynamic_partitions
na Skryptota_from_target_files
. - Możesz go zastosować do wszystkich kompilacji.
-
Jest generowane z dodatkowym argumentem
-
$(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ę.