Układ partycji

W Androidzie 10 główny system plików nie jest już znajduje się w folderze ramdisk.img i zostanie scalone z system.img (czyli system.img jest zawsze tworzony jako jeśli ustawiono BOARD_BUILD_SYSTEM_ROOT_IMAGE). Urządzenia Wprowadzenie na rynek z Androidem 10:

  • Użyj układu partycji systemowej jako roota (automatycznie egzekwowanego przez bez możliwości zmiany jego działania).
  • Musisz użyć dysku RAM, który jest wymagany w przypadku dm-linear.
  • BOARD_BUILD_SYSTEM_ROOT_IMAGE musi mieć wartość false. To ustawienie służy tylko do rozróżniania urządzeń korzystających z dysku ramdisk a także na urządzeniach, które nie korzystają z dysku RAM (zamiast tego system.img).

Konfiguracja systemu jako roota różni się w przypadku Androida 9 i Androida 9. Android 10. W Androidzie 9 systemowym BOARD_BUILD_SYSTEM_ROOT_IMAGE ma wartość true, co wymusza na kompilacji połączenie głównego systemu plików z system.img, następnie podłącz system.img jako plik główny (rootfs). Ta konfiguracja jest obowiązkowa w przypadku urządzeń wprowadza na rynek Androida 9, ale jest opcjonalne na urządzeniach przechodzących na Androida 9 i urządzeń z starszymi wersjami Androida. Na urządzeniu z Androidem 10 konfiguracji systemu jako roota, kompilacja zawsze scala komórki $TARGET_SYSTEM_OUT i $TARGET_ROOT_OUT w system.img; Ta konfiguracja jest domyślnym zachowaniem na wszystkich urządzeniach z Androidem 10.

Android 10 wprowadza kolejne zmiany partycje dynamiczne, system partycjonowania przestrzeni użytkownika, który umożliwia bezprzewodowe aktualizacje tworzyć, niszczyć i zmieniać ich rozmiar. W ramach tej zmiany jądro nie może już podłączyć logicznej partycji systemu na urządzeniach uruchomionych Android 10, więc ta operacja jest obsługiwana przez pierwszy zainicjowanie etapu.

W poniższych sekcjach opisano wymagania systemowe dla OTA dostępne tylko dla systemu: wskazówki dotyczące aktualizowania urządzeń, aby umożliwić korzystanie z systemu jako roota (w tym zmiany układu partycji i wymagania dotyczące jądra dm-verity). Dla: szczegółowe informacje na temat zmian w pamięci RAM, zobacz Ramdysk Partycje.

Informacje o aktualizacjach OTA działających tylko w sposób systemowy

OTA dostępne tylko dla systemu, które umożliwiają aktualizowanie wersji Androida system.img i product.img bez zmiany innych wymaga układu partycji systemowej jako roota. Wszystkie urządzenia z Androidem 10 musi używać układu partycji systemu jako roota, włączyć OTA dostępne tylko dla systemu.

  • na urządzeniach A/B, które instalują partycję system jako rootfs, są już używane jako system główny i nie wymagają zmian w celu obsługi systemowych OTA.
  • urządzeń innych niż A/B, które instalują partycję system pod adresem /system, należy zaktualizować, aby używać układ partycji systemu jako roota do obsługi systemowych OTA.

Aby uzyskać szczegółowe informacje na temat urządzeń typu A/B i urządzeń innych niż A/B, zapoznaj się z artykułem Aktualizacje systemu typu A/B (łatwo).

Użyj nakładki dostawcy (<=AOSP 14)

Nakładka dostawcy umożliwia nakładanie zmian na vendor podczas uruchamiania urządzenia. Nakładka dostawcy to zestaw modułów dostawców w partycji product, które są nakładane na vendor. partycjonuj podczas uruchamiania urządzenia, zastępując i dodając do istniejących modułów.

Po uruchomieniu urządzenia proces init kończy pierwszy etapie montowania i odczytuje właściwości domyślne. Następnie wyszukuje /product/vendor_overlay/<target_vendor_version> i punkty montowania każdego podkatalogu w odpowiednim katalogu partycji vendor, jeśli są spełnione te warunki:

  • /vendor/<overlay_dir> istnieje.
  • /product/vendor_overlay/<target_vendor_version>/<overlay_dir> ma ten sam kontekst pliku co /vendor/<overlay_dir>.
  • init może podłączać do kontekstu pliku /vendor/<overlay_dir>

Wdróż nakładkę dostawcy

Zainstaluj pliki z nakładkami dostawców w: /product/vendor_overlay/<target_vendor_version> Te pliki nakładać partycję vendor po włączeniu urządzenia, zastępując pliki o tej samej nazwie i dodawać nowe pliki. Nie można usunąć plików w nakładce dostawcy z partycji vendor.

