aboutsummaryrefslogtreecommitdiff
path: root/java/sdk_library_test.go
Commit message (Collapse)AuthorAgeFilesLines
* Mechanism to select a specific version of java_sdk_library_importSpandan Das2024-02-061-0/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL is the java_sdk_library_import equivalent of aosp/2928483. With trunk stable, we will have multiple apex prebuilts in the tree. Each apex prebuilt will have its own module sdk. This means that it is possible to have mutliple versions of `framework-foo` in the tree. This CL introduces a mechanism to select a specific versioned java_sdk_library prebuilt. Implementation details - Add a `source_module_name` property to java_sdk_library_import. This will identify the source equivalent of the jsl in packages/modules. This used to be implicit - i.e. the name without the prebuilt_ prefix. With multiple prebuilts, this has to become explicit. - Set appropriate `source_module_name`(s) in the dynamically created child modules. e.g. the source_module_name on sdklib.v1.stubs and sdklib.v2.stubs will both be sdklib.stubs, assuming `source_module_name` on the top-level jsl_import is sdklib - Add a private Created_by_java_sdk_library_name property to java_import and prebuilt_stubs_sources modules. This will be used to idenfity the top level java_sdk_library_import that was used to create these child modules. This is necessary because java_sdk_library_imoprt is a macro that creates 1:many modules. However, to avoid toil, only the top-level java_sdk_library_import will be listed in `apex_contributions`. This new property will be used for source/prebuilt selection in android/prebuuilt.go - Rename BaseModuleName in commonSdkLibraryAndImportModule to RootLibraryName. This is necesssary because the former is now reserved to identify the source equivalent of a prebuilt module (maybe we should rename it?) Bug: 322175508 Test: Added a unit test Change-Id: If6aa6b0e939a07f8263874941413908383c81a78
* Do not replace the direct edge between rdeps and java_sdk_librarySpandan Das2024-02-031-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | android/prebuilt.go#isSelected has a special-case inside it to ignore apex_contributions contents for the top-level java_sdk_library hook. This was necessary because even though we might want source stubs in next builds, we still needed the top-level prebuilt hook to be active to emit the dexpreopt rules to .mk. This worked fine for rdeps that create a dependency edge on the child stub modules of java_sdk_library. Notable examples include the full android api stubs created by f/b/api.go. In postdeps mutator, these expanded deps get rewritten to source/prebuilt if necesssry. The exception to this are workflows which depend on the top-level hook directly via `libs`. We resolve these rdeps to an appropriate provider during GenerateAndroidBuildActions stage. This meant that rdeps were getting prebuilt stubs of these even in next builds. Bug: 323454855 Test: Added a unit test Test: lunch cf_x86_64_only_phone-next-userdebug Test: aninja -t query out/soong/.intermediates/packages/modules/Permission/SafetyCenter/Config/safety-center-config/android_common/javac/safety-center-config.jar | grep prebilts/module_sdk # empty now Change-Id: Id91333d88055519f3c58ab40466f9628085f5180
* Enable hiddenapi check for exportable stubsJihoon Kang2024-01-121-0/+26
| | | | | | | | | | | | | | | | | | | | This change modifies the dependencies of the hiddenapi to always depend on the exportable stubs, instead of the currently utilized everything stubs. To support this, the full api surface exportable stubs are defined in a separate change at the `frameworks/base` project. Note that the full api surface exportable stubs are only used for the hiddenapi purpose, and `sdk_version` continues to utilize the currently existing everything stubs. Currently, this feature is hidden behind the build flag "RELEASE_HIDDEN_API_EXPORTABLE_STUBS". This feature will be fully enabled once metalava fully supports handling of the flagged apis. Test: ENABLE_HIDDENAPI_FLAGS=true m Bug: 317426356 Change-Id: I109b7cd27b20ceffcdf1766ab8106b0c276be2b3
* Generate "exportable" stubs library in java_sdk_libraryJihoon Kang2024-01-081-1/+54
| | | | | | | | | | | | | | | | | | | | Given that now the droidstubs module generates the "exportable" stubs, this change modifies java_sdk_library to generate the java_library modules that compiles the "exportable" stubs per api scope. The detailed naming scheme of the generated modules are available in the bug linked in the footer. Similar to the from-text java_api_library vs from-source java_library static lib selection for the "everything" stubs, the "exportable" stubs module can also toggle between the stubs java_api_library and the java_library module. However, given that the "exportable" stubs generation has not been implemented for from-text stubs, the module always default to depend on the from-source "exportable" stubs compiling java_library module. Test: go test ./java Bug: 315495926 Change-Id: I5798312c1338c55625b2030da728b056385171a4
* Use the correct prof file when multiple prebuilt apexes existSpandan Das2023-12-191-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Generating boot image requires a .prof file provided by the ART apex. When building with prebuilts, this comes via the prebuilt_bootclasspath_fragment module, which acts as a shim for prebuilt_apex/apex_set. If we have multiple prebuilt apexes in the tree, this shim becomes 1:many. This CL prepares dex_bootjars to select the right .prof file when multiple prebuilts exist. Implementation details - Update deps mutator of dex_bootjars to create a dep on all_apex_contributions. The latter contains information about which apex is selected in a specific release configuration. dex_bootjars will create a dependency on the selected apex in a postdeps phase mutator. - All apex module types (apex, prebuilt_apex and apex_set) will set a provider that contains info about the location of the .prof file on host - dex_bootjars will access the provider of the selected apex to get the location of the .prof file This CL does not drop the old mechanism to get the .prof file (i.e. by creating a dep on {prebuilt_}bootclasspath_fragment). Once all mainline modules have been flagged using apex_contributions, the old mechanism will be dropped Bug: 308790457 Test: Added a unit test that checks that the right .prof is selected when multiple prebuilts exists Change-Id: I40fdb21416c46bed32f6ff187ce5153711ec2c69
* Convert ModuleProvder to generic providers APIColin Cross2023-12-141-1/+1
| | | | | | | | | Convert all of the callers of ModuleProvider/ModuleHasProvider to use the type-safe android.SingletonModuleProvider API. Bug: 316410648 Test: builds Change-Id: I6f11638546b64749e451cebbf33140248dc1d193
* Add the ability for a java_sdk_library to depend on another.Jamie Garside2023-11-271-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This simply exports all of the uses_libs: [] libraries into a "dependency=''" statement in the generated XML file (with the <library> stanza in it). Test: `go test` in java/ Bug: 184396657 NOTE FOR REVIEWERS - original patch and result patch are not identical. PLEASE REVIEW CAREFULLY. Diffs between the patches: func formattedDependenciesAttribute(dependencies []string) string { > + if dependencies == nil { > + return "" > + } > + return fmt.Sprintf(` dependency=\"%s\"\n`, strings.Join(dependencies, ":")) > +} > + > + dependenciesAttr := formattedDependenciesAttribute(module.properties.Uses_libs_dependencies) > + dependenciesAttr, > --- java/sdk_library_test.go > +++ java/sdk_library_test.go > + > +func TestSdkLibraryDependency(t *testing.T) { > + result := android.GroupFixturePreparers( > + prepareForJavaTest, > + PrepareForTestWithJavaSdkLibraryFiles, > + FixtureWithPrebuiltApis(map[string][]string{ > + "30": {"bar", "foo"}, > + }), > + ).RunTestWithBp(t, > + ` > + java_sdk_library { > + name: "foo", > + srcs: ["a.java", "b.java"], > + api_packages: ["foo"], > + } > + > + java_sdk_library { > + name: "bar", > + srcs: ["c.java", "b.java"], > + libs: [ > + "foo", > + ], > + uses_libs: [ > + "foo", > + ], > + } > +`) > + > + barPermissions := result.ModuleForTests("bar.xml", "android_common").Rule("java_sdk_xml") > + > + android.AssertStringDoesContain(t, "bar.xml java_sdk_xml command", barPermissions.RuleParams.Command, `dependency=\"foo\"`) > +} Original patch: diff --git a/java/sdk_library.go b/java/sdk_library.go old mode 100644 new mode 100644 --- a/java/sdk_library.go +++ b/java/sdk_library.go @@ -1993,6 +1993,7 @@ Min_device_sdk *string Max_device_sdk *string Sdk_library_min_api_level *string + Uses_libs_dependencies []string }{ Name: proptools.StringPtr(module.xmlPermissionsModuleName()), Lib_name: proptools.StringPtr(module.BaseModuleName()), @@ -2002,6 +2003,7 @@ Min_device_sdk: module.commonSdkLibraryProperties.Min_device_sdk, Max_device_sdk: module.commonSdkLibraryProperties.Max_device_sdk, Sdk_library_min_api_level: &moduleMinApiLevelStr, + Uses_libs_dependencies: module.usesLibraryProperties.Uses_libs, } mctx.CreateModule(sdkLibraryXmlFactory, &props) @@ -2968,6 +2970,11 @@ // // This value comes from the ApiLevel of the MinSdkVersion property. Sdk_library_min_api_level *string + + // Uses-libs dependencies that the shared libra [[[Original patch trimmed due to size. Decoded string size: 3559. Decoded string SHA1: 67fbd040aa818732a686514c4556850c8c36dc8d.]]] Result patch: diff --git a/java/sdk_library.go b/java/sdk_library.go index fb27812..fbfe509 100644 --- a/java/sdk_library.go +++ b/java/sdk_library.go @@ -1993,6 +1993,7 @@ Min_device_sdk *string Max_device_sdk *string Sdk_library_min_api_level *string + Uses_libs_dependencies []string }{ Name: proptools.StringPtr(module.xmlPermissionsModuleName()), Lib_name: proptools.StringPtr(module.BaseModuleName()), @@ -2002,6 +2003,7 @@ Min_device_sdk: module.commonSdkLibraryProperties.Min_device_sdk, Max_device_sdk: module.commonSdkLibraryProperties.Max_device_sdk, Sdk_library_min_api_level: &moduleMinApiLevelStr, + Uses_libs_dependencies: module.usesLibraryProperties.Uses_libs, } mctx.CreateModule(sdkLibraryXmlFactory, &props) @@ -2968,6 +2970,11 @@ // // This value comes from the ApiLevel of the MinSdkVersion property. Sdk_library_min_api_level *string + + // Uses-libs dependencies that the shared library [[[Result patch trimmed due to size. Decoded string size: 3614. Decoded string SHA1: b5730ecbeeaad420439ddb67eaaa9150ede94585.]]] Change-Id: I73f69e2a4573e416492f68e083fe739f3f75b721
* Special-case java_sdk_library in source vs prebuilt selectionSpandan Das2023-11-081-0/+131
| | | | | | | | | | | | | | | | | | | | | | | If a java_sdk_library is listed in `contents`, then restrict the source vs prebuilt selection superseding to only the internal stub libraries. Defer the source vs prebuilt selection mechanism of the top-level library to the existing mechanisms for now. This is necessary because this top-level library acts as a hook for - hiddenapi: boot jars are deapxed from the prebuilt apex - dexpreopt: system server jars are deapexed from the prebuilt apex and installed via required If `next` uses `framework-foo` and `service-foo` as the top-level library instead of the prebuilt equivalents, then the bootjars installed in out/soong/dexpreopt_x86_64/apex_bootjars will come from source. And the *.odex files of the system server jars will come from source. Bug: 308174768 Test: Added a java_sdk_library unit test to assert that the new mechanism supersedes the `prefer` flag Change-Id: Ib43198a3b547c58b54f1f0966e95584215096d32
* SdkTestCore for non-updatable modulesMark White2023-10-231-0/+26
| | | | | | | | | | | | | Provides SdkTestCore/test_core_current sdk_version for non-updatable modules that have their test scope dependent on test apis from framework-minus-apex. Ignore-AOSP-First: Change in topic with internal-first projects Bug: 289776578 Test: m checkapi | go test ./java Merged-In: Iba3213e8c34ea75ac9dd8532a95ef62fb5455e6c Change-Id: Iba3213e8c34ea75ac9dd8532a95ef62fb5455e6c
* Create java_api_contribution_import from sdk_library_importJihoon Kang2023-09-181-0/+5
| | | | | | | | | | | | This change modifies sdk_library_import so that it directly creates java_api_contribution per api scope. The module creates api_contribution module for api scopes where the api file is specified. Test: m nothing && MODULE_BUILD_FROM_SOURCE=false m nothing --build-from-text-stub and inspect ninja dependency of java_api_library Bug: 300175323 Change-Id: I74be3b4f1efef7f7d1cb8bd7b6c893b9cef0f370
* Modify static lib stub library visiblityJihoon Kang2023-09-071-0/+29
| | | | | | | | | | | | | java_sdk_library generates stub java_library module which compiles the stub generated from either source or txt files, which is toggled based on the build configuration. The java_api_library/java_library module that compiles the stubs should not be directly accessible to the modules outside of the sdk_library module scope, thus modify their visibility as private. Test: m nothing Bug: 299373105 Change-Id: Ia4a08bf6e65c521814c82f54ea43cc8d367834e3
* Stop sdk_library generated api_library to depend on full surface api_libraryJihoon Kang2023-08-141-3/+3
| | | | | | | | | | | | | | | | | | | | Since full_api_surface_libs extract class files instead of srcjar file, full_api_surface_stub can be replace with android_*_stubs_current, instead of the api_library android_*_stubs_current.from-text. Functionally, the class files of the two modules are identical (in from-text stub build), but depending on the from-text java_api_library leads to missing dependency errors in partial branches (especially ART branches). To resolve this problem, make sdk_library generated api_library depend on the missing dependency handled android_*_stubs_current. Since android_module_lib_stubs_current.from-text does not have its from-source equivalent, this can remain as dependency as the module is moved to build/soong in aosp/2674196 Test: m (default to from-text stub build) Bug: 274805756 Change-Id: Ic8bbd25252e5f9f1dc7c059ce6b00a951188985d
* Extract class files from dep_api_srcs instead of java filesJihoon Kang2023-06-291-16/+16
| | | | | | | | | | | | | | | | | | | | | | Currently, stub java files are extracted from srcjar file provided from dep_api_srcs in java_api_library module generated in java_sdk_library per api scope. However, compiling the java files may lead to difference in the content of the generated class files even if the stub java files are equivalent, as javac may arbitrarily add overridden methods. Thus, create a stub jar file instead of creating a stub srcjar file and compiling it, in order to guarantee stub jar files content equivalence and thus enable hiddenapi during from-text stub build. Note that this change does not fully resolve differences between the full api surface csv and the per sdk_library csv. Instead, it removes the difference caused by methods arbitrarily added by javac. This change also renames dep_api_srcs to full_api_surface_stubs to be more intuitive. Test: rebase on top of aosp/2617274 and `m --build-from-text-stub` Bug: 275570206 Change-Id: I22b6d56624633681f5c3b000370b5782655c7b8d
* Dynamically link static libs for sdk_library created java_libraryJihoon Kang2023-06-151-2/+1
| | | | | | | | | | Rename java_library created inside sdk_library with the ".from-source" suffix, and set it as static lib of the top level java_library, which gets java_api_library instead as static lib during from-text stub build. Test: m nothing && m nothing --build-from-text-stub Bug: 286446015 Change-Id: I32e8ea264987e9f9df05e462292bd54e45074912
* Generate java_api_library from java_sdk_libraryJihoon Kang2023-05-191-0/+63
| | | | | | | | | | | | This change enables java_sdk_library to generate java_api_library modules per api surface, so that from-text stubs can be generated per api domain scope. This module is only created when `--build-from-text-stub` flag is passed during build. Test: enable disabled modules in java/core-libraries/TxtStubLibraries.bp then m art.module.public.api.stubs.from-text --build-from-text-stub Bug: 276957733 Change-Id: Ic1ead15b3d0bcb921ca8d31bcaeeb4cd9ee8715c Merged-In: Ic1ead15b3d0bcb921ca8d31bcaeeb4cd9ee8715c
* Call hook in java_sdk_library after droidstubs generationJihoon Kang2023-02-071-0/+1
| | | | | | | | | | | Currently, droidstubs module create java_api_contribution module, but when a java_sdk_library module dynamically creates a droidstubs module, java_api_contribution is not created as the hook inside droidstubs get lost. Therefore, call hook inside sdk_library after creating the droidstubs module. Test: m Change-Id: I68bf1d796f6f9a6f81011ae35e4991b6ed1421ea
* Propagate stub_only_libs to the invocation generating stub sourcesNikita Ioffe2022-11-211-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | In some cases the java_sdk_library needs to compile against hidden platform APIs, in order to do so it needs to add impl_only_libs dependency on the framework library, and set the sdk_version property to the "core_*" one (e.g. core_platform). However, if this java_sdk_library depends on the Android SDK in it's stable API surface, then the setup above will break the stubs srcs generation, as it uses the sdk_version of the java_sdk_library (e.g. core_platform), which doesn't have symbols from the Android SDK. This chage solves the problem by propagating the stub_only_libs to the invocation that generates the stub sources. It allows the java_sdk_libraries to add a stub_only_libs dependency on the android_module_lib_stubs_current stubs library to fix their stubs build. For more context see another change in this topic: https://android-review.git.corp.google.com/c/platform/packages/modules/Virtualization/+/2310569 Bug: 243512044 Test: builds Test: m nothing Change-Id: Id745cfb2789901672561050c1c3f8bb163922379
* Allow sdk_version: "system_server_current" modules to access module-lib APIsPaul Duffin2022-10-051-0/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, a java module with sdk_version: "system_server_current", would only be able to access the system server or public API of a java_sdk_library. This change allows it to access the system server, module lib, system and public APIs in that order. The apiScope structs define the characteristics of each of the different API scopes used as required by the java_sdk_library. They are organized into a hierarchy which is used for two different purposes. The first purpose is to define an extension hierachy. If scope X extends Y then X provides a superset of all API elements (classes, fields, methods, etc) provided by Y. That is reflected in the fact that the .txt file for X would be a delta on the .txt file for Y. So, system extends public and so system_current.txt only contains additional API elements to add to current.txt. The second purpose is when a java_sdk_library/import is asked to provide a specific API scope. e.g. a library that has: sdk_version: "module_current" will ask each of the SDK libraries it depends upon for a module-lib API. However, not all of them will provide an API for that scope. In that case it will find the closest suitable API scope. Previously, it did that by traversing up the API extension until it found an API scope that it did provide and return that. As system_server_current extended the public API that meant that a library which has: sdk_version: "system_server_current" would provide a system server API if available, and if not fall straight back to public. That meant that the library could not access system or module-lib APIs even though it is running in the system server which should be able to access all APIs. One way to fix this would have been to just have system server API scope extend module-lib but that would have had a number of nasty side effects: * It would have created a significant overhead as every module that provides a system server API would also have to provide a module-lib and system API, along with their corresponding .txt files. * Each existing java_sdk_library that provided a system server API would need those .txt files created. * Generating sdk snapshots for older releases would have been more complicated. * It would have confused developers. All of that would be unnecessary because the system server API scope is intended to be provided by libraries that are used solely by the system server so there is no point in them providing anything other than a system server API. So, instead a separate access hierarchy was added which is the same as the extension hierarchy for all existing scopes except for the system server scope, which instead of just being able to access the public API will be able to access the module-lib scope, which can in turn access system and it can in turn access public. That achieves what we want which is a library that is loaded into the system server to be able to access all API scopes. Bug: 204176972 Test: m nothing Change-Id: I854df63fcaeba32afbc1eb0d1a501238022673d0
* java_sdk_library_import: Copy all prebuilt properties to child modulesPaul Duffin2022-09-281-2/+68
| | | | | | | | | | | | | | | | | | | | | | | | Previously, only the prefer property was copied from the java_sdk_library_import module to its child modules which meant that if the use_source_config_var property was used to control the prefer property that the child modules would never be used. That can cause build breakages when building against prebuilts as some parts of the build will use prebuilt files from java_sdk_library_import and some will use source files from the corresponding java_sdk_library. This change copies the use_source_config_var property too. It also adds tests to verify that dependencies on child modules of a java_sdk_library use the prebuilt child modules of the corresponding java_sdk_library_import. That revealed a bug with the handling of stub sources where the prefer property was set after creating the module which has also been fixed. Bug: 249192297 Test: m nothing # Cherry pick into branch broken by previous behavior and make # sure that it fixes it. Change-Id: I5719c257f8457bcb2238bc7965215512a20f1095
* Add custom java_sdk_library info to the SDK info filePaul Duffin2022-05-161-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously the SDK info file only contained basic common information about each member. This change adds support for each member to provide custom information to add to the info file. It uses that mechanism to add the following: * "dist_stem" * "scopes" object containing: * for each scope a: "<scope>" object containing: * "current_api" - the path within the snapshot for the API's .txt file. * "removed_api" - the path within the snapshot for the removed API's .txt file. * "latest_api" - the path within the build to the latest finalized API .txt file. * "latest_removed_api" - the path within the build to the latest finalized removed API .txt file. In order to access the latest API files it was necessary to add and resolve dependencies on the module that makes them available. In order to do that safely the code for creating the names of the modules was refactored to avoid duplicating the name creation logic. Bug: 204763318 Test: m nothing Change-Id: Ica68abbd2b2c7c2b2b7877b502f96cc89f06fd68
* Pass shared library updatability attributes as stringsPedro Loureiro2022-02-111-8/+9
| | | | | | | | | | | | Migrate from ints to Strings so we can pass codenames. Otherwise we can't use these attributes representing a release in progress until that release is finalized. I.e. if release T is in progress, we don't get the correct behaviour if we use "T" in those attributes Bug: 191978330 Test: m nothing Change-Id: I35389da0a01549ba2f820f5e5b78f6ea88c2aea1
* Add new property "exclude_files_in_output" for excluding files from the ↵Wei Li2022-01-111-0/+9
| | | | | | | | output files of Java related modules. Bug: 204888276 Test: m service-permission Change-Id: I9f6113834826358b0e3af22ed1dd63a43c255452
* Rename updatable-library to apex-libraryPedro Loureiro2022-01-061-1/+1
| | | | | | | | | Mostly for consistency with the names used in related changes. Test: m nothing Bug: 191978330 Change-Id: I34637986ead1c671bcc649891aceb3fe0f44b52a
* Perform CheckMinSdkVersion for java_sdk_library.satayev2021-12-081-0/+84
| | | | | | | | | | | | | In a follow up, apex would expect that any module that implements ModuleWithMinSdkVersionCheck to have performed appropate checks on min_sdk_version, to allow relaxing some of the existing conditions. This change moves the responsibility of checking min_sdk_version of java_sdk_library to java_sdk_library itself. Bug: 205923322 Test: presubmit Change-Id: I79b5a1fc34098fff60221e416db6e6e69e01f531
* Fix attribute names in generated permissions.xmlPedro Loureiro2021-11-241-8/+8
| | | | | | | | | | | | | | | Previously it would write min_device_sdk whereas the correct name should be min-device-sdk. This happened for all shared libs attributes. Test: m nothing Test: manually installed an apex with a shared lib and made sure PM used the attributes as expected Bug: 191978330 Change-Id: Iecf7edd6bae98c7af908d3f320f10ae4973d0396 Merged-In: Iecf7edd6bae98c7af908d3f320f10ae4973d0396 (cherry picked from commit bde653e5fdde3c2136b524e2afbd42bfa008dd2f)
* Perform validation of shared library attributesPedro Loureiro2021-11-241-13/+124
| | | | | | | | | | | | | | | | | | | | | Perform consistency checks as per http://go/updatable-shared-libraries These include: * no attribute can specified can be less than T * max-device-sdk can't be less than min-device-sdk * min and max-device-sdk need to be at least the module's min_sdk_version * using on-bootclasspath-before implies that the module's min_sdk_version is at least T or the library has min-device-sdk of at least T Test: m nothing Bug: 191978330 Change-Id: Iaca5cf23fb0bc7e65effb3529c8e829560894c2e Merged-In: Iaca5cf23fb0bc7e65effb3529c8e829560894c2e (cherry picked from commit f9e584dd20068334f7ab44c8a989fc1b177e3886)
* Add support for new permissions library tag attributesPedro Loureiro2021-11-241-1/+70
| | | | | | | | | | | | | We are expanding PackageManager's supported attributes and this change enables the developer to define them in the .bp file. Test: m nothing Bug: 191978330 Change-Id: I01d579190fb585662086a7fc456f3b33cb89fb57 Merged-In: I01d579190fb585662086a7fc456f3b33cb89fb57 (cherry picked from commit 826863c8e0844b2172fde38ccdcc0d83aa2ae7e5)
* Add annotations.zip support to java_sdk_libraryAnton Hansson2021-09-221-1/+29
| | | | | | | | | | | | | | | The annotations zip file is produced by the "main" sdk build and is primarily consumed by android studio. In order to support building the main SDK without requiring the sources of all modules, we are adding module SDK artifacts that allows reconstructing these outputs. The annotations zip contains XML files which should be fairly easy to merge from all the individual parts. Bug: 187397779 Test: unit tests in this CL Test: m sdkextensions-sdk and inspect output Change-Id: I955cae720e6f1382936836ee1d8fb11003f51b7d
* Preopt APEX system server jars from prebuilts.Jiakai Zhang2021-09-151-1/+2
| | | | | | | | | Similar to the previous CL, but for jars from prebuilts. Test: manual - 1. Patch aosp/1818020 and aosp/1810840. 2. m SOONG_CONFIG_art_module_source_build=false com.android.art Bug: 194150908 Change-Id: Idc0c73a78045a602ad3a91cb5071d291bd611015
* Propagate <uses-library> dependencies from `java_library` to apps.Ulya Trafimovich2021-08-181-1/+1
| | | | | | | | | | | | | | | | | Automatically add `uses_libs`/`optional_uses_libs` properties specified in `java_library` modules to the apps that transitively depend on these libraries. Note that a library may choose to specify its <uses-library> deps as either optional or required. If this is not the right choice for an app, it should be able to override it by specifying its own `uses_libs`/ `optional_uses_libs` properties. Add Soong tests to cover the new cases. Bug: 196377222 Test: lunch aosp_cf_x86_64_phone-userdebug && m Change-Id: I601f3e2830ed9699b78d911966ee70812d32b4f6
* Fix the way manifest fixer detects optional <uses-library> entries.Ulya Trafimovich2021-08-131-2/+3
| | | | | | | | | | | | | | | | | | | Previously manifest_fixer used a naive way to distiniguish optional libs from required ones: it checked if a library is on the list of optional compatibility libraries. This works for compatibility libs, but not for other libs. Now we properly track optionality through all stages of the build, starting with the addition of the library as a dependency (here's where the `uses_libs`/`optional_uses_libs` distinction kicks in), store it in dependency tag and propagate to class loader context, and from there to the manifest_fixer. The tests have been updated accordingly. Bug: 196377222 Test: lunch bertha_x86_64-userdebug && m droid dist cts mts Change-Id: I3631ce59ebe47116ce7a9b3d33a86f636846ef0f
* Add sdk_library_test.go to Android.bp filePaul Duffin2021-06-271-1/+1
| | | | | | | | | | | | When this file was initially created by extracting the test from the java_test.go file it was not added to Android.bp file so was not being built and tested as it should. That lead to a recent change that left it unable to compile. This change corrects both those issues. Bug: 186723288 Bug: 179354495 Test: m nothing Change-Id: I06f32bb572f57b6df3c772f1d9d21fe323fbf353
* Remove duplicate component from sdk snapshotPaul Duffin2021-06-231-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, an sdk snapshot could contain the following: * A java_sdk_library_import module, e.g. "foo" which creates component modules "foo.stubs", etc. * A corresponding versioned module, e.g. "sdk_foo@current" which created component modules "sdk_foo@current.stubs", etc. * An internal (to the sdk snapshot) java_import for one of "foo"'s components, e.g. "sdk_foo.stubs" * A corresponding versioned module, e.g. "sdk_foo.stubs@current". That causes a few problems: 1. The "foo.stubs" is duplicated. 2. The names of the components created by the versioned java_sdk_library_import are invalid, as they append the component's suffix to the version and not the name before the version. The latter causes problems when building against prebuilts and fixing that causes the generated snapshot to be invalid because it contains duplicate definitions of the "sdk_foo.stubs@current" module. One explicitly in the Android.bp file and one created by the "sdk_foo@current" module. Removing the duplicates from the snapshot causes errors as the name generated by the snapshot for the component module, i.e. "sdk_foo.stubs@current" does not match the name generated by the "sdk_foo@current", i.e. "sdk_foo@current.stubs". This change fixes them together. Bug: 179354495 Test: m nothing Merged-In: I515f235fe21755b5275af12366e96c24c94c0273 Change-Id: I515f235fe21755b5275af12366e96c24c94c0273 (cherry picked from commit a1aa7387f74a49c8c974ba2198def0e081488624)
* Don't use unsafe_ignore_missing_latest_api in TestJavaSdkLibraryDistColin Cross2021-06-021-4/+5
| | | | | | | | | Use FixtureWithLastReleaseApis to create the necessary files instead of disabling the check with unsafe_ignore_missing_latest_api. Bug: 186723288 Test: TestJavaSdkLibraryDist Change-Id: I162b0f68eec596274f8d98dca9d3f0500ab13f5d
* Remove core_lib property from java_sdk_libraryColin Cross2021-06-021-12/+0
| | | | | | | | Its not used, remove it. Bug: 186723288 Test: TestJavaSdkLibraryDist Change-Id: I1689b670a8ae6a614e5e4ec5e79cb5e283b2e277
* Ignore owner property when computing java_sdk_library dist subdirectoryColin Cross2021-06-021-4/+5
| | | | | | | | | The owner property is no longer used, the dist subdirectory is determined by the dist_group property. Bug: 186723288 Test: TestJavaSdkLibraryDist Change-Id: Id6d997eef05f6511070677974219674f248cb754
* Make the default java_sdk_library dist_group "unknown"Colin Cross2021-06-021-2/+2
| | | | | | | | | | Change the default dist_group from "android" to "unknown" to prevent accidentally including java_sdk_library stubs that do not set dist_group or owner in the public SDK. Bug: 186723288 Test: TestJavaSdkLibraryDist Change-Id: I9aae2a16254ac1a8d444acfa63bc571d1ef4b045
* Support dist_group property instead of owner for setting sdk dist subdirectoryColin Cross2021-06-011-0/+12
| | | | | | | | | | Reusing the owner property is confusing, especially when the property is required on every java_sdk_library module. Create a new dist_group property to use instead. Bug: 186723288 Test: TestJavaSdkLibraryDist Change-Id: I9e62c703a95d6b63cafa60bffb1b37ba85388593
* Add test for java_sdk_library dist propertiesColin Cross2021-06-011-0/+79
| | | | | | | | Add tests that cover the owner, core_lib and dist_stem properties. Bug: 186723288 Test: TestJavaSdkLibraryDist Change-Id: I4c2ae2a23dcd9a668c46ed5cc23b1d7dcfae798a
* Move java_sdk_library tests to sdk_library_test.goColin Cross2021-06-011-0/+840
Seperate the java_sdk_library tests into their own file. Bug: 186723288 Test: go test ./java/... Change-Id: I899c2946cb2234dc595a4281e64bbb239b89bda8
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-20 03:34:17 +0000