Budowanie pakietów OTA

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Możesz użyć narzędzia ota_from_target_files dostępnego w build/make/tools/releasetools do tworzenia pełnych i przyrostowych pakietów OTA dla urządzeń korzystających z aktualizacji systemu A/B lub aktualizacji systemu innych niż A/B . Narzędzie pobiera plik target-files.zip utworzony przez system kompilacji Androida jako dane wejściowe.

W przypadku urządzeń z systemem Android 11 lub nowszym możesz zbudować jeden pakiet OTA dla wielu urządzeń z różnymi jednostkami SKU. Wymaga to skonfigurowania urządzeń docelowych do korzystania z dynamicznych odcisków palców i zaktualizowania metadanych OTA , aby uwzględnić nazwę urządzenia i odcisk palca we wpisach stanu wstępnego i końcowego.

Wycofane z systemu Android 8.0 pakiety OTA oparte na plikach dla urządzeń innych niż A/B, które muszą zamiast tego używać pakietów OTA opartych na blokach . Aby wygenerować oparte na blokach pakiety OTA lub urządzenia z systemem Android 7.x lub starszym, przekaż opcję --block do parametru ota_from_target_files .

Budowanie pełnych aktualizacji

Pełna aktualizacja to pakiet OTA, który zawiera cały stan końcowy urządzenia (partycje systemowe, rozruchowe i odzyskiwania). Dopóki urządzenie jest w stanie odebrać i zastosować pakiet, pakiet może zainstalować kompilację niezależnie od aktualnego stanu urządzenia. Na przykład, poniższe komendy używają narzędzi do wydania, aby zbudować archiwum target-files.zip dla urządzenia tardis .

. build/envsetup.sh && lunch tardis-eng
mkdir dist_output
make dist DIST_DIR=dist_output

make dist buduje pełny pakiet OTA (w $OUT ). Wynikowy plik .zip zawiera wszystko, co jest potrzebne do skonstruowania pakietów OTA dla urządzenia tardis . Możesz także zbudować ota_from_target_files jako plik binarny Pythona i wywołać go, aby zbudować pełne lub przyrostowe pakiety.

ota_from_target_files dist_output/tardis-target_files.zip ota_update.zip

Ścieżka ota_from_target_files jest ustawiona w $PATH , a wynikowy plik binarny Pythona znajduje się w katalogu out/ .

ota_update.zip jest teraz gotowy do wysłania na urządzenia testowe (wszystko jest podpisane kluczem testowym). W przypadku urządzeń użytkowników wygeneruj i użyj własnych kluczy prywatnych zgodnie z opisem w kompilacjach podpisywania do wydania .

Budowanie aktualizacji przyrostowych

Aktualizacja przyrostowa to pakiet OTA zawierający binarne poprawki do danych znajdujących się już na urządzeniu. Pakiety z aktualizacjami przyrostowymi są zazwyczaj mniejsze, ponieważ nie muszą zawierać niezmienionych plików. Ponadto, ponieważ zmienione pliki są często bardzo podobne do swoich poprzednich wersji, pakiet musi zawierać jedynie kodowanie różnic między tymi dwoma plikami.

Pakiet aktualizacji przyrostowej można zainstalować tylko na urządzeniach z kompilacją źródłową używaną do konstruowania pakietu. Aby zbudować aktualizację przyrostową, potrzebujesz pliku target_files.zip z poprzedniej kompilacji (tej, z której chcesz zaktualizować ), a także pliku target_files.zip z nowej kompilacji. Na przykład poniższe polecenia używają narzędzi do wydania, aby zbudować aktualizację przyrostową dla urządzenia tardis .

ota_from_target_files -i PREVIOUS-tardis-target_files.zip dist_output/tardis-target_files.zip incremental_ota_update.zip

