We used to silently ignore the return value from apply_patch() even if
it had failed. It gives us more trouble to investigate the failure when
the affected file/partition gets touched in subsequent OTAs. This CL
adds the checking of the return value and aborts the update accordingly.
Bug: 25893277
Change-Id: Ie5e1c563576e503343e6a5b28ed4d7039f6f919c
the value of USER is dependent from the compilation environment,so
when compiling one same device project, the BUILD_FINGERPRINT may
exceed 91 characters because ${USER} is long, but with short ${USER}
the compilation can pass.
Signed-off-by: wei qiao <qiaowei224@gmail.com>
Change-Id: Ia0f7dfa9cf7d605f1f2603f70dd0e6877482eb8a
There is currently an intentional incremental rebuild issue with
import_includes. export_includes might get updated with an identical
version, but we don't want to force everything downstream of it to
rebuild.
When BUILDING_WITH_NINJA==true, only update export_includes if it
changes, and use .KATI_RESTAT to only run downstream rules if it
changes. import_includes will only be updated if one of the
export_includes files is updated, so object files can have a normal
dependency on import_includes instead of an order-only dependency.
All downstream object files will now be recompiled if their imported
include paths change.
Bug: 25910568
Change-Id: I626f3b24ac02ac1309049cf1ce66cfe8ec816513
am: bff3c9b4c1
* commit 'bff3c9b4c10dcb3ce3820d3a5e144e3df20313dc':
Use libstdc++ for ijar
Build ijar for apps build
Use .KATI_RESTAT to reduce unnecessary rebuilds of .jar files
Add an option "--log_diff <filename>" to ota_from_target_files.py
script. When enabled, it logs the differences between the source
and target builds into <filename> when generating incremental OTAs.
Also move target_files_diff.py into releasetools/ so that it can be
packed into otatools.zip.
Bug: 25372309
Change-Id: Ifd4ed0f2f12ef040ee377621ec8c35a873cec34f
For some reason ijar won't build against libc++ for TARGET_BUILD_APPS
builds, but does build with libstdc++.
(cherry picked from commit 718bab6aec)
Bug: 25904002
Change-Id: I1de103918faa5bb574af6f12cc954e7fed44dc62
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
For some reason ijar won't build against libc++ for TARGET_BUILD_APPS
builds, but does build with libstdc++.
Change-Id: I8e900b0f764f0bb8f827705cb9173f07e4f33862
When the 4th argument specified is non-empty then it attempts to
use either HOST_OUT_GEN_COMMON or TARGET_OUT_GEN_COMMON
depending on whether the 3rd argument is non-empty or not
respectively. Unfortunately, those two variables do not exist,
the correct names for those variables is HOST_OUT_COMMON_GEN and
TARGET_OUT_COMMON_GET.
Change-Id: I66edb02824c06e0f504ebe04ff80ddbd77a16c95
LOCAL_DONT_DELETE_JAR_META_INF is meant for deleting resources carried
by static Java libraries, see comment in clear_vars.mk.
For a module's own resources, we should pick up whatever in
LOCAL_JAVA_RESOURCE_DIRS.
The same applies when building .jack from a prebult jar in
transform-jar-to-jack.
Bug: 25860887
Change-Id: I20c120e039342a1124362c5f8747eace94b03931
(cherry-pick from commit 996ae38ffd)