Currently NDK ABI monitoring is enabled by switching boolean flag in
soong code. When this flag is switched, it will enable ABI monitoring in
all release configurations at once.
This change moves the flag from soong code to the trunk-stable flags
framework ("build/release/build_flags.scl") that allows to enable it
only in specific configurations like "trunk-staging".
Test: TH
Bug: 156513478
Change-Id: Ibb810a834c0d756b22782b1a2d8ec5a5e575a4b3
When generating vendor/etc/linker.config.pb, STUB_LIBRARIES was used.
Because it lists *all* libraries with stubs regardless of its
install location (vendor or system), using it for vendor
linker.config.pb doesn't make sense. Instead, use vendor-specific
STUB_LIBRARIES, which is named SOONG_STUB_VENDOR_LIBRARIES.
Bug: 313806237
Test: m (aosp_cf_x86_64_phone)
Test: $OUT/vendor/etc/linker.config.pb not listing libz.so
Change-Id: Icd0aaf92d9630c07f58c4739a9f0ac713516db43
Afdo creates more variants to build, and optimizing LTO is costly to
perform. Turn off these two optimizations for eng builds for a faster
build speed.
This reduces total C/C++ invocation time for aosp_arm64-eng by 6.28%.
Test: presubmit
Bug: 307753064
Change-Id: Ibac4269c66a64e896dba2074b607d71a2da37546
This is to handle libz special case. libz has stubs but not an LLNDK.
So, libz.vendor should be treated as non-stub-providing libraries and
Vendor APEX should bundle it if it's used by its contents.
libz will set no_stubs for vendor/product variants.
Bug: 313806237
Test: go tests ./apex/...
Change-Id: I10759d7073838909126f8bfe87654f11aa02fd32
The next CL will need a TestContext parameter in
ContentFromFileRuleForTests in order to retrieve the file rule contents
from the Config. Add it and update all the tests that use it in order
to simply review of the next CL.
Bug: 306029038
Test: go test ./...
Change-Id: Ia4b4c9854017ea3472fa2f8ba42cf7f72720496e
By default clang assumes that on riscv64 jumps are really expensive.
That's probably not true for the kind of SoCs we're dealing with, but
more importantly (see the bug) it causes clang to do loads from the
right hand side of a `&&` before the left hand side has been evaluated.
This found one latent bug in libcore, and it doesn't seem like the best
use of anyone's time to have to chase similar issues if they're going
to be similarly latent for riscv64 when we get clang's default fixed.
Bug: https://github.com/google/android-riscv64/issues/124
Test: treehugger
Change-Id: I640f1b43ea3d2452366ab86e97a9189fa9f5326c
To generate module-info.json in Soong for b/309006256 Soong needs to
know the test data paths. Moving test data installation into Soong will
also help later for test suite packaging.
Add ModuleContext.InstallTestData that installs the files listed in a
[]DataPath alongside the test. The files will also be passed to Make
to allow it to continue packaging them into the test suites for now.
Update the module types that are producing LOCAL_TEST_DATA entries
in their Android.mk files to go through InstallTestData instead.
Bug: 311428265
Test: atest --host toybox-gtests --test-timeout=120000
Change-Id: Ia8b964f86e584ea464667fd86a48d754d118bead
cc modules can use __ANDROID_VENDOR_API__ to read BOARD_API_LEVEL
that is the API level of the vendor surface.
Bug: 313822931
Test: check ninja commands to have -D__ANDROID_VENDOR_API__=<version>
Change-Id: Iceb5918cbfce0f24929d02d7e3caf1e9942b88e8
This can be used to add apex-specific shared_libs to a CC module. It
would be nice if we could have apex.shared_libs. But it would make code
much harder to follow because we need to record the shared_libs list as
"exclude list" for non-apex anyway.
Bug: 312510312
Test: m libhardware libhardware.vendor libhardware.vendor.com.google.cf.ir
# check DTNEEDED for libapexsupport
# only apex-variant should have the dependency
Change-Id: I56a3dc280127d8ba44337707444ea226a49ccf0f
For LTO compilation, we do not need MLGO flags in cflags, since codegen
happens during link only.
Fixes compiler warnings for unused command line argument.
Test: presubmit
Change-Id: I361e4292b10a3582fd5c69fa7b5678c654b44a0f
This Cl sets testModule field to True in cc.NewTest(). This will cover "cc_test", "cc_test_host" and "art_cc_test".
Change-Id: I4a8db86835b195db34fd9f86560e7bf9321fbd7d
Provider added for the following test modules in this change: art_cc_test, cc_benchmark, cc_fuzz, cc_test, cc_test_host, rust_test,and rust_test_host.
Bug: 296873595
Test: Manual test
Change-Id: I815680529bcbecacb3a2bdb8f3746053afdee48c
Fix various issues that prevent building or running tests with the
Go tools:
Remove testing/test_spec_proto/go.mod. There's already a go.mod at
the top level, and adding testing/test_spec_proto/go.mod breaks
compiling with the Go tools in IntelliJ or from the command line.
Fix go vet issues when trying to print []DataPath.
Fix aconfig_conversion_test.go and add it to Android.bp so it runs
in presubmit.
Test: go test ./...
Change-Id: I18af2f05631446fe507744a2951e4b02c7ab59be
We should update gnu++2a to gnu++2b too, but not in this CL.
Bug: 311052584
Test: treehugger
Test: m checkbuild
Change-Id: I3637444d74868b3a29b425fd749ecbbe1a45fbf7
This reverts commit febf8b9bdf.
We are still seeing flaky performance alerts from microbenchmarks even
with this change, and this has caused binary size / memory usage
increase. Let's add this flag back and observe whether performance
regression reports become more frequent.
Change-Id: I0fec1296b1f49b21b59d81add677f6a926ee88dc
To simulate 16k page size in x86-64 cuttefish, it is necessary
to compile the shared libraries and binaries with max-page-size greater
than 4096.
Bug: 309816695
Test: source build/envsetup.sh
lunch aosp_cf_x86_64_phone_pgagnostic-trunk-userdebug
m
Change-Id: I32670ef2c25fdcefec11bd07ba41cd0ea96c92bd
To simulate 16k page size in x86-64 cuttefish, it is necessary
to compile the shared libraries and binaries with max-page-size greater
than 4096.
Bug: 309816695
Test: source build/envsetup.sh
lunch aosp_cf_x86_64_phone_pgagnostic-trunk-userdebug
m
readelf -l out/target/product/vsoc_x86_64_only/system/bin/toybox
Change-Id: I38e4449a7826a2eca0c1a1cccc916af21f0b3a93
The MLGO model we embed in the Android Clang is trained on ARM64
ThinLTO artefacts. Applying the model across architectures does not
necessarily translate to performance improvement. Therefore only enable
the optimisation on ARM64 ThinLTO for now.
Test: presubmit
Bug: 293827654
Change-Id: Ie64a65c11191cf700a463637a0746c8470d3aa3c
In a trunk stable branch, the ABI-monitored libraries under different
release configurations share the source code. The exported symbols are
filtered by version scripts and API level. header-abi-linker needs to
take the API level as a parameter.
Test: make
Bug: 308192597
Change-Id: I4b55b7ec023451b3a4cd1da308a1de10842d51d2
Also add -Wno-everything as suggested by Pirama
Bug: b/308179696
Follow up: https://b.corp.google.com/issues/308179380
Change-Id: Iaa73f2b52363562b2391346d8b2e5dc73bab4f2d
