Now that mac compatibility has been fixed
BUG: 27657762
Change-Id: I49933ccedf74b9d172967dad721971a752047da6
Signed-off-by: Mohamad Ayyash <mkayyash@google.com>
When building apps with EMMA_INSTRUMENT=true, we must ensure that
jacoco is at least on the classpath (or even embedded for unbundled
branches) and that proguard will ignore jacoco classes. Otherwise
the Jack compilation would fail.
For unbundled build, we include the proguard configuration file
build/core/proguard.jacoco.flags to ignore jacoco classes.
For full build, we ensure jacoco is on the classpath during the
jack compilation.
Bug: 27607712
(cherry picked from commit d9641e01f3)
Change-Id: Ib46c91d03721f2418b15c17546d4f322f2f90a28
Bug: 19735423
- Unlike other archs, x86_64 has both usr/lib and usr/lib64. we need
to search for libm.so and libc.so in lib64/. Otherwise the linker
will report error.
Change-Id: I2859bee066a9eb100828d90da8adf0f9817d77e6
(cherry picked from commit 57ef7ea490)
Used to select between releases of the NDK (r10, r11, etc).
Some of the libraries we use in Android come as prebuilts from
google3, which are most likely built against an older NDK than what
we have in the platform. Since things may not be ABI compatible
release to release, we need to keep legacy versions accessible for
those to keep building.
Change-Id: Ia3df42fa6f3a7bd5108ff6bbb0f2ca06239c3be9
We removed code and variables related to running dx on classes.jar in
this change. Also removed target emma rules (but kept the emma rules for
host java libraries), for it's now done by Jack.
We still support to build classes.jar (and javalib.jar for static Java
libraries) using javac, because tools like javadoc need class files as
input.
Removed the obsolete install-dex-debug.
Bug: 27400061
Change-Id: If0bcdfe62cb181a98754fb0dbe1c12c92e38d3e8
Keep coverage.em file name for host rules where Jack is not called.
(Partially reverts change 491c9ce48a)
Bug: 27822188
Change-Id: Ia9344e17ecbecfb9c335608740ab7dc5490c48d5
Soong uses the copy of `ar` in the OSX SDK instead of the wrapper in
/usr/bin/ar. /usr/bin/ar appears to be a thin wrapper that looks up the
current SDK and passes execution to it. Soong does this so that it can
actually set up a dependency on the tool.
Change-Id: Ia4e4fbe3287539933fa98a1354c3ccee91f4d552
* Put all Clang-Tidy warning messages in a group for now.
There are too many coding style warnings.
* Change the 'top' link to the top of the page.
* Add a few more new clang compiler warnings.
Bug: http://b/27779618
Change-Id: I385b9db927a397704b56f53440301352da8694cf
Clang and MinGW are not expected to work together currently, and you get
strange errors when this is attempted. Instead, error out with a clear
error message.
Before the windows build rewrite, we'd just explicitly set my_clang to
false without checking what the module asked for. Now, error out if the
module explicitly asked for clang, since by default they'd have it
already if it wasn't for windows. That way when Clang+Windows does
become possible, it can gradually be tested by setting LOCAL_CLANG to
true.
Change-Id: I9e0b0dca30946d94894119443f2fd0593cee1793
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)
So that we don't mess up with the vendor path check by accident.
Bug: 27543283
Change-Id: I6c34caefe3ff4abfdd8349a32c68fcca524cfd8e
(cherry-pick from commit efaf5efd06)
To rebuild odex files of Java libraries and apps,
we store the jars/apks without stripping the classes.dex inside the
platform.zip. We also save the build variables that may affect how we
rebuild an odex in pdk_dexpreopt_config.mk in the platform.zip.
We store the files and configuration only for libraries/apps that get
installed to the system.img (or vendor.img).
In PDK fusion build, we auto-generate prebuilt module definitions for
the javalib.jar and package.dex.apk carried in the platform.zip, using
configuration stored in pdk_dexpreopt_config.mk.
With the prebult modules, we override the implicit rule that directly
copies the odex from the platform.zip.
To rebuild odex of javalib.jar, we added support for prebuilt shared Java
library to prebiult_internal.mk. An installable prebuilt Java library is
treated as shared Java library, i.e. with classes.dex in the jar instead
of a set of .class files.
For apks in the platform.zip, we install the stripped version from
platform files inside platform.zip, instead of the package.dex.apk,
using a new variable LOCAL_REPLACE_PREBUILT_APK_INSTALLED. We can't
strip package.dex.apk because we can't re-sign the stripped apk at this
point.
We generate prebuilt module only if it's not already defined in the
source tree.
Bug: 27543283
Change-Id: I9e146f8b713d6f57c397fd28d88c9ab700757ca1
(cherry-pick from commit 3a61eeb6cb)
We no longer use emma with Jack. However, during the process of a
full build, we may run the emma task and overwrite the coverage file
generated by Jack with the one from emma because they use the same
filename.
This CL renames coverage files generated by emma so they no longer
break those created by Jack.
Bug: 27822188
Change-Id: Ie3fdc2b8f53deafbefbd6973e39f29d8c46f371e
- Remove javac support in host_dalvik_java_library.mk
- Simplify host_dalvik_static_java_library.mk by including
host_dalvik_java_library.mk instead of host_java_library.mk.
- Take configure_local_jack out of host_java_library_common.mk because
it's only needed by host dalvik java libraries.
Bug: 27400061
Change-Id: I4088b09092198118d832a759663bbaadff669ed5
We don't need to run rmtypedefs in javac compilation now, because the
runtime libraries are compiled by only jack, which takes care of
rmtypedefs by itself.
Bug: 27828139
Change-Id: Ie480ae5aead8f3f58f956978fc4a05c28a35dec6
javac-check covers all classes.jars that are compiled with javac
instead of jack. This target is required by tools that still need java
class files as input.
Bug: 26705771
Change-Id: I6896b9a6026a2a0dae6145d1ef5a839756aa3458
Sen Jiang