Previously the recovery binary was configured to be installed to the
system.img and then got copied to recovery.img in the recovery.img's
build rule.
With this change, a module, such as the recovery binary, can configure
itself to be installed directly to the recovery.img, just like how other
modules get installed to system.img.
Bug: 19667686
Change-Id: I46b0b4a95cf078a68999db9c0f6635d6a3f5cd86
Previously when a file in LOCAL_SRC_FILES starts with "../", the object
file may escape out of the module's intermediate directory, because we
insert the source file's path (but not with LOCAL_PATH) to the object
file's path. Even worse when two object files escape to the same destination
and cause conflict.
This change fixes the issue by removing the "../" inside the object
files' paths. To do that, we have to set up the compilation rules for
those files one by one, instead of using the one-for-all static
pattern rules.
Bug: 19641115
Change-Id: I19f3c48ece3244fa14acb2caa609deea710840d3
By default we build both 64-bit and 32-bit odex files for a Java library.
With this change:
- For system server jars (PRODUCT_SYSTEM_SERVER_JARS), we build only
64-bit odex;
- A library can opt to build only 64-bit odex with
"LOCAL_MULTILIB := first".
Bug: 19650934
Change-Id: Ic0b7fd381396ed276e6129f883881c5c41c6e154
On non-arm architectures, there is no TARGET_CPU_VARIANT set. For x86,
art assumes that the CPU variant is actually the TARGET_ARCH_VARIANT.
Therefore, if no TARGET_CPU_VARIANT is set, use the TARGET_ARCH_VARIANT.
If TARGET_ARCH_VARIANT is not set, then use default as the value.
Change-Id: I17fc9e3ac7412462103b8f0b287fce106298b741
Expectation is that classes in pre-compiled apps should be structurally
sound and not cause a hard failure.
Bug: 19606409
Change-Id: Idc9da4d4c6bd259555671c657d3414a97940717f
We should put the NDK library path before
$(TARGET_OUT_INTERMEDIATE_LIBRARIES), so that we link against the NDK
libc/libm, instead of the platform libc/libm in
$(TARGET_OUT_INTERMEDIATE_LIBRARIES), which may still being written out,
because we don't have dependency on them.
Bug: 19613709
Change-Id: I26a8b272e38b7436bca3324246b21cd71349662b
The Mac linker doesn't understand --start-group, which is needed for
properly linking libgcc/libc statically. It isn't needed for dynamic
executables though, so use that driver behavior where appropriate.
Bug: 19567451
Change-Id: Ifeb03bea55bc87561c64ddafdb99f664fef0f00e
BUILD_HOST_static=1 forces all host binaries to be statically linked.
Since -nodefaultlibs was passed (to disable libstdc++), libgcc wasn't
being passed. This change emulates the driver's behavior.
Also fix default STL selection for BUILD_HOST_static.
Bug: 19567451
Change-Id: I617aab782d40ac76ca5a7d9dddf0f202a4e3a69b
http://llvm.org/bugs/show_bug.cgi?id=15086,
llvm tail call optimization is wrong for x86.
For Android/x86 to use SSE* instructions safely, stack should be 16-byte
aligned before JNI function call, which isn't true for all x86 device,
so -mstackrealign should be the default.
BUG: 19234330
Change-Id: I4c6676366788772dbe64fd7f0dd33b3ed5c9b80e
Previously if user has a directory with name dummy in the root of the
source tree, "zip -qd package.apk dummy" fails with:
"zip error: Nothing to do!".
This change mitigates the error.
Change-Id: I642e3bf0378e5b9911a068ecb72f795b3e92f1fe
- Add a new flag to zipalign (-p) that page aligns shared
libraries (zip entries ending with ".so") in the archive.
- Add a new build variable LOCAL_PAGE_ALIGN_SHARED_LIBRARIES
to turn on this behaviour in zipalign.
- Add a new LOCAL_JNI_SHARED_LIBRARIES_ZIP_OPTIONS to control
zip behaviour.
Bug: 8076853
Bug: 19330157
Co-Authored-By: Simon Baldwin <simonb@google.com>
Co-Authored-By: Dimitry Ivanov <dimitry@google.com>
Change-Id: I1aa2c039bb2a590ae72f256acc9ba5401c2c59b1
These CFLAGS and CPPFLAGS will always be added last, and are
controlled by the build system. This way we can add warnings that
users are not allowed to disable.
Change-Id: Id71f69249078f62ca2687ecbf764aff0fd3a1c1b
Implicit function declarations are much more dangerous on LP64 because
sizeof(int) != sizeof(void*), so any function that returns a pointer will
lose its top bits, leading to relatively hard to debug crashes.
Change-Id: Ia05beffb949ca747833c2e12c40daf896f7a60a5
Ying Wang