Przegląd

Urządzenia z Androidem zawierają kilka partycji, które pełnią różne funkcje w procesie rozruchu.

Standardowe partycje

• partycja boot . Ta partycja zawiera obraz jądra i jest tworzona przy użyciu mkbootimg . Możesz użyć partycji wirtualnej do bezpośredniego flashowania dowolnego obrazu bez konieczności flashowania nowej partycji rozruchowej. Ta partycja zawiera również ogólny ramdysk w urządzeniach uruchomionych przed Androidem 13.

  • jądro. Wirtualna partycja kernel zastępuje jądro ( zImage , zImage-dtb , Image.gz-dtb ), zapisując nowy obraz jądra na starym obrazie jądra. Jeśli dostarczone jądro rozwojowe jest niekompatybilne, może zaistnieć potrzeba aktualizacji vendor , system lub partycji dtb (jeśli jest obecna) za pomocą powiązanych modułów jądra.

  • ramdysk. Wirtualna partycja ramdisk zastępuje ramdysk, zapisując nowy obraz ramdysku na starym obrazie ramdysku.

  Operacja nadpisywania określa lokalizację początkową istniejącego obrazu w eMMC i kopiuje nowy obraz do tej lokalizacji. Nowy obraz (jądro lub ramdysk) może być większy od istniejącego; aby zwolnić miejsce, program ładujący może przenieść dane zgodnie z obrazem lub przerwać operację z powodu błędu.

• partycja init_boot . Ta partycja zawiera ogólny ramdysk dla urządzeń uruchamianych z systemem Android 13 i nowszym.

• partycja system . Ta partycja zawiera środowisko Androida.

• partycja odm . Ta partycja zawiera oryginalne dostosowania producenta projektu (ODM) do pakietów obsługi płyt systemowych (SoC) dostawców (BSP). Takie dostosowania umożliwiają ODM wymianę lub dostosowanie komponentów SoC oraz wdrożenie modułów jądra dla komponentów specyficznych dla płyty głównej, demonów i funkcji specyficznych dla ODM w warstwach abstrakcji sprzętu (HAL). Ta partycja jest opcjonalna; zazwyczaj służy do dostosowywania, dzięki czemu urządzenia mogą używać obrazu jednego dostawcy dla wielu jednostek SKU sprzętu. Aby uzyskać szczegółowe informacje, zobacz Partycje ODM .

• partycja odm_dlkm . Ta partycja jest przeznaczona do przechowywania modułów jądra ODM. Przechowywanie modułów jądra ODM na partycji odm_dlkm (w przeciwieństwie do partycji odm ) umożliwia aktualizację modułów jądra ODM bez aktualizacji partycji odm .

• partycja recovery . Na tej partycji przechowywany jest obraz odzyskiwania, który jest uruchamiany podczas procesu OTA. Urządzenia obsługujące bezproblemowe aktualizacje mogą przechowywać obrazy odzyskiwania jako ramdysk zawarty w obrazie boot lub init_boot (a nie w oddzielnym obrazie).

• partycja cache . Ta partycja przechowuje dane tymczasowe i jest opcjonalna, jeśli urządzenie korzysta z płynnych aktualizacji. Partycja pamięci podręcznej nie musi umożliwiać zapisu z poziomu programu ładującego, ale musi umożliwiać jej wymazanie. Rozmiar partycji zależy od typu urządzenia i dostępności miejsca na userdata ; zazwyczaj wystarczające jest 50–100 MB.

• misc partycja. Ta partycja jest używana przez partycję odzyskiwania i ma rozmiar 4 KB lub większy.

• partycja userdata . Ta partycja zawiera aplikacje i dane zainstalowane przez użytkownika, w tym dane dotyczące dostosowywania.

• partycja metadata . Ta partycja służy do przechowywania klucza szyfrowania metadanych, gdy urządzenie korzysta z szyfrowania metadanych . Rozmiar wynosi 16 MB lub więcej. Nie jest szyfrowany, a jego dane nie są kopiowane. Jest usuwany po przywróceniu ustawień fabrycznych urządzenia. Użycie tej partycji jest ściśle ograniczone.

• partycja vendor . Ta partycja zawiera dowolny plik binarny, którego nie można dystrybuować do AOSP. Jeśli urządzenie nie zawiera informacji zastrzeżonych, możesz pominąć tę partycję.

• partycja vendor_dlkm . Ta partycja jest przeznaczona do przechowywania modułów jądra dostawcy. Przechowywanie modułów jądra dostawcy na partycji vendor_dlkm (w przeciwieństwie do partycji vendor ) umożliwia aktualizację modułów jądra bez aktualizowania partycji vendor .

• partycja radio . Ta partycja zawiera obraz radia i jest potrzebna tylko w przypadku urządzeń, które zawierają radio z oprogramowaniem specyficznym dla radia na dedykowanej partycji.

