We used to check for 'attr >> 16 == 0xa1ff' (i.e. 0o120777) to detect
symlinks in the input target_files zip (TF.zip). This becomes broken
after we switch to soong_zip, which packs symlinks with 0o120700.
This CL fixes the issue by using stat.S_ISLNK() instead.
Note that we don't need to stage the files with the exact permission
bits as in the input TF.zip. Because this part is covered by mkbootfs
by using the canned or the compiled-in fs_config - as long as the
files/directories are accessible and the symlinks are created.
Bug: 38455129
Test: sign_target_files_apks.py on bullhead TF.zip. Check the
checksums in SYSTEM/bin/install-recovery.sh.
Change-Id: I51c1fc9a257fb3f18c16c2ed71528abaa6f7d9c9
(cherry picked from commit 406050bdb6)
Allow using a host java library as an intermediate processor step
after javac but before desugar, proguard, or dx.
Test: manual
Change-Id: I7fb843e10d96c0167f6e4371582fabcc1454521f
This CL resubmits a fixed version of commit
e2a8da2683.
This CL applies the following changes:
- explicitly set the path where desugar will dump temporary class files.
This ensures that the system property is set before it is read during
InnerClassLambdaMetafactory.<clinit>. Before this CL, the system
property was set by Desugar.createAndRegisterLambdaDumpDirectory(),
which may run too late.
- explicitly specify -source 1.8 for droiddoc's javadoc run.
Previously, the command used the language version of the build
toolchain, which might fail due the backward-incompatible restrictions
imposed by the proposed module system.
Some Android build targets use LOCAL_JAVA_LANGUAGE_VERSION 1.7,
but droiddoc combines sources from multiple build targets and there
where no backwards incompatible changes in 1.8, so it should be fine
to use 1.8 for code from either language level.
Bug: 38318052
Bug: 38225656
Bug: 38177295
Test: make clean && make ANDROID_COMPILE_WITH_JACK=false checkbuild tests \
&& make checkbuild tests
(using OpenJDK 8 toolchain)
Change-Id: I2fffe6668747f48be44e34c67332af9b8a996d2a
Some cts, doclava and javassist code uses private APIs that require
tools.jar to be on the classpath when building with the standard
OpenJDK 8 toolchain. However, OpenJDK 9 toolchains do not have this
file nor require it to be on the classpath. The reliance on the
presence of tools.jar means that AOSP can currently not build on
such toolchains.
After this CL, when EXPERIMENTAL_USE_OPENJDK9 is set, the value of
HOST_JDK_TOOLS_JAR is empty.
That flag can be set via:
export EXPERIMENTAL_USE_OPENJDK9=true
and unset via:
unset EXPERIMENTAL_USE_OPENJDK9
Test: make checkbuild (using OpenJDK 8 toolchain)
Test: manually confirmed that device boots
Bug: 38177295
Change-Id: Icc5451b51e44a574fd21024d434ed1fa8711de17
Required to preserve sane defaults for old codebases.
Test: inspect soong.variables
Test: ensure PRODUCT_SHIPPING_API_LEVEL is set in config.mk
Bug: 38415912
Merged-In: I0244fb02754663be3106391c9360fd1b2cc00d4a
Change-Id: I0244fb02754663be3106391c9360fd1b2cc00d4a
So that the SONAME will match the actual installed name. This allows two
shared libraries (with different LOCAL_MODULE names) to be built with
the same name, but in different locations. So to partially emulate
Soong's vendor_available, you could define:
include $(CLEAR_VARS)
LOCAL_MODULE := libmyutils
...
include $(BUILD_SHARED_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libmyutils_vendor
LOCAL_VENDOR_MODULE := true
LOCAL_INSTALLED_MODULE_STEM := libmyutils.so
...
include $(BUILD_SHARED_LIBRARY)
All of the users would need to explicitly use libmyutils vs
libmyutils_vendor based on how their runtime lookup paths are going to
work, but it will install into both places:
/system/lib/libmyutils.so
/vendor/lib/libmyutils.so
Bug: 38225484
Test: Example similar to above, ensure DT_NEEDED / DT_SONAME are correct
Test: multiproduct_kati to verify the only module this changes on
master is libart_fake
Change-Id: Ifa4b8adff50d8b5a754c70ce8e865b05f9889c6c
Clear fs_config_generate_extra_partition_list after use.
Test: build fs_config_files and fs_config_dirs targets.
Change-Id: Ie18bcd2df2ff1becb178e9ba45d226e2e9a8faab
Signed-off-by: William Roberts <william.c.roberts@intel.com>
