Currently we're building the boot/recovery image twice, which is
redundant. And b/38455129 shows a problematic case when the image
from two builds doesn't match. We should only build the recovery
image once in the add_img_to_target_files.
Bug: 62021378
Test: call sign_target_files_apk on an angler target file,
recovery-from-boot.p generates successfully; and SHA of recovery.img
matches the one in install-recovery.sh.
Change-Id: I01e033501d80c18a87cbb870300eee5c19a04441
If we pass "rebuild_recovery" to add_img_to_target_files, the recovery
patch is rebuilt. But related files under SYSTEM/ (e.g.
SYSTEM/recovery-from-boot.p && SYSTEM/bin/install-recovery.sh) are not
updated.
This may cause a mismatch between system.img and SYSTEM/, and
may lead to a failure in validate_target_files.py.
Bug: 62096364
Test: Rebuild the system image in the TF and observe the recovery files
under SYSTEM/ get updated.
Change-Id: I7d679a612a86d02cf2eff81d1d120c0067138ed9
Bug: 38342163
- obj/lib is deprecated and TARGET_OUT_INTERMEDIATE_LIBRARIES will be
removed. We need to use per-module intermediates directory instead.
- prebuilts/ndk/current folder is gone. For libm and libc, we just
need ndk/r10 as stub libs for linking.
Test: mm and made sure this does not affect on device target.
Test: make -j50 FORCE_BUILD_RS_COMPAT=true RSTest_Compat works as
expected.
Change-Id: I8fbf5c10322707849a23c6b0dacc28b028db451e
This way we'll share ninja files with the equivalent normal configs. We
were already parsing them in the make config step in order to fix
TARGET_PRODUCT / TARGET_BUILD_VARIANT / TARGET_BUILD_APPS, now they
replace themselves in MAKECMDGOALS with the appropriate goals.
If we're not going to pass any goals to ninja, pass the default goal.
Test: ALLOW_MISSING_DEPENDENCIES=true m -j APP-Calculator
Test: m -j PRODUCT-aosp_fugu-eng
Test: m -j PRODUCT-aosp_fugu-eng sdk
Test: m -j PRODUCT-aosp_fugu-sdk
Test: lunch aosp_arm64-userdebug; m -j
Test: lunch aosp_arm64-userdebug; m -j dist
Test: lunch aosp_arm64-userdebug; m -j adb
Change-Id: I73787aff9f74aed328e3fa75c571ae15a28851b0
showcommands is all handled in soong_ui, make/kati/ninja never see the
argument.
Remove the dist goal, since we'll never pass it to ninja, only to Kati
as a modifier.
Remove DUMP_%, since that's not used anywhere (it appears to be in our
code search via the NDK build system)
Test: m -j showcommands dist
Change-Id: I0d1498128caece685e98c2c2b5b0c3f545da0e11
signapk relies on internal APIs sun.security.{pkcs,x509},
for example in com.android.apksig.internal.apk.v1.V1SchemeSigner.
This breaks at signapk runtime under OpenJDK 9 because those
packages are not exported by the java.base module.
This CL unbreaks signapk by allowing it to access these internal
packages. In the long term, signapk should migrate away from these
internal APIs (bug 37137869).
Test: make ANDROID_COMPILE_WITH_JACK=false checkbuild tests \
&& make checkbuild tests
(with OpenJDK 8u45 toolchain on the PATH)
Test: make EXPERIMENTAL_USE_OPENJDK9=true \
ANDROID_COMPILE_WITH_JACK=false checkbuild
(with jdk 9-ea+170 toolchain on the PATH)
Bug: 37137869
Bug: 38177295
Change-Id: I64cab83e6eb7b135cf2ad7b523736cb409aaae02
Also enable ALLOW_MISSING_DEPENDENCIES when TARGET_BUILD_PDK is set
so that soong modules can reference modules that are disabled in the
PDK.
Test: builds
Bug: 62086238
Change-Id: Ic43e843a717b802ace0cee568b9e7e561a6c0868
Desugar reflects over internal APIs at runtime, using the
java.lang.invoke.MethodHandles.Lookup API.
On OpenJDK 9 toolchains, such reflection is only allowed
to packages to which the java.lang.invoke module is opened.
This CL adds an override to open the module to all unnamed
modules (i.e., to Desugar) when running Desugar.
Test: make checkbuild
(with OpenJDK 8u45 toolchain on the PATH)
Test: make EXPERIMENTAL_USE_OPENJDK9=true checkbuild
(with OpenJDK 9-ea toolchain on the PATH)
Bug: 38177295
Change-Id: I2cf74a96ea17366dd50b8d92af8e41e812247ef7
`make custom_images` supports to build different kinds of *non-droid* images,
e.g., odm.img. Adding the support of signing them with either AVB HASH footer
or AVB HASHTREE footer. The user can use HASH for small images and
HASHTREE for large images.
Sample signing configurations:
* AVB HASH footer:
- CUSTOM_IMAGE_AVB_HASH_ENABLE := true
- CUSTOM_IMAGE_AVB_ADD_HASH_FOOTER_ARGS := --append_to_release_string my_odm_image
* AVB HASHTREE footer:
- CUSTOM_IMAGE_AVB_HASHTREE_ENABLE := true
- CUSTOM_IMAGE_AVB_ADD_HASHTREE_FOOTER_ARGS := --fec_num_roots 8
* Using custom signing key:
- CUSTOM_IMAGE_AVB_ALGORITHM := SHA256_RSA2048
- CUSTOM_IMAGE_AVB_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
Bug: 36701014
Test: `make custom_images` with AVB HASH footer
Test: `make custom_images` with AVB HASHTREE footer
Test: `make droid` to check system.img is still properly signed with AVB HASHTREE
Test: `make droid` to check vendor.img is still properly signed with AVB HASHTREE
Change-Id: I8dc420e12e37e9a631345c0cd883339db05d489f
package_extract_dir is used in file based OTA only and should be killed.
Bug: 37959785
Test: code search shows no usage of this function in aosp.
Change-Id: Id3719b969c24b7ecef0c7f0e4a3af09a72be54d4
This flag allowed for building with an OpenJDK 7 toolchain. It was
used for build bot builds that now work with an OpenJDK 8 toolchain.
Hence, this feature is no longer required. This CL drops it.
Bug: 27583810
Test: Treehugger build succeeds.
Change-Id: I7efca363d665292bfb88f4a4d6f3a120fc8f93f3
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
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
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>
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
Change-Id: I0244fb02754663be3106391c9360fd1b2cc00d4a
This can be a little faster, but also means that we don't need to call
kati/ninja twice when we need to handle the automatic installclean.
Test: m -j installclean
Test: m -j dataclean
Change-Id: I8f5e5544bcf30c58bf9abee30a37256cb18436ac
This CL gets us closer to having incremental builds for ASAN by
separating the generation of sanitized intermediates from their
non-sanitized counterparts.
Bug: 38145756
Test: time (m -j40 && SANITIZE_TARGET="address" m -j40) # reduces from
17 mins to ~9 mins with these changes.
Change-Id: I7e3e7d88d276d834192b2e2427643f70e89d731e
- 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 checkbuild docs
(using OpenJDK 8 toolchain)
Change-Id: Ie5fe0502dfe2f99fc58b1a723b7c18d5896a2646
This CL changes the build system to always look for shared JNI
libraries at their unsanitized install locations.
Bug: 38309771
Test: m -j40 && SANITIZE_TARGET="address" m -j40
Change-Id: Icb9d4f5365def6ea7a780553f455f41d2cb8b8bf
