aboutsummaryrefslogtreecommitdiff
path: root/java/java.go
Commit message (Collapse)AuthorAgeFilesLines
...
* | Automatically set compile_dex:true and hostdex:true for APEX variantsJiyong Park2020-02-121-0/+10
|/ | | | | | | | ... unless they are turned off explicitly. Bug: 147221965 Test: m Change-Id: I6b91d6409d9cf06ad09467c53d5d51a9c693256e
* Add java_system_modules to sdk/module_exportsPaul Duffin2020-02-071-8/+10
| | | | | | | | | | | | | | | Adds an SdkMemberType implementation for java_system_modules. It specifies that java_system_modules can be used with sdk as well as module_exports, and also that the libs property should be included as transitive members in the sdk. It also adds support for treating appropriate tagged properties in the snapshot prebuilts module as references to sdk members so that they are correctly transformed when creating the versioned modules. Bug: 142940300 Test: m nothing Change-Id: Ic10b5a6d5b92b6018334fe876f06feaf79cc55e9
* apex_available tracks static dependenciesJiyong Park2020-02-061-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change fixes a bug that apex_available is not enforced for static dependencies. For example, a module with 'apex_available: ["//apex_available:platform"]' was able to be statically linked to any APEX. This was happening because the check was done on the modules that are actually installed to an APEX. Static dependencies of the modules were not counted as they are not installed to the APEX as files. Fixing this bug by doing the check by traversing the tree in the method checkApexAvailability. This change includes a few number of related changes: 1) DepIsInSameApex implementation for cc.Module was changed as well. Previuosly, it returned false only when the dependency is actually a stub variant of a lib. Now, it returns false when the dependency has one or more stub variants. To understand why, we need to recall that when there is a dependency to a lib having stubs, we actually create two dependencies: to the non-stub variant and to the stub variant during the DepsMutator phase. And later in the build action generation phase, we choose one of them depending on the context. Also recall that an APEX variant is created only when DepIsInSameApex returns true. Given these, with the previous implementatin of DepIsInSameApex, we did create apex variants of the non-stub variant of the dependency, while not creating the apex variant for the stub variant. This is not right; we needlessly created the apex variant. The extra apex variant has caused no harm so far, but since the apex_available check became more correct, it actually breaks the build. To fix the issue, we stop creating the APEX variant both for non-stub and stub variants. 2) platform variant is created regardless of the apex_available value. This is required for the case when a library X that provides stub is in an APEX A and is configured to be available only for A. In that case, libs in other APEX can't use the stub library since the stub library is mutated only for apex A. By creating the platform variant for the stub library, it can be used from outside as the default dependency variation is set to the platform variant when creating the APEX variations. 3) The ApexAvailableWhitelist is added with the dependencies that were revealed with this change. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
* sdk_version: "module_current" is supportedJiyong Park2020-01-311-1/+14
| | | | | | | | | | | module_* is a new API surface for OS modules (e.g. APEXes). It has slightly bigger API surface than the system_* SDK. Specifically, APIs with @SystemApi(client=MODULE_LIBRARIES) are added there. Bug: 146757305 Test: m Change-Id: I8980e50c0e3a4cd843048e0de1f638e854384f46
* Merge "Store uncompressed and aligned DEX files for java libs in APEXes."Ulyana Trafimovich2020-01-291-0/+5
|\
| * Store uncompressed and aligned DEX files for java libs in APEXes.Ulya Trafimovich2020-01-271-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Test: aosp_walleye-userdebug boots. Test: In internal, cherry-picked this CL, walleye-userdebug boots. Test: In internal, ensure that DEX file wifi-service.jar in the com.android.wifi APEX is now stored uncompressed: $ zipinfo out/target/product/walleye/apex/com.android.wifi/javalib/wifi-service.jar Archive: out/target/product/walleye/apex/com.android.wifi/javalib/wifi-service.jar Zip file size: 3086879 bytes, number of entries: 3 -rw---- 2.0 fat 3086304 b- stor 08-Jan-01 00:00 classes.dex -rw---- 2.0 fat 339 b- defN 80-Feb-01 00:00 META-INF/proguard/androidx-annotations.pro -rw---- 2.0 fat 45 b- defN 08-Jan-01 00:00 META-INF/MANIFEST.MF 3 files, 3086688 bytes uncompressed, 3086480 bytes compressed: 0.0% Before the change it was: $ zipinfo out/target/product/walleye/apex/com.android.wifi/javalib/wifi-service.jar Archive: out/target/product/walleye/apex/com.android.wifi/javalib/wifi-service.jar Zip file size: 1241938 bytes, number of entries: 3 -rw---- 2.0 fat 3086304 bl defN 08-Jan-01 00:00 classes.dex -rw---- 2.0 fat 339 b- defN 80-Feb-01 00:00 META-INF/proguard/androidx-annotations.pro -rw---- 2.0 fat 45 b- defN 08-Jan-01 00:00 META-INF/MANIFEST.MF 3 files, 3086688 bytes uncompressed, 1241526 bytes compressed: 59.8% Bug: 148099857 Bug: 146984232 Change-Id: Ia302967b280be85665032cc870c5d5d2419586fc
* | Merge "Abstract sdk_version string using sdkSpec type"Treehugger Robot2020-01-281-39/+25
|\ \
| * | Abstract sdk_version string using sdkSpec typeJiyong Park2020-01-251-39/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The value format that sdk_version (and min_sdk_version, etc.) can have has consistently evolved and is quite complicated. Furthermore, with the Mainline module effort, we are expected to have more sdk_versions like 'module-app-current', 'module-lib-current', etc. The goal of this change is to abstract the various sdk versions, which are currently represented in string and is parsed in various places, into a type called sdkSpec, so that adding new sdk veresions becomes easier than before. The sdk_version string is now parsed in only one place 'SdkSpecFrom', in which it is converted into the sdkSpec struct. The struct type provides several methods that again converts sdkSpec into context-specific information such as the effective version number, etc. Bug: 146757305 Bug: 147879031 Test: m Change-Id: I252f3706544f00ea71c61c23460f07561dd28ab0
* | | Revert "Get the dex2oat host tool path from module dependency on..."Hans Boehm2020-01-271-16/+0
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert submission 1211982-dex2oat-soong-dep Reason for revert: Build failures. See b/148312086. Reverted Changes: Ibc427a9a8: Make dex2oat(d) visible for use as implicit dexpre... I71df11c1e: Move the Once cache for dexpreopt.GlobalConfig int... I38317f2d5: Get the dex2oat host tool path from module depende... I440a09dba: Separate dexpreopt.GlobalSoongConfig to allow inde... Bug: 148312086 Bug: 145934348 Exempt-From-Owner-Approval: Plain revert Change-Id: I0cf6fef04434fd3c0b7957ee9abdcaabeb20b9d8
* / Get the dex2oat host tool path from module dependency on the binaryMartin Stjernholm2020-01-241-0/+16
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | module. This uses the Once cache for GlobalSoongConfig to propagate the dex2oat path from a module dependency to the singletons (both the one that writes out dexpreopt_soong.config and the one that creates the dexpreopted boot images). Unless dexpreopting is disabled altogether through DisablePreopt in dexpreopt.config, that means: - We must ensure at least one module registers a dex2oat tool dependency and resolves a GlobalSoongConfig using it, or else the singletons fail. That means we litter dex2oat dependencies in java modules even when they won't get dexpreopted and hence don't really need them. - We still assume there's at least one java_library or android_app in the build. Bug: 145934348 Test: m (check that out/soong/dexpreopt_soong.config points to dex2oatd64) Test: env USE_DEX2OAT_DEBUG=false m (check that out/soong/dexpreopt_soong.config points to dex2oat) Test: env OUT_DIR=out-tools prebuilts/build-tools/build-prebuilts.sh on the aosp-build-tools branch Change-Id: I38317f2d5e5cf6822f87daae25745767c8a3656c
* Merge "Reland^2 "m <apex_name>-deps-info prints the internal/external deps ↵Treehugger Robot2020-01-151-0/+8
|\ | | | | | | of the APEX""
| * Reland^2 "m <apex_name>-deps-info prints the internal/external deps of the APEX"Jiyong Park2020-01-141-0/+8
| | | | | | | | | | | | | | | | | | | | This reverts commit 7cb4d378e79ffdd46d9a675aeb9780cd6c5ee022. Test: m Test: ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist ./art/tools/dist_linux_bionic.sh -j80 com.android.art.host (in the master-art-host branch) Change-Id: I9beca73aafdf42f03bfa19cf1634b2641dac417b
* | Merge "Allow sdk and core modules to use sysprop_library"Inseob Kim2020-01-151-5/+2
|\ \ | |/ |/|
| * Allow sdk and core modules to use sysprop_libraryInseob Kim2020-01-141-5/+2
| | | | | | | | | | | | | | | | | | This allows javaSdk and javaCore modules to link against Public stub of Platform owned sysprop_library. Bug: 141246285 Test: m nothing Change-Id: Ie11c43cc72ddd0ee13e4163955775c13eb9dbe92
* | Merge "Revert "Reland "m <apex_name>-deps-info prints the internal/external ↵Jiyong Park2020-01-141-8/+0
|\ \ | |/ |/| | | deps of the APEX""""
| * Revert "Reland "m <apex_name>-deps-info prints the internal/external deps of ↵Jiyong Park2020-01-141-8/+0
| | | | | | | | | | | | | | | | | | | | | | the APEX""" This reverts commit 956305c61c48d1048001d3fff33da176e3870c69. Reason for revert: broke master-art-host branch Exempt-From-Owner-Approval: reverting a bad change Change-Id: Id7faed4ee85328c7c65847a3543ea9e67a3d50b3
* | Merge "Reland "m <apex_name>-deps-info prints the internal/external deps of ↵Treehugger Robot2020-01-141-0/+8
|\| | | | | | | the APEX"""
| * Reland "m <apex_name>-deps-info prints the internal/external deps of the APEX""Jiyong Park2020-01-091-0/+8
| | | | | | | | | | | | | | | | | | | | This reverts commit 4513f703f9902193fc5c29607ddb4a8f71bfd702. Bug: 1190898 Test: m Test: EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true NATIVE_COVERAGE=true m dist Change-Id: I50fdccabb43e4751694db83ee451d388657257e0
* | Merge "Do not add jacocoagent to framework libraries in static coverage builds."Ulyana Trafimovich2020-01-131-7/+8
|\ \ | |/ |/|
| * Do not add jacocoagent to framework libraries in static coverage builds.Ulya Trafimovich2020-01-091-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Framework libraries need special handling in static coverage builds: they should not have static dependency on jacoco, otherwise there would be multiple conflicting definitions of the same jacoco classes coming from different bootclasspath jars. This CL does two things: - Move the code that enables instrumentation of framework libraries from AndroidGenerateBuildActions phase to the earlier DepsMutator phase. This is necessary because DepsMutator phase already does some things that depend on the instrumentation flag. - Explicitely exclude framework libraries from those libraries which have static dependency on jacoco. This CL does not fix any apparent build problems: prior to it the framework libraries were not excluded properly, but this was masked by wrong order of checking / setting instrumentation flag. Note that static coverage builds without framework coverage fail to boot, namely this build command: $ build/soong/soong_ui.bash --make-mode \ SKIP_ABI_CHECKS=true \ TARGET_PRODUCT=aosp_walleye TARGET_BUILD_VARIANT=userdebug droid \ EMMA_INSTRUMENT=true \ EMMA_INSTRUMENT_STATIC=true \ NATIVE_COVERAGE=true ..causes the following boot-time errors in logcat: 01-08 12:31:48.670 1252 1252 E System : java.lang.StackOverflowError: stack size 8192KB 01-08 12:31:48.670 1252 1252 E System : at org.jacoco.agent.rt.internal.Offline.$jacocoInit(Unknown Source:13) 01-08 12:31:48.670 1252 1252 E System : at org.jacoco.agent.rt.internal.Offline.getProbes(Unknown Source:0) Also note that static coverage with framework coverage failed to build prior to CL Iaa198b8505aaff36e6685559642ff721637ce55f (dex2oat failed to create boot image due to missing classes). Test: non-static coverage without framework coverage boots: $ build/soong/soong_ui.bash --make-mode \ SKIP_ABI_CHECKS=true \ TARGET_PRODUCT=aosp_walleye TARGET_BUILD_VARIANT=userdebug droid \ EMMA_INSTRUMENT=true \ NATIVE_COVERAGE=true Test: non-static coverage with framework coverage boots: $ build/soong/soong_ui.bash --make-mode \ SKIP_ABI_CHECKS=true \ TARGET_PRODUCT=aosp_walleye TARGET_BUILD_VARIANT=userdebug droid \ EMMA_INSTRUMENT=true \ EMMA_INSTRUMENT_FRAMEWORK=true \ NATIVE_COVERAGE=true Test: static coverage with framework coverage boots: $ build/soong/soong_ui.bash --make-mode \ SKIP_ABI_CHECKS=true \ TARGET_PRODUCT=aosp_walleye TARGET_BUILD_VARIANT=userdebug droid \ EMMA_INSTRUMENT=true \ EMMA_INSTRUMENT_FRAMEWORK=true \ EMMA_INSTRUMENT_STATIC=true \ NATIVE_COVERAGE=true Change-Id: I700f979a5d638ce632f5e8b920b9d0adb3c80248
* | Merge "Revert "m <apex_name>-deps-info prints the internal/external deps of ↵Jiyong Park2020-01-091-8/+0
|\ \ | | | | | | | | | the APEX""
| * | Revert "m <apex_name>-deps-info prints the internal/external deps of the APEX"Jiyong Park2020-01-091-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 114ff53f5e66f4493dcee443db677c09e0b9b32b. Reason for revert: broke cf_x86_phone-userdebug_coverage Change-Id: I7221fd0b0baee5407a7322240c170aef8e549e4d
* | | Merge "jacoco correctly gathers info from APK-in-APEX"Treehugger Robot2020-01-091-0/+9
|\ \ \
| * | | jacoco correctly gathers info from APK-in-APEXJiyong Park2020-01-081-0/+9
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change fixes a bug that jacoco-report-classes-all.jar does not include info for APK-in-APEX such as the MediaProvider apk in com.android.mediaprovider APEX. Firstly, LOCAL_SOONG_JACOCO_REPORT_CLASSES_JAR is correctly set also for the APKs included in APEXes. Secondly, the Make modules for the embedded APKs are now built with soong_app_prebuilt.mk to correctly import the jacoco file into the Make world. Bug: 147296855 Test: execute the following command in internal master. $ choosecombo cf_x86_phone userdebug $ NINJA_ARGS="-t path out/target/product/vsoc_x86/jacoco-report-classes-all.jar out/target/common/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/jacoco-report-classes.jar" EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true m The result shows that there is a path as follows: out/target/product/vsoc_x86/jacoco-report-classes-all.jar out/target/product/vsoc_x86/apex/com.android.mediaprovider/priv-app/MediaProvider/MediaProvider.apk out/target/product/vsoc_x86/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/package.apk out/target/common/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/jacoco-report-classes.jar Change-Id: I52d11534a34eb35219bfafca4453e75a1b701c0e
* | | Merge "m <apex_name>-deps-info prints the internal/external deps of the APEX"Treehugger Robot2020-01-091-0/+8
|\ \ \ | |/ / |/| / | |/
| * m <apex_name>-deps-info prints the internal/external deps of the APEXJiyong Park2020-01-021-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to have a way to see the list of modules that directly or indirectly contribute to an APEX. People find it difficult to determine whether a module is included in which APEXes because APEX tracks indirect dependencies as well as direct dependencies. Therefore, just looking at Android.bp for the APEX itself doesn't give the answer. This change adds a new make target <apex_name>-deps-info, which generates out/soong/<apex_name>-deps-info.txt file that shows the internal and external dependencies of the said APEX. Here, internal means the dependencies are actually part of the APEX, while external means the dependencies are still external to the APEX. Bug: 146323213 Test: m (apex_test amended) Change-Id: I33d1ccf5d1ca335d71cd6ced0f5f66b8c3886d13
* | Add support for java_test in sdkPaul Duffin2019-12-311-6/+107
|/ | | | | | | | | | | Adds java_test_import module type for use by the sdk snapshot and adds java_tests property to the sdk and sdk_snapshot module type. This is needed for the conscrypt test sdk. Bug: 143678475 Test: m nothing Change-Id: Ied4c56c978dac2f92a9b3bc34b3235d7eeba2fd3
* Restrict SdkMemberTypes that can be used with sdk/sdk_snapshotPaul Duffin2019-12-311-0/+1
| | | | | | | | | | | | | | By default SdkMemberTypes are only supported on module_exports module type. Support for sdk module type has to be explicitly specified. The java_header_libs, native_shared_libs and stubs_sources are supported on sdk. The latter is required to provide the stubs source for an API specified in java_header_libs as they should be kept in sync. Bug: 146341462 Test: m nothing Change-Id: I19b9e60792780a797458d4a9e489506602b13144
* Support java_sdk_library as java_libs of apexJooyung Han2019-12-201-4/+0
| | | | | | | | | | | | | | | | | When a java_sdk_library module is added, both impl jar and permission xml files are packaged together. For example, when a java_sdk_library "foo" is listed, following two entries will be in an APEX package. /javalibs/foo.jar /etc/permissions/foo.xml Bug: 145474221 Test: m com.android.cronet deapexer list com.android.cronet.apex Change-Id: If5883c02255e9309f20810b1532d3fbe73bf4e95
* Dedup registration code for module types and singletonsPaul Duffin2019-12-191-18/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The registration of module types and singletons is duplicated between init() functions that register them for use in the build runtime and test context creation code that registers them for testing. This is a proof of concept for a mechanism that will allow the code to be shared. It defines a RegistrationContext interface that is implemented by both the TestContext and the new initRegistrationContext type. An instance of the the latter is available through the InitRegistrationContext variable. The intent is that the registration of the module types and singleton types will be extracted from the init() function into a separate function that takes a RegistrationContext parameter. That method is called from init() passing in the InitRegistrationContext and from a test passing in the TestContext. Something like this: func init() { RegisterBuildComponents(android.InitRegistrationContext) } func RegisterBuildComponents(ctx android.RegistrationContext) { ctx.RegisterModuleType(....) .... } A test would do something like this: ctx := android.NewTestContext() RegisterBuildComponents(ctx) Test: m nothing Change-Id: I97173cabb6d6cf7ce98fdb5f73418438b1997b35
* Merge "Create public stub for platform's sysprop_library"Treehugger Robot2019-12-191-2/+30
|\
| * Create public stub for platform's sysprop_libraryInseob Kim2019-12-191-2/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Java modules using SystemAPI can now link against platform owned sysprop_library with public stub. This allows modules to use platform's public sysprops (which should be regarded as an API) without any hidden API usages, if using dynamic linking and boot class path. This doesn't affect any vendor or odm owned sysprop_library. Bug: 141246285 Bug: 145167888 Test: m Change-Id: I99824fb24a75cc8282211c2ad6c6296ae9fca393
* | Reland "Also package recursive jni_libs deps of android_apps as well as ↵Peter Collingbourne2019-12-171-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | direct deps." with bug fix. This time, exclude NDK libraries instead of LLNDK libraries from the package. This is necessary because there are libraries such as libvndksupport which are LLNDK but are not accessible to apps. Original commit message: > Previously, android_app targets for which a.shouldEmbedJnis(ctx) = true > (e.g. CtsSelinuxTargetSdk25TestCases) would need to specify all of their > recursive library dependencies, including for example libc++ when depending > on the platform libc++. This means unnecessary churn when we add a new > dependency to libc++ (e.g. libunwind [1]). To avoid the churn and allow > jni_libs clauses to be simplified, make the build system search for the > recursive dependencies and automatically include them. > > This change allows us to remove code that was previously adding NDK libc++ > as a special case, as it is now covered by the generic code. > > Also fix some improper quoting that was exposed as a result of this change > causing more files to be packaged than before. > > [1] https://android-review.googlesource.com/q/topic:%22libunwind-so%22 Bug: 144430859 Test: atest CtsAppOpsTestCases Test: atest FrameworksNetSmokeTests Change-Id: I8311ede0b44d7e50b9f272912ead8ef07e82b074
* | Merge "Revert "Also package recursive jni_libs deps of android_apps as well ↵Joseph Murphy2019-12-181-0/+1
|\ \ | | | | | | | | | as direct deps.""
| * | Revert "Also package recursive jni_libs deps of android_apps as well as ↵Lorenzo Colitti2019-12-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | direct deps." This reverts commit 6f907ad3ddad9eb0e928ff7ad7965fa17a8a6946. Reason for revert: Broke FrameworksNetSmokeTests Bug: 146456945 Change-Id: Ibef7bb80c532e70cfcfb974f51a99ed25437a343
* | | Merge "Also package recursive jni_libs deps of android_apps as well as ↵Peter Collingbourne2019-12-171-1/+0
|\| | | | | | | | | | | direct deps."
| * | Also package recursive jni_libs deps of android_apps as well as direct deps.Peter Collingbourne2019-12-161-1/+0
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, android_app targets for which a.shouldEmbedJnis(ctx) = true (e.g. CtsSelinuxTargetSdk25TestCases) would need to specify all of their recursive library dependencies, including for example libc++ when depending on the platform libc++. This means unnecessary churn when we add a new dependency to libc++ (e.g. libunwind [1]). To avoid the churn and allow jni_libs clauses to be simplified, make the build system search for the recursive dependencies and automatically include them. This change allows us to remove code that was previously adding NDK libc++ as a special case, as it is now covered by the generic code. Also fix some improper quoting that was exposed as a result of this change causing more files to be packaged than before. [1] https://android-review.googlesource.com/q/topic:%22libunwind-so%22 Bug: 144430859 Change-Id: I3d6fbcce75bc108a982eb7483992a4b202056339
* / hostdex:true modules are available for platformJiyong Park2019-12-161-0/+10
|/ | | | | | | | | | | | Java libraries with hostdex: true are available for the platform even if it doesn't have "//apex_available:platform" in the apex_available property. Note that the java libraries are still prevented from being installed to the device. Bug: 128708192 Test: m Change-Id: I6463ebc59cf7fd861b812999d7a79c387bbb3335
* Decouple addition of new sdk member types from sdk codePaul Duffin2019-12-131-4/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, adding a new SdkMemberType would require adding a new sdkMemberListProperty instance to the sdkMemberListProperties as well as adding a new property into the sdkProperties struct. They are potential sources of conflict and couple the sdk code with all the packages that add members to it. This change switched to a registration model that allows each package to register its sdk member types decoupling them from the sdk code. Adds an SdkPropertyName() method to SdkMemberType that specifies the name of the property to use in the sdk/sdk_snapshot. Also provides an SdkMemberTypeBase struct to be used by providers of SdkMemberType implementations. SdkMemberType instances are registered using the RegisterSdkMemberType() func which sorts the registered instances by their SdkPropertyName() to ensure the behavior is consistent and not affected by order of registration. When creating a new sdk module a dynamicSdkMemberTypes instance is created that contains the following: * A properties struct is created dynamically that contains a field for each registered SdkMemberType, corresponding to that type's SdkPropertyName(). * A list of sdkMemberListProperty instances is also created, one for each registered SdkMemberType. The dynamicSdkMemberTypes instance is cached using a key that uniquely identifies the set of registered types just in case new types are registered after one has been created, e.g. by tests. Bug: 142918168 Test: m checkbuild Change-Id: I4bf2bf56a2a49025aa41454048bc1e8ccc6baca2
* Pass SdkMember to AddPrebuiltModule instead of the namePaul Duffin2019-12-091-1/+1
| | | | | | | | | This is needed for a follow up change that makes sure that the prebuilt modules have the same visibility as the source modules. Bug: 143678475 Test: m conscrypt-module-sdk Change-Id: I9461c8c094ab19ee9ececb5e5fd50565789f2fa2
* Merge "Cleanup java.DefaultsFactory()"Treehugger Robot2019-12-071-3/+2
|\
| * Cleanup java.DefaultsFactory()Paul Duffin2019-12-061-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function took a props varargs parameter but it was only ever called with no parameters. The props parameter meant it could not be used directly with RegisterModuleType() so the defaultsFactory() func was added which simply called through to DefaultsFactory(). Removing the props varargs parameter allowed it to be used directly with RegisterModuleType() and so the defaultsFactory() could be removed. This was needed because a follow up change adds a test in another package that uses java_defaults and so it needs the factory method (defaultsFactory()) to be exported. Test: m nothing Change-Id: I33d5c4d4ce8f349b1e6fc706d5e9656faf303b4f
* | Merge "Support header and implementation jars in sdk"Treehugger Robot2019-12-071-15/+49
|\|
| * Support header and implementation jars in sdkPaul Duffin2019-12-061-15/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new java_header_libs property that exports header jars (as java_libs currently does) and switch java_libs to export implementation jars instead. Refactors implementation of the existing library sdk member type so both properties can be supported from common code as they differ only on the jar being exported. Bug: 143678475 Test: m nothing Change-Id: I04642122f72d083bbdfd3290624f957b71ee8875
* | Merge "Link type checking for java_library"Treehugger Robot2019-12-061-2/+1
|\ \ | |/ |/|
| * Link type checking for java_libraryJeongik Cha2019-12-071-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Link type checking for java_library has not been working unintentionally. So turn on link type checking for these types. And also add tests for link type checking. Bug: 145799020 Test: cherry-pick aosp/1182522 and check if build fails Test: m nothing and there is no error(soong unittest) Change-Id: Ifc347f657885de1028ac0076ddd103c0387b597a
* | Parameterize the sdk member processingPaul Duffin2019-12-061-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extracts the type specific functionality into the SdkMemberType interface which has to be implemented by each module type that can be added as a member of the sdk. It provides functionality to add the required dependencies for the module type, check to see if a resolved module is the correct instance and build the snapshot. The latter was previously part of SdkAware but was moved because it has to be able to process multiple SdkAware variants so delegating it to a single instance did not make sense. The custom code for handling each member type specific property, e.g. java_libs, has been replaced with common code that processes a list of sdkMemberListProperty struct which associates the property (name and getter) with the SdkMemberType and a special DependencyTag which is passed to the SdkMemberType when it has to add dependencies. The DependencyTag contains a reference to the appropriate sdkMemberListProperty which allows the resolved dependencies to be grouped by type. Previously, the dependency collection methods would ignore a module if it was an unsupported type because they did not have a way of determining which property it was initially listed in. That meant it was possible to add say a droidstubs module to the java_libs property (and because they had the same variants) it would work as if it was added to the stubs_sources property. Or alternatively, a module of an unsupported type could be added to any property and it would just be ignored. However, the DependencyTag provides information about which property a resolved module was referenced in and so it can detect when the resolved module is of the wrong type and report an error. That check identified a bug in one of the tests where the sdk referenced a java_import module (which is not allowed in an sdk) instead of a java_library module (which is allowed). That test was fixed as part of this. A list of sdkMemberListProperty structs defines the member properties supported by the sdk and are processed in order to ensure consistent behaviour. The resolved dependencies are grouped by type and each group is then processed in defined order. Within each type dependencies are grouped by name and encapsulated behind an SdkMember interface which includes the name and the list of variants. The Droidstubs and java.Library types can only support one variant and will fail if given more. The processing for the native_shared_libs property has been moved into the cc/library.go file so the sdk package code should now have no type specific information in it apart from what is if the list of sdkMemberListProperty structs. Bug: 143678475 Test: m conscrypt-module-sdk Change-Id: I10203594d33dbf53441f655aff124f9ab3538d87
* | Merge "Add model to represent generated snapshot .bp file"Paul Duffin2019-12-031-24/+2
|\ \ | |/ |/|
| * Add model to represent generated snapshot .bp filePaul Duffin2019-12-021-24/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Having each module type generate the contents of the snapshot's .bp file results in lots of duplicated code. This adds an intermediate model for use by the module types and then generates the .bp file contents from that. This not only removes the duplicated formatting code but it also allows consistent handling of shared properties such as name further reducing duplication. It also makes it possible to duplicate the versioned and unversioned prebuilt modules from the same model. Extracts generatedContents from generatedFile to allow the contents to be populated without creating an output file, for testing. Cleans up unused code. Bug: 143678475 Test: m nothing Change-Id: If21b84db0ef3fdfb5dc11ea0973ce6cb73603ea3
* | Merge "Link type will be check in android_library also"Treehugger Robot2019-12-031-9/+17
|\ \ | |/ |/|
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-23 11:10:16 +0000