After this change, there is a clear separation between tests that are
related to dexpreopt and tests that are not. The former uses
PrepareForTestWithDexpreopt, while the latter uses
PrepareForTestWithJavaDefaultModules. The benefit is that the latter
will no longer affected by any dexpreopt changes.
Bug: 280776428
Test: m nothing
(cherry picked from https://android-review.googlesource.com/q/commit:b95998be731406209f18fab764b96421a17ab4c9)
Merged-In: Ib957765b9287d51c082e0a33cee17a6bb56daeef
Change-Id: Ib957765b9287d51c082e0a33cee17a6bb56daeef
so that Vendor APEXes don't embed the LLNDK prebuilts (which are just
stubs of LLNDK libraries).
Bug: 280697209
Bug: 277403349
Test: m nothing (soong test)
Merged-In: I9e6c123e73fa0ab56d8494a01652ee32a9b6a6cd
Change-Id: I9e6c123e73fa0ab56d8494a01652ee32a9b6a6cd
(cherry picked from commit e3f0281b88)
Apexer rule with symbol files causes "no build rule" error when the apex
is replaced with prebuilt.
Bug: 251299786
Test: m checkbuild (presubmit)
Change-Id: I7390f72c321beaeb49fcee4e02a219c07f184664
Teach rustc to generate object files instead of a linked executable
for binary and shared library crates. This lets us skip the lengthy
Rust compilation phase when only the C++ dependencies of these crates
have changed.
This works using a Python script that replaces the linker invoked by
rustc and converts the linker command line into a rspfile that can be
used during the link phase. The script makes certain assumptions about
how rustc invokes the linker, but since we control the version of Rust
we use, we can update the script if those assumptions ever break. I've
asked the Rust developers about adding an official way to do this so
hopefully we won't need to rely on this hack in the future.
The rustc rule for Kythe has been altered to pass linker=true, somewhat
consistent with the main rustc rule, which now doesn't invoke the actual
linker either. `m xref_rust` still succeeds, but hopefully we can find
someone who knows more about the rest of the Kythe pipeline who can let
us know whether it should still work. Otherwise, let's use this CL as
an opportunity to find out whether the rest of the pipeline is happy
with linker=true, since otherwise we will find it hard to maintain the
Kythe rule in the future.
Change-Id: Ifb9c8689c1bd78c0afcf6fdfd111140d20377536
Updatable apexes should set a min_sdk_version that is not current. This
enforcement does not exist today, but will soon be added to the build
system. In preparation for that, cleanup the min_sdk_version property
used in this unit test.
Test: go test ./apex
Bug: 221087384
Change-Id: I8a163595f85cb0f8dabccc3321ef210215675714
Updatable apexes should set a min_sdk_version that is not current. This
enforcement does not exist today, but will soon be added to the build
system. In preparation for that, cleanup the min_sdk_version property
used in this unit test.
Test: go test ./apex
Bug: 221087384
Change-Id: Idabc4c6f20e134b38ed0ae3ce68f6b7d54d7a13c
There are no tests to verify the generated action for the canned fs
config entries, so add some.
Also update the prop's docstring to reflect the actual logic.
Bug: 275209284
Fixes: 275280970
Test: soong tests
Change-Id: I37f2a8640bf4c307068a77db7a635c9bbeb9f38f
For vendor apexes, use_vndk_as_stable: true means the apex is tied with
the current VNDK version while min_sdk_version: N means the apex should
work with N+ VNDK versions. Setting both properties together doesn't
make sense.
Bug: 274396342
Test: m nothing (soong tests)
Change-Id: I00dcac43f95ce6a90b3f3273ae4611a300ea5028
Vendor APEXes can be updatable unless it sets "use_vndk_as_stable:true".
When "updatable:true", it should meet the "updatable" requirements like
"should set min_sdk_version".
Bug: 274396342
Bug: 274041915
Test: m nothing (soong tests)
Change-Id: I746d8941c21e883c1eba3e1f1e5a414a67db071a
strict_updatability_linting currently only makes it so
that NewApi can't be added to the lint baseline.
However, since we're updating NewApi to work on a lot
more apis than before, we need to baseline many issues
across the android tree. Temporarily disable
strict_updatability_linting so that we can add these
baselines.
Bug: 193460475
Test: Presubmits
Change-Id: I8d92df95a46e9b903f0cc0e3be56f17722c50430
When set true, use file_contexts file as is and do not force-label / and
/apex_manifest.pb
Bug: 268439003
Test: m (soong tests)
Change-Id: I252eef9569deeac87bb71a3425a8eb07bab3c634
The type of min_sdk_version is being migrated from
android.SdkSpec(kind+level) to android.ApiLevel(level). This affects
`ShouldSupportSdkVersion` for java modules. This function skips the
check for modules compiling against `core`, and that requires access to
SdkVersion and not MinSdkVersion after the migration.
Skip the check explicitly using SdkVersion.
Test: go test ./java
Test: No change in ninja file
Bug: 208456999
Change-Id: I14eca4f8e8c5d7477ded00c4fe54097323fab4a2
Implement APEX stub of API surface so any stub can be replaced with API
surface when APEX stub interface is required.
Unlike other stub interface, APEX stub can be decided if it should be
used after APEX postdeps mutator analyzes which modules should be
included in which APEX. To cover this, APEX stub is being added to the
dependency if the dependency should not be covered with LLNDK or NDK
stub, and APEX stub exists. From depsToPaths, if dependency to both
original module and API library exists, then it choose one of the
dependency and ignore the other.
To cover this logic, a new property is added to the api_surface :
apex_libs. This is introduced as it is difficult to
gather all api library with apex stub before DepsMutator.
Bug: 264963986
Test: cf_x86_64_phone_vendor build succeeded
Change-Id: I9f0b1f70968e32eba94d3e0d7bb1f4bb29ff2438
This reverts commit be90172f0a.
Reason for revert: not used, and not desired
Bug: 270542561
Test: presubmit
Change-Id: I415440dbae965f3c07c6f3ccf6ab4bc9ec57fbf6
Previously, the symlink optimization for APEXes assumed that the target
of the symlinks are in the system partition. The assumption however
doesn't hold always because the file that was added to the APEX might be
with system_ext_specific: true or vendor: true.
Bug: 265598720
Test: m nothing
Change-Id: Ieb9a6769320c0ec697a88c0cae977e7d65288362
The tests in bootclasspath_fragment_test setup the environment to have
two APEXes: a source one and a prebuilt one. Before this change, the
tests for prebuilt incorrectly check the contents in the source one.
This change introduces a new function that properly checks files
deapexed from the prebuilt one.
Bug: 241823638
Test: m nothing
Change-Id: I1865c20b198d50e7ebc8ebfb9f7c71394a225ab7
This reverts commit d1209a89c7.
Reason for revert: apex_name was still in use in the internal/intermediate branch. Fixed(removed apex_name) in the internal branch.
Change-Id: I10b8e0cfdb01dcdb6b623bddf9c04f4dac71fc90
apex_name was used to install symbol files under /apex/<apex name>,
which caused duplicate rules when there's two apexes with the same
apex_name. (e.g. override_apex or multi-install apexes)
Since symbol files can be looked up via ELF Build-Id, we don't have to
install symbol files with the actual "apex name", but instead we can
install them with soong module name.
Bug: 267581665
Test: m (soong test)
Change-Id: I1cbe5c86d287f180c7deef93ba85ea5552680011
VNDK APEX has been using "apex_name" property to set "name" field in
apex_manifest. But setting apex_name had a side-effect of emitting
duplicate rules for symbol files for VNDK APEX and its override_apex.
(Please see the removed comments for more details about error)
Not using "apex_name" fixes the duplicate errors.
There're a few more vendor apexes with the same issue, which I will
handle in follow-ups.
Bug: 267581665
Test: m (soong test) && boot
Change-Id: I00f617cef8af4d21880d4e8b9c0b9ab9322ba15c
Since fe4ff29b4d47fa8ae242fb7e084215d3afada4b5 (in system/apex), apexer
doesn't check keyname (--key vs --manifest.name). So, passing
--do_not_check_keyname doesn't make any sense.
This is a preparation to remove (or deprecate) "apex_name" property from
"apex" module.
Bug: 267581665
Test: m
Change-Id: I3737d1e36d305375a523a23a6bbeb2d23586e578
This piggybacks onto the ApexInfo cquery handler, so we're issuing a
single bazel query call that reads two providers in the starlark expr.
Also rename requiredDeps to makeModulesToInstall to differentiate it from
APEX's required/provided libs in the apex manifest.
Test: unit test
Test: mkdiff
Fixes: 263123189
Change-Id: Ib7e43f1586f29864eee8627dba3631bfaff27afa
This reverts commit eb8cd3122a.
Reason for revert: mainline module jacoco jar do not contain JAVA_LIBRARIES needed for coverage, see: b/266679012
Change-Id: If756f7aaf40c6bcfed170c59c494bcc426620039
Currently, Bazel sets __ANDROID_APEX_MIN_SDK_VERSION__ based on the cc library's min_sdk_version while Soong does based on apex's min_sdk_version. This causes a diff in the clang commands.
Digging further, we realized __ANDROID_APEX_MIN_SDK_VERSION__ isn't used anywhere so we might just delete it altogether instead of fixing it.
Bug: 265134933
Test: presubmit
Change-Id: I08e89dc8f6ef86669248ea5c47de6603e9d2ffbb
The image apex does not need all the files that make up a flattened
apex.
Bug: 254205429
Test: go tests
Change-Id: I7c574c5b30b55ab6d1b3981ee26d168c2f2427c4
This was revealed by the new check added in
Ib3c6efd16bdf13b59f79be66d4f9dba49100f6cc.
This was okay since the old implementation relied on the fact that impl
variant comes before stub variants.
To make the new check happy and keep the intention explicit, stub
variants are not added to VNDK apex.
Bug: 191770320
Test: m (apex_test)
Change-Id: I455f2c9b6bc471c579379286c0198f36d325adf6
A single file generated by different modules is almost never correct;
make it an error.
The check is skipped for some error cases, which will be handled in follow-ups.
Bug: 191770320
Test: m (soong test)
Change-Id: Ib3c6efd16bdf13b59f79be66d4f9dba49100f6cc
Add AndroidMkEmitAssignList to emit a line to assign the items from
the given list of string arrays.
Test: treehugger
Change-Id: Id5acbef38ea4e91349bd2461f226db352d4b8123
Add an option to override defaultManifestVersion using environment
variable. The environment variable will be used to override the apex
version locally when developing a desert release feature in
mainline-prod branch. Overriding the apex version in mainline-prod
branch allows us to install apex built in mainline-prod branch to device
running code from git_master which has a higher apex version than
mainline-prod branch.
Bug: b/233608815
Bug: b/196860838
Test: presubmit
Test: go test -v ./build/soong/apex/
Change-Id: I8ac2aae2b6b29da7f09db6edb893e0a0f0691e51
This leads to an arm64 apex being used on a device that is mixed
x86_64 with nativebridge=arm64. A device like that doesn't appear
to work with arm64 binaries. For example, the boringssl-self-check
binary crashes on boot.
Bug: 260115309
Test: unit test
Test: boot emulator with this combination
Change-Id: Ic4a91974290a05b1799f755fcf52ef226d68f4c2
