Wdróż bibliotekę pakietu SDK Java

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 i stubs.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żyj m update-api. Aby sprawdzić, czy interfejs API jest aktualny, użyj funkcji m 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 wersje prebuilts/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 nazwie module_name.txt w katalogu version/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:

  1. Dwie kopie biblioteki implementacji: jedną o nazwie X i druga o nazwie X.impl. Biblioteka X jest zainstalowana na urządzeniu. Biblioteka X.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.
  2. 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ów java_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 i stub_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.

Tworzenie przepływu z biblioteką pakietu SDK Java
Rysunek 1. Tworzenie przepływu z biblioteką pakietu Java SDK
.

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_dirsmerge_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 aplikacji droiddoc_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 nazwie module_name.txt i module_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