There are two parts to this change.
Normalization: If a module specifies 'java_version: "9"', this is now
normalized into 'java_version: "1.9"'. Users might reasonably assume
that "9" should be valid, since javac treats them as synonyms (and, in
fact, the javac documentation lists "9" as a valid value but doesn't
mention "1.9"). However, the soong code that triggers JPMS support
(i.e. setting -system rather than --boot-class-path) looks for the
string "1.9", so prior to this change modules specifying "9" would
fail with a confusing error ('javac: option --boot-class-path not
allowed with target 1.9'). Normalizing "9" to "1.9" fixes this. (The
change normalizes the other supported values, too, for consistency.)
Validation: This change also makes the build fail-fast with a clear
error message for invalid values. In particular, modules specifying
"10" or "11" fail with an explicit message that this is not supported,
in anticipation of the switch to OpenJDK 11. Prior to this change,
modules setting those values would get the confusing
'--boot-class-path not allowed' error described about since JPMS
support would not be triggered. (That could be fixed by changing the
JPMS logic to trigger on "10" and "11", but that would be dangerous
since support in the rest of the system for v54 and v55 class files is
unproven: it is better to fail explicitly.) (This change also makes it
fail-fast for any unrecognized values.)
Test: make java
Test: make targets with java_version set to "1.8", "8", "1.9", and "9", all succeed ("9" fails without this change)
Test: make targets with java_version set to "10" and "11", fail with the explicit "not supported" message
Test: make target with java_version set to "xxx", fails fast with the "unrecognized" message
Bug: 131683177
Change-Id: I2f5eb496c29d7736c68c01401c3f0967aeae99fc
This prevents SystemConfig from trying to read them. Also removed ' ' prefix+postfix when creating an empty config.
Bug: 140074769
Bug: 140092095
Test: Flashed device, no more "SystemConfig: Tag compat-change is unknown..." warnings in logcat
Change-Id: I374826526fe3e4555474688b65a0be7253c6dd8c
The new option will allow the auto-generated test config for cc_test to
include RunCommandTargetPreparer to disable framework before the test
run and re-enable it after the test run.
Bug: 140065309
Test: test hello_world_test with the new option.
Change-Id: If2189e9474f5b11bd0d0471e231a2cae14155389
Adds support to Soong for building rust modules. This currently only
supports x86_64 device and x86 linux host targets. The functionality
is sufficient to build crosvm.
Bug: 136189233
Test: Test module builds.
Test: crosvm builds.
Change-Id: I6ea04615834a6d673578ab10ea1a2eb04259fe09
This includes a few changes that make AndroidMkEntries more resemble
AndroidMkData, especially in terms of how extra entries are added.
Most importantly it can now have multiple custom functions.
Test: Soong tests
Change-Id: Ibf9102624d16d0c1c9894a2794fc7c797bb34c9a
Disables FORTIFY for fuzz target builds. We generally build with a
sanitizer and want the sanitizer to handle the bugs and provide us with
a nice stack trace.
Bug: 140187921
Test: m example_fuzzer && $ANDROID_HOST_OUT/fuzz/example_fuzzer (note
that you get a proper ASan report instead of a fortify crash)
Change-Id: I15a117b26c401a03785fb44c0f796588f366bc55
Builtin APEXes (/system, ...) don't need hashtree.
So if we remove hashtree from builtin APEXes we can save more space in
/system.
However, this change only affects to the apex bundles which are built
from source, not from prebuilts.
Removing hashtree from prebuilts will be handled in a follow CL.
Bug: 139957269
Test: m
Test: see if /system/apex/*.apex have hashtree
Change-Id: Id755382b2153bf6bbaf2c480f3bbb91b6f62a564
Usually, ".S" files are processes with the c preprocessor, and ".s"
files are not, so they don't have any dependency information, since it
is generated by the preprocessor.
But with the -xassembler-with-cpp flag, ".s" files are processed with
the preprocessor, so we should ask for dependency information from them.
Test: NINJA_ARGS="-t deps out/soong/.intermediates/external/sonivox/arm-wt-22k/libsonivox/android_arm_armv7-a-neon_core_static/obj/external/sonivox/arm-wt-22k/lib_src/ARM-E_filter_gnu.o" m
Test: treehugger
Change-Id: Iee7baeebc2b205b5a2f33e7c1705ea4a5b4fc95a
Instead of just making this an error when building for the device, also
turn on this error for host builds. This is more important as we begin
to use remote caches during the build.
Test: treehugger
Change-Id: I6fcc945464032d951729aead540ea77850c88c41
Allow modules to depend on the flattened flavor of an APEX package
using `module.{flattened}` (returning the output install path of the
flattened APEX).
Also add this flattened output install path as an implicit output
dependency of a flattened APEX phony module.
Test: m checkbuild
Bug: 139277987
Change-Id: I8c55d5ff2922a36fcc8ec0819fbe3e93a772ef8a
Merged-In: I8c55d5ff2922a36fcc8ec0819fbe3e93a772ef8a
Allow the `enabled` Soong/Blueprint property (e.g. in `genrule` and
`cc_prebuilt_binary` module definitions) to have a different value
when APEX flattening is enabled.
Test: m checkbuild
Bug: 139277987
Change-Id: Ic586bdfac7690077445da12543154381d92cf98e
Merged-In: Ic586bdfac7690077445da12543154381d92cf98e
If no_apex module is static library, this module is not included to
filesInfo. So add a check tat the static library is no_apex among
indirect dependencies.
Bug: 139016109
Test: m -j
Change-Id: I46ddf099715aea0e088027a1141e282969cef0e1
am: 309b9c02a5 -s ours
am skip reason: change_id I9d25f5dc64299e666527ca8e23d7233966901c4e with SHA1 2f791a246b is in history
Change-Id: I81e12d32e81b2e05e46d7140ad908399240896dd
am: 0f60062cb5 -s ours
am skip reason: change_id I62ff2a7dd3943d9a3d95d91c36a30fd44ea467d2 with SHA1 6d3550cbe6 is in history
Change-Id: I916c3d6f844ee4a97bf44dd21698886c934cf8a0
