| Age | Commit message (Collapse) | Author |
|---|
|
Currently, apex rules read the secondary arch directly from the
soong.variables file, which means that when transitioning into a
different product, the new secondary arch wouldn't be picked up.
Instead, make the secondary arch its own constraint setting/values.
One hiccup with this is that it's not really clear what to do when
there is no secondary arch. I think that making a "none" constraint
value might introduce more confusing behavior / edge cases, so instead
I decided to make the secondary arch match the primary arch when it
doesn't exist. The platform utils will convert it back to an empty
string to match the soong.variables behavior.
Bug: 269577299
Test: Diffed the result of `b build --config=android //build/bazel/vendor/google:build.bazel.examples.apex.minimal_apex_aab` before and after this cl. For some reason there is a diff in the apex.pb file in the aab, but it's just differences in the order of fields: https://diff.googleplex.com/#key=7rKBCiPxby9p
Change-Id: Ifc41045feef9d05691cf49bcfc1b1c2fac15177e
|
|
Bug: 271709362
Test: Presubmits
Change-Id: I660458c2194999182f7b3cccb79813a267a156fc
|
|
|
|
accessing the java binary via the local_jdk is discouraged and the toolchain set-up I'm planning will break this.
TEST: presubmits
Change-Id: I432725de9d39081edc65611e306e9111da09a2bd
|
|
There are still some lint warnings remaining, mostly revolving around
adding documentation where I didn't feel confident filling it out.
Bug: 271709362
Test: Presubmits
Change-Id: Ie9021ef5920ce94b0037c50d211a9a952e8b3e62
|
|
Also add support to producing apex bundle base zips with the right names
for 64+32 packages. Verified all of these with filelist diff tests.
For example:
$ zipinfo -1 bazel-bin/build/bazel/vendor/google/build.bazel.examples.apex.minimal/build.bazel.examples.apex.minimal.aab
BundleConfig.pb
base/apex/armeabi-v7a.img
base/apex/armeabi-v7a.build_info.pb
base/root/apex_manifest.pb
base/assets/NOTICE.html.gz
base/apex/arm64-v8a.armeabi-v7a.img
base/apex/arm64-v8a.armeabi-v7a.build_info.pb
base/apex/arm64-v8a.img
base/apex/arm64-v8a.build_info.pb
base/apex/x86.img
base/apex/x86.build_info.pb
base/apex/x86_64.x86.img
base/apex/x86_64.x86.build_info.pb
base/apex/x86_64.img
base/apex/x86_64.build_info.pb
base/manifest/AndroidManifest.xml
base/assets.pb
base/apex.pb
Also remove tests that are doing binary diffing - we're excluding
everything, which makes the test not useful at all. Plus we don't have a
goal of keeping everything bit for bit identical, as long as we
understand where the differences lie.
Also remove shell-based apex_aab_test for filelist diffing. The BUILD
diff_test is much easier to maintain and debug.
Test: new filelist diff tests
Bug: 268335710
Fixes: 271424450
Fixes: 271421585
Change-Id: I43e3297952817e5df32ba2ccf926a98ee8ecc973
|
|
Otherwise the copywrite would be the main module-level documentation
when generating documentation.
Bug: 271709362
Test: Presubmits
Change-Id: Ifc385b321e7226048dda47a6e1d0e0d667226483
|
|
blkid is now accepted by an deapexer arg, so no need to expose /usr/sbin.
Also add zip2zip into the PATH for the action.
Bug: 268335710
Test: $ b build //build/bazel/vendor/google:mainline_modules --config=android
Change-Id: Icb199dd7110cb2a12365e796110fdf19f8b72cb9
|
|
We create an android_product macro that replaces a lot
of the existing platform code. It takes a soong.variables
file, and creates bazel platforms for the android product,
various other arches, and the host platforms. (currently
host builds still depend on product config variables)
To change products, you'll be able to pass
--platform=//build/bazel/product_config/generated/products/<product_name>,
however currently we only generate the platforms for the
currently lunched product for performance. When the other
products are in starlark, we can allow using all of them.
Bug: 249685973
Test: Presubmits
Change-Id: Ic1b0942a60c66eb3fe2b1aa7a2ff436ec9b3c3fb
|
|
This enables these files to be dist'd using the copy_to_dist_dir rule
and a filegroup.
$ b build //build/bazel/vendor/google:build.bazel.examples.apex.minimal_apex_aab --output_groups=apex_files --config=android
This produces the following layout:
$ tree bazel-bin/build/bazel/vendor/google/
bazel-bin/build/bazel/vendor/google/
├── mainline_modules_arm
│ ├── build.bazel.examples.apex.minimal.apex
│ ├── build.bazel.examples.apex.minimal-base.zip
│ ├── java_apis_usedby_apex
│ │ └── build.bazel.examples.apex.minimal_using.xml
│ ├── ndk_apis_backedby_apex
│ │ └── build.bazel.examples.apex.minimal_backing.txt
│ └── ndk_apis_usedby_apex
│ └── build.bazel.examples.apex.minimal_using.txt
├── mainline_modules_arm64
│ ├── build.bazel.examples.apex.minimal.apex
│ ├── build.bazel.examples.apex.minimal-base.zip
│ ├── java_apis_usedby_apex
│ │ └── build.bazel.examples.apex.minimal_using.xml
│ ├── ndk_apis_backedby_apex
│ │ └── build.bazel.examples.apex.minimal_backing.txt
│ └── ndk_apis_usedby_apex
│ └── build.bazel.examples.apex.minimal_using.txt
├── mainline_modules_x86
│ ├── build.bazel.examples.apex.minimal.apex
│ ├── build.bazel.examples.apex.minimal-base.zip
│ ├── java_apis_usedby_apex
│ │ └── build.bazel.examples.apex.minimal_using.xml
│ ├── ndk_apis_backedby_apex
│ │ └── build.bazel.examples.apex.minimal_backing.txt
│ └── ndk_apis_usedby_apex
│ └── build.bazel.examples.apex.minimal_using.txt
└── mainline_modules_x86_64
├── build.bazel.examples.apex.minimal.apex
├── build.bazel.examples.apex.minimal-base.zip
├── java_apis_usedby_apex
│ └── build.bazel.examples.apex.minimal_using.xml
├── ndk_apis_backedby_apex
│ └── build.bazel.examples.apex.minimal_backing.txt
└── ndk_apis_usedby_apex
└── build.bazel.examples.apex.minimal_using.txt
Fixes: 262267828
Fixes: 262267670
Fixes: 262267551
Test: mainline build script with --bazel-mode.
Change-Id: I67e9afff09d681a6ddf761889fa72524d5a8f713
|
|
APEX builds in Soong use an allowlist to track modules that are included
as transitive dependencies in the built APEX. We need to replciate this
behavior in the Bazel rules.
Bug: 218419109
Test: b build //packages/modules/adb/apex:com.android.adbd
Test: b build //system/timezone/apex:com.android.tzdata
Test: b build //packages/modules/NeuralNetworks/apex:com.android.neuralnetworks
Test: remove `if not d.is_external` clause from dep_module_names in
apex_deps_validation.bzl; verify that build fails due to unexpected
deps
Test: comment out `if not d.is_external` &&
UNSAFE_DISABLE_APEX_ALLOWED_DEPS_CHECK=1 b build \
//packages/modules/adb/apex:com.android.adbd
Test: compare com.android.adbd.current_deps output file with
out/soong/.intermediates/packages/modules/adb/apex/com.android.adbd/android_common_com.android.adbd_image/depsinfo/flatlist.txt
and verify that the only diff comes from toolchain dependencies
(which are not available via aspect traversal)
diff <(cat out/bazel/output_user_root/5d143b37c5ed18ccb97f9009299a2d6c/execroot/__main__/bazel-out/android_target-fastbuild/bin/packages/modules/adb/apex/com.android.adbd.current_deps | sort -u) <(cat out/soong/.intermediates/packages/modules/adb/apex/com.android.adbd/android_common_com.android.adbd_image/depsinfo/flatlist.txt | sed -e "s/prebuilt_//g" | sort -u)
Change-Id: I037b8f6e4942a02c039b4f132925039c697b9743
|
|
This transition was added so that the tests are run under
an android configuration.
In theory, instead of this, we should be able to mark apexes
as target_compatible_with = ["//build/bazel/platforms/os:android"],
and then the tests will also be treated as incompatiable as well, given
this docs quote:
"Targets that transitively depend on incompatible targets are themselves
considered incompatible. They are also skipped for building and testing."
https://bazel.build/reference/be/common-definitions#common.target_compatible_with
However, it appears that toolchains are still attempted to be resolved
even when the target being built is incompatible. To work around this,
make the apex toolchain optional.
Bug: 249685973
Test: b test --toolchain_resolution_debug='//build/bazel/rules/apex:apex_toolchain_type' //build/bazel/tests/apex:all
Change-Id: Ifa4b72f6d391094f5a779b44ccc720123589ffd8
|
|
This creates both the .base file used by aab in the apex rule and the
-base.zip used for mixed build compatibility.
Test: mixed_droid
Test: unit tests
Change-Id: I54cc1b4ef3c795c33083216dfb8ed4458f937b62
|
|
and com.google.mainline.
Bug: 243748589
Test: b build //vendor/google/build:com.google.android.adbd_aab --config=android
Test: b test //build/bazel/rules/apex:apex_aab_tests
Change-Id: I53cc1d84b1f84eb61fbd3c340c95440de98b9dde
|
|
The function is enabled only when building on internal master since dev_sign_bundle is an internal tool.
Test: b build //vendor/google/build:com.google.android.adbd_aab --config=android
Bug: 243748589
Change-Id: I399629f2eaceb2f60464f7140e08723caeb50edb
|
|
just like the apex rule.
This ensures that the apex_aab is always built for android, and given
apex_toolchain's target_compatible_with restrictions, it also cannot be
used with --platform=linux_x86_64.
Test: $ b build //build/bazel/vendor/google:mainline_modules
Test: CI
Change-Id: I85adac2e3ccceb883ff9d6fb0305df241ffe0a8e
|
|
Bug: 234748998
Test: CI
Change-Id: I5b5a80cbbec23c56edd515225bdb78ab95b93df3
|
|
Test: presubmit
Change-Id: Ib9169a960afd7ff617b76060e7c06c0e692607fc
|
|
Test: b build //build/bazel/vendor/google:build.bazel.examples.apex.minimal_apex_aab
Test: zipinfo -1
bazel-bin/build/bazel/vendor/google/build.bazel.examples.apex.minimal/build.bazel.examples.apex.minimal.aab
BundleConfig.pb
base/apex/armeabi-v7a.img
base/apex/armeabi-v7a.build_info.pb
base/root/apex_manifest.pb
base/apex/arm64-v8a.img
base/apex/arm64-v8a.build_info.pb
base/apex/x86.img
base/apex/x86.build_info.pb
base/apex/x86_64.img
base/apex/x86_64.build_info.pb
base/manifest/AndroidManifest.xml
base/apex.pb
Bug: 236673372
Change-Id: I7639ace6e19f279f45a3bcb6d98a7c8c0730f04d
|
|
Future proof the rules against remote actions by not assuming that host == exec platform.
Test: presubmits
Change-Id: I5f09b11cf70a458e120bf6ca053331c3dbdb5e01
|
|
for each architecture.
The Mainline CI build target produces both .aab files and .apex files
for each module, in the following layout:
x.aab
y.aab
mainline_modules_arm/x.apex
mainline_modules_arm/y.apex
mainline_modules_arm64/x.apex
mainline_modules_arm64/y.apex
..
Currently, we're only producing the .aab files by building the apex_aab
targets. To dist the .apex files, we either build the apex targets
separately within a --config={android_arm, android_arm64, ..} loop, or
we could just forward the 1:4 split transition'd multi-arch apex files
from the apex_aab target, which are already built.
This is a output group because it can be controlled from a filegroup or
the command line --output_groups flag, which makes it easy to extend the
mainline build script.
For example:
```
apex_aab(
name = "module",
mainline_module = "//path/to:apex",
)
filegroup(
name = "apex_files",
srcs = [":module"],
output_group = "apex_files",
)
```
Or: b build //path/to/module --output_groups=apex_files
produces the following:
bazel-bin/path/to/mainline_modules_arm/module.apex
bazel-bin/path/to/mainline_modules_arm64/module.apex
bazel-bin/path/to/mainline_modules_x86/module.apex
bazel-bin/path/to/mainline_modules_x86_64/module.apex
Test: new analysis test
Bug: 238723069
Change-Id: I3f4efa4eff1adeba8c315d9f97729a3a529b32c0
|
|
Bug: 238905076
Test: Presubmits
Change-Id: I10bec78eab298b9f34a0cad09c00d8f3e03606b2
|
|
Bug: 230893497
Test: ./build/bazel/vendor/google/build_mainline_modules.sh
Test: b build //build/bazel/examples/apex/minimal:build.bazel.examples.apex.minimal
Change-Id: I41f0b979f98d6ee99fe1437cd8963eabf6e717fb
|
