Introduce `commonAttributes` & `fillCommonBp2BuildModuleAttrs used in
CreateBazelTargetModule
Adapt `bp2BuildInfo` to use `commonAttrs` instead of `Name`.
And thus also all downstream users of `CreateBazelTargetModule`.
As initial user, the Soong `required` property will be
translated to Bazel's `data`.
Bug: 198146582, 196091467
Test: build_converstion_test.go:TestCommonBp2BuildModuleAttrs
Test: go test
Test: mixed_{libc,droid}.sh
Change-Id: Ib500e40f7e2cb48c459f1ebe3188962fc41ec124
There are cases where two modules try to install the same test data
into CTS, which results in collisions when CTS puts the data for all
tests in the same directory. Add a flag that allows enabling a
per-testcase directory for an individual test for all test suites.
Bug: 193168159
Test: cts-tradefed run commandAndExit CtsBionicTestCases
Change-Id: If034723e8fe937ca71d3e2d39b7d46702e41bc8c
invalid with a message.
This will allow propagating any error from the deapexer module for
prebuilt APEXes to the location where the dex jars get used. It's only
at those points that we can raise errors about not being able to
extract files from the deapexer modules if they are invalid, and this
way we avoid encoding knowledge there about why they may be invalid.
To keep the refactoring limited it intentionally does not change any of
the existing logic for when dexJarFiles are set or not (non-nil vs nil
prior to this change), although there may be opportunity to use this
for more conditions when dex jars aren't available.
The refactoring is also not extended to
dexpreopt.ClassLoaderContextMap.
Test: m nothing
Bug: 192006406
Change-Id: I68986dccd9a9b3fee4d24caa1947ea17a36caedc
dep.OutputFile().Path() can panic if the OutputFile
is invalid, so move more of the code into the check
for validity. This changes the go crash into a
build error.
Bug: 158624492
Test: Apply the patchset 1 of ag/11815659, lunch aosp_x86_64-eng, m
Change-Id: Ic8a728be1b570ac73be7b2b9461676f9fd99c266
These properties specify libraries that cannot be implicitly inferred by
Soong. If these properties are added to Android.bp, this can only be for
the reason that there is a <uses-library> tag in the manifest which is
unknown to the build system. Adding them to the manifest_fixer doesn't
make sense: if they are not in the manifest, they should be removed from
Android.bp as well.
Bug: 132357300
Test: $ lunch aosp_cf_x86_64_phone-userdebug && m && launch_cvd
$ adb wait-for-device && adb root && adb logcat \
| grep -E 'ClassLoaderContext [a-z ]+ mismatch'
# empty grep output, no errors
Change-Id: Ic6eb5268a954ef3be7f06a181ec72af99000c547
A performance improvement for bp2build as Blueprint/Soong no longer have
the overhead of additional modules. The creation of these modules
results in:
* traversal of additional modules for each subsequent mutator
* synchronization over a go channel to collect newly created modules:
https://cs.android.com/android/platform/superproject/+/master:build/blueprint/context.go;l=2594,2600;drc=1602226f23181b8c3fbfcaf3358f0297e839d7d3
We avoid both of these by storing the information directly in the
underlying module.
Also as a fringe benefit, removes some necessary boilerplate for
conversion.
For benchmarks, reduces runtime ~1% for 1% converted, ~24% for 100%
converted. See more: go/benchmarks-for-https:-r.android.com-1792714
Test: ran benchmarks/tests in bp2build
Test: build/bazel/ci/bp2build.sh
Change-Id: Ie9273b8cbab5bc6edac1728067ce184382feb211
Previously manifest_fixer used a naive way to distiniguish optional libs
from required ones: it checked if a library is on the list of optional
compatibility libraries. This works for compatibility libs, but not for
other libs.
Now we properly track optionality through all stages of the build,
starting with the addition of the library as a dependency (here's where
the `uses_libs`/`optional_uses_libs` distinction kicks in), store it in
dependency tag and propagate to class loader context, and from there to
the manifest_fixer.
The tests have been updated accordingly.
Bug: 196377222
Test: lunch bertha_x86_64-userdebug && m droid dist cts mts
Change-Id: I3631ce59ebe47116ce7a9b3d33a86f636846ef0f
A Java module may depend on a stub library. In that case an additional
dependency on the implementation library is created, and it is used to
add the implementation library to class loader context. We should not
attempt to add the stubs library as well (previously the attempt to add
it happend after the implemention was added to CLC, to the attempt was
unsuccessful).
Raise an error if someone tries to add the same library with different
build/instal paths.
Also, rename local variable `implicitSdkLib` to `sdkLib` to better
reflect its meaning.
Bug: 193425964
Test: $ lunch aosp_cf_x86_64_phone-userdebug && m && launch_cvd
$ adb wait-for-device && \
adb root && \
adb logcat | \
grep -E 'ClassLoaderContext [a-z ]+ mismatch' -C1
# empty output, no errors
Change-Id: I01c1bdd23f9d118d891d0b806e7e3b4d78896a34
Changes:
- Cut off "prebuilt_" prefix from `dep`, not `libName`, because `dep` is
used to replace library name in `usesLibraryProperties`, and these
properties are specified without "prebuilt_" prefix.
- Do not remove "prebuilt_" prefix on the return value of
`ProvidesUsesLib()`: this boils down to `provides_uses_lib` property
which is specified without the prefix.
Bug: 193425964
Test: $ lunch aosp_cf_x86_64_phone-userdebug && m && launch_cvd
$ adb wait-for-device && \
adb root && \
adb logcat | \
grep -E 'ClassLoaderContext [a-z ]+ mismatch' -C1
# empty output, no errors
Change-Id: I6cb65040027023d12ca0bc132d60c2c245174c40
Bug: 188179858
Test: compare dexpreopt_config.zip files from
1. TARGET_BUILD_UNBUNDLED_IMAGE=true m dexpreopt_config_zip
2. m dexpreopt_config_zip
(note that m clean should run between steps)
Change-Id: I36a6e8b10b9922cc5522accaf90af1aa05049a86
Refactors the vendor snapshot support to use the LinkableInterface
so that support can be extended to Rust. This CL does not add
vendor snapshot support for Rust; that is left for a follow-on CL.
Bug: 184042776
Test: m nothing
Change-Id: Id0c4970ca00053484a52677d182153cbc454c301
Previously, SdkSpec was constructed only from the user string. It didn't
make use of the Config struct where information about the latest stable
SDK version, etc. is recorded. As a result, the build system couldn't
check if the sdk version "current" is referring to the in-development
(i.e. not-yet-frozen) SDK version or the latest stable version.
"current" was always assumed to be in-development (IsPreview() returns
true) even when Platform_sdk_final == true.
As the first step for fixing that, this change requires
android.EarlyModuleContext to be passed when constructing SdkSpec from
the user string.
In the following changes, "current" will be mapped to either
FutureApiLevel (10000) or one of the FinalApiLevels() depending on
whether the platform SDK was finalized or not.
Bug: 175678607
Test: m
Change-Id: Ifea12ebf147ecccf12e7266dd382819806571543
From an ART perspective, calling module-lib APIs requires the
ability to bypass hiddenapi enforcement entirely. This CL ensures
that if an APK compiles against module-lib APIs, it will be able
to call those APIs. Currently, compiling against module-lib APIs
is not safe because APKs that are subject to hiddenapi protection
will crash at runtime.
Bug: 181309531
Test: made NetworkStackNext compile against module-current, and:
Test: aapt dump xmltree .../NetworkStackNext.apk AndroidManifest.xml | grep usesNonSdk
Change-Id: I5ca3328c64412078d803e0e3ffa1d8383602416f
SdkSpec.Version was an int type. Now it becomes ApiLevel type which
is a better abstraction of the version (or api level).
Bug: 1655587
Test: m
Change-Id: I4d67b9b9eae45f653b6af4f5b73da9e091b3dfab
... in preparation for making the handling of sdk versions consistent
across java and cc modules.
Bug: 175678607
Test: m
Change-Id: I598f0454bce9b7320621022115412fbe97403945
Otherwise the check fails, as it depend on non-existent dexpreopt.config
files. This CL fixes broken build cf_x86_phone-userdebug_coverage.
Bug: 183931403
Bug: 132357300
Test: forrest build for cf_x86_phone-userdebug_coverage.
Change-Id: Id3ffeb742c1b82c677795fa701a7b5a867eabbbd
This is a follow-up for https://android-review.googlesource.com/1614807.
Bug: 132357300
Test: lunch aosp_cf_x86_64_phone-userdebug && m
Test: lunch qemu_trusty_arm64-userdebug && \
m out/soong/.intermediates/packages/apps/DocumentsUI/DocumentsUI/android_common/DocumentsUI-unsigned.apk
Change-Id: I84c5d171bd976f35f342abd94b592506c71e4b1d
Previously there were two different scripts that did similar things:
1) build/soong/scripts/manifest_check.py
2) build/make/core/verify_uses_libraries.sh
Both scripts extracted <uses-library> tags and `targetSdkVersion` from
the manifests of Java modules, but 1) worked for XML manifests, and 2)
worked for APKs. This CL reimplements the functionality from 2) in 1),
so that one script can handle both XML manifests and APKs.
Bug: 132357300
Test: lunch cf_x86_64_phone-userdebug && m && launch_cvd \
adb wait-for-device && adb root && adb logcat \
| grep -E 'ClassLoaderContext [a-z ]+ mismatch'
# empty grep output, no errors
Change-Id: Id1b66e4f3f30f307dba70cb111c7571762cb546a
Modules that are not available for platform are developed with
updatability in mind, and do not require manual approvals.
Bug: 181223240
Test: checkbuild
Change-Id: I10b91053b3ef5a9ff5400d9d7a68fae3144a671c
They should have had `android:"path"` tags attached so that users can
point them to filegroup modules.
Test: app_test.go & app_import_test.go
Bug: 182175153
Change-Id: I5580408488ffe5fc12c869cbfb7a468713dcbc96
Without dexpreopt the check is not necessary, and although it is good to
have, it is difficult to maintain on non-linux build platforms where
dexpreopt is generally disabled (the check may fail due to various
unrelated reasons, such as a failure to get manifest from an APK).
Bug: 181570790
Bug: 132357300
Test: m nothing
Change-Id: Ie012690e8f047ae9256e26565d162c19af4e8921
Previously `provides_uses_lib` property affected only those
<uses-library> dependencies that are automatically deduced by Soong as
implicit Java SDK libraries reachable from the `libs` property. Other
<uses-library> dependencies that are explicitly added in `uses_libs` and
`optional_uses_libs` properties ignored `provides_uses_lib`.
As TestUsesLibraries shows (see the TODOs), Soong behaviour is still
incorrect in two ways (to be addressed in follow-up CLs):
- `uses_libs`/`optional_uses_libs` are passed to manifest_fixer
- verify_uses_libraries check is based on `uses_libs`/
`optional_uses_libs`, and not on the CLC as it should be
Bug: 132357300
Test: m nothing
Change-Id: I0ec7aab9dcd44554d1a79ddd382491c562266fa3
Use the java resources jar as the dex jar when building apps that
have no code.
Also remove maybeStrippedDexJar, the dex jar is never stripped now.
Fixes: 176305357
Test: TestAppJavaResources
Change-Id: Ic8b1165bd35d71237d307e7f5f895764e203a10d
The new mode is enabled with environment variable
RELAX_USES_LIBRARY_CHECK. If the variable is set to true, then a
verify_uses_libraries check failure does not fail the build, instead it
sets a special compiler filter "extract" for dexpreopt, which means that
the DEX file will be extracted, but it won't be compiled to native code.
Class loader context will be set to empty in this case (not &, as it is
going to be deprecated soon).
If the variable RELAX_USES_LIBRARY_CHECK is unset or set to something
other than "true", then the old behaviour of the verify_uses_libraries
check is preserved.
The intended use case for this flag is to have a smoother migration path
for the Java modules that need to add <uses-library> information in
the build files. The flag allows to quickly silence build errors. This
flag should be used with caution and only as a temporary measure, as it
masks real errors and affects performance.
verify_uses_libraries check is reworked so that it writes the error
message to a status file (which is used instead of the former timestamp
file). Currently the stored error message is not used, but it may be
used later to produce a warning. Dexpreopt command checks if the status
file exists and is nonempty; if that is the case, then compiler filter
is set to "extract".
Bug: 132357300
Test: Manually add some mismatch between the libraries in the Android.bp
and Android.mk files for dexpreopted apps, build with
RELAX_USES_LIBRARY_CHECK=true and obsserve that the build doesn't
fail and they are compiled with compiler-filter "extract".
Unset RELAX_USES_LIBRARY_CHECK and observe that the build fails.
Change-Id: Ibb5d993a25b1df1d2e70b7d5aafc6997f9d64e67
This is needed for Java libraries that are <uses-library> dependencies
of Java libraries and apps defined as Make modules. Each dexpreopted
module in Make generates a dexpreopt.config file, which incorporates
information from its dependencies' dexpreopt.config files. For
dependencies that are Make modules their dexpreopt.config files are
generated by Make, and for Soong modules they are generated by Soong.
Since Soong doesn't know which libraries are used by Make, it generates
build rules for a superset of the necessary libraries.
Bug: 132357300
Test: lunch aosp_cf_x86_phone-userdebug && m
Change-Id: I325b1037658736ee3c02450b08c00eca1a175962
The removed API has been unused since https://r.android.com/1533342
(except for unit tests).
Changes in the unit tests reflect the change of API in
https://r.android.com/1533342: early errors caused by unknown library
paths at CLC construction time have been replaced with late errors at
the time of CLC validation.
Bug: 132357300
Test: m nothing
Change-Id: I739c7c41b6f882b7e28cdd6acd05961d754d8687
dexpreopt doesn't strip dex files from the input jar anymore, so there's
no point returning the input jar path untouched.
Test: m nothing + TreeHugger
Change-Id: I8fde6cdc19e85a2fbc946513696417b945c5de0f
This method logically belongs with other UsesLibraryDependency methods,
as it is used in the same context when computing class loader context.
Previously it was part of Dependency interface, which doesn't cover SDK
libraries. We do not currently have the necessary information for
SdkLibraryImport (so ClassLoaderContexts() returns nil for it), but we
do have it for SdkLibrary (via Library).
Bug: 132357300
Test: m nothing
Change-Id: I56437f260efc6a9af3f45b334e84e915244ccce1
This fixes a bug where android_app_import or android_test_import without
a matching variant or a default apk property value breaks the build.
Test: app_test.go
Fixes: 152343232
Change-Id: I8215aa1a6dad74b503eaa1169a64f8c30dda287c
Enable the RuleBuilder and RuleBuilderCommand methods to access
the BuilderContext by passing it to NewRuleBuilder instead of
RuleBuilder.Build.
Test: genrule_test.go
Test: rule_builder_test.go
Test: m checkbuild
Change-Id: I63e6597e19167393876dc2259d6f521363b7dabc
This patch reworks the approach introduced in
https://r.android.com/1450819. That patch based the decision which
libraries should be added to the manifest <uses-library> tags by the
manifest_fixer on the "shared" status of the library.
That approach is incorrect for two reasons:
- It doesn't make sense to have a non-shared library in class loader
context ("shared" libraries are those specified in
frameworks/base/data/etc/platform.xml, and they are the only ones
that PackageManager knows about).
- It doesn't make sense to add anything but the top-level of the
class loader context tree to the manifest, because this part of the
tree is flattened to a sequence, and PackageManager cannot restore
it to the previous tree shape (there is an information loss).
This patch removes the "shared" bit of information from class loader
context elements and assumes that all libraries that end up in class
loader context are shared. Consequently, only the top-level libraries
should be passed to manifest_fixer.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Bug: 168686456
Change-Id: I902690f0f38f1047fa79cf6ccbe956077eceaab0
Storing ndkKnownLibs prevents multiple tests from running in parallel
as one may be writing to the list while another is reading from it.
Store it in the config so each test has its own copy.
Test: go test -race ./apex
Change-Id: Iba57c9494012c9e0ae9e5ffaa63b9b2bd2c77492
When adding a subcontext in a class loader context tree, there are two
possible cases: 1) the root of the subcontext is itself a <uses-library>
and should be present as a node in the tree, or 2) the root is not a
<uses-library>, but some of its dependencies are -- in that case they
should be disconnected from the root, and the resulting forrest should
be added at the top-level.
Example:
1) C is a <uses-library>:
A
├── B
└── C
├── D
└── E
└── F
2) C is not a <uses-library>:
A
├── B
├── D
└── E
└── F
Before the patch subcontexts for transitive dependencies were added
before the subcontext for the direct dependency (even if it was a
<uses-library>, resulting in case-2 hierarchy when case-1 should have
been used. Previosuly this didn't matter because class loader context
was a flat set of libraries, but now it matters because class loader
context is a tree.
This patch changes the order in which libraries are added, so that
direct dependencies are added before transitive ones. The context adding
method now accepts an "implicit root" parameter, so that when adding
transitive dependencies it can check if the corresponding direct
dependency is a <uses-library> and already present in the context.
Partially constructed class loader context is now propagated top-down
into aapt.buildActions, so that the method can use existing part of the
context to decide where the missing part should be connected.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: I649aff9e27494306885a4f4fc90226c399636b57
The old representation consisted of a list of libraries (UsesLibraries),
a list of optional libraries (OptionalUsesLibraries) and a mapping from
library name to its build/install paths (LibraryPaths). The separation
into lists and map was necessary because of special handling of
compatibility libraries, which is now unified with normal libraries.
The new representation is a mapping from target SDK version to a tree
structure ClassLoaderContext. Each node of the tree represents a library
and contains library name, build/install paths and a slice of
subcontexts for dependencies. The same library may occur in the tree
multiple times in case it is a dependency of multiple libraries. The
order in which libraries are added matters (the resulting tree shape may
be different).
Test results have to be updated, as the resulting <uses-library> list is
reodered (previously it was a sorted list of map keys, and now it is
formed by a depth-first preorder traversal of the class loader tree).
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Bug: 168686456
Change-Id: I11be8cd2967f004fd58753d7c5fb99fed179cd63
The version in the tag is the SDK version that in which compatibility
library was added as a separate libary. Using distinct tags makes it
possible to differentiate between dependencies for different SDK
versions (this will be needed in subsequent CLs).
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: I72296c05d6649e811ddc701aaeb84f91d1ba66cb
Targets[Android][0] is not always the first, preferred target. Add a new
field to config to provide the correct target and begin to use it.
Test: m nothing
Test: build/soong/scripts/build-ndk-prebuilts.sh
Fixes: 156980228
Change-Id: Ib56f52424ebf47f3eee6ac62b9fd9eca2919d63a
Support GetDirectDepsWithTag on JNI deps by replacing the
jniDependencyTag type with a jniLibTag value.
Test: app_test.go
Change-Id: I8d66a5d3f433562e131a1fbafce75891d1b094dd
A global variant was used to store the global mapping between
modules and APEXes. Replace it with storing pointers to APEX
contents inside each module so that they can query the contents
of any APEXes they belong to.
Bug: 146393795
Test: all Soong tests
Test: single line change to build.ninja host install dependency ordering
Test: no Android-${TARGET_PRODUCT}.mk, make_vars-${TARGET_PRODUCT}.mk or late-${TARGET_PRODUCT}.mk
Change-Id: Id2d7b73ea27f8c3b41d30820bdd86b65c539bfa4
A host target is considered as being cross-compiled when the target
can't run natively on the build machine. For example, linux_glibc/x86_64
is a non-cross target on a standard x86/Linux machine, but is a cross
host on Mac. Previously, whether cross or not was a static attribute of
an OsType. For example, Windows was always considered as cross host,
while linux_bionic was not. This becomes a problem when we support more
host targets like linux_bionic/arm64 which should be cross-host on
standard x86/Linux machines.
This change removes HostCross from the OsClass type and instead adds a
property HostCross to the Target type. When a target is being added, it
is initialized to true when the target can't run natively on the current
build machine.
Bug: 168086242
Test: m
Change-Id: Ic37c8db918873ddf324c86b12b5412952b0f2be2
The test case I removed is invalid. The codename has had its int
assigned, but the config claims it is not final.
If this ever does need to be supported it's just a matter of making
sure the Q -> 29 mapping (or whatever) in the finalized codenames map
in android/api_levels.go.
Test: treehugger
Bug: http://b/154667674
Change-Id: I4f42ec2fd4a37750519ee3937938a1c65b6bb1e8
Previously default install path was provided only for comatibility
libraries that are added explicitly via `uses_libs`/`optional_uses_libs`
properties. This didn't take into account compatibility libraries that
are added by Soong when it computes transitive closure of SDK library
dependencies. As a result, install path in such cases remained unknown,
and the corresponding compatibility library was omitted from class
loader context, which caused 'ClassLoaderContext shared library size
mismatch' errors at first boot on device.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: If661272f46803299c8640f7f5ef161c8217d07e4
The previous property was boolean-valued and provided only the
information whether the library should be treated as <uses-library>
by Soong. The new property is an optional string, which is the name of
the <uses-library>. The name can be different from the module name, as
in the case of "qcrilhook" module which provides <uses-library>
"com.qualcomm.qcrilhook".
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: I65b68e6f7c420ab9c443a76de4c917d31fcd8c8f
Allow default install paths only for compatibility libraries. For other
libraries that are explicitly specified in `uses_libs` and
`optional_uses_libs` unknown install path should be an error.
Bug: 132357300
Test: lunch cf_x86_phone-userdebug && m
Change-Id: I2209c90a939a8aa46c42e13bb42d09c07e4d0895
Extend usesLibraryProperties with a boolean is_uses_lib property and
move these properties from java.AndroidApp to java.Module to allow
java.Library modules set the new propery and be recognized as
<uses-library> by Soong.
Bug: 132357300
Test: lunch cf_x86_phone-userdebug && m
Change-Id: I01cd5e0da3dd543c1c0597249d37d0914b213ca7
For some dependencies, like stubs, the SDK library may not be found at
build time (either because the implementation library is not among the
dependencies of the dexpreopted module, or because it's part of a
prebuilt, or because it's missing from the build altogether). In such
cases dexpreopt is useless, because dex2oat does not have access to the
full classpath (unless the &-classpath is used). Therefore do not
dexpreopt in such cases.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: If289088cfd103011ccb16165e95a97b30fd31b81
Previously only the names were collected, and later used in the
manifest_fixer to add missing <uses-library> entries to the manifest.
Now we also need to collect build-time and on-device paths, to be used
in class loader context for dexpreopt. This commit only collects paths,
but does not pass them to dexpreopt yet.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: I34b229ee68f16ba215ba03770feadb4d890ec2bf
This allows the android stubs to depend on framework-res' exportPackage
without special-casing inside the build system.
Bug: 161214753
Test: depending on this output in a followup CL
Change-Id: I8c5d17540d2624974983d73e56ba17898505dba8
We want to support a compile_dex property for java_import. This splits
dex-related properties into a dexer struct which can be embedded in
relevant modules.
Test: m
Test: soong tests
Bug: 160455085
Change-Id: If56a51dac43f630d49483a36db29cd50e9ccd529
The implementation before libraryDependencyTag was added failed to
include some JNI libraries into apps because it did not handle
sharedExportDepTag, earlySharedDepTag or lateSharedDepTag.
Also fix a bug in cc.*Module.IsNdk that was comparing "liblog.ndk"
against "liblog" and incorrectly returning false that would have
caused NDK libraries that now pass the check above to incorrectly be
packaged into the APK.
Bug: 162437057
Test: m checkbuild
Change-Id: I02fb745abb5cace2b4e5bfff2f35cef6d2e0a4ff
dependencyTag uses a set of predefined tags to identify different types
of dependencies. There are already multiple bits of metadata stored
in the dependency tag (Library, Shared, ReexportFlags), and supporting
them all requires a combinatorial explosion of predefined tags and
causes issues when using equality comparisons if a new bit of metadata
is added.
Add a new libraryDependencyTag type that will contain the metadata
bits, and replace the quality comparisons with checks on the metadata
bits.
There are 5 TODOs where modifying the checks identified problems with
the existing checks. These were left in place to produce identical
build output and will be fixed separately.
Bug: 162437057
Test: no change to build.ninja or {Android,make_vars,late}-${TARGET_PRODUCT}.mk
Change-Id: I72d4207dcf381c07c92e00e5a03968ebb5ed8d30
Update android_app_set to use word install rather than master for
android_app_sets, this better matches the phrasing used for apex_set.
See https://source.android.com/setup/contribute/respectful-code for
reference
Bug: 161896447
Test: m nothing
Change-Id: I429e7f8b16c42c10ad4d9543110f5ce814a893b1
Add a rule to build a zip containing the lint reports from transitive
dependencies for apps, and pass it to Make.
Bug: 153485543
Test: m TARGET_BUILD_APPS=Gallery2 lint-check
Change-Id: I523c09016251377ff89d76084769be7401b95425
This relands I70a43c2163709afc90262d74f975ce14a556cf55 with a property
to disable renaming of the package in resource files to support
compatibility with packages that would be infeasible to change without
causing failures.
When rename_resources_package is true, uses aapt2 flag to change the
package name encoded in the resources table for override apps.
Test: app_test.go
Bug: 147434671
Change-Id: I3a051ddeb5979f9c0838d176656a1b5cf2677a9b
Pass a list of unstripped JNI libraries to Make so that they can be
installed into the symbols directory.
Bug: 159726429
Test: forrest
Change-Id: Ieb4bffbb3d0a09f476da011399c5b8b1611929d7
* changes:
Make native_coverage clause work with ClangCoverage
Introduce product variables to select Java code coverage paths in Soong.
Rename native code coverage paths product variables in Soong.
Make uses NATIVE_COVERAGE to enable gcov coverage and CLANG_COVERAGE
to enable clang coverage. NATIVE_COVERAGE is translated to the Soong
Native_coverage product variable which triggers the native_coverage
clause in Android.bp files. The clause also needs to be triggered
for CLANG_COVERAGE.
Rename the existing Native_coverage product variable to GcovCoverage,
and regenerate Native_coverage when either GcovCoverage or
ClangCoverage are set.
Also remove NativeLineCoverage, it wasn't doing anything differently
than Native_coverage.
Bug: 159059537
Test: m checkbuild
Merged-In: I215124a9b35a2ad50ad562079d392e3d33da11f4
Change-Id: I215124a9b35a2ad50ad562079d392e3d33da11f4
Soong and Make have no ways to figure out what splits will be outputted
from a given android_app_set, so it's impossible for them to provide
full PACKAGES.$(LOCAL_MODULE).CERTIFICATE entries, which are required to
build a final apkcerts.txt. This change makes extract_apks produce
apkcerts.txt files for each input modules instead. The Make-side
counterpart of this change merges all local apkcerts.txt into a final
one.
Fixes: 160119159
Test: main_test.go
Test: m apkcerts-list
Merged-In: I321e80fd636a955213761f56a3ac64bfe7f7f7c0
Change-Id: I321e80fd636a955213761f56a3ac64bfe7f7f7c0