• tos partycja. Ta partycja przechowuje binarny obraz systemu operacyjnego Trusty i jest używana tylko wtedy, gdy na urządzeniu znajduje się system Trusty. Aby uzyskać szczegółowe informacje, zobacz Partycje TOS .

• partycja pvmfw . Na tej partycji przechowywane jest oprogramowanie sprzętowe chronionej maszyny wirtualnej (pvmfw), które jest pierwszym kodem uruchamianym na chronionych maszynach wirtualnych. Aby uzyskać więcej informacji, zobacz oprogramowanie sprzętowe chronionej maszyny wirtualnej .

Partycje dynamiczne

Urządzenia z systemem Android 11 lub nowszym obsługują partycje dynamiczne, czyli system partycjonowania przestrzeni użytkownika dla systemu Android, który umożliwia tworzenie, zmianę rozmiaru lub niszczenie partycji podczas aktualizacji OTA. Aby uzyskać szczegółowe informacje, zobacz Partycje dynamiczne .

Wyznaczanie partycji krytycznych

Jeśli urządzenie wymaga do działania określonych partycji lub danych, należy wyznaczyć te partycje/dane jako w pełni chronione lub nadające się do ponownego flashowania, co oznacza, że ​​można je ponownie zbudować, udostępnić lub wyodrębnić za pomocą polecenia fastboot oem . Obejmuje to takie dane, jak ustawienia fabryczne poszczególnych urządzeń, numery seryjne, dane kalibracyjne i inne.

Zmiany w Androidzie 11

Android 11 zawiera liczne zmiany w partycjach, w tym ograniczenia w zakresie łączenia z bibliotekami i nowe warianty obrazu Soong.

Rysunek 1. Układ partycji w systemie Android 11

• Pojedynczy obraz systemu (SSI). Nowy, koncepcyjny obraz zawierający obrazy system i system_ext . Jeśli te partycje są wspólne dla zestawu urządzeń docelowych, urządzenia te mogą współużytkować interfejs SSI i pomijać tworzenie obrazów system i system_ext .

• partycja system_ext . Nowa partycja, która może korzystać z zasobów system i może zawierać moduły systemowe, które:

  • Rozszerz moduły systemowe AOSP na partycji system . Zalecamy przesłanie takich modułów do AOSP, aby można było je później zainstalować na partycji system .

  • Połącz moduły OEM lub specyficzne dla SoC. Zalecamy rozdzielenie takich modułów, aby można je było zainstalować na partycji product lub vendor .

• partycja system . Wspólny obraz systemu używany w produktach OEM. Zalecamy przeniesienie zastrzeżonych modułów poza partycję system , przesyłając je do AOSP lub przenosząc je na partycję system_ext .

• podział product . Ta partycja może teraz używać dozwolonych interfejsów do instalowania modułów specyficznych dla produktu, które nie są dołączone do żadnych innych partycji.

Zmiany w VNDK

Vendor Native Development Kit (VNDK) to zestaw bibliotek instalowanych na partycji system i przeznaczony wyłącznie dla dostawców w celu wdrożenia ich warstw HAL.

• W systemie Android 10 i starszych partycja vendor może łączyć się z bibliotekami VNDK na partycji system , ale nie może łączyć się z innymi bibliotekami na partycji system . Natywne moduły w partycji product mogą łączyć się z dowolną biblioteką w partycji system .

• W systemie Android 11 i nowszych partycje product i vendor mogą łączyć się z bibliotekami VNDK na partycji system , ale nie mogą łączyć się z innymi bibliotekami na partycji system .

Wkrótce warianty produktów

System kompilacji Soong wykorzystuje warianty obrazu do dzielenia zależności kompilacji. Moduły natywne ( /build/soong/cc ) mogą mutować moduły procesów systemowych do wariantu podstawowego i moduły procesów dostawcy do wariantu dostawcy; moduł w jednym wariancie obrazu nie może być powiązany z innymi modułami w innym wariancie obrazu.

• W systemie Android 10 lub starszym moduł systemowy automatycznie tworzy warianty podstawowe. Może także tworzyć warianty dostawców, definiując vendor_available: true w swoich plikach Android.bp ; umożliwia to modułom dostawcy łączenie się z modułami systemu. Biblioteki VNDK, które są wariantami dostawców bibliotek system , mogą również tworzyć warianty dostawców dla modułów dostawców poprzez zdefiniowanie vendor_available: true w swoich plikach Android.bp (patrz przykład ).

• W systemie Android 11 moduł systemowy może również utworzyć wariant produktu (oprócz wariantów podstawowych i dostawców), definiując vendor_available: true .

• W systemie Android 12 lub nowszym moduł systemowy z vendor_available: true tworzy wariant dostawcy oprócz wariantu podstawowego. Aby utworzyć wariant produktu, należy zdefiniować product_available: true . Niektóre biblioteki VNDK bez product_available: true nie są dostępne dla modułów produktu.