Ta kompilacja jest bardzo podobna do poprzedniej, a pakiet aktualizacji przyrostowych ( incremental_ota_update.zip ) jest znacznie mniejszy niż odpowiednia pełna aktualizacja (około 1 MB zamiast 60 MB).

Dystrybuuj pakiet przyrostowy tylko do urządzeń, które działają dokładnie w tej samej poprzedniej kompilacji, która była używana jako punkt początkowy pakietu przyrostowego. Musisz sflashować obrazy w PREVIOUS-tardis-target_files.zip lub PREVIOUS-tardis-img.zip (oba zbudowane za pomocą make dist , które mają być sflashowane wraz z fastboot update ), zamiast tych w katalogu PRODUCT_OUT (zbudowanym za pomocą make , który zostanie flashowany z fastboot flashall ). Próba zainstalowania pakietu przyrostowego na urządzeniu z inną kompilacją skutkuje błędem instalacji. Gdy instalacja się nie powiedzie, urządzenie pozostaje w tym samym stanie roboczym (ze starym systemem); pakiet weryfikuje poprzedni stan wszystkich plików, które aktualizuje przed ich dotknięciem, więc urządzenie nie jest zawieszone w stanie w połowie zaktualizowanego.

Aby zapewnić użytkownikom jak najlepsze wrażenia, oferuj pełną aktualizację co 3–4 aktualizacje przyrostowe. Pomaga to użytkownikom nadążyć za najnowszą wersją i uniknąć długiej sekwencji instalacji z aktualizacjami przyrostowymi.

Tworzenie pakietów OTA dla wielu jednostek SKU

Android 11 lub nowszy obsługuje korzystanie z jednego pakietu OTA dla wielu urządzeń z różnymi jednostkami SKU. Wymaga to skonfigurowania urządzeń docelowych tak, aby korzystały z dynamicznych odcisków palców i aktualizacji metadanych OTA (przy użyciu narzędzi OTA), aby uwzględnić nazwę urządzenia i odcisk palca we wpisach stanu przed i po.

Informacje o jednostkach SKU

Format jednostki SKU jest odmianą połączonych wartości parametrów kompilacji i jest zwykle niezadeklarowanym podzbiorem bieżących parametrów build_fingerprint . Producenci OEM mogą używać dowolnej kombinacji parametrów kompilacji zatwierdzonych przez CDD dla jednostki SKU, jednocześnie używając jednego obrazu dla tych jednostek SKU. Na przykład następująca jednostka SKU ma wiele odmian:

SKU = <product><device><modifierA><modifierB><modifierC>
  • modifierA to poziom urządzenia (np. Pro, Premium lub Plus)
  • modifierB to odmiana sprzętowa (taka jak radio)
  • modifierC to region, który może być ogólny (np. NA, EMEA lub CHN ) lub specyficzny dla kraju lub języka (np. JPN, ENG lub CHN)

Wielu producentów OEM używa jednego obrazu dla wielu jednostek SKU, a następnie uzyskuje ostateczną nazwę produktu i odcisk palca urządzenia w czasie wykonywania po uruchomieniu urządzenia. Proces ten upraszcza proces rozwoju platformy, umożliwiając urządzeniom z niewielkimi dostosowaniami, ale różnymi nazwami produktów wspólne obrazy (takie jak tardis i tardispro ).

Korzystanie z dynamicznych odcisków palców

Odcisk palca to zdefiniowana konkatenacja parametrów kompilacji, takich jak ro.product.brand , ro.product.name i ro.product.device . Odcisk palca urządzenia pochodzi z odcisku palca partycji systemowej i jest używany jako unikalny identyfikator obrazów (i bajtów) działających na urządzeniu. Aby utworzyć dynamiczny odcisk palca, użyj dynamicznej logiki w pliku build.prop urządzenia, aby uzyskać wartość zmiennych programu ładującego w czasie rozruchu urządzenia, a następnie użyj tych danych do utworzenia dynamicznego odcisku palca dla tego urządzenia.

