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
As-is, dexpreopt config and bootjar is in the dir including
DeviceName(). It causes unnecessary dexpreopt invocation when target is
changed repeatly. To avoid it, rename dir to common name.
Bug: 278833696
Test: m
(cherry picked from https://android-review.googlesource.com/q/commit:4753b39ccaaf573910e6b7a4200e9ca03ec8d96d)
Merged-In: I2818d9ae09e6c22ca6989cc8efdb70b470ec502c
Change-Id: I2818d9ae09e6c22ca6989cc8efdb70b470ec502c
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
.. as a validation for apex.
apex_sepolicy_tests checks the contents of the apex against
precompilec_sepolicy. This is to avoid common mistakes in file_contexts.
For example, etc/vintf directory should be read-able by servicemanager.
Bug: 267269895
Test: m com.google.cf.wifi (with wrong file_contexts entry)
Change-Id: Ic363345df43e5b2108b07de787f5f6817bbe6af4
libc_hwasan is a new library in the runtime apex that lives in
bionic/hwasan/libc.so and is symlinked to /system/lib64/hwasan/libc.so.
This is chosen by the linker if an app or binary requires HWASan
support.
Bug: 276930343
Change-Id: If331744ad84241ad99a41805ea3110d37cf9b0af
Otherwise when other modules use the apex as data (for example, in
tests) they get the full path from the root of the workspace to the
apex.
Fixes: 276416485
Test: atest timezone_data_e2e_tests:com.android.tests.apex.TimezoneDataHostTest#testStageActivateUninstallApexPackage -- --abi x86_64 then tree out/host/linux-x86/testcases/timezone_data_e2e_tests
Change-Id: Id740856794770df2edc55dfff5f6f938fc31d0c5
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
This includes apex_test and apex_vndk. Rely on mixed builds module
allowlist to filter further.
Test: presubmits
Test: m test_com.android.adbd; showcommands test_com.android.adbd | tail -n1 | grep bazel-out
Change-Id: Id73db0917ad4a6dd9c0646d5186753ed940e735f
This relands aosp/2457063. The original change broke T and U since those
branches still contain soong modules of type (kind+level). Those soong
modules have been cleaned up now
Test: Used go/abtd to test T and U branches with this change
Bug: 208456999
Change-Id: I0ef7933c055f88cb512a02108f1173e51156ef1c
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
Add skip-sdk-check to skip checking the SDK version when extracting an
APK/APEX from an App Set Bundle. This can be used when the platform SDK
version is not defined and the APEXs/APKs use SHA based SDK versions.
This check should not be set to true for non Beta dessert releases
Bug: 274518686
Test: # Add SHA targeting modules to platform
m SOONG_SKIP_APPSET_SDK_CHECK=true #Build Passes
m SOONG_SKIP_APPSET_SDK_CHECK=false #Build Fails
m #No config supplied, build fails
Change-Id: I1919437d3410f09c991e1de39031bd88e1f8246a
* changes:
Revert "Create two sentinel api levels"
Revert "Create EffectiveVersion* functions for ApiLevel"
Revert "Prework for migrating min_sdk_version from (kind+level) ..."
Revert "Always include host variants in the sdk snapshot"
Revert "Update min_sdk_version from SdkSpec to ApiLevel"
min_sdk_version signifies device version and does not need an sdkKind to
describe it fully. Update the type and cleanup existing usages. As a
side benefit, we also get better error handling since users can no
longer enter something like `public_30` as a valid min_sdk_version in bp
files
Will do a similar cleanup for targetSdkVersion and maxSdkVersion in a
followup CL
Test: m nothing
Test: no change in ninja files (this should be a no-op)
Bug: 208456999
Change-Id: Ie6ae7e267d093c5e4787e82685daaca1021d202e
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
This CL adds a few things:
1) Populate the filesInfo struct with cquery'd information from an
apex's ApexMkInfo provider. This filesInfo is then used in
apex/androidmk.go to generate Make modules (soong_cc_rust_prebuilt.mk),
which are then used in packaging to generate zip files of symbols in $PRODUCT_OUT.
2) Make a list of dicts of primitives JSON-encodable.
3) Tests.
Bug: 271423316
Bug: 271423062
Test: presubmits
Change-Id: Iaa34f51044de310510e580d9cf1fe60bbef801c1
When evaluating whether to build the VNDK for the multi-target
configurations, we construct the API level based on the VNDK
version. When the VNDK version is 'current', we replace the
version name with the platform SDK version e.g. 'UpsideDownCake'.
For architectures that currently have a MinApiArch of FutureApiLevel
(i.e. 'current'), comparing 'UpsideDownCake' with 'current' will
assume 'current' is at a higher API level and skip building the
VNDK.
Before perofrming the API level comparison, we check that the VNDK
version does not match the platform VNDK version. If true, it is
necessary to disable the VNDK when it does not meet the minimum API
level for the architecture. If false, we skip this check and allow
the VNDK to be enabled, as this implies we are targeting the 'current'
VNDK version and should include the target platform VNDK.
Test: m (soong test) & boot
Change-Id: Iacc33d2858fef670ddfdff5bbde9d32b084979c9
override_apex's bp2build converter had a bug where it was looking at
the product variables for the override_apex module itself instead of
for the base module it is overriding.
Fixes: 271424349
Test: go test
Change-Id: If1e2653d3751fa908faf0ab97dfa2e943ebe98ec
