If embed_notices or ALWAYS_EMBED_NOTICES is set, collect NOTICE files
from all dependencies of the android_app, merge them with the app's own
one (if exists), transform it to HTML, gzip it, and put it as an asset
in the final APK output.
Bug: 135460391
Test: app_test.go
Change-Id: I52d92e2fd19b3f5f396100424665c5cc344190d8
Corrects an error message that refers to no_framework_libs.
Removes any tests that use no_framework_libs:true where possible as
there are duplicate tests for sdk_version:"core_platform". Otherwise,
switches them over to use sdk_version:"core_platform".
Bug: 134566750
Test: m droid
Change-Id: I41abe1a49f5c744e3393ca9cdf0c41888f810c9f
Don't pass --legacy by default, it is rarely necessary and converts
some errors into warnings that crash at runtime. The modules that
need it have had --legacy added to aaptflags.
Bug: 135597368
Test: m java
Change-Id: Ib05a07ead4084dd32ba28df26708d81bb53f2f2a
--legacy will soon no longer be passed by default to all aapt2
compiles. Allow it to be specified in aaptflags by passing it to
aapt2 compile when it is present and filtering it out from the
flags passed to aapt2 link.
Bug: 135597368
Test: m java
Change-Id: Ib65d1a9b7c32ae4ff5ab6f58e66aedfb5f296712
This was preventing us from actually using system module dependencies
from Make.
Fixes: 135679136
Test: EXPERIMENTAL_JAVA_LANGUAGE_LEVEL_9=true m legacy-performance-test-hostdex
Change-Id: Ic51c30d09cf39e35f2fe5f534a23273f450d9138
Instead of just depending on the main .art file (boot.art, etc), also
expose the dependencies to the .oat/.vdex files (boot.oat/boot.vdex),
and all of the module files that get implicitly loading (boot-ext.*,
boot-framework.*, etc)
This is necessary for RBE, where the rule only gets the files that it
depends upon.
Test: treehugger
Test: build a system image with RBE
Change-Id: I0c7051f18582f1891d3398b46763b1521e4326c8
Where possible this duplicates any tests that use no_framework_libs:true
with ones that use sdk_version:"core_platform". If not possible (e.g. in the
default targets included in java/testing.go) it switches some to use
sdk_version:"core_platform" to ensure that there is no regression in the
behavior of no_framework_libs:true.
Follow up changes will switch all usages of no_framework_libs:true over
to use sdk_version:"core_platform" at which point no_framework_libs will be
removed.
Bug: 134566750
Test: m droid
Change-Id: I42cb181f628b723c8f32a158ae4752b4c83365ae
Corrects an error message that refers to no_standard_libs.
Removes any tests that use no_standard_libs:true where possible as
there are duplicate tests for sdk_version:"none". Otherwise, switches
them over to use sdk_version:"none".
The androidmk mapping from LOCAL_NO_STANDARD_LIBRARIES to
no_standard_libs has also been removed. There was little point in
updating the tool to map it through to sdk_version:"none" as there are
only a couple of places where it is used, in art's test running mk
targets and in some unbundled packages to work around some limitation
in .mk based build.
Bug: 134566750
Test: m droid
Change-Id: I6413c9b1fe3e63b93753a6a017d2981e32b7e013
Explicitly pass the list of tests as LOCAL_ROBOTEST_FILES, and
support sharding the list of tests into multiple test runners.
Also filter out BaseRobolectricTest.java, which covers the only
use of LOCAL_ROBOTEST_FILES in Android.mk files.
Bug: 133878985
Test: m RunSettingsLibRoboTests runs the same number of tests before and after
Test: m RunSettingsLibRoboTests runs the same number of tests when sharded
Change-Id: Id85ffe03c98e722303eaa6def17812ed2244c6a6
Merged-In: Id85ffe03c98e722303eaa6def17812ed2244c6a6
Explicitly pass the list of tests as LOCAL_ROBOTEST_FILES, and
support sharding the list of tests into multiple test runners.
Also filter out BaseRobolectricTest.java, which covers the only
use of LOCAL_ROBOTEST_FILES in Android.mk files.
Bug: 133878985
Test: m RunSettingsLibRoboTests runs the same number of tests before and after
Test: m RunSettingsLibRoboTests runs the same number of tests when sharded
Change-Id: Id85ffe03c98e722303eaa6def17812ed2244c6a6
Where possible this duplicates any tests that use no_standard_libs:true
with ones that use sdk_version:"none". If not possible (e.g. in the
default targets included in java/testing.go) it switches some to use
sdk_version:"none" to ensure that there is no regression in the
behavior of no_standard_libs:true.
Follow up changes will switch all usages of no_standard_libs:true over
to use sdk_version:"none" at which point no_standard_libs will be
removed.
Bug: 134566750
Test: m droid
Change-Id: I5f0fd3daa980f6b223abe454cba7f25a97a39d7a
Previously, different parts of the build used different sources of
information about the SDK (i.e. the default libraries) against which
a Java module aimed at the device was built. Some used the sdk_version
property, others used the no_standard_libs or no_framework_libs, some
used a combination of all three.
That lead to inconsistent handling in the code, e.g. some parts treated
no_standard_libs: true as implying no_framework_libs: true and others
did not, and also in the build files, e.g. some modules specified
no_framework_libs: true and sdk_version: "system_current" which makes
no sense, or no_standard_libs: true and sdk_version: "core_current"
which are inconsistent.
This is the first step in a refactoring to simplify the sdk selection
process by replacing the no_standard_libs/no_framework_libs properties
with some extra options for the sdk_version property. This change
consists of:
1) Extra functions sdkContext to access the no_standard_libs and
no_framework_libs properties.
2) Extra field/functions in sdkDep to store and access the value of
no_standard_libs/no_framework_libs.
3) Changes to decodeSdkDep(...) to pass the values of the no_...
properties through to the returned sdkDep.
4) Change all code that accesses the no_... properties directly to
call decodeSdkDep(...) to get an sdkDep object and then accessing
the values of the no_... properties from there.
The accessor functions on sdkDep are called has...() rather than
no...() as most callers of the methods invert the value anyway and
!no...() is harder to reason about than has...().
The hasFrameworkLibs() function returns true if and only if
no_standard_libs and no_framework_libs are false. That is consistent
with all but one usage of the no_framework_libs property and that is
not affected by it.
Bug: 134566750
Test: m droid
Change-Id: I196e3304e8bd802fb154e897397b0dd337f868e2
Exempt-From-Owner-Approval: Colin has already given +2 modulo some
minor nits and this blocking other changes.
The build generates a file out/soong/hiddenapi/hiddenapi-flags.csv
which is used by the hiddenapi-blacklist tests in cts/tests/signature.
The generation is done at the ninja level and so is not accessible from
the soong layer that runs on top. This change adds the hiddenapi-flags
module type which makes the file accessible from other soong modules.
Bug: 122332514
Test: atest -p cts/tests/signature
Change-Id: If38c8a8ffca110f2ae01f97f19a2740ca3fde1b7
Exempt-From-Owner-Approval: Colin has already reviewed and only had minor
nits and this is blocking other changes.
Unbundled builds may not have definitions of shared libraries, and
they are not dexpreopted so the dependencies are not used anyways.
Test: manual
Change-Id: I89ad92f3b073422734f824ac3a8a3b9baf995ccb
* changes:
Consolidate *MutatorContext and ModuleContext into BaseModuleContext
Add test for missing defaults modules with AllowMissingDependencies
Capture missing dependency error rules
Share buildDir for android/soong/android tests
Reimplement AddMissingDependencies
Add GenerateAndroidBuildActions to DefaultsModuleBase