Pliki nakładek dostawców muszą mieć ten sam kontekst co pliki docelowe są zastępowane na partycji vendor. Domyślnie pliki w folderze Katalog /product/vendor_overlay/<target_vendor_version> mają kontekst vendor_file. Niezgodność kontekstu pliku między plikami nakładek dostawców a zastępowanymi plikami, określ to w dla konkretnego urządzenia. Kontekst pliku jest ustawiany na poziomie katalogu. Jeśli kontekstu pliku katalogu nakładek dostawcy nie pasuje do katalogu docelowego, a w ustawieniach konkretnego urządzenia nie zostanie określony prawidłowy kontekst pliku, że katalog nakładek dostawcy nie jest nałożony na katalog docelowy.

Aby można było używać nakładki dostawcy, jądro musi włączyć OverlayFS przez ustawienie CONFIG_OVERLAY_FS=y Jądro musi być też scalone z typowe jądro w wersji 4.4 lub nowszej albo zainstalowane poprawki z "overlayfs: override_creds=off option bypass creator_cred".

Przykład implementacji nakładki dostawcy

Ta procedura przedstawia wdrożenie nakładki dostawcy, która nakłada katalogi /vendor/lib/*, /vendor/etc/* i /vendor/app/*

  1. Dodaj gotowe pliki dostawcy do device/<vendor>/<target>/vendor_overlay/<target_vendor_version>/:

    device/google/device/vendor_overlay/28/lib/libfoo.so
device/google/device/vendor_overlay/28/lib/libbar.so
device/google/device/vendor_overlay/28/etc/baz.xml
device/google/device/vendor_overlay/28/app/qux.apk

  2. Zainstaluj gotowe pliki dostawcy w product/vendor_overlay in device/google/device/device.mk:

    PRODUCT_COPY_FILES += \
    $(call find-copy-subdir-files,*,device/google/device/vendor_overlay,$(TARGET_COPY_OUT_PRODUCT)/vendor_overlay)

  3. Określ kontekst plików, jeśli docelowe pliki partycji vendor mają konteksty inne niż vendor_file. Ponieważ /vendor/lib/* używa kontekstu vendor_file, ten nie zawiera tego katalogu.

    Dodaj następujące elementy do device/google/device-sepolicy/private/file_contexts:

    /(product|system/product)/vendor_overlay/[0-9]+/etc(/.*)?   u:object_r:vendor_configs_file:s0
/(product|system/product)/vendor_overlay/[0-9]+/app(/.*)?   u:object_r:vendor_app_file:s0

  4. Zezwalaj procesowi init na podłączanie nakładki dostawcy w pliku kontekstów innych niż vendor_file. Ponieważ init proces ma już uprawnienia do podłączania w kontekście vendor_file, ten przykład nie definiuje zasady dla vendor_file.

    Dodaj następujące elementy do device/google/device-sepolicy/public/init.te:

    allow init vendor_configs_file:dir mounton;
allow init vendor_app_file:dir mounton;

Nakładka z prośbą o sprawdzenie dostawcy

Aby sprawdzić konfigurację nakładki dostawcy, dodaj pliki w /product/vendor_overlay/<target_vendor_version>/<overlay_dir> i sprawdź, czy pliki w folderze /vendor/<overlay_dir>

W przypadku kompilacji userdebug dostępny jest moduł testowy dotyczący testu Atest:

$ atest -v fs_mgr_vendor_overlay_test

Aktualizacja do wersji systemowej jako roota

Aby zaktualizować urządzenia inne niż A/B tak, aby używały systemu operacyjnego jako root, musisz zaktualizować schemat partycjonowania dla boot.img i system.img, ustawiony up dm-verity i usuń wszelkie zależności rozruchu na poziomie głównym urządzenia. foldery.

Zaktualizuj partycje

W odróżnieniu od urządzeń A/B, w których /boot jako partycji recovery. Urządzenia inne niż A/B muszą utrzymywać partycję /recovery oddzielnie, ponieważ nie mają zastępczej partycji przedziału (na przykład od boot_a do boot_b). Jeśli /recovery to usunięte na urządzeniach innych niż A/B i podobne do schematu A/B: tryb przywracania może ulec awarii podczas nieudanej aktualizacji partycji /boot. Dla: z tego powodu partycja /recovery musi być typu oddzielne partycjonowanie od /boot dla urządzeń innych niż A/B, co oznacza, obraz przywracania jest nadal aktualizowany z odroczeniem tak samo jak na urządzeniach z Androidem 8.1.0 lub starszym).

W tabeli poniżej znajdziesz różnice w partycjach obrazów w przypadku urządzeń innych niż A/B przed i po Androidzie 9.

Obraz Ramdisk (przed 9) System jako root (po 9)
boot.img Zawiera jądro i ramdisk.img: 
ramdisk.img
  -/
    - init.rc
    - init
    - etc -> /system/etc
    - system/ (mount point)
    - vendor/ (mount point)
    - odm/ (mount point)
    ...
 Zawiera tylko normalne jądro rozruchowe.
recovery.img Zawiera jądro i plik przywracania ramdisk.img
system.img Zawiera: 
system.img
  -/
    - bin/
    - etc
    - vendor -> /vendor
    - ...
 Zawiera scaloną treść oryginalnych plików system.img i ramdisk.img: 
system.img
  -/
    - init.rc
    - init
    - etc -> /system/etc
    - system/
      - bin/
      - etc/
      - vendor -> /vendor
      - ...
    - vendor/ (mount point)
    - odm/ (mount point)
    ...

Same partycje się nie zmieniają. używanie zarówno dysku RAM, jak i systemu jako roota następujący schemat partycjonowania:

  • /boot
  • /system
  • /system
  • /recovery
  • /vendor itp.

Skonfigurujdm-verity

W systemie operacyjnym jako root jądro musi zamontować system.img w / (punkt podłączania) z dm-verity. AOSP obsługuje następujące zasoby dm-verity implementacji na koncie system.img.

Vboot 1.0

W przypadku vboot 1.0 jądro musi być analizowane Tylko na Androida metadane włączone /system, a następnie przekonwertuj na parametry dm-verity do skonfigurowania dm-verity (wymaga poprawki jądra). Poniższy przykład pokazuje ustawienia dotyczące wersji Dm-verity dla systemu operacyjnego jako roota wiersz poleceń jądra: 

ro root=/dev/dm-0 rootwait skip_initramfs init=/init
dm="system none ro,0 1 android-verity /dev/sda34"
veritykeyid=id:7e4333f9bba00adfe0ede979e28ed1920492b40f

Vboot 2.0

Dla vboot 2.0 (AVB), program rozruchowy musi się zintegrować external/avb/libavb, który następnie analizuje deskryptor hashtree dla: /system, konwertuje go do parametrów dm-verity, a na koniec przekazuje je do funkcji z jądra systemu operacyjnego. (Deskryptory hashtagu /system może znajdować się w /vbmeta lub w samym /system).

vboot 2.0 wymaga tych poprawek jądra:

.

Poniższy przykład pokazuje ustawienia dotyczące wersji Dm-verity dla systemu operacyjnego jako roota wiersz poleceń jądra: 

ro root=/dev/dm-0 rootwait  skip_initramfs init=/init

dm="1 vroot none ro 1,0 5159992 verity 1
PARTUUID=00000016-0000-0000-0000-000000000000
PARTUUID=00000016-0000-0000-0000-000000000000 4096 4096 644999 644999
sha1 d80b4a8be3b58a8ab86fad1b498640892d4843a2
8d08feed2f55c418fb63447fec0d32b1b107e42c 10 restart_on_corruption
ignore_zero_blocks use_fec_from_device
PARTUUID=00000016-0000-0000-0000-000000000000 fec_roots 2 fec_blocks
650080 fec_start 650080"

Użyj folderów głównych na danym urządzeniu

Z systemem jako root, po ogólnym obrazie systemu (GSI) jest migana na urządzeniu (i przed uruchomieniem). testy Vendor Test Suite), dowolne foldery główne na poszczególnych urządzeniach za pomocą funkcji BOARD_ROOT_EXTRA_FOLDERS zostały usunięte, ponieważ cała zawartość katalogu głównego została zastąpiona do systemu GSI systemu jako poziomego głównego. Usunięcie tych folderów może spowodować, że urządzenie nie można uruchomić rozruchu, jeśli istnieje zależność od folderów głównych na danym urządzeniu (służą na przykład jako punkty podłączania).

Aby uniknąć tego problemu, nie używaj BOARD_ROOT_EXTRA_FOLDERS do: dodawania folderów głównych przeznaczonych na konkretne urządzenia. Jeśli musisz określić punkt montowania na poziomie urządzenia punktów, użyj funkcji /mnt/vendor/<mount point> (dodanej w tych list zmian). Takie punkty podłączania specyficzne dla dostawcy mogą być określona bezpośrednio w drzewie urządzeń fstab (na potrzeby pierwszego etapu) mount) i /vendor/etc/fstab.{ro.hardware} bez dodatkowa konfiguracja (ponieważ fs_mgr tworzy je w /mnt/vendor/*).