Na przykład, aby używać dynamicznych odcisków palców dla urządzeń tardis i tardispro , zaktualizuj następujące pliki, jak pokazano poniżej.

  • Zaktualizuj plik odm/etc/build_std.prop , aby zawierał następujący wiersz.

    ro.odm.product.device=tardis

  • Zaktualizuj plik odm/etc/build_pro.prop , aby zawierał następujący wiersz.

    ro.odm.product.device=tardispro

  • Zaktualizuj plik odm/etc/build.prop , aby zawierał następujące wiersze.

    ro.odm.product.device=tardis
import /odm/etc/build_${ro.boot.product.hardware.sku}.prop

Te wiersze dynamicznie ustawiają nazwę urządzenia, odcisk palca i wartości ro.build.fingerprint na podstawie wartości właściwości bootloader ro.boot.product.hardware.sku (która jest tylko do odczytu).

Aktualizowanie metadanych pakietu OTA

Pakiet OTA zawiera plik metadanych ( META-INF/com/android/metadata ), który opisuje pakiet, w tym warunek wstępny i końcowy pakietu OTA. Na przykład poniższy kod jest plikiem metadanych dla pakietu OTA skierowanego do urządzenia tardis .

post-build=google/tardis/tardis:11/RP1A.200521.001/6516341:userdebug/dev-keys
post-build-incremental=6516341
post-sdk-level=30
post-security-patch-level=2020-07-05
post-timestamp=1590026334
pre-build=google/tardis/tardis:11/RP1A.200519.002.A1/6515794:userdebug/dev-keys
pre-build-incremental=6515794
pre-device=tardis

Wartości pre-device , pre-build-incremental i pre-build definiują stan, jaki musi mieć urządzenie, zanim będzie można zainstalować pakiet OTA. Wartości post-build-incremental i post-build definiują stan, jaki ma mieć urządzenie po zainstalowaniu pakietu OTA. Wartości pól pre- i post- pochodzą z następujących odpowiednich właściwości kompilacji.

  • Wartość pre-device pochodzi z właściwości kompilacji ro.product.device .
  • Wartości pre-build-incremental post-build-incremental są uzyskiwane z właściwości kompilacji ro.build.version.incremental .
  • Wartości pre-build i post-build pochodzą z właściwości kompilacji ro.build.fingerprint .

Na urządzeniach z systemem Android 11 lub nowszym możesz użyć flagi --boot_variable_file w narzędziach OTA, aby określić ścieżkę do pliku, który zawiera wartości zmiennych środowiska uruchomieniowego używanych podczas tworzenia dynamicznego odcisku palca urządzenia. Dane są następnie wykorzystywane do aktualizacji metadanych OTA, aby uwzględnić nazwę urządzenia i odcisk palca w warunkach pre- i post- (przy użyciu znaku pionowego | jako ogranicznika). Flaga --boot_variable_file ma następującą składnię i opis.

  • Składnia: --boot_variable_file <path>
  • Opis: określa ścieżkę do pliku, który zawiera możliwe wartości właściwości ro.boot.* . Służy do obliczania możliwych odcisków palców środowiska wykonawczego, gdy niektóre właściwości ro.product.* są zastępowane przez instrukcję import. Plik oczekuje jednej właściwości na wiersz, przy czym każdy wiersz ma następujący format: prop_name=value1,value2 .

Na przykład, gdy właściwość to ro.boot.product.hardware.sku=std,pro , metadane OTA dla urządzeń tardis i tardispro są pokazane poniżej.

post-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-device=tardis|tardispro

Aby obsługiwać tę funkcję na urządzeniach z systemem Android 10, zapoznaj się z implementacją referencyjną . Ta lista zmian warunkowo analizuje instrukcje import w pliku build.prop , co umożliwia rozpoznanie nadpisań właściwości i ich odzwierciedlenie w ostatecznych metadanych OTA.