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
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
Leaving out LOCAL_CERTIFICATE for flattened apex APKs causes
the apkcerts.txt to have empty keys for those APKs, which
confuses the signing tools. Set LOCAL_CERTIFICATE for them.
Also refactor the Certificate support to avoid introducing
duplicated handling for presigned certificates.
Bug: 147765187
Test: m apkcerts-list
Change-Id: Ife07661761cd5a89c9f009b8ce041db4dff9ec54
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
Resource configs should not be deduped when building RROs since it
would be impossible to override some resource configs with the same
value as the default config. Also, aapt2 removes resources that do not
have default configurations. If an overlay attempts to overlay a
non-default configuration without overlaying the default, the resource
will be removed and the value will not be overlaid at all.
Bug: 146227008
Fixes: 119811120
Test: app_test.go
Change-Id: I834a58b18d1e74a0f6b3de3d0523009788787e42
If the install apk name is different than the module name, use
test_config_fixer to update the test-file-name value in the config.
Test: app_test.go
Fixes: 147375216
Change-Id: I2141eeebbb3552995400b45634712306673fd812
Skip the JNI uncompress step for presigned prebuilt test apps. They
don't need it, and they can invalidate the signature. Also, fix the
install partition of prebuilt test apps.
Fixes: 143472191
Test: app_test.go
Test: Converted CtsShimPrivUpgradePrebuilt to bp and checked the
final output apk signature.
Change-Id: Ied7d3576b5db4de40a9ca9e388336229d07212f5
Needed in order to enforce apex_available is set for
everything that gets added to apexes.
Bug: 147364041
Test: apex_test.go
Change-Id: I083ec35283c4c7b5101d00139416d0734b97bab4
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
Make LoadHookContext embed a new EarlyModuleContext instead of
BaseModuleContext to reduce its API surface in preparation for
moving it to run during parsing instead of mutators.
Test: m checkbuild
Change-Id: I1cd3ff3b636e7e24991a9184d7521903473e505a
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
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
It needs to be an implicit input for it to work consistently.
Test: m GooglePermissionControllerUnitTests
Bug: 145011263
Change-Id: Ib71d768e750faa5b577652e79a18d05929bde52f
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
If package_name is set for an android_test module, package names in its
AndroidTest.xml config need to be updated too.
Test: test_config_fixer_test.py
Fixes: 145011263
Change-Id: I52f17ef1d1902364b9bcfec4f6e246bd655dbf09
Dexpreopted files for privleged app prebuilt(android_app_import) are
installed wrongly to /system/app.
To fix this issue, install path is changed to /system/priv-app
in the case that "privileged" flag is true.
Bug: 144945646
Test: build and check dexpreopted files of privileged app are
installed to /system/priv-app
Change-Id: Iec140119f58179a3eb0feeff7af2699fcc855fe7
This change also adds instrumentation_target_package to android_test, so
that the target package name in a test manifest can be easily
overridden.
Fixes: 134624457
Test: app_test.go
Change-Id: Ib8dd703da0038ac76210c92d79e133e37c718122
When an android_app is (directly or transitively) included in an APEX,
multiple variants of the app is created. The problem was that all the
variants were unconditionally installed to the device, which resulted in
duplicated targets. Fixing the problem by not installing the app when it
is included in APEX.
Bug: 144387414
Bug: 144135069
Test: m
Test: OUT_DIR=out DIST_DIR=out/dist build/soong/scripts/build-ndk-prebuilts.sh
Change-Id: Ibcc1096e30bc55a70ddc592490805f447e185eae
If a JNI lib is depended on by an APK that is included in an APEX, the
lib is embedded inside the APK.
This change also fixes a bug that APKs are not mutated for APEXes.
Bug: 144135069
Test: m (apex_test.go amended)
Change-Id: I21ac24412b30c05afc03385655c6b196130dffe3
If a JNI lib is depended on by an APK that is included in an APEX, the
lib is embedded inside the APK.
This change also fixes a bug that APKs are not mutated for APEXes.
Bug: 144135069
Test: m (apex_test.go amended)
Change-Id: Icf490d2701a7ede8bcad7e671fc72be9c8d7c01e
This fixes a bug where unsigned split apks were installed instead of
their signed counterparts.
Fixes: 140795853
Test: app_test.go
Test: m Split && apksigner verify --print-certs
Change-Id: I12cdbcaff9932b6388f920d7e03301d687c3bfdb
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
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
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
Soong has been outputting incorrect Android.mk entries for split apks.
soong_app_prebuilt.mk expects LOCAL_SOONG_BUILT_INSTALLED to contain a
list of <split apk path>:<on device install path> pairs whereas Soong
outputs <split apk path>:$(LOCAL_MODULE_PATH)/<split apk filename> pairs.
This also adds a missing underscore in split apk filenames.
Test: m Split
Bug: 140795853
Change-Id: I3d6506f5e12106174fbbaef34749a272b5e1b90c
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
New property "apps" is added to APEX soong module. This property
configure a list of APKs to package inside APEX payload. For each
android_app module package it's APK into /app/$(android_app module Name)
directory.
Bug: 139906763
Test: m -j
Change-Id: Ic6655f211951af08097c76e157a07ebc52425718
This change introduces two changes required to put
framework-res explicitly in srcs property, without relying on the build
system to specially add framework-res as a dependency to
framework-minus-apex, etc.
1) R.java and Manifest.java generated from aapt were packaged to the file
R.jar directly under the gen directory. With this change, the file
becomes android/R.srcjar under the gen directory.
2) android_app module now overrides OutputFileProducer interface so that
it can recognize "{.aapt.srcjar}" tag to reference the generated srcjar file.
Being able to put framework-res in srcs allows us to pass all the source
files (both in the source tree and the ones generates) via a filegroup.
Previously, the source files could only be passed via the java_library
module type. This caused a circular dependency problem when the java
library was used as an input (src_libs) of the droiddoc module. Using
filegroup eliminates the circular dependency.
Bug: 70046217
Test: m
Merged-In: I9ab6116bcc6fa3da60933d427575463b05ae69b4
(cherry picked from commit 94f37f33ed)
Change-Id: I9ab6116bcc6fa3da60933d427575463b05ae69b4
Martin Stjernholm