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
If PLATFORM_VNDK_VERSION has a version $VER other than "current",
install current VNDK libs to /system/lib[64]/vndk[-sp]-$VER.
Otherwise, they will be installed to /system/lib[64]/vndk[-sp].
Bug: 69883025
Test: device boot
Change-Id: Ifa8564f39687dab5b407bf2178b13022625a94f3
Add a rule in soong that re-executes soong_build in order to
generate build documentation. This allows Soong to customize
the documentation.
Bug: 70516282
Test: m soong_docs
Change-Id: If143cfacd6ac20274cd7bb8d8fab0c07025a5553
Make the currently-unused SingletonContext.Rule match
ModuleContext.Rule and take a blueprint.RuleParams instead
of an android.RuleParams, and delete android.RuleParams.
Test: m checkbuild
Change-Id: I018685a3dc13f60825b5ba383ef365df2bc98dfc
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 CL topic:
https://r.android.com/#/q/topic:bug69449021_attempt2
Bug: 69449021
Test: Treehugger
Change-Id: I9ead8d569226bd487baee3c6d5be9ec7033eb56a
(This is cherry-picked from the first attempt to submit this CL
topic, which was reverted after 3 hours because of bug 70286093;
robolectric 3.{1.1,4.2} now stick with OpenJDK 8 to avoid that bug).
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: Running robolectric tests succeeds on internal-master
after cherry-picking this CL topic, using the command
line from http://b/70286093#comment1
(cherry picked from commit 0ae8b548af)
Change-Id: Ide6a7e55126d919a44f89ef8e0bd14fb12ff470e
Logtags files in cc and java are treated fundamentally differently.
In cc, they are not used for compiling at all, but need to be passed
to Make to be combined into the global logtags list, and logtag files
are listed in a logtags property. In java they are listed in srcs
and produce generated code that is compiled in, and so shouldn't
also need to be listed in a logtags property.
Move the logtags property to cc and export it to Make from there,
and have java extract logtags files from srcs to be exported to
Make.
Test: m checkbuild
Change-Id: I31d49289efe72db60d2f33566df771b4a3ebc8a0
Add a common_first multilib type and use it for java.Binary
so that the java part is compiled as a "common" arch type
but the wrapper script is installed as a "linux_glibc" arch
type. This allows java_binary to be used as a tool dependency
for a genrule.
Bug: 68397812
Test: TestJavaBinary
Change-Id: I809060839ce8878300da3fb76426ceb1ea6b0e8e
This allows TestModule.Output("foo") to be used to find
a file called "foo" that was installed using ctx.InstallFile.
Test: soong tests
Change-Id: I04833c9ee8ac5baa6b6afd35715d1191c1622a78
Debugging when writing tests using TestModule.Outputs is
unnecessarily hard, it panics when an incorrect output path
is given but doesn't provide any help to figure out why.
Follow the pattern used by TestContext.ModuleForTests
and print the list of valid output paths on failure.
Test: m checkbuild
Change-Id: I50e8e2dfc2070bd538d47cf6495a489f727b1564
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,
https://r.android.com/#/q/topic:bug_69449021
Bug: 69449021
Test: Treehugger
This reverts commit 0ae8b548af.
Change-Id: Ief7646a94f1a264085cd299b4327d244b78a1537
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: "make core-oj", checked that compilation now uses
OpenJDK 9 javac -target 1.8
Test: Checked that this is still compiled using OpenJDK 8.
export EXPERIMENTAL_USE_OPENJDK9=false
make core-oj
Change-Id: Ic87e9bb2a2e5da0ff13a2e51845b5365901c1507
