Producenci OEM i dostawcy SoC, którzy chcą wdrożyć aktualizacje systemu A/B, muszą upewnić się, że ich program ładujący implementuje warstwę HAL boot_control i przekazuje prawidłowe parametry do jądra.
Zaimplementuj kontrolę rozruchu HAL
Programy ładujące obsługujące A/B muszą implementować warstwę HAL boot_control
pod adresem hardware/libhardware/include/hardware/boot_control.h
. Możesz przetestować implementacje za pomocą narzędzia system/extras/bootctl
i system/extras/tests/bootloader/
.
Musisz także zaimplementować maszynę stanów pokazaną poniżej:
Skonfiguruj jądro
Aby wdrożyć aktualizacje systemu A/B:
- Cherrypick następującą serię poprawek do jądra (w razie potrzeby):
- W przypadku uruchamiania bez ramdysku i używania opcji „rozruch jako odzyskiwanie”, cherrypick android-review.googlesource.com/#/c/158491/ .
- Aby skonfigurować dm-verity bez ramdysku, wybierz cherrypick android-review.googlesource.com/#/q/status:merged+project:kernel/common+branch:android-3.18+topic:A_B_Changes_3.18 .
- Upewnij się, że argumenty wiersza poleceń jądra zawierają następujące dodatkowe argumenty:
skip_initramfs rootwait ro init=/init root="/dev/dm-0 dm=system none ro,0 1 android-verity <public-key-id> <path-to-system-partition>"
<public-key-id>
jest identyfikatorem klucza publicznego używanego do weryfikacji podpisu tabeli prawdziwości (więcej szczegółów znajdziesz w dm-verity ) . - Dodaj certyfikat .X509 zawierający klucz publiczny do bazy kluczy systemowych:
- Skopiuj certyfikat .X509 sformatowany w formacie
.der
do katalogu głównego katalogukernel
. Jeśli certyfikat .X509 jest sformatowany jako plik.pem
, użyj następującego poleceniaopenssl
, aby przekonwertować z formatu.pem
na.der
:openssl x509 -in <x509-pem-certificate> -outform der -out <x509-der-certificate>
- Zbuduj
zImage
, aby uwzględnić certyfikat jako część systemowego zbioru kluczy. Aby to sprawdzić, sprawdź wpisprocfs
(wymaga włączeniaKEYS_CONFIG_DEBUG_PROC_KEYS
):angler:/# cat /proc/keys 1c8a217e I------ 1 perm 1f010000 0 0 asymmetri Android: 7e4333f9bba00adfe0ede979e28ed1920492b40f: X509.RSA 0492b40f [] 2d454e3e I------ 1 perm 1f030000 0 0 keyring .system_keyring: 1/4
Pomyślne dodanie certyfikatu .X509 oznacza obecność klucza publicznego w systemie kluczy (podświetlenie oznacza identyfikator klucza publicznego). - Zamień spację na
#
i przekaż ją jako<public-key-id>
w wierszu poleceń jądra. Na przykład przekażAndroid:#7e4333f9bba00adfe0ede979e28ed1920492b40f
zamiast<public-key-id>
.
- Skopiuj certyfikat .X509 sformatowany w formacie
Ustaw zmienne kompilacji
Programy ładujące obsługujące A/B muszą spełniać następujące kryteria zmiennych kompilacji:
Należy zdefiniować cel A/B |
/device/google/marlin/+/android-7.1.0_r1/device-common.mk . Opcjonalnie możesz przeprowadzić krok dex2oat po instalacji (ale przed ponownym uruchomieniem) opisany w Kompilacja . |
---|---|
Zdecydowanie zalecane w przypadku celu A/B |
|
Nie można zdefiniować celu A/B |
|
Opcjonalne w przypadku kompilacji debugowania | PRODUCT_PACKAGES_DEBUG += update_engine_client |
Ustaw partycje (sloty)
Urządzenia A/B nie potrzebują partycji odzyskiwania ani partycji pamięci podręcznej, ponieważ system Android nie używa już tych partycji. Partycja danych jest teraz używana dla pobranego pakietu OTA, a kod obrazu odzyskiwania znajduje się na partycji rozruchowej. Wszystkie partycje A/B powinny mieć następujące nazwy (gniazda są zawsze nazywane a
, b
itd.): boot_a
, boot_b
, system_a
, system_b
, vendor_a
, vendor_b
.
Pamięć podręczna
W przypadku aktualizacji innych niż A/B partycja pamięci podręcznej była używana do przechowywania pobranych pakietów OTA i tymczasowego przechowywania bloków podczas stosowania aktualizacji. Nigdy nie było dobrego sposobu na określenie rozmiaru partycji pamięci podręcznej: jej wielkość zależy od tego, jakie aktualizacje chcesz zastosować. W najgorszym przypadku partycja pamięci podręcznej będzie wielkości obrazu systemu. Dzięki aktualizacjom A/B nie ma potrzeby ukrywania bloków (ponieważ zawsze piszesz na partycję, która nie jest aktualnie używana), a przy przesyłaniu strumieniowym A/B nie ma potrzeby pobierania całego pakietu OTA przed jego zastosowaniem.
Powrót do zdrowia
Dysk RAM odzyskiwania znajduje się teraz w pliku boot.img
. Podczas odzyskiwania program ładujący nie może umieścić opcji skip_initramfs
w wierszu poleceń jądra.
W przypadku aktualizacji innych niż A/B partycja odzyskiwania zawiera kod używany do stosowania aktualizacji. Aktualizacje A/B są stosowane przez update_engine
działający w normalnie uruchamianym obrazie systemu. Nadal istnieje tryb odzyskiwania używany do przywracania danych fabrycznych i bocznego ładowania pakietów aktualizacji (stąd wzięła się nazwa „odzyskiwanie”). Kod i dane trybu odzyskiwania są przechowywane na zwykłej partycji rozruchowej w ramdysku; aby uruchomić komputer z obrazu systemu, program ładujący mówi jądru, aby pominęło ramdysk (w przeciwnym razie urządzenie uruchomi się w trybie odzyskiwania. Tryb odzyskiwania jest mały (i większość zawartości znajdowała się już na partycji rozruchowej), więc partycja rozruchowa nie zwiększa się) W rozmiarze.
Fstab
Argument slotselect
musi znajdować się w wierszu dla partycji A/B. Na przykład:
<path-to-block-device>/vendor /vendor ext4 ro wait,verify=<path-to-block-device>/metadata,slotselect
Żadna partycja nie powinna mieć nazwy vendor
. Zamiast tego zostanie wybrana partycja vendor_a
lub vendor_b
i zamontowana w punkcie podłączenia /vendor
.
Argumenty gniazda jądra
Bieżący sufiks gniazda powinien zostać przekazany albo przez określony węzeł drzewa urządzeń (DT) ( /firmware/android/slot_suffix
), albo przez wiersz poleceń jądra androidboot.slot_suffix
lub argument bootconfig.
Domyślnie fastboot miga bieżące gniazdo na urządzeniu A/B. Jeśli pakiet aktualizacji zawiera również obrazy dla drugiego, nieaktualnego gniazda, fastboot również miga tymi obrazami. Dostępne opcje obejmują:
-
--slot SLOT
. Zastąp domyślne zachowanie i poproś program fastboot o flashowanie gniazda przekazanego jako argument. -
--set-active [ SLOT ]
. Ustaw slot jako aktywny. Jeśli nie zostanie podany żaden opcjonalny argument, bieżący slot zostanie ustawiony jako aktywny. -
fastboot --help
. Uzyskaj szczegółowe informacje na temat poleceń.
Jeśli bootloader implementuje fastboot, powinien obsługiwać polecenie set_active <slot>
, które ustawia bieżący aktywny slot na dany slot (musi to również wyczyścić flagę unbootable dla tego slotu i zresetować licznik ponownych prób do wartości domyślnych). Bootloader powinien także obsługiwać następujące zmienne:
-
has-slot:<partition-base-name-without-suffix>
. Zwraca „tak”, jeśli dana partycja obsługuje sloty, „nie” w przeciwnym razie. -
current-slot
. Zwraca sufiks gniazda, który będzie uruchamiany od następnego. -
slot-count
. Zwraca liczbę całkowitą reprezentującą liczbę dostępnych miejsc. Obecnie obsługiwane są dwa gniazda, więc ta wartość wynosi2
. -
slot-successful:<slot-suffix>
. Zwraca „tak”, jeśli dany slot został oznaczony jako pomyślnie uruchamiający się, „nie” w przeciwnym razie. -
slot-unbootable:<slot-suffix>
. Zwraca „tak”, jeśli dany slot jest oznaczony jako niemożliwy do rozruchu, „nie” w przeciwnym razie. -
slot-retry-count
. Liczba pozostałych prób uruchomienia danego gniazda.
Aby wyświetlić wszystkie zmienne, uruchom fastboot getvar all
.
Generuj pakiety OTA
Narzędzia pakietu OTA wykonują te same polecenia, co polecenia dla urządzeń innych niż A/B. Plik target_files.zip
należy wygenerować poprzez zdefiniowanie zmiennych kompilacji dla celu A/B. Narzędzia pakietów OTA automatycznie identyfikują i generują pakiety w formacie aktualizatora A/B.
Przykłady:
- Aby wygenerować pełne OTA:
./build/make/tools/releasetools/ota_from_target_files \ dist_output/tardis-target_files.zip \ ota_update.zip
- Aby wygenerować przyrostową OTA:
./build/make/tools/releasetools/ota_from_target_files \ -i PREVIOUS-tardis-target_files.zip \ dist_output/tardis-target_files.zip \ incremental_ota_update.zip
Skonfiguruj partycje
update_engine
może aktualizować dowolną parę partycji A/B zdefiniowanych na tym samym dysku. Para partycji ma wspólny przedrostek (taki jak system
lub boot
) i przyrostek poszczególnych gniazd (taki jak _a
). Lista partycji, dla których generator ładunku definiuje aktualizację, jest konfigurowana za pomocą zmiennej make AB_OTA_PARTITIONS
.
Na przykład, jeśli uwzględniona jest para partycji bootloader_a
i booloader_b
( _a
i _b
to przyrostki gniazd), możesz zaktualizować te partycje, określając następujące opcje w konfiguracji produktu lub płyty:
AB_OTA_PARTITIONS := \ boot \ system \ bootloader
Wszystkie partycje aktualizowane przez update_engine
nie mogą być modyfikowane przez resztę systemu. Podczas aktualizacji przyrostowych lub delta dane binarne z bieżącego gniazda są wykorzystywane do generowania danych w nowym gnieździe. Jakakolwiek modyfikacja może spowodować, że dane nowego gniazda nie zostaną zweryfikowane podczas procesu aktualizacji, a co za tym idzie, aktualizacja nie powiedzie się.
Skonfiguruj poinstalację
Możesz skonfigurować krok po instalacji inaczej dla każdej zaktualizowanej partycji, używając zestawu par klucz-wartość. Aby uruchomić program znajdujący się w /system/usr/bin/postinst
na nowym obrazie, określ ścieżkę względem katalogu głównego systemu plików na partycji systemowej.
Na przykład usr/bin/postinst
to system/usr/bin/postinst
(jeśli nie używasz dysku RAM). Dodatkowo określ typ systemu plików, który ma zostać przekazany do wywołania systemowego mount(2)
. Dodaj następujące elementy do plików .mk
produktu lub urządzenia (jeśli dotyczy):
AB_OTA_POSTINSTALL_CONFIG += \ RUN_POSTINSTALL_system=true \ POSTINSTALL_PATH_system=usr/bin/postinst \ FILESYSTEM_TYPE_system=ext4
Kompiluj aplikacje
Aplikacje można kompilować w tle przed ponownym uruchomieniem przy użyciu nowego obrazu systemu. Aby kompilować aplikacje w tle, dodaj następujące elementy do konfiguracji urządzenia produktu (w pliku Device.mk produktu):
- Dołącz natywne komponenty do kompilacji, aby mieć pewność, że skrypt kompilacji i pliki binarne zostaną skompilowane i uwzględnione w obrazie systemu.
# A/B OTA dexopt package PRODUCT_PACKAGES += otapreopt_script
- Połącz skrypt kompilacji z
update_engine
, który będzie uruchamiany po instalacji.# A/B OTA dexopt update_engine hookup AB_OTA_POSTINSTALL_CONFIG += \ RUN_POSTINSTALL_system=true \ POSTINSTALL_PATH_system=system/bin/otapreopt_script \ FILESYSTEM_TYPE_system=ext4 \ POSTINSTALL_OPTIONAL_system=true
Aby uzyskać pomoc dotyczącą instalowania wstępnie wybranych plików na nieużywanej drugiej partycji systemowej, zobacz Instalacja plików DEX_PREOPT przy pierwszym uruchomieniu .