Dostawca – APEX

Za pomocą formatu pliku APEX możesz spakować instalowanie modułów systemu operacyjnego Android niższego poziomu. Pozwala na niezależne tworzenie instalacja komponentów takich jak usługi i biblioteki natywne, HAL wdrożenia, oprogramowanie układowe, pliki konfiguracyjne itp.

Punkty APEX dostawcy są automatycznie instalowane przez system kompilacji w /vendor partycjonowania i aktywowane w czasie działania przez apexd, tak jak w innych partycji.

Przykłady zastosowań

Modularyzacja obrazów dostawców

Punkty APEX ułatwiają naturalne grupowanie i modularyzację cech implementacji na obrazach dostawców.

Gdy obrazy dostawców są tworzone jako połączenie niezależnego dostawcy firmy APEX, czyli producenci urządzeń, mogą łatwo wybrać konkretne na urządzeniach różnych dostawców. Producenci mogą nawet stworzyć wskaźnik APEX nowego dostawcy, jeśli żaden z nich nie odpowiada jego potrzebom lub Zupełnie nowy, niestandardowy sprzęt.

Na przykład producent OEM może zdecydować się na połączenie urządzenia z siecią Wi-Fi AOSP. implementacji APEX, wdrożenia bluetooth SoC i niestandardową wersję OEM APEX po wdrożeniu usług telefonicznych.

Bez APEX dostawcy, implementacja oferująca tak wiele zależności wymaga dokładnej koordynacji i śledzenia. Dodając wszystkie komponentów (w tym plików konfiguracji i dodatkowych bibliotek) w APEX z w jasny sposób zdefiniowane interfejsy w każdym punkcie komunikacji między funkcjami, że różne komponenty stają się wymienne.

Iteracja programisty

APEX dostawców pomaga deweloperom w szybszej iteracji oraz opracowywanie modułów dostawców przez łączenie całej implementacji funkcji, np. interfejsu Wi-Fi HAL, w ramach jednego dostawcy. APEX. Deweloperzy mogą następnie kompilować i indywidualnie przekazać APEX dostawcy do testów. zmian, zamiast tworzyć cały obraz dostawcy.

Ułatwia to i przyspiesza cykl iteracji u deweloperów, którzy Pracują głównie w ramach jednego obszaru cech i chcesz wykorzystać tę cechę w pobliżu.

Naturalne grupowanie obszarów cech w APEX również upraszcza proces. tworzenia, przekazywania i testowania zmian w danym obszarze cech. Przykład: ponowna instalacja pakietu APEX automatycznie aktualizuje wszystkie pakiety biblioteki lub pliki konfiguracyjne uwzględnia m.in. raport APEX.

Dołączenie obszaru cech do punktu APEX upraszcza też debugowanie lub przywracanie, gdy zaobserwowane nieprawidłowe działanie urządzenia. Jeśli na przykład telefon nie działa słabo w nowej wersji, programiści mogą spróbować zainstalować starsze wdrożenia APEX na urządzeniu (bez konieczności aktualizowania pełnej kompilacji). czy wróci do normalnego działania.

Przykładowy przepływ pracy:

# Build the entire device and flash. OR, obtain an already-flashed device.
source build/envsetup.sh && lunch oem_device-userdebug
m
fastboot flashall -w

# Test the device.
... testing ...

# Check previous behavior using a vendor APEX from one week ago, downloaded from
# your continuous integration build.
... download command ...
adb install <path to downloaded APEX>
adb reboot
... testing ...

# Edit and rebuild just the APEX to change and test behavior.
... edit APEX source contents ...
m <apex module name>
adb install out/<path to built APEX>
adb reboot
... testing ...

Przykłady

Podstawy

Zobacz główną stronę Format pliku APEX, aby uzyskać informacje o ogólnym formacie APEX. informacje, w tym wymagania dotyczące urządzeń, szczegóły formatów plików kroków instalacji.

W systemie Android.bp ustawienie właściwości vendor: true sprawia, że moduł APEX APEX dostawcy.

apex {
  ..
  vendor: true,
  ..
}

Pliki binarne i biblioteki udostępnione

APEX zawiera zależności pośrednie wewnątrz ładunku APEX, chyba że mieć stabilne interfejsy.

Stabilne interfejsy natywne dla zależności APEX dostawcy obejmują cc_library z stubs, ndk_library lub llndk_library. Te zależności są wykluczone z i zależności są rejestrowane w pliku manifestu APEX. Plik manifestu to przetworzono przez funkcję linkerconfig, tak aby zewnętrzne zależności natywne były dostępne w czasie działania.

