Soong now adds .vendor suffix only for modules having both core and
vendor variants. Furthermore, names listed in LOCAL_SHARED_LIBRARIES
are correct (= have .vendor suffix when the dependent lib has variants).
Therefore, make does not need to force add .vendor suffix when parsing
modules from soong.
Bug: 37480243
Test: BOARD_VNDK_VERSION=current m -j <name> is successful, where <name>
is one of the vendor-only libraries in Soong. (i.e.
android.hardware.renderscript@1.0-impl)
Test: m -j does not break anything
Change-Id: Id8d0d01313c63496a10de4cd3ddb9f75180efef6
Enabled via:
export EXPERIMENTAL_USE_OPENJDK9=true
Other nonempty values of EXPERIMENTAL_USE_OPENJDK9 will
allow OpenJDK 9 toolchains, but will still default to
-source 1.8 and -target 1.8.
Note that -source 1.9 and -target 1.9 does not currently
successfully build.
Test: Treehugger.
Bug: 38177569
Experimental flag to set LOCAL_JAVA_LANGUAGE_VERSION := 1.9
Change-Id: I9eb881b3fbd1806984a132f6da7b5a4cc6612247
This saves 20-50ms for `lunch` (~7-10%), and double that for every build
execution.
Test: Check HOST_OS_EXTRA on Linux & Mac
Change-Id: I863200b2287c8867f40606237895b1d3ad91e1b3
All users of this variable have been removed. This command was adding
50-175ms to `lunch` (~15-30%), and was running at least twice (serially)
in every build too.
Test: cs/HOST_JDK_IS_64BIT_VERSION
Test: prebuilts/jdk/jdk8/linux-x86/bin/java -version, is 64-bit.
Change-Id: Ifdd9663b010ec45918b29ac037849f49c8cd8f69
Android bundles an OpenJDK-derived toolchain to avoid issues with
unsupported toolchains. For development / experiment purposes, this
CL the toolchain to be overridden via OVERRIDE_ANDROID_JAVA_HOME.
It is an error for OVERRIDE_ANDROID_JAVA_HOME to be set but not
point to a valid toolchain, but this error is not explicitly
checked for.
Bug: 38177295
Test: Treehugger
Change-Id: I72f641f560501e498f9c86a4380f19941fca11ad
Write into a temp file, then use `cmp` to determine whether to update
the actual file. This means that we'll only run Kati twice on a clean
build, since we'll omit the redundant write during the regeneration
check.
Simplify writing using $(file >) instead of $(shell), which doesn't have
character count limitations.
Bug: 35970961
Test: m clean; m -j nothing; m -j nothing; m -j nothing
Test: Ensure clean_steps.mk is equivalent before/after
Change-Id: Id574f416647434ab8d11ed3481da21b55e8797b7
Export JAVA_HOME as an absolute path to commands running inside
a build.
Should fix errors invoking gradle from inside a build:
ERROR: JAVA_HOME is set to an invalid directory: prebuilts/jdk/jdk8/linux-x86
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.
Test: treehugger
Change-Id: I16e4482b2d74ede0843715be3b08c65ce33cf403
This attribute has been removed from public policy and is no longer
available.
Bug: 38316109
Test: build policy
Change-Id: I3407ced2d725de982e19b77345827de03d93c426
(cherry picked from commit ec488e1fee)
The mac implementation of sed has different requirements for the -i
option. Instead of using that, just redirect the output to the final
location of modules.dep, since it's being copied in the very next
line anyway.
Bug: 38268091
Test: run build with kernel modules on macOS
Merged-In: I49e4a1a69f01139ef47711ab1223d3a8e5cda568
Change-Id: I49e4a1a69f01139ef47711ab1223d3a8e5cda568
In BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS, if we have defined
"--include_descriptors_from_image" with an image file whose path points
to source tree, add_img_to_target_files.py or sign_target_files_apks.py
may fail to find the file. Because these scripts may run without a
source tree, by taking target_files.zip as the only input.
This CL scans additional locations in the input target_files.zip to find
those missing files in avb_vbmeta_args. As long as the files are included
in the target_files.zip, they get a second chance to be found.
Bug: 63910867
Test: As follows:
1. Setup BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS with a local file path;
2. Remove the local file;
3. sign_target_files_apks.py fails without this CL;
4. sign_target_files_apks.py works.
Change-Id: I3c58f80a5535db02b74cfe40d0c0beff72587cf8
(cherry picked from commit 1dc5d47653)
INTEGER_OVERFLOW_EXCLUDE_PATHS should only apply to the global sanitizer
setting, and should not override local module settings. This pulls out
the check so it occurs earlier and does not interfere with local
settings. This makes Make consistent with Soong's behavior as well.
Bug: 30969751
Test: Created a test build file with this explicitly set, excluded the
path, and checked if it was still being sanitized.
Change-Id: I9020d92bae136b6087d37f71d5337acaefe850b4
Ubsan is currently support ARM/ARM64,
so It's OK to enable the build Flag
Test: build test module with flags in Android.mk:
LOCAL_SANITIZE := undefined
LOCAL_SANITIZE_DIAG := undefined
BUG:38250996
Change-Id: I6c640bad67353cc736640b2e3c4a0b1812dde3fc
Desugaring try-with-resources is not necessary for platform builds,
and triggers some problems for apps built as part of the platform
that target SDK versions before 19. Disable all try-with-resource
desugaring.
Bug: 63180735
Bug: 63900665
Bug: 63901645
Test: m -j ANDROID_COMPILE_WITH_JACK=false checkbuild
Change-Id: I98b827aa1e80b43e6eb7b58254c23c7a4f7dc52d
full_java_lib_deps has trailing whitespace if $(LOCAL_CLASSPATH)
is empty. Because the calculation of PRIVATE_CLASSPATH was
missing a $(strip ...), this resulted in an (unintentional)
trailing ':' in the values of the -classpath and -sourcepath
arguments to the javadoc tool, which that tool is documented
to interpret as '.' (the working directory).
This CL converts the expression to a call to normalize-path-list,
from definitions.mk, which contains the $(strip ...):
define normalize-path-list
$(subst $(space),:,$(strip $(1)))
endef
After this CL, an empty $(LOCAL_CLASSPATH) no longer gets
misinterpreted as the current working directory.
This issue was minor (it made no difference in practice).
Test: Treehugger
Bug: 62049770
Change-Id: Ia0e3e5657d0fa057fe998515f34bc7b8df5f6f16
Point the make java variables at JDK prebuilts in
prebuilts/jdk/jdk8, add them to the path, and clean up
some old overrides.
Reapplies Ibbeb30fab96e45aedd5bb6d710d1170f85789982 after updating
some more manifests to include the prebuilts.
Bug: 62956999
Test: m -j checkbuild
Change-Id: I9e27aa5cb04d1ed09e43b798e5d654843afc000f
(cherry picked from commit 1931750940)
When BOARD_VNDK_VERSION is set, native libs that were labeled as
native:platform are now divided into native:platform and native:vendor
sets depending on their install locations. In order to keep the existing
apks to use all the libraries that they have been using, native:vendor
is also added to the allowed types for apks.
However, in the future when we have vendor SDK and enforce all vendor
apks to use the vendor SDK, we will disallow native:vendor to
app:platform and native:vendor will be allowed only to those vendor apks
(probably labeled as app:vendor).
Bug: 33241851
Test: BOARD_VNDK_VERSION=current m <a vendor lib using vendor jni>
(e.g. ModemDiagnosticSystem in internal master)
Change-Id: I6ad0967ab17f07be9657b58c20fa9b96bd1a342b
Add support for excluding paths from having integer_overflow applied to
them when using SANITIZE_TARGET=integer_overflow via an
INTEGER_OVERFLOW_EXCLUDE_PATHS make and product variable. This covers
the make side of the change.
Bug: 30969751
Test: Build with SANITIZE_TARGET=integer_overflow
SANITIZE_TARGET_DIAG=integer_overflow
INTEGER_OVERFLOW_EXCLUDE_PATHS=<path> and confirmed this was no
longer being applied to binaries in that path.
Change-Id: I24e328257bc5a7962024c8676a1e23d7d70a8666
The extension directory defaults to lib/ext and does not
exist by default. Setting it to the empty string de facto
disables this obsolete feature.
AOSP is moving to a hermetic toolchain so this argument
will stop working soon. Further, OpenJDK 9 javac no longer
supports this command line argument when compiling for
-source 1.9 -target 1.9.
This command line argument has been around since the
earliest versions of Android, but is now obsolete.
This CL drops it.
Bug: 63746471
Test: Treehugger
Change-Id: Ia0214c1b192e3ffda10772d777557a81ce346c03
OpenJDK 9's javadoc tool doesn't support the -bootclasspath
command line option, even with -source 1.8.
Instead, under OpenJDK 9, javadoc needs to be passed a
--patch-module argument to tell it the location of the
classes patching packages from java.* modules.
The source files in libcore/{dalvik,libart,luni,ojluni} and
external/icu/android_icu4j that go into PRIVATE_BOOTCLASSPATH
patch packages from the modules java.base, java.desktop,
java.logging, java.prefs, java.sql, jdk.net, and
jdk.unsupported. However, this CL takes the simpler approach
of placing them all in java.base, which appears to work for
the purposes of the javadoc run.
Test: Ran the following both on OpenJDK 8 toolchain and on
OpenJDK 9 (with EXPERIMENTAL_USE_OPENJDK9=true):
rm -rf out/target/common/docs/ && make docs
Test: Compared (via meld) the contents of out/target/common/docs
for the two toolchains (there were some differences, see bug).
Bug: 62049770
Change-Id: If3dd927477ca32dab7ffb528350de872e1017184
Tobias Thierer