Runtime resource overlay is a bare APK with just the overlaid
resources. There is no need for additional subdir.
See http://go/sku-colors.
Bug: 31692079
Change-Id: Iff3d58f941e764a7be3ec04cafeefd592bd8b944
The toc optimization had been disabled for host builds to ensure that
the timestamp of the final binary changed whenever its implementation
changed, in order to support rerunning host tools that were modified
during incremental builds. However, only the final install rule must be
re-run to update the timestamp, and not the link rule.
Update the shared library install dependencies to use normal
dependencies instead of order-only dependencies for host modules, and
then enable the the toc optimization for host modules. If the
implementation of a library changes it will be reinstalled, and
libraries or binaries that depend on it will also be reinstalled.
Bug: 26015464
Test: m -j; touch art/disassembler/disassembler_x86.cc; m -j, verify
out/host/linux-x86/bin/oatdump is updated
Change-Id: I0a14decc1994eb55ad269d841943aef66e320c63
Move extra module dependencies like symlinks from dependencies of
$(my_register_name) to $(my_all_targets), and make $(my_register_name)
and other convenience phony modules depend on $(my_all_targets). Move
$(LOCAL_MODULE)-host/-target to depend on $(my_all_targets) instead of
directly depending on the built and installed modules.
Change-Id: I3b093986db7a1bff118f1f2482275f0997a98fb6
Make symlinks an order-only dependency of the module name phony target
so that they get installed with make module or make MODULES-IN-path.
Test: mmma -j art/dalvikvm, remove symlink in $OUT and retry
Change-Id: Iae472a1c8fa1e8386cc9556cfe819bd4fca99428
AUX is a new class, similar to TARGET
While TARGET defines toolchain for Application Processors
AUX is defining toolchains for arbitrary utility cores (DSPs, GPUs,
MCUs, etc). This allows building of non-android sources as part
of Android tree and avoid using prebuilts if source code is avaliable
Bug: 29635686
Change-Id: Ie755ea054b16c3e86369f5fb2ba6eb0b384af77f
Signed-off-by: Alexey Polyudov <apolyudov@google.com>
We supported de-duplicating LOCAL_INIT_RC across multiple architecture
variants in a single module definition, but that didn't work if the
module was defined with two different BUILD_PREBUILT definitions. That's
how we're exporting modules from Soong to Make.
Change-Id: Ifc93b15ef78ea3d8e78005d428a3ec57d7e414e8
Creates a build_system_stats.txt build artifact that contains statistics
on how many BUILD_* modules are defined in a build. Also writes out
information about the Soong module types sent from the Soong build.
Merged-In: Iaf0c7062f542dc6942b5349854f3d49267cac4a5
Change-Id: Iaf0c7062f542dc6942b5349854f3d49267cac4a5
Specifying LOCAL_MODULE_SYMLINKS will create symlinks to the installed
module in the same directory.
Change-Id: Idecb2b75f0c9999eb000eed9a79a989244ccf6c2
am: 58b7c1c744
* commit '58b7c1c744aa49fb0686848b281ae75c2485f420':
Add LOCAL_LOGTAGS_FILES that prebuilts can use
Change-Id: I76a6077c3945463a5b52fb8a4f5146a2590de716
Soong modules can define logtags files that need to be combined into
/system/etc/event-log-tags, so add a new LOCAL_LOGTAGS_FILES variable
that can be used to specify *.logtags file outside of LOCAL_SRC_FILES.
Bug: 28989759
Change-Id: I53c5d396dfb7c6006806758f351eb5cdde90fe74
Host native tests have been getting installed into
out/host/linux-x86/bin/..., but this pollutes the bin directory with a
lot of poorly named tests. Also, to support 32-bit and 64-bit tests, we
need to have different names with different suffixes. This causes
problems when tests expect to be named something specific (like gtest).
It's also convenient to store test data next to the test itself.
So with this change, native tests will be installed in
out/host/linux-x86/nativetest[64]/$(LOCAL_MODULE)/$(LOCAL_MODULE_STEM)
just like target tests get installed into /data/nativetest[64].
Implement this using a new NATIVE_TESTS class, which is like
EXECUTABLES, but sets up the install path differently, and configures
the rpath to load shared libraries with the proper relative path.
LOCAL_MODULE_RELATIVE_PATH can be used to control the directory name, it
will default to $(LOCAL_MODULE). This way multiple related tests can be
grouped together.
Target native tests also use NATIVE_TESTS now, but nothing should change
other than LOCAL_MODULE_RELATIVE_PATH can be used.
Change-Id: I535e42b1a6b21c5b8d6a580aa2f944d2be35e27d
Support TARGET_2ND_ARCH as the binary translation arch.
See target/board/generic_x86_arm/BoardConfig.mk and
target/product/aosp_x86_arm.mk as example for the setup.
In BoardConfig, use the TARGET_2ND_ARCH/etc. variables to set up the
binary translation arch;
Set "TARGET_TRANSLATE_2ND_ARCH := true" to tell the build system it's
not a typical 64-bit multilib configuration.
In product makefile, use "PRODUCT_PACKAGES += libfoo_<2nd_arch>" to
install the TARGET_2ND_ARCH libraries. This also pulls in any dependency
libraries.
By default we don't install any TARGET_2ND_ARCH modules, unless it's
pulled in by PRODUCT_PACKAGES.
Bug: 27526885
Change-Id: I0578e9c80da0532d2fa886a8fcdb140bbc703009
(cherry-pick from commit 277e75a488)
Now that copy-file-to-target doesn't use acp, nothing in the acp build
path uses acp, so we don't need to special case it to prevent loops.
Change-Id: I12810c1b064d0c03135a80077a76bc4c9cc18b24
And everything special-cased on that. Add a warning if USE_NINJA is
set to let users know that it no longer changes anything.
Change-Id: Ib8739151fe26ea6bf8f76b7ac2b8f4097dab0b47
This is mostly the same as the existing 2ND_HOST / HOST_CROSS support.
The interesting thing I did here was make x86 the 'first' architecture,
and x86_64 the second. This way LOCAL_MULTILIB := first defaults to
32-bit windows modules.
windows-x86/bin <- defaults to 32-bit executables
windows-x86/lib <- 32-bit libraries, like before
windows-x86/lib64 <- 64-bit libraries
windows-x86/obj <- 32-bit intermediates
windows-x86/obj64 <- 64-bit intermediates
Then modules are registered with the names:
host_cross_liblog <- 32-bit, like before
host_cross_liblog_64 <- 64-bit
Bug: 26957718
(cherry picked from commit 9ecbf83259)
Change-Id: Iab2d36e20d7002568c3534e7781e9ac8ab21a4a9
It's a valid situation for all three of LOCAL_INIT_RC, LOCAL_INIT_RC_32,
and LOCAL_INIT_RC_64 to be used.
Bug: 26773181
Change-Id: If9661f93b1823279075fc3d55195f7a939e01b6f
So that you can have LOCAL_COMPATIBILITY_SUPPORT_FILES generated in the
out directory.
Change-Id: I3e011fc3db5de170f7befcb12841d230283671a6
(cherry picked from commit c3e4b2f390)
This is mostly the same as the existing 2ND_HOST / HOST_CROSS support.
The interesting thing I did here was make x86 the 'first' architecture,
and x86_64 the second. This way LOCAL_MULTILIB := first defaults to
32-bit windows modules.
windows-x86/bin <- defaults to 32-bit executables
windows-x86/lib <- 32-bit libraries, like before
windows-x86/lib64 <- 64-bit libraries
windows-x86/obj <- 32-bit intermediates
windows-x86/obj64 <- 64-bit intermediates
Then modules are registered with the names:
host_cross_liblog <- 32-bit, like before
host_cross_liblog_64 <- 64-bit
Bug: 26957718
Change-Id: I9f119411acb43e973ec1e6bca3c1dc291c91556c
Building a module by name with make <module name>, or with mm or mma
through all_modules, should also build the .toc file so that future uses
of mm on modules that depend on this one can find the .toc file.
Bug: 26936761
Change-Id: Id0c592f0860a10b732b2b5b13c7e967c9bcb1c6b
Host binaries may be run during the build process and the internal
implementation of the shared libraries makes a difference for the build
result. This change makes sure host tools get re-linked and re-run when
any of its dependency libraries gets updated.
DEX2OAT is such a host tool. We also changed DEX2OAT as full dependency
of dex-preoptimization, so we rebuild the odex files if DEX2OAT itself,
or any dependency libraries changed.
Bug: 24597504
Change-Id: Idf0d9be82ccebd826d9c5b405a39cff437e0af29
am: dbeab8de65
* commit 'dbeab8de6543db1d0393789cb18ee7fd7ed8fedd':
Use libstdc++ for ijar
Build ijar for apps build
Use .KATI_RESTAT to reduce unnecessary rebuilds of .jar files
The same optimization was done for binaries in
https://android-review.googlesource.com/#/c/175250/
To create a TOC file from .jar files, this change introduces
ijar, which is designed for this purpose. Only #include lines
were modified from the original version.
https://github.com/bazelbuild/bazel/tree/master/third_party/ijar
Performance:
$ m && touch
frameworks/base/core/java/com/google/android/util/Procedure.java && time
m
Before: 4m30s (1580 targets)
After: 3m57s (772 targets)
Unfortunately, the improvement is small yet, but local
experiments showed we can cut ~2 more minutes if the similar
optimization is done for .dex files.
(cherry picked from commit c1f5d9c203)
Bug: 24597504
Change-Id: Iec3b2b0b0e674bee5d80cce3c300dc8fad6e7c13
The same optimization was done for binaries in
https://android-review.googlesource.com/#/c/175250/
To create a TOC file from .jar files, this change introduces
ijar, which is designed for this purpose. Only #include lines
were modified from the original version.
https://github.com/bazelbuild/bazel/tree/master/third_party/ijar
Performance:
$ m && touch
frameworks/base/core/java/com/google/android/util/Procedure.java && time
m
Before: 4m30s (1580 targets)
After: 3m57s (772 targets)
Unfortunately, the improvement is small yet, but local
experiments showed we can cut ~2 more minutes if the similar
optimization is done for .dex files.
Bug: 24597504
Change-Id: Id54953aea25e497c8ebbe783b03f13b488577c6a
When a shared object is rebuilt, all dependent libraries and
executables are rebuilt. Such rebuild is unnecessary when there
is no interface change. With this patch, .toc files will be
generated for all .so files. The rule which generates .toc files
has ninja's restat=1 and .toc files are not changed ninja won't
rebuild dependent targets.
Performance:
$ m && touch bionic/libc/stdio/stdio.c && time m
Before: 1m03s (2563 targets)
After: 21s (90 targets)
Bug: 24597504
Change-Id: Ia5dd950273d143f4e99eee8bef7478f1a94cd138
