Od 27 marca 2025 r. zalecamy używanie android-latest-release zamiast aosp-main do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.

Ta strona została przetłumaczona przez Cloud Translation API.

Tworzenie pakietów OTA

Możesz użyć narzędzia ota_from_target_files udostępnionego w build/make/tools/releasetools, aby utworzyć pełne i przyrostowe pakiety OTA dla urządzeń, które korzystają z aktualizacji systemu A/B lub aktualizacji systemu innych niż A/B. Narzędzie przyjmuje jako dane wejściowe plik target-files.zip wygenerowany przez system kompilacji Androida.

W przypadku urządzeń z Androidem 11 lub nowszym możesz utworzyć jeden pakiet OTA dla wielu urządzeń z różnymi kodami SKU. Wymaga to skonfigurowania urządzeń docelowych do używania dynamicznych odcisków palców i zaktualizowania metadanych OTA, aby uwzględniały nazwę urządzenia i odcisk palca we wpisach warunków wstępnych i następczych.

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

Tworzenie pełnych aktualizacji

Pełna aktualizacja to pakiet OTA, który zawiera cały ostateczny stan urządzenia (partycje systemową, rozruchową i przywracania). Jeśli urządzenie może odbierać i stosować pakiet, można zainstalować kompilację niezależnie od jego bieżącego stanu. Na przykład poniższe polecenia używają narzędzi do tworzenia wersji, aby utworzyć archiwum target-files.zip na urządzenie tardis.

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

make dist tworzy pełny pakiet OTA (w $OUT). Wynikowy plik .zip zawiera wszystko, co jest potrzebne do utworzenia pakietów OTA dla urządzenia tardis. Możesz też utworzyć ota_from_target_files jako plik binarny Pythona i wywołać go, aby utworzyć 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 skonfigurowana w $PATH, a wynikowy plik binarny Pythona znajduje się w katalogu out/.

ota_update.zip jest teraz gotowa 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 sekcji Podpisywanie wersji.

Tworzenie aktualizacji przyrostowych

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

Pakiet aktualizacji przyrostowej można zainstalować tylko na urządzeniach, które mają kompilację źródłową używaną do tworzenia pakietu. Aby utworzyć aktualizację przyrostową, potrzebujesz pliku target_files.zip z poprzedniej kompilacji (tej, którą chcesz zaktualizować z) oraz pliku target_files.zip z nowej kompilacji. Na przykład poniższe polecenia używają narzędzi do publikowania, aby utworzyć 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 przyrostowej (incremental_ota_update.zip) jest znacznie mniejszy niż odpowiednia pełna aktualizacja (około 1 MB zamiast 60 MB).

Rozpowszechniaj pakiet przyrostowy tylko na urządzeniach, na których działa dokładnie ta sama poprzednia kompilacja, która została użyta jako punkt wyjścia pakietu przyrostowego. Musisz wgrać obrazy w wersji PREVIOUS-tardis-target_files.zip lub PREVIOUS-tardis-img.zip (oba utworzone za pomocą make dist, do wgrania za pomocą fastboot update), a nie te z katalogu PRODUCT_OUT (utworzone za pomocą make, które zostaną wgrane za pomocą fastboot flashall). Próba zainstalowania pakietu przyrostowego na urządzeniu z inną kompilacją spowoduje błąd instalacji. Jeśli instalacja się nie powiedzie, urządzenie pozostanie w tym samym stanie (będzie działać na starym systemie). Pakiet przed wprowadzeniem zmian w plikach sprawdza ich poprzedni stan, więc urządzenie nie pozostanie w stanie częściowej aktualizacji.

Aby zapewnić użytkownikom jak najlepsze wrażenia, co 3–4 aktualizacje przyrostowe udostępniaj pełną aktualizację. Dzięki temu użytkownicy mogą szybko przejść do najnowszej wersji i uniknąć długiej sekwencji instalacji przyrostowych aktualizacji.

Tworzenie pakietów OTA dla wielu kodów SKU

Android 11 lub nowszy obsługuje używanie jednego pakietu OTA na wielu urządzeniach z różnymi numerami SKU. Wymaga to skonfigurowania urządzeń docelowych do korzystania z dynamicznych odcisków palców i zaktualizowania metadanych OTA (za pomocą narzędzi OTA) w celu uwzględnienia nazwy urządzenia i odcisku palca we wpisach warunków wstępnych i końcowych.

