Install preloaded-classes as a standalone configuration file
/system/etc/preloaded-classes, so we can configure different file per product.
To override the default frameworks/base/preloaded-classes, just override
in your product configuration makefile with PRODUCT_COPY_FILES before it
inherits from build/target/product/base.mk: if there are multiple items
in PRODUCT_COPY_FILES with the same destination, the first one takes
precedence.
Bug: 18305157
Change-Id: I937632b4a1aa73310ec90e73fd708fbd0c704a21
This feature is now available in AOSP, but not for any shipped
release. We don't have an API version for the release that this will
be available in yet, so for now the check is commented out.
Bug: 18395015
Change-Id: I247233d047ed5a7564d6602d47c9ad962313c8dc
The previous position of libgcc.a/libatomic.a on the link line causes
the linker to prefer satisfying dependencies from these libraries from
other libraries that might include them, rather than from libgcc.a (or
libatomic.a) itself. This imposes an ABI requirement that those
intermediate shared libraries _always_ export those symbols, which is
undesirable.
Change-Id: Ib593236b475d3e98356b2b1be6f96cee2b67378f
Previously, there was one generic definition for each of the
transform-o-to-* functions in definitions.mk, and one target specific
one in each combo/TARGET_*.mk. The generic one was entirely unused,
and the target specific ones were all nearly identical.
Changing anything in these functions was tedious at best, and often
error prone. The differences between any 32-bit arch and its 64-bit
equivalent were restricted to the name of the linker, and the ARM and
MIPS definitions were identical. The few differences between ARM and
x86 looked to be compatibility for an old (ca. 2008) toolchain issue
with --gc-sections, and a bug (LDFLAGS coming first rather than
later).
To simplify things, I've moved the definitions for these out of
combo/TARGET_*.mk and back into definitions.mk. The differences
between ARM and x86 have been scrapped. Anything that really does
still need to be target specific can be handled as I have the linker:
add a TARGET_FOO variable to the given target and then add it to the
generic definition.
Change-Id: I54dc1bffc32ac39f27f0b87247dd6a6dbaf0b162
Now that the platforms stlport linked gtest is gone, we don't need the
logic for this any more. All platform tests will use libc++ (which has
been renamed to libgtest without a suffix).
Note that tests built with the NDK will still use stlport, but they
will use the NDK's stlport, not the platform's.
Bug: 15193147
Change-Id: Ifcb2489ed60c41e4ed028096b516c1ee643de907
This should obviate much of the need for cleanspecs, and also make it
unnecessary to continue adding LOCAL_ADDITIONAL_DEPENDENCIES for this
sort of thing all over the tree.
Change-Id: I97aa8fd280ae868a5f6364f8b7bf3c2fe235d6ce
The NDK protobuf library depends on the final target linking stlport
(since it is a static library). Since the platform stlport is going
away, we need to use a separate version of the protobuf library that
is compiled for the platform against libc++.
Note that this should be the case for _all_ libraries built with the
NDK. If a library needs to be used by both an NDK built final target
and a platform built final target, there should be both an NDK and
platform version of the library.
Bug: 15193147
Change-Id: I0ead61c2d1cd9d0248b304ab7d8682dedd6e8366
Also, add it to the ANDROID_BUILD_PROPERTIES.
Remove non-default instruction set features.
Bug: 18056890
Change-Id: I9169cdfecbb176f62b941852948222edc3f511fd
Nothing in our tree is using this HAVE_BACKTRACE definition, but we do have
a hack in external/llvm to work around the namespace pollution.
Change-Id: Ib51d8bbd598dd2961a028216bf0b489dc7ad4880
Previously, code defaulted to using libstdc++ (which was GNU libstdc++
on the host, or Bionic's "libstdc++" on the target). Now we default to
libc++. The exception for this is when using mingw, because we cannot
build libc++ for mingw.
Change-Id: I68726fa26cdcb6263f17c838d3e859debd57fae1
