Armv9 with mandatory PAC and BTI extensions.
Stack protector is disabled as it is irrelevant with PAC.
Bug: 263283855
Test: NFC
Change-Id: I2f298f21dade12824597e0a6920772a2bfc63afb
Unlike most module types, config variable handling is always namespaced
to the Android.bp file, which limits reuse of the variable definitions.
Additionally multiple of these module types can define a string variable
in the same config namespace, but specify different valid values for the
string.
Previously, we cached the first instance we see of variable + namespace;
however, this caused non-determinism in which defintion would be used
and not migrating all values. Instead, we now only cache within a single
Android.bp file where the variable definitions are re-used.
Test: go tests
Bug: 271481817
Change-Id: Ic327657c508e47a705bacd24712a1916e105c7cd
Add definitions for the Cortex-A32 CPU. This is an aarch32 only ARMv8-A
core. See more here https://developer.arm.com/Processors/Cortex-A32 .
Test: added new minidroid target using this CPU variant and built
Change-Id: Id2351a43b9c6cb9785ef469b8c13fadd8b6324b8
Signed-off-by: Mark Slevinsky <markslevinsky@google.com>
Signed-off-by: Jesus Sanchez-Palencia <jesussanp@google.com>
can allowlist instead. bp2build now handles kotlin srcs
Change-Id: I0f96eb50cbb5bd2c6dc69f253b1a35cfd4edecf2
Test: built codegen_cli with bazel
Bug: b/245731902
This feature is toggled on with USE_PERSISTENT_BAZEL, which is off by
default. Those that opt-in will have a bazel server running between
builds (with a 3hr default TTL) which will greatly improve analysis on
subsequent builds. (As Bazel maintains a cache of analysis results).
Bug: 266983462
Test: Manual `m nothing` runs (timing with and without the feature)
Test: New integration test
Test: Presubmits
Change-Id: I3af4948baa0c490e9b87c48ffdbe9f67732586c7
Currently it would return the default one even if the requested one is
an active sdk.
Bug: 270609292
Test: go test ./java
Test: built `rkpdapp` locally in internal and verified that its
targetSdkVersion is U and V
Test: TH
Change-Id: Idb03ff4786ff87fb7911bf31205941618a662404
After this change, the dependency hierachy can be arbitrarily deep. For
example, you can have one boot image that extends another boot image
that extends yet another boot image.
Bug: 269230245
Test: m
Change-Id: I096d0b57bda36b982ecc97378647f9c59071a3bf
This fixes current breakage on aosp-master-bazel on bp2build-incremental. aosp/2401793 addes android.frameworks.stats-V2-ndk to libtestvendoratoms but android.frameworks.stats aidl_interface is not allowlisted yet.
However, `//frameworks/proto_logging/stats/stats_log_api_gen:libtestvendoratoms` is still not building because of another issue in genrule + proto.
```
ERROR: out/soong/workspace/frameworks/proto_logging/stats/stats_log_api_gen/BUILD.bazel:87:8: Executing genrule //frameworks/proto_logging/stats/stats_log_api_gen:test_vendor_atoms.cpp failed: (Segmentation fault): bash failed: error executing command (from target //frameworks/proto_logging/stats/stats_log_api_gen:test_vendor_atoms.cpp) /bin/bash -c ... (remaining 1 argument skipped)i
```
The fix to this is similar to aosp/2401794 and is fixed in aosp/2449265
Test: presubmit
Bug: 270131691
Change-Id: I8bcc336d843ee4f0de44f377c828a9a4c959b0ec
Bug: 240424572
Test: Manual tests:
1. m --dev-mode-staging com.android.adbd com.android.media.swcodec.
2. verify the DCLA libs from the two apexes have the same size and
sha1sum, and also match the libs in bazel-out.
3. empty the DCLA libs list in allowlist.go and repeat step 1
4. repeat step 2 and verify the opposite result
5. build git_master: mainline_modules_bundles-userdebug in ABTD
with the cl, then follow go/build-sideload-dcla-locally to
download the adbd and swcodec aab files, run the DCLA trimming
workflow locally, and verify the symlinks in the two trimmed
apexes are identical and also match the lib path in the DCLA
apex that was created by the workflow.
Change-Id: Ib2f8a29126a54829c0e10eba17b256a79930fd70
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
Creation of build statements is largely parallelizable because each
action is independent apart from updates/reads to
depsetHashToArtifactPathsCache. Locally resulted in build statements
taking ~.45 seconds on staging mode to ~.02 seconds
Test: CI
Change-Id: Iab00c8394a9eab17353f71230885ff0870e17f24