Informacje o kodach SKU

Format kodu SKU to odmiana połączonych wartości parametru build i zwykle jest to niezadeklarowany podzbiór bieżących parametrów build_fingerprint. Producenci OEM mogą używać dowolnej kombinacji parametrów kompilacji zatwierdzonych w CDD dla danego kodu SKU, a jednocześnie używać jednego obrazu dla tych kodów SKU. Na przykład ten kod SKU ma kilka wersji:

SKU = <product><device><modifierA><modifierB><modifierC>

modifierA to poziom urządzenia (np. Pro, Premium lub Plus).
modifierB to wariant sprzętowy (np. radio).
modifierC to region, który może być ogólny (np. NA, EMEA lub CHN) albo dotyczyć konkretnego kraju lub języka (np. JPN, ENG lub CHN).

Wielu producentów OEM używa jednego obrazu dla wielu jednostek SKU, a następnie w czasie działania urządzenia po jego uruchomieniu uzyskuje ostateczną nazwę produktu i odcisk palca urządzenia. Upraszcza to proces tworzenia platformy, dzięki czemu urządzenia z niewielkimi modyfikacjami, ale różnymi nazwami produktów mogą korzystać ze wspólnych obrazów (takich jak tardis i tardispro).

Używanie dynamicznych odcisków palców

Odcisk palca to zdefiniowane połączenie parametrów kompilacji, takich jak ro.product.brand, ro.product.name i ro.product.device. Odcisk cyfrowy urządzenia jest wyodrębniany z odcisku cyfrowego partycji systemowej i służy jako unikalny identyfikator obrazów (i bajtów) działających na urządzeniu. Aby utworzyć dynamiczny odcisk palca, użyj logiki dynamicznej w pliku build.prop urządzenia, aby uzyskać wartość zmiennych programu rozruchowego w momencie uruchomienia urządzenia, a następnie użyj tych danych do utworzenia dynamicznego odcisku palca dla tego urządzenia.

Aby na przykład używać dynamicznych odcisków palców na urządzeniach tardis i tardispro, zaktualizuj te pliki w sposób pokazany poniżej.

Zaktualizuj plik odm/etc/build_std.prop, aby zawierał ten wiersz.
```
ro.odm.product.device=tardis
```
Zaktualizuj plik odm/etc/build_pro.prop, aby zawierał ten wiersz.
```
ro.odm.product.device=tardispro
```

Zaktualizuj plik odm/etc/build.prop, aby zawierał te 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 ro.boot.product.hardware.sku bootloadera (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 warunki wstępne i następcze pakietu OTA. Na przykład ten kod to plik metadanych pakietu OTA przeznaczonego na urządzenie 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 określają stan, w jakim musi znajdować się urządzenie, zanim będzie można zainstalować pakiet OTA. Wartości post-build-incremental i post-build określają stan, w jakim urządzenie powinno się znajdować po zainstalowaniu pakietu OTA. Wartości pól pre- i post- pochodzą z tych właściwości kompilacji:

Wartość pre-device pochodzi z właściwości kompilacji ro.product.device.
Wartości pre-build-incremental i 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 Androidem 11 lub nowszym możesz użyć flagi --boot_variable_file w narzędziach OTA, aby określić ścieżkę do pliku zawierającego wartości zmiennych środowiska wykonawczego używanych do tworzenia dynamicznego odcisku palca urządzenia. Dane są następnie używane do aktualizacji metadanych OTA, aby uwzględnić nazwę urządzenia i odcisk palca w warunkach pre- i post- (z użyciem znaku | jako separatora). 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 zawierającego 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ę importu. Plik powinien zawierać po jednej usłudze w wierszu, a każdy wiersz powinien mieć format: prop_name=value1,value2.

Jeśli na przykład właściwość to ro.boot.product.hardware.sku=std,pro, metadane OTA dla urządzeń tardis i tardispro są takie jak 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 Androidem 10, zapoznaj się z implementacją referencyjną. Ta lista zmian warunkowo analizuje instrukcje import w pliku build.prop, co umożliwia rozpoznawanie zastąpień właściwości i odzwierciedlanie ich w końcowych metadanych OTA.