Previously, setting PRODUCT_BUILD_SUPER_PARTITION to false for a partial
build (with PRODUCT_USE_DYNAMIC_PARTITIONS == true) would fail to
include necessary keys in misc_info.txt that are required when merging
two partial builds to create a dynamic-partition-enabled mixed build.
This change ensures these necessary keys are included even when
PRODUCT_BUILD_SUPER_PARTITION is false. Setting
PRODUCT_BUILD_SUPER_PARTITION to false causes partial builds to skip
building super.img and super_empty.img, instead relying on these images
to come from the final merged build.
Bug: 134764140
Test: Building & booting a dynamic-partition-enabled mixed build, and
inspecting partial builds' logs / out folder to ensure that
super.img/super_empty.img were not created.
Change-Id: I99431a9a342e9b0617510e250597f3024ef39322
BOARD_SUPER_PARTITION_ERROR_LIMIT can be set by OEMs to cause a
build failure when the sum of sizes of logical partitions exceeds the same.
It is set to BOARD_SUPER_PARTITION_SIZE by default.
Bug: 133329143
Test: mmm -j32
Change-Id: Ief85c9ab3e3b9d071cd22b70e13b5c64bb784b9c
Bug: 134509111
Test: add "require_root: true" to init_benchmarks and libpower_test
build the modules, confirm the extra target preparer is added in the
test config.
Change-Id: I2fdae79d45fd1e5866ee94d1f0e59df106be2a87
Current information is not enough if the prebuilt modules are depend on
AAR libs Therefore, AIDEGen has to collect the classes.jar of the
prebuilt modules from build system.
Build module-info.json without this change:
Build time: 1m55.001s
File size: 14,918,354 Bytes
Build module-info.json with this change:
Build time: 1m56.292s
File size: 15,577,031 Bytes
Bug: 132768299
Test: 1. Checkout the internal master branch
2. Patch this CL
3. m -j out/target/product/generic_x86_64/module-info.json
4. Open the module-info.json
5. For verifying soong_java_prebuilt.mk, check the classes.jar of
module prebuilt-google-play-* exists.
e.g.
"prebuilt-google-play-...": {
...
"classes_jar": [
"out/target/common/obj/JAVA_LIBRARIES/
prebuilt-google-..._intermediates/classes.jar"
]
}
5. For verifying java_prebuilt_internal.mk, check the classes.jar
of module ink exists.
e.g.
"ink": {
...
"classes_jar": [
"out/target/common/obj/JAVA_LIBRARIES/ink_intermediates/
classes.jar"
]
}
Change-Id: I09518c92260db47d2686493fa13951f316159d13
* changes:
Fix dependency on BOARD_AVB_SYSTEM_KEY_PATH
Fix some java library dependencies
Depend on NDK libraries
Call clean-path in more places
Add missing dependecy on SOONG_ZIP
Add dependencies on the toolchain (clang, etc)
When an Android.mk specifies a local path that is outside the current
directory, it uses '..', since we prepend $(LOCAL_PATH)/ to the given
path.
This path ('a/b/../c') gets inserted into command lines and
dependencies. For dependencies, when it gets to Ninja, Ninja calls
CanonicalizePath and removes those references ('a/c'), but the command
line is preserved.
So we've got a command line that references 'a/b', but no dependency on
it. Usually that's not a big problem, but it's an issue if we're trying
to only expose dependencies to the rule, like with RBE only sending the
dependencies to the remote workers. So use our 'clean-path' macro to
collapse the '..' references in Kati so that they don't show up in the
command line either.
Test: treehugger
Test: build a system image with RBE
Change-Id: I0706faa2ac15e9c12c720f43c7bb8171c5efd97c
Historically, we've relied on the path to the clang compiler changing in
order to trigger rebuilds instead of direct dependencies on the compiler
itself. That's somewhat more reliable, since the actual $(CLANG) file is
often a script that doesn't actually change during every update.
In Soong, we've added the dependency anyway, so do it here as well. This
makes it easier for my RBE experiments to identify when we intend to use
clang and to send the entire compiler.
Test: treehugger
Test: build a system image with RBE, find that every command that needed
the compiler gets it.
Change-Id: I3838b5d77884394a8c0f7a1ba133142102602084
JVM occasionally (0.5% time) crashes on entering a method with SIGSEGV.
It might be due to excessive load on the host machine. Reduce the number
of the compiler threads to 6, and do not start all the GC threads
immediately. If JVM crashes, copy full diagnostics to stderr.
Bug: 132766811
Test: treehugger
Change-Id: Ic1b09e0f2cbcf4c22214eaaeae464899b2b99ef7
Dan Shi