W przeciwieństwie do punktów dostępu APEX w partycji /system punkty APEX dostawcy są zwykle powiązane konkretnej wersji VNDK. Biblioteki VNDK gwarantują stabilność ABI w co pozwala nam traktować biblioteki VNDK jako stabilne i zmniejszyć rozmiar biblioteki docelowych odbiorców APEX, wykluczając je z wyników wyszukiwania za pomocą funkcji use_vndk_as_stable usłudze.

W poniższym fragmencie kodu APEX będzie zawierać zarówno plik binarny (my_service), jak i jego niestabilne zależności (liczba plików: *.so). Nie będzie zawierać bibliotek VNDK, nawet jeśli my_service korzysta z bibliotek VNDK takich jak libbase. Zamiast tego: środowisko wykonawcze my_service będzie używać biblioteki libbase z bibliotek VNDK udostępnionych przez systemu.

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  binaries: ["my_service"],
  ..
}

We fragmencie kodu poniżej interfejs APEX będzie zawierał zasoby udostępnione. my_standalone_libi wszystkich jego niestabilnych zależności (jak opisano powyżej).

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  native_shared_libs: ["my_standalone_lib"],
  ..
}

Implementacje HAL

Aby zdefiniować implementację HAL, udostępnij odpowiednie pliki binarne i biblioteki w APEX dostawcy, podobnie jak w następujących przykładach:

Aby w pełni uwzględnić implementację HAL, APEX powinien też określić odpowiednie fragmenty VINTF i skrypty init.

Fragmenty VINTF

Fragmenty VINTF mogą być wyświetlane z APEX dostawcy, gdy fragmenty znajdują się w etc/vintf procent APEX.

Aby umieścić fragmenty VINTF w APEX, użyj właściwości prebuilts.

apex {
  ..
  vendor: true,
  prebuilts: ["fragment.xml"],
  ..
}

prebuilt_etc {
  name: "fragment.xml",
  src: "fragment.xml",
  sub_dir: "vintf",
}

Skrypty inicjujące

Węzły APEX mogą zawierać skrypty init na 2 sposoby: (A) gotowy plik tekstowy w APEX lub (B) zwykły skrypt inicjujący w /vendor/etc. Możesz ustawić oba dla tego samego wskaźnika APEX.

Skrypt inicjujący w APEX:

prebuilt_etc {
  name: "myinit.rc",
  src: "myinit.rc"
}

apex {
  ..
  vendor: true,
  prebuilts: ["myinit.rc"],
  ..
}

Skrypty inicjowane w regionach APEX mogą mieć maksymalnie tyle definicji: service. Skrypty inicjujące w przypadku źródeł APEX dostawcy również mogą mieć dyrektywy on <property>.

Zachowaj ostrożność podczas korzystania z dyrektyw on. Skrypty inicjujące w regionach APEX są przeanalizowane i wykonane po aktywowaniu punktów APEX, niektóre zdarzenia lub właściwości Nie można użyć. Używaj apex.all.ready=true, by uruchamiać działania jak najszybciej.

Oprogramowanie układowe

Przykład:

Umieść oprogramowanie układowe w APEX dostawcy z typem modułu prebuilt_firmware takim jak co dalej.

prebuilt_firmware {
  name: "my.bin",
  src: "path_to_prebuilt_firmware",
  vendor: true,
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.bin"],  // installed inside APEX as /etc/firmware/my.bin
  ..
}

