For some APEX packages (i.e. the Runtime Testing APEX), the set of
files to copy can be so large that the copy commands (which are part
of the Ninja shell command executed for an APEX package) may exceed
the maximum length of argument to the exec() functions (ARG_MAX). To
work around this limitation, record these copy commands in a Ninja
response file (rspfile) and `source` this file in the Ninja command to
execute them.
Test: m nothing (`apex/apex_test.go` amended)
Test: m com.android.runtime.testing (with CL https://android-review.googlesource.com/c/platform/art/+/1008034/ cherry-picked)
Bug: 129534335
Change-Id: I09ff2d9cf66bfd4cbc12cb724a45d455d08da0b2
Before, the values were often simply ignored. If bad values are provided
now, we should be able to catch them.
Bug: 119771576
Test: relying on this for AIDL/HIDL
Change-Id: I8d2ff26da0b2d01ebe7f78c26d69c7b618a65367
For smart terminals, default to using the status table, using 1/4 of the
terminal height (with a min of 1 and a max of 10).
This behavior can still be overriden to a specific height with
SOONG_UI_TABLE_HEIGHT, and turned off by setting SOONG_UI_TABLE_HEIGHT
to 0.
Test: m <adjust terminal height, see it shrink when it gets too short>
Test: SOONG_UI_TABLE_HEIGHT=20 m
Test: SOONG_UI_TABLE_HEIGHT=0 m
Change-Id: I224348a29a6e07f168c92cf5514a94bd27e32618
To build the platform for ASAN, we do
`m && SANITIZE_TARGET='addresss' m`
However, at the end of the second build, the system partition could have
conflicting APEXes; prebuilt APEXes from the first build and
source-built APEXes from the second build. Since the file names for the
prebuilt and the source-built are different (e.g.
com.google.android.media.apex v.s. com.android.media.apex), we end up
having two files for the same APEX. This is confusing apexd at runtime
and the device fails to boot.
To fix this, when building a non-prebuilt APEX, the prebuilt APEX might
have been installed by the previous build is deleted.
Bug: 138146044
Test: lunch aosp_cf_x86_pasan; m && SANITIZE_TARGET='address' m
check that out/target/product/vsoc_x86/system/apex has
com.android.*.apex only.
Change-Id: Ib5a021a297cf0173ea5a3b50e9398b1cf295c558
The code still needs to exist, but for buildspec.mk files, not the
PRODUCT-* arguments.
Test: none
Change-Id: I60c6044ab2d1627af7e6e2e8831b77d9db12aa55
If sort_bss_symbols_by_size is true, a shared library is built twice.
The first build generates an unsorted output file, which is used to
generate the symbol ordering file. The output of the second build is
a shared library with its bss symbols sorted by their size.
With this, the only user of symbol_ordering_file, libc, is migrated to
use the new property, so we remove symbol_ordering_file support as well.
Bug: 135754984
Test: Build and check the resulting libc.so has its bss symbols sorted.
Change-Id: I5c892b44d82eb99cbc070cfa2c680be3087f3364
In `apex.apexBundle.GenerateAndroidBuildActions`, we used to pass the
"all tests" ("") module as `module` for all `apexFile` objects created
from a test module using `test_per_src: true`. An immediate issue of
this situation was that the "" module is hidden from Make, which made
all the generated `apexFile` objects hidden from Make too. This would
break the construction of flattened APEXes, as they rely on Make logic
to install their files.
Instead of collecting `test_per_src` test variations' output files in
`cc.Module.GenerateAndroidBuildActions` and using them in
`apex.apexBundle.GenerateAndroidBuildActions` as part of handling the
"" variation as a direct dependency of an `apexBundle`, process them
as indirect dependencies (and do nothing for the "" variation direct
dependency).
Adjust the indirect dependency logic in
`apex.apexBundle.GenerateAndroidBuildActions` to allow not only
shared/runtime native libraries as indirect dependencies of an
`apexBundle`, but also `test_per_src` tests.
Test: m (`apex/apex_test.go` amended)
Bug: 129534335
Change-Id: I845e0f0dd3a98d61d0b7118c5eaf61f3e5335724
As sdk_check.mk checks, soong starts to check every app.
If sdk_version is empty, platform_apis must be true.
If sdk_version is not empty, platform_apis must be false.
Test: soong test
Test: m
Bug: 132780927
Change-Id: I7ba702d616404d155f8ac40cd008828663ad1488
Reduce boot image space taken from 28803072B -> 9572352B (-20MB).
No reason to have this be configurable yet.
Test: ls -l $OUT/system/framework/*/apex*.art | awk '{s += $5} END {print s}'
Bug: 77863440
Change-Id: I280b740dfbd001109ce1e288e395595f21567aa6
Use Kythe (https://kythe.io) to build cross reference for the Android
source code. ~generate the input for it during the build. This is done
on demand: if XREF_CORPUS environment variable is set, build emits a
Ninja rule to generate Kythe input for each compilation rule. It
also emits two consolidation rules (`xref_cxx` and `xref_java`),
that depend on all Kythe input generation rules for C++ and Java.
The value of the XREF_CORPUS environment variable is recorded in the
generated files and thus passed to Kythe. For the AOSP master branch it is
`android.googlesource.com/platform/superproject`, so the command to build
all input for Kythe on that branch is:
```
XREF_CORPUS=android.googlesource.com/platform/superproject m xref_cxx xref_java
```
Each Kythe input generation rule generates a single file with .kzip
extension. Individual .kzip files have a lot of common information, so
there will be a post-build consolidation step run to combine them.
The consolidated .kzip file is then passed to Kythe backend.
The tools to generate .kzip files are provided by Kythe (it calls them
'extractors'). We are going to build them in toolbuilding branches
(clang-tools and build-tools) and check them in as binaries into master
and other PDK branches:
For C++, `prebuilts/clang-tools/linux-x86/bin/cxx_extractor`
for Java, `prebuilts/build-tools/common/framework/javac_extractor.jar`
Bug: 121267023
Test: 1) When XREF_CORPUS is set, build generates Ninja rules to create
.kzip files; 2) When XREF_CORPUS is set, building
`xref_cxx`/`xref_java` creates .kzip files; 3) Unless XREF_CORPUS is
set, build generates the same Ninja rules as before
Change-Id: If957b35d7abc82dbfbb3665980e7c34afe7c789e
* changes:
Add defaults_visibility support
Refactor visibility to support visibility on defaults modules
Add DefaultsModule interface
Improve documentation of defaults mechanism
Clang derives the value of __ANDROID_API__ from the triple these days. In a
future version of clang I plan to start making the behaviour of the HWASAN pass
dependent on the API level in the triple, so it's going to need to be accurate.
Test: walleye-userdebug boots
Change-Id: Ie5e36b5c8f6dcda084cc12b1160abbdf94765174
Dan Willemsen