AUX build environent is volatile and is only instantiated in
a context of AUX-aware module.
link-type checking is happening outside such context, and
is not able to correctly determine AUX build dependencies.
1. Save enough of context in LINK_TYPE variable;
Use AUX-<variant-name> instead of AUX
2. Load correct set of AUX meta build vars before
building link_type rules
Bug: 62060489
Test: make auxiliary
build no longer tries to access "/STATIC_LIBRARIES" path
Change-Id: I9764d4a0740da1c55a6f8429398872fc4362942c
(cherry picked from commit 55ebe631b4)
This reverts commit 9b99ddc8a5.
and add syste-qemu.img to the dependency list of sdk target
BUG: 64235252
Test: build sdk target successfully
(cherry picked from commit f0d50bbef0)
Change-Id: I813233c7c3f06eb1eca18aad5ea890a55814eb1b
- Partners building java test using legacy test API needs it.
bug: 64121067
Test: make platform-java and check if library is in platform.zip
Change-Id: If831f8cc89a386ccb51f46935667057efb3cdf91
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
Merged-In: Id8d0d01313c63496a10de4cd3ddb9f75180efef6
Change-Id: Id8d0d01313c63496a10de4cd3ddb9f75180efef6
(cherry picked from commit a9c4c71756)
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
Merged-In: 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
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
