ASan runtime library (when using dynamic linking) must be the first
dependency of the main executable to achieve correct symbol
interposition. This matches how the clang driver works.
In multilib setup, ASan-RT name depends on the target arch:
/system/lib/libclang_rt.asan-arm-android.so
/system/lib64/libclang_rt.asan-arm64-android.so
We also set RPATH to /system/lib/asan or /system/lib64/asan
to have a place for ASan-only versions of system libraries.
Change-Id: I937d202077b6e433ba476c075d31be818b662d53
Always link libm with asan. Hasn't been a problem before because ASAN
was only ever used when libc++ was as well, which already links libm.
Pass --no-as-needed for host modules.
These aren't needed for the target builds because the target uses the
shared RTL.
Change-Id: I3b95c8682c0f63bac6b726f8cd15c638aaa98311
Define BOARD_SEPOLICY_DIRS for the arm64, mips64, and x86_64
emulator targets. As a first cut, simply inherit from the
existing policy directories used for generic and generic_x86.
We may need further board-specific policy added for these targets
but testing will require first enabling SELinux in the relevant
kernel configs.
(cherrypicked from commit 21ebc213bb)
Change-Id: I7b4459b32298698fc2908cbbdd0e3afadbe5ac24
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
In order to work around the zip 2GiB limit, we need to wrap the related
functions in zipfile. Calls to those functions should always be replaced
with calls to the wrappers instead.
Bug: 18015246
Change-Id: I499574cee51ec4804bc10cbefe0b17940afed918
(cherry picked from commit 2ed665a033)
The only remaining users of stlport are vendor blobs. Prevent any new
users from using it.
Bug: http://b/15193147
Change-Id: I577a16c8c52e2c7d939c3b5026e18ad90e4b9f26
(cherry picked from commit 3a360a7353)
- Detect java-source-list before transforming to java-source-list-uniq.
This fixes non-fatal errors in build log like:
/bin/bash:
out/target/common/obj/APPS/android.core.tests.libcore.package.tzdata_intermediates/classes/java-source-list:
No such file or directory
- Cleaned the outdated incrementaljavac. Nobody is using this feature
and now we switched to jack.
Change-Id: If1adb9b5820d9b295a11984c0f170f9a7ff4de7b
Also filter out gcc-only flags -Wno-clobbered and -fno-devirtualize
when compiled with clang/llvm.
BUG: 19872411
Change-Id: I6de57583be04da607f569df65e93531787dbb789
(cherry picked from AOSP commit 90036610dd)
When an app's LOCAL_SDK_VERSION is lower than the support library's
LOCAL_SDK_VERSION, we artifically raises the "SDK version" "linked"
by ProGuard, to
- suppress ProGuard warnings of referencing symbols unknown to the
lower SDK version.
- prevent ProGuard stripping subclass in the support library that
extends class added in the higher SDK version.
This allows us to remove the dangerous ProGuard flag
"-dontwarn android.support.**".
Notes:
- We don't raise the app's LOCAL_SDK_VERSION, so that the app's own
code is still unable to use the higher SDK version.
- For platform build, we can't just raise to the "current" SDK,
because would break apps that use APIs removed from the current SDK.
We raise it to framework.jar instead, which contains the most complete
symbol set.
Bug: 20658265
Change-Id: I90099073457a65cb8031fbaec6b396d68ce614a7
(cherry picked from commit 8e8d1e7aba)
* commit '55abf4c22d08693cfb2838a79654fc32c7de3ff8':
Doc change: remove deprecated templates-sdk-dyn files, add new development files based on production templates-sdk.
* commit 'ff233cc92e379d501d8b256ba9a015827d77e012':
Doc change: remove deprecated templates-sdk-dyn files, add new development files based on production templates-sdk.
We need PT_LOAD segments to match for the gdb sake.
If we pack module after stripping symbolic version
PT_LOAD differ from actual ones; this confuses gdb.
Bug: http://b/20687795
Change-Id: If7b1ffcda918d0cc47051a30ca1202007ed62403
- We don't need LOCAL_PAGE_ALIGN_JNI_SHARED_LIBRARIES now, for we always
page-align jni shared libraries and store them umcompressed.
- For prebuilt apks, we don't extract jni any more; Instead we always run
uncompress-shared-libs on them.
- For apks built from source, we still install the jni separately, because
that way multiple apks can share the same jni and it saves space.
With this change, for most prebuilt apks, we don't need to specify
LOCAL_PREBUILT_JNI_LIBS ("@lib/<abi>/foo.so") any more, for the build
system automatically replaces the embedded jni with uncompressed files;
But if a prebuilt is a fat apk (i.e. containing jni not needed by the
current product architecture), you still need LOCAL_PREBUILT_JNI_LIBS to
specify what jni to keep. Otherwise all embedded jni will be replaced with
uncompressed files, that wastes space.
Bug: 8076853
Change-Id: Icf07e0998ac3602e6e05e80fed836fbafca33e01
