summaryrefslogtreecommitdiff
path: root/java/java.go
AgeCommit message (Collapse)Author
2020-02-24Reland "Turn on the instrumentation by default for the java code in APEXes"Jiyong Park
This reverts commit c021ea0b3543d4ff64b16414c0276b96dc5b2c4b. Bug: 149353192 Change-Id: I2b1c0736202de26c5ea88c0ab14574bd7207a5fb Test: N/A (this is a clean revert) forward fix will be followed
2020-02-21Use header jar without jarjar for sharded classpathColin Cross
Sharding uses the header jar of all of the classes of the module with the sources of a subset, but was incorrectly used the jarjar version of the header jar, which may have renamed some of the classes. Fixes: 149969343 Test: m framework-minus-apex Change-Id: I568c939f8030d3ddc1e7fa8796cffcac4d6172e8 Merged-In: I568c939f8030d3ddc1e7fa8796cffcac4d6172e8 (cherry picked from commit f5a6628b27ab67cba0aa5fd153973cc5d704a366)
2020-02-21Use header jar without jarjar for sharded classpathColin Cross
Sharding uses the header jar of all of the classes of the module with the sources of a subset, but was incorrectly used the jarjar version of the header jar, which may have renamed some of the classes. Fixes: 149969343 Test: m framework-minus-apex Change-Id: I568c939f8030d3ddc1e7fa8796cffcac4d6172e8
2020-02-19Allow java_system_modules_import to replace java_system_modulesPaul Duffin
Previously, there were some places where a java_system_module_import could not be used in place of a java_system_module. That was because the code assumed a *SystemModules type not a *systemModulesImport type. This change introduces a SystemModulesProvider interface that is used instead and is implemented on both types. Bug: 142940300 Test: m nothing ran new tests before changes to make sure they detected the issue and after to make sure the changes fixed the issue. Change-Id: I7b16ac5708880bdf61e6f5b1e6616c986f0ed763
2020-02-18Merge "sdk_version: "system_server_current""Treehugger Robot
2020-02-17Merge "Revert "Turn on the instrumentation by default for the java code in ↵Jackal Guo
APEXes""
2020-02-17Revert "Turn on the instrumentation by default for the java code in APEXes"Jackal Guo
This reverts commit 33b6654eeace28ceeb8f8328c01722abc4cdc6c6. Reason for revert: verify build breakage Change-Id: I712a9de8ca3bfb17c36d3b8efa6176cdaf26640e
2020-02-14Merge "Turn on the instrumentation by default for the java code in APEXes"Treehugger Robot
2020-02-14Turn on the instrumentation by default for the java code in APEXesJiyong Park
Bug: 149353192 Test: DIST_DIR=dist_dir TARGET_BUILD_VARIANT=userdebug EMMA_INSTRUMENT=true NATIVE_COVERAGE=true TARGET_BUILD_APPS="com.android.media" vendor/google/build/build_unbundled_coverage_mainline_module.sh and check that jacoco-report-classes.jar is created. Change-Id: I28e3dc82b7913f60b2278126fca255306e48a424
2020-02-13Do all dexpreoptDisabled checks before registering a dex2oat host dep.Martin Stjernholm
Also disable dexpreopting for host. These are necessary to avoid adding dependencies on dex2oat in various non-platform builds where they will break. Since we cannot assume at least one module enables dexpreopting now, the two dexpreopt singletons are silently disabled if there has been no call to dexpreopt.GetGlobalSoongConfig. Bug: 145934348 Bug: 148312086 Bug: 148319588 Bug: 148690468 Test: m Test: env OUT_DIR=out-tools prebuilts/build-tools/build-prebuilts.sh on the aosp-build-tools branch Test: build/soong/soong_ui.bash --make-mode static_sdk_tools dist DIST_DIR=out-dist BUILD_HOST_static=1 on internal (cf b/148312086#comment8) Test: build/soong/soong_ui.bash --make-mode dist DIST_DIR=out-apps TARGET_BUILD_APPS=Launcher3 TARGET_BUILD_VARIANT=userdebug on internal without art/ and external/vixl/ (cf b/148319588) Change-Id: I240dade7204b87fc2d12181534ab23439eca8b46
2020-02-13Reland: Get the dex2oat host tool path from module dependency on theMartin Stjernholm
binary 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. This relands https://r.android.com/1205730 without changes - the necessary fixes are in the child CLs. 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 dex2oat64) Test: env OUT_DIR=out-tools prebuilts/build-tools/build-prebuilts.sh on the aosp-build-tools branch Change-Id: I66661711b317d1e4ec434861982919bdde19b575
2020-02-13Reland: Move the Once cache for dexpreopt.GlobalConfig into theMartin Stjernholm
dexpreopt package. Preparation for a future CL that will need to get the make-written GlobalConfig from within dexpreopt. Also rename the Load*Config functions to Parse*Config, since they don't actually load the config files anymore. This relands https://r.android.com/1211982. Bug: 145934348 Test: m Change-Id: Icb9332a93811d77d2d8b06e983b92501b180a358
2020-02-13Use precise class loader context for system server jars.Ulya Trafimovich
This patch excludes non-Soong system server jars from dexpreopting. System server jars should be dexpreopted together for better performance: each jar should have all preceding system server jars in its class loader context (that is passed to dex2oat and recorded in the resulting .oat file to be used by the loader). This means that we need a total order on system server jars. The default order provided by PRODUCT_SYSTEM_SERVER_JARS is not good, as it does not always respect genuine dependencies between jars (counter- examples are rare, but non-trivial to fix: b/148219586). This patch adds a post deps mutator pass that creates additional dependencies and enforces global order. These are later used to generate precise class loader contexts and system server classpath. Test: Class loader contexts in the oat files for system server jars match expectations: $ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/com.android.location.provider.odex | grep '^classpath' classpath = PCL[] $ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/services.odex | grep '^classpath' classpath = PCL[/system/framework/com.android.location.provider.jar*1919890654] $ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/wifi-service.odex | grep '^classpath' classpath = PCL[/system/framework/com.android.location.provider.jar*1919890654:/system/framework/services.jar*4269704903:/system/framework/services.jar!classes2.dex*134345935] ... Test: The phone boots and logcat has no scary messages related to class loader contexts: $ lunch aosp_walleye-userdebug && m $ adb reboot bootloader && fastboot flashall -w && adb wait-for-device $ adb root $ adb shell stop $ adb logcat -c $ adb shell setprop dalvik.vm.extra-opts -verbose:oat $ adb shell start $ adb logcat | egrep -i 'system_server: .*load.*/system/framework' 02-03 14:14:26.912 5016 5016 I system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1 02-03 14:14:26.914 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1 02-03 14:14:26.914 5016 5016 I system_server: Loading /system/framework/oat/arm64/services.odex with executable: 1 02-03 14:14:26.916 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/services.odex with executable: 1 02-03 14:14:26.927 5016 5016 I system_server: Loading /system/framework/oat/arm64/wifi-service.odex with executable: 1 02-03 14:14:26.933 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/wifi-service.odex with executable: 1 02-03 14:14:26.933 5016 5016 I system_server: Loading /system/framework/oat/arm64/ethernet-service.odex with executable: 1 02-03 14:14:26.934 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/ethernet-service.odex with executable: 1 02-03 14:14:26.946 5016 5016 I system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 0 02-03 14:14:26.947 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 0 02-03 14:14:26.947 5016 5016 I system_server: Loading /system/framework/oat/arm64/services.odex with executable: 0 02-03 14:14:26.948 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/services.odex with executable: 0 02-03 14:14:26.948 5016 5016 I system_server: Loading /system/framework/oat/arm64/wifi-service.odex with executable: 0 02-03 14:14:26.948 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/wifi-service.odex with executable: 0 02-03 14:14:26.949 5016 5016 I system_server: Loading /system/framework/oat/arm64/ethernet-service.odex with executable: 0 02-03 14:14:26.949 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/ethernet-service.odex with executable: 0 02-03 14:14:30.480 5016 5016 I system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1 02-03 14:14:30.481 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1 Bug: 141785760 Bug: 140451054 Bug: 148944771 Change-Id: Idac678dbd1f5fe0e381ce8e0e3561423f8a31389
2020-02-12Automatically set compile_dex:true and hostdex:true for APEX variantsJiyong Park
... unless they are turned off explicitly. Bug: 147221965 Test: m Change-Id: I6b91d6409d9cf06ad09467c53d5d51a9c693256e
2020-02-12sdk_version: "system_server_current"Jiyong Park
The new sdk version "system_server_current" is for system server components that needs to use all public APIs, system APIs, module APIs, and the system server APIs. Bug: 146757305 Test: m Change-Id: I24fd5af010532a110393676607dc90889f2ec17e
2020-02-07Add java_system_modules to sdk/module_exportsPaul Duffin
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
2020-02-06apex_available tracks static dependenciesJiyong Park
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
2020-01-31sdk_version: "module_current" is supportedJiyong Park
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
2020-01-29Merge "Store uncompressed and aligned DEX files for java libs in APEXes."Ulyana Trafimovich
2020-01-28Merge "Abstract sdk_version string using sdkSpec type"Treehugger Robot
2020-01-27Revert "Get the dex2oat host tool path from module dependency on..."Hans Boehm
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
2020-01-27Store uncompressed and aligned DEX files for java libs in APEXes.Ulya Trafimovich
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
2020-01-25Abstract sdk_version string using sdkSpec typeJiyong Park
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
2020-01-24Get the dex2oat host tool path from module dependency on the binaryMartin Stjernholm
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
2020-01-15Merge "Reland^2 "m <apex_name>-deps-info prints the internal/external deps ↵Treehugger Robot
of the APEX""
2020-01-15Merge "Allow sdk and core modules to use sysprop_library"Inseob Kim
2020-01-14Reland^2 "m <apex_name>-deps-info prints the internal/external deps of the APEX"Jiyong Park
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
2020-01-14Merge "Revert "Reland "m <apex_name>-deps-info prints the internal/external ↵Jiyong Park
deps of the APEX""""
2020-01-14Revert "Reland "m <apex_name>-deps-info prints the internal/external deps of ↵Jiyong Park
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
2020-01-14Allow sdk and core modules to use sysprop_libraryInseob Kim
This allows javaSdk and javaCore modules to link against Public stub of Platform owned sysprop_library. Bug: 141246285 Test: m nothing Change-Id: Ie11c43cc72ddd0ee13e4163955775c13eb9dbe92
2020-01-14Merge "Reland "m <apex_name>-deps-info prints the internal/external deps of ↵Treehugger Robot
the APEX"""
2020-01-13Merge "Do not add jacocoagent to framework libraries in static coverage builds."Ulyana Trafimovich
2020-01-09Do not add jacocoagent to framework libraries in static coverage builds.Ulya Trafimovich
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
2020-01-09Reland "m <apex_name>-deps-info prints the internal/external deps of the APEX""Jiyong Park
This reverts commit 4513f703f9902193fc5c29607ddb4a8f71bfd702. Bug: 1190898 Test: m Test: EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true NATIVE_COVERAGE=true m dist Change-Id: I50fdccabb43e4751694db83ee451d388657257e0
2020-01-09Merge "Revert "m <apex_name>-deps-info prints the internal/external deps of ↵Jiyong Park
the APEX""
2020-01-09Revert "m <apex_name>-deps-info prints the internal/external deps of the APEX"Jiyong Park
This reverts commit 114ff53f5e66f4493dcee443db677c09e0b9b32b. Reason for revert: broke cf_x86_phone-userdebug_coverage Change-Id: I7221fd0b0baee5407a7322240c170aef8e549e4d
2020-01-09Merge "jacoco correctly gathers info from APK-in-APEX"Treehugger Robot
2020-01-09Merge "m <apex_name>-deps-info prints the internal/external deps of the APEX"Treehugger Robot
2020-01-08jacoco correctly gathers info from APK-in-APEXJiyong Park
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
2020-01-02m <apex_name>-deps-info prints the internal/external deps of the APEXJiyong Park
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
2019-12-31Add support for java_test in sdkPaul Duffin
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
2019-12-31Restrict SdkMemberTypes that can be used with sdk/sdk_snapshotPaul Duffin
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
2019-12-20Support java_sdk_library as java_libs of apexJooyung Han
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
2019-12-19Dedup registration code for module types and singletonsPaul Duffin
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
2019-12-19Merge "Create public stub for platform's sysprop_library"Treehugger Robot
2019-12-19Create public stub for platform's sysprop_libraryInseob Kim
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
2019-12-17Reland "Also package recursive jni_libs deps of android_apps as well as ↵Peter Collingbourne
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
2019-12-18Merge "Revert "Also package recursive jni_libs deps of android_apps as well ↵Joseph Murphy
as direct deps.""
2019-12-18Revert "Also package recursive jni_libs deps of android_apps as well as ↵Lorenzo Colitti
direct deps." This reverts commit 6f907ad3ddad9eb0e928ff7ad7965fa17a8a6946. Reason for revert: Broke FrameworksNetSmokeTests Bug: 146456945 Change-Id: Ibef7bb80c532e70cfcfb974f51a99ed25437a343
2019-12-17Merge "Also package recursive jni_libs deps of android_apps as well as ↵Peter Collingbourne
direct deps."
generated by cgit v1.2.3 (git 2.25.1) at 2025-10-04 19:59:03 +0000