Aktualizacje systemów innych niż A/B

Na starszych urządzeniach z Androidem bez partycji A/B przestrzeń flash zazwyczaj zawiera następujące partycje:

uruchomić: Zawiera jądro Linux i minimalny główny system plików (ładowany na dysk RAM). Montuje system i inne partycje oraz uruchamia środowisko uruchomieniowe znajdujące się na partycji systemowej.
system: Zawiera aplikacje systemowe i biblioteki, które mają kod źródłowy dostępny w Android Open Source Project (AOSP). Podczas normalnej pracy ta partycja jest montowana tylko do odczytu; jego zawartość zmienia się tylko podczas aktualizacji OTA.
sprzedawca: Zawiera aplikacje systemowe i biblioteki, które nie mają kodu źródłowego dostępnego w Android Open Source Project (AOSP). Podczas normalnej pracy ta partycja jest montowana tylko do odczytu; jego zawartość zmienia się tylko podczas aktualizacji OTA.
dane użytkownika: Przechowuje dane zapisane przez aplikacje zainstalowane przez użytkownika itp. Ta partycja nie jest zwykle dotykana przez proces aktualizacji OTA.
Pamięć podręczna: Tymczasowy obszar przechowywania używany przez kilka aplikacji (dostęp do tej partycji wymaga specjalnych uprawnień aplikacji) oraz do przechowywania pobranych pakietów aktualizacji OTA. Inne programy wykorzystują tę przestrzeń w nadziei, że pliki mogą zniknąć w dowolnym momencie. Niektóre instalacje pakietów OTA mogą spowodować całkowite wyczyszczenie tej partycji. Pamięć podręczna zawiera również dzienniki aktualizacji z aktualizacji OTA.
powrót do zdrowia: Zawiera drugi kompletny system Linux, w tym jądro i specjalny plik binarny odzyskiwania, który odczytuje pakiet i używa jego zawartości do aktualizacji innych partycji.
różne: Mała partycja używana przez odzyskiwanie do przechowywania niektórych informacji o tym, co robi, na wypadek ponownego uruchomienia urządzenia podczas stosowania pakietu OTA.

Życie aktualizacji OTA

Typowa aktualizacja OTA zawiera następujące kroki:

Urządzenie regularnie sprawdza się na serwerach OTA i jest powiadamiane o dostępności aktualizacji, w tym o adresie URL pakietu aktualizacji i opisie, który ma pokazać użytkownikowi.
Aktualizacja jest pobierana do pamięci podręcznej lub partycji danych, a jej podpis kryptograficzny jest weryfikowany z certyfikatami w /system/etc/security/otacerts.zip . Użytkownik zostanie poproszony o zainstalowanie aktualizacji.
Urządzenie uruchamia się ponownie w trybie odzyskiwania, w którym jądro i system na partycji odzyskiwania są uruchamiane zamiast jądra na partycji rozruchowej.
Plik binarny odzyskiwania jest uruchamiany przez init. Znajduje argumenty wiersza poleceń w /cache/recovery/command , które wskazują na pobrany pakiet.
Odzyskiwanie weryfikuje podpis kryptograficzny pakietu z kluczami publicznymi w katalogu /res/keys (część dysku RAM znajdująca się na partycji odzyskiwania).
Dane są pobierane z pakietu i używane do aktualizacji partycji rozruchowej, systemowej i/lub dostawcy w razie potrzeby. Jeden z nowych plików pozostawionych na partycji systemowej zawiera zawartość nowej partycji odzyskiwania.
Urządzenie uruchamia się ponownie normalnie.
1. Nowo zaktualizowana partycja rozruchowa jest ładowana, montuje się i rozpoczyna wykonywanie plików binarnych na nowo zaktualizowanej partycji systemowej.
2. W ramach normalnego uruchamiania system sprawdza zawartość partycji odzyskiwania pod kątem żądanej zawartości (która była wcześniej zapisana jako plik w katalogu /system ). Są różne, więc partycja odzyskiwania jest odświeżana z żądaną zawartością. (Przy kolejnych rozruchach partycja odzyskiwania zawiera już nową zawartość, więc ponowne flashowanie nie jest konieczne).

Aktualizacja systemu zakończona! Dzienniki aktualizacji można znaleźć w /cache/recovery/last_log. # .

Zaktualizuj pakiety

Pakiet aktualizacji to plik .zip , który zawiera wykonywalny plik binarny META-INF/com/google/android/update-binary . Po zweryfikowaniu podpisu na pakiecie, recovery wyodrębnia ten plik binarny do /tmp i uruchamia go, przekazując następujące argumenty:

Zaktualizuj numer wersji binarnego interfejsu API . Jeśli argumenty przekazywane do aktualizacji binarnej zmieniają się, liczba ta wzrasta.
Deskryptor pliku potoku poleceń . Program aktualizacyjny może używać tego potoku do wysyłania poleceń z powrotem do pliku binarnego odzyskiwania, głównie w przypadku zmian interfejsu użytkownika, takich jak wskazywanie postępu użytkownikowi.
Nazwa pliku pakietu aktualizacji .zip .

Pakiet aktualizacji może używać dowolnego pliku binarnego połączonego statycznie jako pliku binarnego aktualizacji. Narzędzia do tworzenia pakietów OTA używają programu aktualizującego ( bootable/recovery/updater ), który zapewnia prosty język skryptowy, który może wykonać wiele zadań instalacyjnych. Możesz zastąpić dowolny inny plik binarny działający na urządzeniu.

Aby uzyskać szczegółowe informacje na temat binarnego aktualizatora, składni edify i funkcji wbudowanych, zobacz Inside OTA Packages .

Migracja z poprzednich wersji

Podczas migracji z wersji Androida 2.3/3.0/4.0 główną zmianą jest konwersja wszystkich funkcji specyficznych dla urządzenia z zestawu funkcji C ze wstępnie zdefiniowanymi nazwami na obiekty C++. W poniższej tabeli wymieniono stare funkcje i nowe metody, które służą mniej więcej równoważnemu celowi:

Funkcja C	Metoda C++
device_recovery_start()	Urządzenie::RecoveryStart()
device_toggle_display() device_reboot_now()	RecoveryUI::CheckKey() (również RecoveryUI::IsKeyPressed())
device_handle_key()	Urządzenie::HandleMenuKey()
urządzenie_wydajność_akcja()	Urządzenie::InvokeMenuItem()
device_wipe_data()	Urządzenie::WipeData()
urządzenie_ui_init()	ScreenRecoveryUI::Init()

Konwersja starych funkcji na nowe metody powinna być dość prosta. Nie zapomnij dodać nowej funkcji make_device() , aby utworzyć i zwrócić instancję nowej podklasy Device.