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
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
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
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
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
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
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
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 fa89944c79)
Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
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
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
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
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
This reverts commit 7cb4d378e7.
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
This reverts commit 956305c61c.
Reason for revert: broke master-art-host branch
Exempt-From-Owner-Approval: reverting a bad change
Change-Id: Id7faed4ee85328c7c65847a3543ea9e67a3d50b3
This allows javaSdk and javaCore modules to link against Public stub of
Platform owned sysprop_library.
Bug: 141246285
Test: m nothing
Change-Id: Ie11c43cc72ddd0ee13e4163955775c13eb9dbe92
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
The behaviour is similar to go/be#java_library.exported_plugins. Plugins added to exported_plugins of library X are not applied to the library itself, but rather to libraries that directly depend on the library X.
Test: m checkbuild
Bug: 139740873
Change-Id: I4042bd482ad9cb12d6fbaac51f039d38b1b7a428
Removes duplicated code for generating a versioned and non-versioned
form of the java_import module in the snapshot.
Bug: 143678475
Test: m nothing and check output for dummy sdk
Change-Id: Ia8d05c3bf9ef79953a817b168dd9d59f2af2d2ce
Creates a SnapshotBuilder and GeneratedSnapshotFile interfaces to allow
the java library snapshot work to be moved into the java package.
Test: m -j60 checkbuild
Change-Id: I857167616026149d5e85885621b53876b419ba9b
ApexPropreties are added in InitApexModule() and they are supposed to be
defaultable. To be defaultable, InitApexModule() should be called before
InitDefaultableModule().
Bug: 144332048
Test: m (soong test added)
Change-Id: I6c90ed3b66a086292a4c0ecb37c61f83769e62bd
Silence the dep-ann warnings until there is an effort to do
something about them.
Test: m framework-minus-apex doesn't print dep-ann warnings.
Change-Id: Ic172e840dded4564fecfb91e96cba0c54358e20a
Only if PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE is set,
every app and java library in product cannot use hidden APIs anymore.
checkSdkVersion() checks if sdk_version of app and library is narrow enough,
checkLinkType() checks every library that app links agianst
Bug: 132780927
Test: m
Test: set PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE, and check whether build
error occurs.
Change-Id: Ic630503b875040f730feda4fef826ed6d71da111
For now, Soong checks link-type in java_library, so it cannot block hidden api usage from android_library that app links with.
So we should add check in 'android_library'
Test: m nothing
Change-Id: Ic040270ec668bdd693b690ac8a88be1048922c3b
62c7829595c0df53e96addcd347c11ac01012eee introduced the new stem
property to java modules, but it wasn't propagated to Make. Fixing the
problem.
This change also fixes a problem that (module name) == (file name) is
assumed in dexpreopt_config.go, which no longer is the case. A mutator
runs to build a map from module name to its stem. The map is then used
when filling up the file paths in the bootImageConfig struct.
Bug: 139391334
Bug: 143494499
Test: m
Test: BootImageProfileTest
Change-Id: Idbc894f877692401471130de6cbfe5e0dd129da9
Java language was set for 1.8 for anything building against the
current SDK because the stubs were not built in Soong, so the
system modules could not be built. The stubs have been built
in Soong since Iabd32b30954b3f4a6d9a779fde52a032b684807e, but
I5e870c34dd0ebc8ae3f888ec627da590c846a76f missed updating
this TODO.
Use 1.9 when building against the stubs, but continue using
1.8 for unbundled builds until we have prebuilt system modules.
Always use the core-current-stubs-system-modules to avoid
splitting android.* packages between the system modules and
the classpath, which would cause new classes in android.*
packages in classpath jars to be ignored. Add a new
java9Classpath field to sdkDep that will contain the stubs jar
when targeting Java language level 1.9, and plumb it through
to javac and turbine. Rename the modules field to bootclasspath.
Bug: 142896162
Test: m checkbuild
Change-Id: Icfd32d0a863b2303a997c7cf03cb3708aade4724
The dependency handling for sdk_version: "none" (which propagated to
!sdkDep.hasStandardLibs()) was very similar to the normal useModule
case. Combine the cases by making decodeSdkDep set useModule: true
and put the system modules in modules for the sdk_version: "none"
case.
Test: TestClasspath
Change-Id: Icc9ff4d43a38da25cc0e3628be95951d61773ad5
Remove the hardcoded checks against "1.9" by making javaVersion
an enum and implementing javaVersion.usesJavaModules().
Test: TestClasspath
Change-Id: I559eeb1f45880bb8177269c6d977ee4dfbadce57
Prior to this change, setting that to "false" turned the default Java
language level back to 8. This change removes that option.
Bug: 115604102
Test: m java droid docs tests cts
Change-Id: I97bfd0dc8d941008b4071c6efe1c0c24950c4f1f
java_library, java_import and dex_import now support stem property to
set the output file name.
Bug: 139391334
Test: m
Merged-In: I11146badf558e524a973806114b9cb1344db4a6e
(cherry picked from commit 62c7829595c0df53e96addcd347c11ac01012eee)
Change-Id: I11146badf558e524a973806114b9cb1344db4a6e
Add a module type for tradefed libraries that causes an additional
copy to be installed at out/host/linux-x86/tradefed.
Bug: 122332235
Bug: 141877526
Test: m tradefed
Change-Id: Ib7160dd060ad83d2dfb81d6a7106cb0dac98553e
When an APEX is built with uses_sdks, any depedndency from the APEX to
the outside of the APEX should be from the SDKs that the APEX is built
against.
Bug: 138182343
Test: m
Change-Id: I1c2ffe8d28ccf648d928ea59652c2d0070bf10eb
The arch variants are hardcoded in every module type. Refactor
them out into a Target.Variations() method in preparation for
splitting the arch mutator into two, which will require using
different variations.
Test: m checkbuild
Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
AIDEGen collects the complied sources which are generated from build
system, the sources includes not only java/kt files but also srcjar
files. Since the srcjar files are record in srcjars parameter in json
file, we should keep only java or kt files in the srcs parameter.
The size diff of module_bp_java_deps.json:
Without this patch: 15,298,369 Bytes
With this patch: 15,044,804 Bytes
The build time diff:
Without this patch: 2m31.345
With this patch: 2m32.662
Bug: 141528361
Test: 1. m clean -j
2. aidegen tradefed
3. Open out/soong/module_bp_java_deps.json
4. Find the module CtsSyncManagerCommon and check the
sync_manager_cts.srcjar files doesn't exist in srcs but exists
in srcjars section.
Change-Id: I43fc5c05b657473054e632cae4795220907dc711
This allows droidstubs to use the same system modules to create the
stubs that will be used to compile them. It improves consistency and
avoids droidstubs having to duplicate the libraries that make up the
system modules on its libs property.
Adds systemModules() to the sdkContext which allows consistent error
checking behavior between droidstubs and java_library.
Bug: 142534789
Test: m checkbuild
Change-Id: Ib2006906d9528a900f16851f50b62152ffb51a1b
Create a new type InstallPath that is similar to OutputPath to
differentiate intermediates output paths from installed output
paths.
RelPathString is a poorly defined, undocumented function that is
primarily used to get an install path relative to out/soong to
generate an equivalent install path for Make relative to $(OUT_DIR).
Move it to InstallPath for now, and fix the one remaining user on
OutputPath.
Add a method to create an NDK install path so that ndk_sysroot.go
doesn't have to do it manually with PathForOutput.
Bug: 141877526
Test: m checkbuild
Change-Id: I83c5a0bd1fd6c3dba8d3b6d20d039f64f353ddd5
Move shardPaths and shardTests to android.ShardPaths and
android.ShardStrings for reuse in other packages.
Test: m checkbuild
Change-Id: I868802872c73616b80f56cbf11f959c01a8b793a
Attribute `auto_gen_config` is added to test modules.
Test config will be generated if:
the attribute is not set and AndroidTest.xml doesn't exists
or
the attribute is set to true, whether or not AndroidTest.xml exists.
Test config will NOT be auto-generated if:
the attribute is not set and AndroidTest.xml exists
or
the attribute is set to false, whether or not AndroidTest.xml exists.
Bug: 141684102
Test: build test module with auto_gen_config set to true
Change-Id: I64fb003a83d8c32a967835e5f8d12fe4476043be
sysprop_library now generates srcjar itself, effectively cutting the
implicit dependency from java module to sysprop module.
Bug: 131637873
Test: m {sysprop_library}-dump-api
Test: m (with no arguments) performs API check
Change-Id: Ia11a744e74b6f733ff0e30d194fbba22505ed644
This change introduces a new module type named 'sdk'. It is a logical
group of prebuilt modules that together provide a context (e.g. APIs)
in which Mainline modules (such as APEXes) are built.
A prebuilt module (e.g. java_import) can join an sdk by adding it to the
sdk module as shown below:
sdk {
name: "mysdk#20",
java_libs: ["myjavalib_mysdk_20"],
}
java_import {
name: "myjavalib_mysdk_20",
srcs: ["myjavalib-v20.jar"],
sdk_member_name: "myjavalib",
}
sdk {
name: "mysdk#21",
java_libs: ["myjavalib_mysdk_21"],
}
java_import {
name: "myjavalib_mysdk_21",
srcs: ["myjavalib-v21.jar"],
sdk_member_name: "myjavalib",
}
java_library {
name: "myjavalib",
srcs: ["**/*/*.java"],
}
An APEX can specify the SDK(s) that it wants to build with via the new
'uses_sdks' property.
apex {
name: "myapex",
java_libs: ["libX", "libY"],
uses_sdks: ["mysdk#20"],
}
With this, libX, libY, and their transitive dependencies are all built
with the version 20 of myjavalib (the first java_import module) instead
of the other one (which is for version 21) and java_library having the
same name (which is for ToT).
Bug: 138182343
Test: m (sdk_test.go added)
Change-Id: I7e14c524a7d6a0d9f575fb20822080f39818c01e
Adds a library dependency to each of the dummy system modules created
by testing.go so that any changes in the behavior were detected by
the existing tests which were then fixed.
Bug: 141359858
Test: m checkbuild
Change-Id: Id4442f4aa3931ac93049f3367b96a5b49cc075e1
Add deviceProperties to robolectric tests so they can set
sdk_version. Use Dependency.BaseModuleName() instead of
ctx.OtherModuleName() to get the dependency name to pass to Make
to support prebuilts in libs, which may have a "prebuilt_" prefix
in ctx.OtherModuleName().
Test: m RunLauncherRoboTests
Change-Id: I59a889bd6107b989f336b147d0eaccabef611894
The kythe pipeline has trouble injesting all 6000 files of
framework.jar at once. Shared invocations of the kythe extractor
when javac is sharded to produce multiple smaller kzip files.
Bug: 140426870
Test: no change to build.ninja
Test: m out/soong/.intermediates/frameworks/base/framework/android_common/framework0.kzip
Test: TestSharding in java_test.go
Change-Id: I867db4ef5cb1e7f3ce8359a46aac2c00ed8a8912
* changes:
Remove srcs_lib and srcs_lib_whitelist_pkgs
Remove the automatic dependency to framework-res.apk for R/Manifest
Prepare to be able to put framework-res in srcs