<apex name>/etc/firmware zawiera moduły prebuilt_firmware katalogu APEX. ueventd skanuje /apex/*/etc/firmware katalogi do modułów oprogramowania układowego.

Element file_contexts APEX powinien oznaczyć etykietami wszystkie wpisy ładunku oprogramowania układowego aby zapewnić, że ueventd będzie mieć do nich dostęp w czasie działania; zwykle wystarczy etykieta vendor_file. Na przykład:

(/.*)? u:object_r:vendor_file:s0

Moduły jądra

Umieść moduły jądra w APEX dostawcy jako gotowe moduły w podany niżej sposób.

prebuilt_etc {
  name: "my.ko",
  src: "my.ko",
  vendor: true,
  sub_dir: "modules"
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.ko"],  // installed inside APEX as /etc/modules/my.ko
  ..
}

Pozycja file_contexts punktu APEX powinna oznaczać etykietami wszystkie wpisy ładunku modułu jądra. bez obaw. Na przykład:

/etc/modules(/.*)? u:object_r:vendor_kernel_modules:s0

Moduły jądra muszą być zainstalowane jawnie. Ten przykładowy skrypt init na partycji dostawcy pokazuje instalację za pomocą insmod:

my_init.rc:

on early-boot
  insmod /apex/myapex/etc/modules/my.ko
  ..

Nakładki zasobów środowiska wykonawczego

Przykład:

Umieszczanie nakładek zasobów środowiska wykonawczego w APEX dostawcy za pomocą właściwości rros.

runtime_resource_overlay {
    name: "my_rro",
    soc_specific: true,
}


apex {
  ..
  vendor: true,
  rros: ["my_rro"],  // installed inside APEX as /overlay/my_rro.apk
  ..
}

Inne pliki konfiguracyjne

Punkty APEX dostawcy obsługują różne inne pliki konfiguracyjne, które zwykle można znaleźć u dostawcy. jako gotową partycję w APEX dostawcy i dodawane są kolejne.

Przykłady:

Dodatkowe funkcje programistyczne

Wybór APEX podczas uruchamiania

Przykład:

Deweloperzy mogą też zainstalować wiele wersji APEX dostawców, które korzystają z tej samej taką samą nazwę i klucz APEX, a następnie wybrać wersję, która ma być aktywowana podczas uruchamiania za pomocą trwałych sysprop. W niektórych przypadkach może to być wartość Prostsze niż zainstalowanie nowej kopii raportu APEX za pomocą adb install.

Przykładowe zastosowania:

  • Zainstaluj 3 wersje interfejsu APEX dostawcy Wi-Fi HAL: zespoły kontroli jakości mogą przeprowadzać konfigurację ręcznie lub automatyczne testowanie z jednej wersji, ponowne uruchomienie innej wersji, ponownie przeprowadzić testy, a następnie porównać ich ostateczne wyniki.
  • Zainstaluj 2 wersje HAL APEX dostawcy aparatu: obecna i eksperymentalne: użytkownicy mogą używać wersji eksperymentalnej bez pobranie i zainstalowanie dodatkowego pliku, aby można było łatwo przywrócić nowy plik.

Podczas uruchamiania apexd szuka sysprop w określonym formacie, aby i włącz właściwą wersję APEX.

Oczekiwane formaty klucza usługi to:

  • Konfiguracja rozruchowa
    • Służy do ustawiania wartości domyślnej w formacie BoardConfig.mk.
    • androidboot.vendor.apex.<apex name>
  • Trwały sysprop
    • Służy do zmiany wartości domyślnej ustawionej na urządzeniu, które zostało już uruchomione.
    • Zastępuje wartość rozruchową, jeśli jest dostępna.
    • persist.vendor.apex.<apex name>

Wartością właściwości powinna być nazwa pliku raportu APEX, Aktywowano.

// Default version.
apex {
  name: "com.oem.camera.hal.my_apex_default",
  vendor: true,
  ..
}

// Non-default version.
apex {
  name: "com.oem.camera.hal.my_apex_experimental",
  vendor: true,
  ..
}

Wersję domyślną należy też skonfigurować za pomocą konfiguracji rozruchowej w BoardConfig.mk:

# Example for APEX "com.oem.camera.hal" with the default above:
BOARD_BOOTCONFIG += \
    androidboot.vendor.apex.com.oem.camera.hal=com.oem.camera.hal.my_apex_default

Po uruchomieniu urządzenia zmień aktywną wersję, ustawiając wartość trwały sysprop:

$ adb root;
$ adb shell setprop \
    persist.vendor.apex.com.oem.camera.hal \
    com.oem.camera.hal.my_apex_experimental;
$ adb reboot;

Jeśli urządzenie umożliwia aktualizowanie konfiguracji rozruchowej po zaktualizowaniu systemu (np. za pomocą poleceń fastboot oem), zmiana właściwości Bootconfig dla konfiguracji wielu instalacji APEX zmienia też wersję aktywowaną przy rozruchu.

W przypadku wirtualnych urządzeń referencyjnych opartych na mątwie: możesz użyć polecenia --extra_bootconfig_args, aby ustawić właściwość startconfig bezpośrednio podczas uruchamiania. Na przykład:

launch_cvd --noresume \
  --extra_bootconfig_args "androidboot.vendor.apex.com.oem.camera.hal:=com.oem.camera.hal.my_apex_experimental";