Platforma Androida zawiera dużą liczbę udostępnianych bibliotek Java
które można opcjonalnie uwzględnić w ścieżce aplikacji z atrybutem
<uses-library>
w manifeście aplikacji. Link do aplikacji
z tymi bibliotekami, więc traktuj je tak samo jak resztę Android API.
pod względem zgodności, weryfikacji interfejsów API i obsługi narzędzi. Pamiętaj jednak,
że większość bibliotek nie ma tych funkcji.
Typ modułu java_sdk_library
pomaga zarządzać bibliotekami
tego rodzaju. Producenci urządzeń mogą używać tego mechanizmu na własne potrzeby
udostępniane biblioteki Java, aby zachować zgodność wsteczną dla swoich interfejsów API.
Jeśli producenci urządzeń używają własnych wspólnych bibliotek Javy
<uses-library>
zamiast ścieżki klasy rozruchowej,
java_sdk_library
może sprawdzić, czy te biblioteki Java są
Stabilny interfejs API.
java_sdk_library
implementuje opcjonalne interfejsy API SDK, których może używać
aplikacji. Biblioteki zaimplementowane za pomocą usługi java_sdk_library
na Twoim
plik kompilacji (Android.bp
) wykonaj te operacje:
- Biblioteki z wyprzedzeniem zostaną wygenerowane tak, aby obejmowały
stubs
,stubs.system
istubs.test
. Te biblioteki skrócone są tworzone przez rozpoznawanie@hide
, Adnotacje@SystemApi
i@TestApi
. java_sdk_library
zarządza plikami specyfikacji interfejsu API (np.current.txt
) w podkatalogu API. Te pliki są sprawdzane pod kątem najnowszego kodu, aby zapewnić, że są one najbardziej w jego obecnych wersjach. Jeśli tak nie jest, pojawi się komunikat o błędzie: zawiera opis sposobu ich aktualizowania. Przejrzyj ręcznie wszystkie zmiany aktualizacji w aby upewnić się, że odpowiadają Twoim oczekiwaniom.
Aby zaktualizować wszystkie interfejsy API, użyjm update-api
. Aby sprawdzić, czy interfejs API jest aktualny, użyj funkcjim checkapi
.- Pliki specyfikacji interfejsu API są sprawdzane pod kątem najnowszych
opublikowanych wersji Androida, by zapewnić zgodność wsteczną interfejsu API.
we wcześniejszych wersjach. Udostępnione moduły
java_sdk_library
i w ramach AOSP umieszczaj wcześniejsze wersjeprebuilts/sdk/<latest number>
- Podczas sprawdzania plików specyfikacji interfejsu API możesz sprawdzić, jedną z tych 3 rzeczy:
- Poczekaj, aż weryfikacja będzie kontynuowana. Nic nie rób.
- Wyłącz sprawdzanie, dodając do
java_sdk_library
ten kod:
unsafe_ignore_missing_latest_api: true,
- Udostępnij puste interfejsy API dla nowych modułów
java_sdk_library
tworząc puste pliki tekstowe o nazwiemodule_name.txt
w kataloguversion/scope/api
. - Jeśli zainstalowana jest biblioteka implementacji środowiska wykonawczego, plik XML zostanie wygenerowana i zainstalowana.
Jak działa pakiet java_sdk_library
Element java_sdk_library
o nazwie X
tworzy te elementy:
- Dwie kopie biblioteki implementacji: jedną o nazwie
X
i druga o nazwieX.impl
. BibliotekaX
jest zainstalowana na urządzeniu. BibliotekaX.impl
jest dostępna tylko po bezpośrednim dostępie do biblioteka implementacji jest potrzebna innym modułom, na przykład i testowania. Pamiętaj, że bezpośredni dostęp jest rzadko wymagany. - Zakresy można włączać i wyłączać, aby dostosowywać dostęp. (Podobne do Java modyfikatory dostępu do słów kluczowych, zakres publiczny zapewnia szeroki zakres dostępu; w zakres testowy zawiera interfejsy API używane tylko do testowania). Dla każdego włączonego zakresu biblioteka tworzy te elementy:
- Moduł źródłowy wersji (
droidstubs
) – zużywa źródła implementacji i zwraca zestaw źródeł z kodem pośrednim w pliku specyfikacji interfejsu API. - Biblioteka namiastów (typu
java_library
) to skompilowaną wersję atrakcji. Biblioteki użyte do skompilowania tego pliku nie są takie same jak w przypadku zasobówjava_sdk_library
, co zapewnia, że szczegóły implementacji nie wyciekają do wersji API. - Jeśli potrzebujesz dodatkowych bibliotek do skompilowania wersji pośrednich, użyj
stub_only_libs
istub_only_static_libs
i dostarczanie ich.
Jeśli element java_sdk_library
nazywa się „X
” i jest
są powiązane z „X
”, zawsze odnoszą się do niego w ten sposób i nie modyfikują
. Kompilacja wybierze odpowiednią bibliotekę. Aby upewnić się, że masz
najodpowiedniejszą bibliotekę, sprawdź wersje, by zobaczyć, czy kompilacja
. Wprowadź niezbędne poprawki, korzystając z tych wskazówek:
- Sprawdź, czy masz odpowiednią bibliotekę, używając wiersza poleceń sprawdzając listę ich wersji w celu określenia zakresu:
- Zakres jest zbyt szeroki: biblioteka zależna wymaga określonego zakresu interfejsów API. Ale zauważysz w bibliotece interfejsy API, które wykraczają poza ten zakres, na przykład do zintegrowanych publicznych interfejsów API.
- Zakres jest zbyt wąski: biblioteka zależna nie ma dostępu do wszystkich do wymaganych bibliotek. Na przykład biblioteka zależnie od potrzeb musi używać system API, ale pobiera publiczny interfejs API. Zwykle skutkuje to wystąpił błąd kompilacji, ponieważ brakuje wymaganych interfejsów API.
- Aby naprawić bibliotekę, wykonaj tylko jedną z tych czynności:
- Zmień
sdk_version
, aby wybrać potrzebną wersję. LUB - Jednoznacznie wskaż odpowiednią bibliotekę, na przykład
<X>.stubs
lub<X>.stubs.system
.
Użycie pakietu java_sdk_library X
Używana jest biblioteka implementacji X
, gdy odwołuje się do niej
apex.java_libs
Jednak ze względu na ograniczenie funkcji Soong, gdy biblioteka
Komponent X
jest wskazywany przez inny moduł java_sdk_library
w tej samej bibliotece APEX, X.impl
bezpośrednio
należy użyć, a nie biblioteki X
.
Jeśli do elementu java_sdk_library
odwołuje się się z innego miejsca,
. Biblioteka wersji pośrednich jest wybierana zgodnie z
w ustawieniach właściwości sdk_version
tego modułu. Na przykład moduł, który
określa sdk_version: "current"
używa wersji publicznej, podczas gdy
który określa sdk_version: "system_current"
, używa funkcji
atrapy systemu. Jeśli nie można znaleźć dopasowania ścisłego,
. java_sdk_library
, który udostępnia tylko publiczny interfejs API,
udostępniać publiczne wersje wszystkim.
Przykłady i źródła
Właściwości srcs
i api_packages
muszą
w java_sdk_library
.
java_sdk_library { name: "com.android.future.usb.accessory", srcs: ["src/**/*.java"], api_packages: ["com.android.future.usb"], }
AOSP zaleca (ale nie jest to wymagane) nowe java_sdk_library
instancje wyraźnie włączają zakresy interfejsu API, których mają używać. Możesz też
(opcjonalnie) przenieś istniejące instancje java_sdk_library
do
wyraźnie włącz zakresy interfejsu API, których będą używać:
java_sdk_library { name: "lib", public: { enabled: true, }, system: { enabled: true, }, … }
Aby skonfigurować bibliotekę impl
używaną w czasie działania, użyj wszystkich
normalne właściwości java_library
, takie jak hostdex
,
compile_dex
i errorprone
.
java_sdk_library { name: "android.test.base", srcs: ["src/**/*.java"], errorprone: { javacflags: ["-Xep:DepAnn:ERROR"], }, hostdex: true, api_packages: [ "android.test", "android.test.suitebuilder.annotation", "com.android.internal.util", "junit.framework", ], compile_dex: true, }
Aby skonfigurować atrapy, użyj tych właściwości:
merge_annotations_dirs
imerge_inclusion_annotations_dirs
.api_srcs
: lista opcjonalnych plików źródłowych, które są częścią ale nie do biblioteki środowiska wykonawczego.stubs_only_libs
: lista bibliotek Java znajdujących się w classpath podczas tworzenia namiotów.hidden_api_packages
: lista nazw pakietów, które muszą być niewidoczny dla interfejsu API.droiddoc_options
: dodatkowy argument dla metalava.droiddoc_option_files
: zawiera listę plików, do których można się odwołać; z aplikacjidroiddoc_options
za pomocą funkcji$(location <label>)
, gdzie<file>
jest pozycją na liście.annotations_enabled
.
java_sdk_library
to java_library
, ale to nie jest
Moduł droidstubs
, więc nie obsługuje wszystkich funkcji droidstubs
usług. Poniższy przykład został wzięty z
kompilacja biblioteki android.test.mock
.
java_sdk_library { name: "android.test.mock", srcs: [":android-test-mock-sources"], api_srcs: [ // Note: The following aren’t APIs of this library. Only APIs under the // android.test.mock package are taken. These do provide private APIs // to which android.test.mock APIs reference. These classes are present // in source code form to access necessary comments that disappear when // the classes are compiled into a Jar library. ":framework-core-sources-for-test-mock", ":framework_native_aidl", ], libs: [ "framework", "framework-annotations-lib", "app-compat-annotations", "Unsupportedappusage", ], api_packages: [ "android.test.mock", ], permitted_packages: [ "android.test.mock", ], compile_dex: true, default_to_stubs: true, }
Zachowaj zgodność wsteczną
System kompilacji sprawdza, czy interfejsy API zostały przywrócone do poprzedniej wersji.
kompatybilnością, porównując najnowsze pliki interfejsu API z
plików interfejsu API w momencie kompilacji. java_sdk_library
wykonuje
aby sprawdzić zgodność, korzystając z informacji udostępnionych przez: prebuilt_apis
.
Wszystkie biblioteki skompilowane za pomocą java_sdk_library
muszą mieć pliki interfejsu API
w najnowszej wersji usługi api_dirs
w usłudze prebuilt_apis
.
Po opublikowaniu wersji interfejs API wyświetla listę plików i krótkich wersji
biblioteki można uzyskać za pomocą metody zdalnej za pomocą funkcji PRODUCT=sdk_phone_armv7-sdk
.
Właściwość api_dirs
to lista katalogów wersji interfejsu API
w aplikacji prebuilt_apis
. Katalogi wersji interfejsu API muszą być
znajduje się na poziomie katalogu Android.bp
.
prebuilt_apis { name: "foo", api_dirs: [ "1", "2", .... "30", "current", ], }
Skonfiguruj katalogi za pomocą atrybutu version/scope/api/
w katalogu z gotowymi komponentami. version
odpowiada poziomowi API, a scope
określa
czy katalog jest publiczny, systemowy czy testowy.
version/scope
zawiera biblioteki Java.version/scope/api
zawiera interfejs API Pliki:.txt
. Utwórz puste pliki tekstowe o nazwiemodule_name.txt
imodule_name-removed.txt
tutaj.├── 30 │ ├── public │ │ ├── api │ │ │ ├── android.test.mock-removed.txt │ │ │ └── android.test.mock.txt │ │ └── android.test.mock.jar │ ├── system │ │ ├── api │ │ │ ├── android.test.mock-removed.txt │ │ │ └── android.test.mock.txt │ │ └── android.test.mock.jar │ └── test │ ├── api │ │ ├── android.test.mock-removed.txt │ │ └── android.test.mock.txt │ └── android.test.mock.jar └── Android.bp