So that you can have LOCAL_COMPATIBILITY_SUPPORT_FILES generated in the
out directory.
Change-Id: I3e011fc3db5de170f7befcb12841d230283671a6
(cherry picked from commit c3e4b2f390)
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
Ninja has an implicit dependency on the command being run, and kati will
regenerate the ninja manifest if any read makefile changes, so there is no
need to have dependencies on makefiles.
This won't catch all the cases where LOCAL_ADDITIONAL_DEPENDENCIES contains
a .mk file, because a few users of LOCAL_ADDITIONAL_DEPENDENCIES don't
include base_rules.mk, but it will fix the most common ones.
Bug: 23566977
Change-Id: I66de882421376303ab7233c8ce7274548f6b2199
This avoids Ninja's path canonicalization on those goal names.
Without this, Ninja complains about duplicate rules for
MODULES-IN/a/b/.. and MODULES-IN/a.
Bug: 24309760
Change-Id: Id3aa9da5d3887a2cd1426cbb5fdf35659c65805e
Previously we use command line variable BUILD_MODULES_IN_PATHS which
causes kati to regenerate build.ninja if any variable value changes.
TODO: Remove the old rules of BUILD_MODULES_IN_PATHS in
build/core/main.mk and ninja.mk once users have re-sourced envsetup.sh.
Probably in a few weeks.
Caveat: With this change, if a user sources the new envsetup.sh, mma/mmma
won't work in old branches from the same shell.
Bug: 24309760
Change-Id: I212e82aeebaaa2bd4114e2066f1995da8886b5e2
LOCAL_COMPATIBILITY_SUPPORT_FILES is a list of <src>:<dest>,
where <src> is relative to LOCAL_PATH and <dest> is relative to the
suite's testcases out directory.
We keep the rule to auto-detect AndroidTest.xml and DynamicConfig.xml,
so you don't need to modify the existing cts Android.mks.
Bug: 24139963
Bug: 21762834
Change-Id: Iecb83fcbcf8c7575c27802bfd773e4134aec39d5
Instead of using recursive make to change the HOST_OS when building the
windows SDK under linux, add the concept of cross-building to another
host os.
Bug: 23566667
Change-Id: I6dc525b601b6251d458d197c30bf4660d7485502
- Added GLOBAL_JAVAC_DEBUG_FLAGS and merge it to
PRIVATE_JAVACFLAGS/PRIVATE_JACK_FLAGS to get rid of
PRIVATE_JAVAC_DEBUG_FLAGS/PRIVATE_JACK_DEBUG_FLAGS.
- With Java rules out of base_rules.mk we can get rid
of java_alternative_checked_module now.
Change-Id: I1a14716c785e3d49330a75044107662ce96a9307
- Moved the target-only .aidl and .logtag rules to java.mk.
- Moved the .proto rules, Java library dependency calculation,
Java resource processing and Java-related
target-specific and global variables setup to a new java_common.java,
which is shared by both target and host Java modules.
- Minor cleanup for the moved code.
Bug: 23597357
Change-Id: Ic3eb72e26bb1a663e5739abe0a935f96b88bc352
So that we can support building both linux and windows binaries at the
same time on a linux host. This replaces the ifeq($(HOST_OS),...) checks
in Android.mk files.
Bug: 23566667
Change-Id: I693e11984e36d55bb6f09fa0d49bc485463e16fb
A module can install a companion init.rc file,
by specifying:
LOCAL_INIT_RC := <init.rc-file-path-replative-to-LOCAL_PATH>
You can also use the variant with _32 or _64 suffix.
Bug: 23186545
Change-Id: I00a96509f5707ae39361a0c5555fa59d46c90322
This is possible now that we have the new Jack server.
Also fix dependency from dex/jack target to jack script
instead of jack.jar.
(cherry picked from commit 5e50b34221)
Change-Id: I8e7aa5087ba8d73cc93140ddfca8f4ab2f505175
This is possible now that we have the new Jack server.
Also fix dependency from dex/jack target to jack script
instead of jack.jar.
(cherry picked from commit 5e50b34221)
Change-Id: I5dce864624e97c27441a5ee7f8c3cd582613390e
This is possible now that we have the new Jack server.
Also fix dependency from dex/jack target to jack script
instead of jack.jar.
Change-Id: I28b5f7176747853ef707b8d4055017bf60296641
A module can specify itself to be a Compatibility Suite module with:
LOCAL_COMPATIBILITY_SUITE := <cts-name>
<cts-name> can be "cts" or any other cts name supported by the
build system.
The cts name's config.mk must define global variable
COMPATIBILITY_TESTCASES_OUT_<cts-name> to point to the testcase
output directory.
This change copies the module's built file, as well as the module's
AndroidTest.xml, to the testcase output directory.
The build system collects all the testcase files in a global variable
COMPATIBILITY.<cts-name>.FILES, which you can reference in a build
task that builds the suite's zip package.
Also copy over the test case files if user runs mm/mmm/etc.
Change-Id: Ica0dbc4f193db7de7d395b9c686733bdac41f566
Build additional images requested by the product makefile.
This script gives the ability to build multiple additional images and
you can configure what modules/files to include in each image.
1. Define PRODUCT_CUSTOM_IMAGE_MAKEFILES in your product makefile.
PRODUCT_CUSTOM_IMAGE_MAKEFILES is a list of makefiles.
Each makefile configures an image.
For image configuration makefile foo/bar/xyz.mk, the built image
file name
will be xyz.img. So make sure they won't conflict.
2. In each image's configuration makefile, you can define variables:
- CUSTOM_IMAGE_MOUNT_POINT, the mount point, such as "oem", "odm"
etc.
- CUSTOM_IMAGE_PARTITION_SIZE
- CUSTOM_IMAGE_FILE_SYSTEM_TYPE
- CUSTOM_IMAGE_DICT_FILE, a text file defining a dictionary
accepted by BuildImage() in tools/releasetools/build_image.py.
- CUSTOM_IMAGE_MODULES, a list of module names you want to include
in the image; Not only the module itself will be installed to proper
path in the image, you can also piggyback additional files/directories
with the module's LOCAL_PICKUP_FILES.
- CUSTOM_IMAGE_COPY_FILES, a list of "<src>:<dest>" to be copied to
the image. <dest> is relativ to the root of the image.
To build all those images, run "make custom_images".
Bug: 19609718
Change-Id: Ic73587e08503a251be27797c7b00329716051927
(cherry picked from commit 5fcf1094f9)
Ying Wang