Call ctx.InstallFile on the primary install file last so that the
primary install file can depend on the extra install files, and so that
the primary install file can be inferred from the last installed file.
Add missing ctx.InstallFile calls for the dexpreopt and hostdex outputs.
Fix the install subdirectory for modules installing to the testcases
directory.
Bug: 204136549
Test: m checkbuild
Change-Id: I7edd7647be27439d3ca0ecc589ca5e89d4ba8474
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
