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_lib
i 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:
- Pliki XML deklaracji funkcji
- Czujniki używają plików XML jako wbudowane czujniki w formacie HAL APEX.
- Wejściowe pliki konfiguracyjne
- Ekran dotykowy jest konfigurowany jako jest gotowy do użytku w kanale APEX dostawcy służący tylko do konfiguracji
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>
- Służy do ustawiania wartości domyślnej w formacie
- 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";