This property allows developers to create multiple modules that provide
the same APEX implemenation with some differences. For example, an APEX
that targets the current SDK can be developed alongside an APEX that
targets a pre-S SDK. Common dependencies of these APEX modules can both
use the value of the apex_available_name property in their
apex_available lists and be packaged in either APEX module.
Bug: 285138555
(cherry picked from https://android-review.googlesource.com/q/commit:ca8165373070b45919e6a1879ebc11705b6c425c)
Merged-In: Ia2cb027e2f19bd6d3d1c02e3d3742a0122a43c97
Change-Id: Ia2cb027e2f19bd6d3d1c02e3d3742a0122a43c97
The core problem I am trying to solve is making sure that stub
libraries in Bazel have a single apex available. In Soong, this will be
enforced using some graph walk which is not easy to port to Bazel.
However, we might need to revisit this when we build the enforcement
mechanism in Bazel. We likely need a `test_for` on the top level
apex_test Bazel rule so that the test apex is _allowed_ to link against impl
of the library it is trying to test.
(This CL retricts this to cc_library, I can expand this to other modules
if this is the right approach.)
Bug: 277651159
(cherry picked from https://android-review.googlesource.com/q/commit:f57a966b6694da970e99f519919f9b845b713163)
Merged-In: Iaeec22c5626df79a33785c766ed29102b1da403e
Change-Id: Iaeec22c5626df79a33785c766ed29102b1da403e
AndroidMk assumes that the app is the last file installed, and it uses
this assumption to populate the LOCAL_SOONG_INSTALLED_MODULE entry. This
CL moves the privapp_allowlist installation to before the app
installation to respect this assumption.
Bug: 242509786
Test: go test
Test: OUT_DIR=out.ref m nothing &&
cp aosp/2562351 && OUT_DIR=out.change m nothing &&
GOWORK=$PWD/build/bazel/mkcompare/go.work \
go run android/bazel/mkcompare/cmd -json \
<(sed -e "s/out\.ref/out/g" out.ref/soong/Android-aosp_cheetah.mk) \
<(sed -e "s/out\.change/out/g" out.change/soong/Android-aosp_cheetah.mk)
&& verify manually that the only diffs are related to the removal of
the prebuilt_etc module.
(cherry picked from https://android-review.googlesource.com/q/commit:b1daccdc97ae08603b0e2f5eafe97bd11238ee58)
Merged-In: I95ec27070f575e79fb976de68493a219717ed89a
Change-Id: I95ec27070f575e79fb976de68493a219717ed89a
This change allows override_android_app to use the same
privapp_allowlist as the non-override module so that they will always
remain in sync.
Test: go test ./java -v -run TestPrivappAllowlist
Test: go test ./apex -v -run TestApexWithApps
Test: m com.android.permission com.google.android.permission and verify
manually that apex_payload.img contains correct privapp_allowlist
Test: m com.android.permission before and after change &&
`diffoscope apex_payload_reference.img apex_payload_with_change.img`
&& verify that there are no semantic changes
Bug: 242509786
(cherry picked from https://android-review.googlesource.com/q/commit:580636bdd23171f31bfedd773c065e0861dd5c4a)
Merged-In: Ifdcb28af40763aed7a4aac9a7f681153554bc256
Change-Id: Ifdcb28af40763aed7a4aac9a7f681153554bc256
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
* 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
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
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
There are no current users of overriding rros, so it's dead code.
Additionally, there is some evidence of accidental misuse, so remove it
for now as we don't want arbitrary properties of AOSP modules to be
overridable in the general case.
Bug: 270542561
Bug: 269568074
Test: presubmit
Change-Id: I030abd644358baefc0d1543649c8a2a81a7491d0
This reverts commit be90172f0a.
Reason for revert: not used, and not desired
Bug: 270542561
Test: presubmit
Change-Id: I415440dbae965f3c07c6f3ccf6ab4bc9ec57fbf6
This reverts commit dd2c76e772.
Reason for revert: This was submitted without build system team +2 with no rationale for why it's needed.
Change-Id: I86b9849122ec2b7a382d4f39bbbc0ea1ff70c4bc
This property allows an APEX bundle to ignore the apex_available rules
defined in its dependencies, effectively allowing it to use any APEX
as its dependency.
Bug: 269660351
Test: m
Change-Id: Ib2797e04438ad908ac10b256dce07a7819e836b3
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
After this change, if "profile_guided: true" is set, profile-guided
compilation will be enabled for the jar and the ".prof" file next to
the jar in the APEX ("javalib/<name>.jar.prof") will be used as the
profile when dexpreopting for the prebuilt APEX.
Bug: 241823638
Test: m nothing
Test: -
1. (on internal master) Patch aosp/2426453.
2. Build the APEX bundle and the module SDK of com.android.wifi
3. (on tm-dev) Patch this CL and aosp/2141972.
4. Copy the APEX bundle and the module SDK built on step 2 to the
source tree
5. Disable hiddenapi check
6. lunch cf_x86_64_phone-userdebug && m MODULE_BUILD_FROM_SOURCE=false com.google.android.wifi
7. cat out/soong/.intermediates/prebuilts/module_sdk/Wifi/current/prebuilt_service-wifi/android_common_com.android.wifi/dexpreopt/oat/x86_64/javalib.invocation
8. See the profile being used.
Change-Id: I55a5a295e9c5d6f0564afb139c5fb7da91ab8cae
filesInfo should not be used for an apex that's converted to Bazel,
since all information should come from the Bazel starlark provider.
filesInfo is populated when there's a full Android.bp module graph of
the apex deps.
Test: presubmits
Change-Id: I4b9c596ca7841f4ea76e21f929039282113b6752
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
After this change, if profile-guided compilation is enabled for an APEX
system server jar, the profile will be installed next to the jar with
the ".prof" suffix, ("javalib/<name>.jar.prof"). This file will later be
used by odrefresh and dexpreopt from prebuilt APEX.
Bug: 241823638
Test: m nothing
Test: -
1. Patch ag/20581649 PS2.
2. banchan com.android.btservices x86_64 && m
3. Check that "javalib/service-bluetooth.jar.prof" exists in the APEX.
Change-Id: Ibcfc6257dade92bd40a6d4b7368148717d0863b9
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
Previously in mixed builds, only the tidy files for the boundary module
were built, whereas all of its transitive dependencies' tidy files were
not being built. Instead we should export the list of transitive tidy
files for a module so that we can run clang-tidy for the boundary module
as well as its dependencies.
Bug: 195029134
Test: WITH_TIDY=1 DISABLE_ARTIFACT_PATH_REQUIREMENTS=true mss tidy-packages-modules-NeuralNetworks --bazel-mode-dev
Change-Id: I463646d2ae1fc4aa075a54c264e1c34571c3fd5c
This has been a workaround to avoid duplicate build rules for
multi-install apexes. The reason for duplicate errors was that apex_name
was used to install symbol files.
We don't need to rely on apex_name for symbol files, hence no need for
the workaround.
Note that symbol files for apexes are still available via the paths
based on "soong module name".
Bug: 267581665
Test: cuttlefish (which uses multi-apex) build & run
Change-Id: Icaca667e139ef2aca32339a75b54b12a00449c2d
It makes sense to make min_sdk overridable because the override_apex is
a variant of the original apex, and this variant might be
created/introduced in the newer Android release compared with the base
apex. Despite the fact that the source of the variant apex is the same
as the original one, the variant may not support the older version, like
Go modules, trimmed modules. If we consider the variant as a "new"
module, then it makes sense to have a new min_sdk to make it only
available for the newer Android released version only.
Bug: 266945903
Test: Build locally, and check if the override works
Change-Id: I7f4c7169e15b7e57f44a4abafe012151dbc226a0
