The prebuilts and defaults mutators start adding some dependencies, so
for them to be able to reference imported modules, we need to
run the namespace mutator earlier.
Test: m nothing
Test: Try to use a global defaults module from a namespace
Change-Id: I6e853d20e32251d0fd33c8b2dcc26c0695b808fd
Bug: 64195575
Test: succeeded building product.img with BOARD_PRODUCTIMAGE_PARTITION_SIZE,
BOARD_PRODUCTIMAGE_FILE_SYSTEM_TYPE and PRODUCT_PRODUCT_VERITY_PARTITION.
Change-Id: Icc4f8c16bc389fe20db680849f311d02df1299c3
PLATFORM_SYSTEMSDK_VERSIONS is the list of System SDK versions that the
platform is supporting. Contrary to the public SDK where platform
essentially supports all previous SDK versions, platform support only a
few recent System SDK versions, since some of old System APIs are
gradually deprecated, removed from the following SDKs and then finally
deleted from the platform. This will be part of the framework manifest.
The list can be specified by setting PLATFORM_SYSTEMSDK_MIN_VERSION. If
it is set to an old version number, then System SDKs from the version
to the current version (PLATFORM_SDK_VERSION) are considered to be
supported by the platform. If PLATFORM_SYSTEMSDK_MIN_VERSION is not set,
only the latest System SDK version is supported.
Next, BOARD_SYSTEMSDK_VERSIONS is the list of System SDK versions that
the device is using. This is put to the device compatibility matrix
device is using. The device and the platform is considered as compatible
only BOARD_SYSTEMSDK_VERSIONS in the device compatibility matrix are
in the PLATFORM_SYSTEMSDK_VERSIONS in the framework manifest.
When BOARD_SYSTEMSDK_VERSIONS is set, a Java app or library in vendor or
odm partitions which didn't specify LOCAL_SDK_VERSION is forced to use
System SDK. Also, the build system does the additional integrity check
to ensure that LOCAL_SDK_VERSION is within BOARD_SYSTEMSDK_VERSIONS or
PLATFORM_SYSTEMSDK_VERSIONS (if BOARD_SYSTEMSDK_VERSIONS isn't set).
Bug: 69088799
Test: m -j
Test: BOARD_SYSTEMSDK_VERSIONS=P m -j
Change-Id: Id38f02b4be86710411be22bc28109e6894f8a483
Handle paths variable provided from Make about where integer overflow
sanitization should be enabled by default, and prepare to enable minimal
runtime diagnostics for integer overflow sanitizers in userdebug/eng builds.
This provides Soong support for on-by-default paths from Make for
integer overflow sanitization.
Bug: 30969751
Bug: 63927620
Test: Include paths passed from Make are being sanitized.
Test: Compilation succeeds with and without diagnostics enabled.
Test: See Make patch for further test notes.
Change-Id: I803a75646cc27ef5b4b5b74b8eb2981c39f8a6a3
This build function is unnecessary now that GCC is completely
unsupported for Android platform builds. It is similar to
USE_CLANG_PLATFORM_BUILD from the build/make side of things.
Bug: http://b/64032869
Test: Builds
Change-Id: Iddf5f91cc997c337c77a644265cb8dc4e5a915b4
This architecture only existed for unbundled use, but even the NDK is
removing support in their r17 release, so just remove support for it.
Test: build/soong/build_test.bash -only-soong
Change-Id: I4bd23babf567128d2d242cbdee3311abb198dd7c
This is cherry-picked from attempt 3, which was reverted
due to http://b/70862583.
Before this CL topic, the build toolchain for .java source files
used OpenJDK 8, targeting 1.8 (v52 class files) by default.
This CL topic switches the default to OpenJDK 9, but still
targeting 1.8 (v52 class files) by default. If USE_ERROR_PRONE
is set to true, then the default remains OpenJDK 8.
Code in the Android platform should generally be unaffected,
but if host tools that are now compiled and run using
OpenJDK 9 are causing problems for your team, then let me
know.
To manually switch back to the old behavior for now (continue
using OpenJDK 8), run this command in your shell:
export EXPERIMENTAL_USE_OPENJDK9=false
Bug: 69449021
Test: Treehugger
Test: art/test/testrunner/run_build_test_target.py -j40 art-interpreter
Test: dalvik/dx/tests/run-all-tests
(cherry picked from commit 13f23a2753)
Change-Id: I57abae73f9bdb21ef004a5118ff0e4ef70418ed9
Merged-in: Iac78122f58df0ebbb55134d55021ce6c57351b5f
This is cherry-picked from attempt 3, which was reverted
due to http://b/70862583.
Before this CL topic, the build toolchain for .java source files
used OpenJDK 8, targeting 1.8 (v52 class files) by default.
This CL topic switches the default to OpenJDK 9, but still
targeting 1.8 (v52 class files) by default. If USE_ERROR_PRONE
is set to true, then the default remains OpenJDK 8.
Code in the Android platform should generally be unaffected,
but if host tools that are now compiled and run using
OpenJDK 9 are causing problems for your team, then let me
know.
To manually switch back to the old behavior for now (continue
using OpenJDK 8), run this command in your shell:
export EXPERIMENTAL_USE_OPENJDK9=false
Bug: 69449021
Change-Id: Iac78122f58df0ebbb55134d55021ce6c57351b5f
Test: Treehugger
Test: art/test/testrunner/run_build_test_target.py -j40 art-interpreter
Test: dalvik/dx/tests/run-all-tests
Add a method on ModuleContext and TopDownMutatorContext to visit
direct dependencies that have a given dependency tag.
Test: m checkbuild
Change-Id: Ib875563091dcae6b7282b3e3427d0eb07d8c8af5
After this revert CL topic, the default toolchain for Android
goes back to being OpenJDK 8.
This revert is being prepared ahead of time in case of
any problems with original change topic.
Bug: 69449021
Test: Treehugger
Change-Id: Idbaefeb5b88ecb5d5168e6b9b4a120f80dedd5b6
This is cherry-picked from attempt 2, which was reverted
due to http://b/70521453 and other issues.
Before this CL topic, the build toolchain for .java source files
used OpenJDK 8, targeting 1.8 (v52 class files) by default.
This CL topic switches the default to OpenJDK 9, but still
targeting 1.8 (v52 class files) by default. If USE_ERROR_PRONE
is set to true, then the default remains OpenJDK 8.
Code in the Android platform should generally be unaffected,
but if host tools that are now compiled and run using
OpenJDK 9 are causing problems for your team, then let me
know.
To manually switch back to the old behavior for now (continue
using OpenJDK 8), run this command in your shell:
export EXPERIMENTAL_USE_OPENJDK9=false
Bug: 69449021
Test: Treehugger
Test: art/test/testrunner/run_build_test_target.py -j40 art-interpreter
Test: dalvik/dx/tests/run-all-tests
(cherry picked from commit 13f23a2753)
Change-Id: I57abae73f9bdb21ef004a5118ff0e4ef70418ed9
Added three properties (soc_specific, device_specific, and
product_specific) that shows what a module is specific to.
`soc_specific: true` means that the module is specific to an SoC
(System-On-a-Chip) and thus need to be installed to vendor partition.
This has the same meaning as the old `vendor: true` setting.
`device_specific: true` means that the module is specific to the entire
hardware configuration of a device includeing the SoC and off-chip
peripherals. These modules are installed to odm partition (or /vendor/odm
when odm partition does not exist).
`product_specific: true` means that the module is specific to the
software configuration of a product such as country, network operator,
etc. These modules are installed to oem partition (or /system/oem when
oem partition does not exist). These modules are assumed to be agnostic
to hardware, so this property can't be true when either soc_specific or
device_specific is set to true.
Bug: 68187740
Test: Build. path_tests amended.
Change-Id: I44ff055d87d53b0d2676758c506060de54cbffa0
We don't support armv5 any more, and we can't build bionic as armv5.
Test: build/soong/scripts/build-ndk-prebuilts.sh
Bug: https://github.com/android-ndk/ndk/issues/272
Change-Id: I4026d48e7d5db78f6aa4e9796da1ec9cf10021ca
Straightforward way of expressing policy inspired by a similar
syntax in SELinux.
Bug: 70165717
Test: no neverallows hit
Test: manually checking neverallow rules by changing them/adding violations
Change-Id: I7e15a0094d1861391bfe21a2ea30797d7593c142
The first include directory affects where protoc places the
output files. Ensure -I . is always the first protoc argument.
Bug: 70704330
Test: m checkbuild
Change-Id: I4992e4074f612409865e6e18dc8993c6f68385fd
This variable is being broken up because it isn't well
defined, and breaking it into smaller components makes
device bringup easier.
Bug: 62019611
Test: nothing uses it
Change-Id: I748958b7276f607f8a711289f3bde163a1a56596
