Previously we have to use LOCAL_REQUIRED_MODULES to install jni
libraries for an apk in bundled build.
With this change, we'll use LOCAL_JNI_SHARED_LIBRARIES alone to
install jni shared libraries.
The new rules are:
- If we are doing unbundled build, or the apk isn't going to be
installed to system partitions, we'll embed the jni libs in the
built apk.
- Otherwise, the jni libraries will be installed to the system
lib path, and symlinks created in the app specific lib path.
Change-Id: Id6bd5301eb632bda3593664acee580f0d8b1d5d4
GCC: 4.9 (which supports -fstack-protector)
Binutils: 2.24 (which supports gc-sections)
GDB: 7.7
NDK libraries are still picked up from prebuilts/ndk/*/4.8/*
GCC has been patched to disable codegen for calling
__cxa_throw_bad_array_new_length.
Change-Id: Ie0bf38357c0cf3d265d8b5dd3c2b8a8fd83b1de1
The "-maarch64linux" switch is needed before aarch64-*4.8 is rebuilt with
backport of upstream patch, see https://android-review.googlesource.com/#/c/91099/
The existing ld.bfd is fine because it's configured to support
aarch64linux only. ld.mcld (see https://android-review.googlesource.com/#/c/91047)
needs explicit emulation switch because it supports multiple targets
Change-Id: Idc1a491c5722ea9e26db917b667b1000bccc1f60
Delete LOCAL_NO_2ND_ARCH, it is no longer used. Equivalent
functionality is available with LOCAL_MULTILIB := first.
Change-Id: I36838a8a7e10b0a59ca0022c4c8a3a190e782c71
GCC: 4.9 (which supports -fstack-protector)
Binutils: 2.24 (which supports gc-sections)
GDB: 7.7
NDK libraries are still picked up from prebuilts/ndk/*/4.8/*
GCC has been patched to disable codegen for calling
__cxa_throw_bad_array_new_length.
Change-Id: Ie647fc4c6b227d6bee792f04d5c2f02eb0099559
Everything under packages/ will build for 64-bit now, and
package.mk has been updated to not produce 64-bit libraries
on devices that don't support them (all of them right now).
Change-Id: I2c10e41f727cfc8fe237819308a6dfa34c4fff3f
Use TARGET_SUPPORTS_32_BIT_APPS and TARGET_SUPPORTS_64_BIT_APPS to
determine which native libraries to build for an app. If
both are set, it will use 64-bit unless TARGET_PREFER_32_BIT is set.
If only one is set, it will only build apps that work on that
architecture. If neither is set it will fall back to only building
32-bit apps.
On existing 32-bit devices neither variable will be set, and the
build system will continue to build 32-bit apps.
Once a device has support for a 64-bit runtime, the same logic
that selects the dual runtimes should set TARGET_SUPPORTS_32_BIT_APPS
and TARGET_SUPPORTS_64_BIT_APPS, and packages will be built for
the preferred arch, or fall back to the non-preferrred arch if
necessary.
For testing, a device may set TARGET_SUPPORTS_64_BIT_APPS without
TARGET_SUPPORTS_32_BIT_APPS to produce only 64-bit apps.
Change-Id: I5b5e23f15602c3cf9bd96791971208a85492c7a3
I don't expect it to be useful for modules, but package.mk will
use it to only install 64-bit native apps on devices that
only have a 64-bit zygote.
Change-Id: If3f5a81c3a60bd13fa6ded08e2a7579a29877324
TARGET_PREFER_32_BIT can't assume that the 32-bit rule is allowed,
it needs to try the 32-bit rule first, then fall back to the 64-bit
rule in case the module specifies LOCAL_MODULE_TARGET_ARCH or
LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH to disallow the 32-bit build.
Also port TARGET_PREFER_32_BIT to package.mk.
Change-Id: I07520b75c4ee11a1e95a82b3afa2a33d4907eb04
We no longer provide this function in bionic. All callers
should be moved over to pthread_condattr_setclock().
Change-Id: Iccd3384b40de423f7d5f9521b6d8073bf8bdea42
Introduce ro.product.cpu.abilist32 / abilist64, which are
comma separated lists of the 32 and 64 bit ABIs that the
device supports. These properties are used by the zygote and
system server to determine what ABI an app should be
started with.
This changes move abilist related make steps out of envsetup.mk
and into config.mk because they depend on variables set by
core/combo/***. Additionally, config.mk performs a few additional
cleanups of these variables (like stripping them) after the
inclusion of envsetup.mk so this seems like a better place to
put them.
bug: 13647418
Change-Id: I3db39bdd761220c5b4966f651892fb592396f9a1
It seems to be a javac/javadoc bug.
See https://code.google.com/p/doclava/issues/detail?id=38
sun.util.resources.OpenListResourceBundle is a class defined in the host rt.jar,
but sometimes on some platform javadoc/javac can't find it.
-XDignore.symbol.file tells javadoc/javac to skip the stubs file ct.sym
and link against rt.jar directly.
Change-Id: I3930f7399fc14b2d6b43c29f737fa90f37515aff
- If it's host module, don't set bootclasspath;
- If it's arget module,
- It can build against the API stubs;
- It can build against a historical SDK version;
- It can build against core.jar
Change-Id: Id1ec3ba624bc38068b206ad7173f4facf590e021
We want javadoc generated from the standard libraries
we supply and not the host standard libraries.
This also has the side effect of fixing javadoc generation
for java7 APIs that android introduced, while compiling
with java6.
bug: 8992787
Change-Id: Idebc7e12c7743a43b425ef4971f4482719fd480d
All introduce a flag LEGACY_USE_JAVA6 to force java6 builds.
This is an unsupported configuration, and provided temporarily
to iron out regressions and compare build output (if required.).
- Increment the version check sequence number.
- Move a more specific check (OpenJDK vs non OpenJDK) after
the more general version check.
- Update the link in the version check error message to the
"initializing" page instead of the "download" page. The latter
talks about repo, mainly.
bug: 8992787
Change-Id: I313e17b1911768d4f3bc318c4162c53dec6eaf0d
Conflicts:
core/main.mk
Unfortunately the previous approach of grepping out java version before
"head -n 1" clash with the effort of running "java -version" only once.
Change-Id: Ic78719c3bf1a54a45342d74bbbfa8e83bbc1bce1
The instruction URL has been amended and a few additional
details have been added.
(cherry picked from 8c06afdea3)
Change-Id: Icaffc3b13ed881ac7e29f2021ed31eb1f877a5ab
"GYP" class targets are used by external/chromium_org for gyp's "none"
type. The processing in these targets needs a separate intermediate
directory for the primary/secondary architecture, so add it to the list
in intermediates-dir-for along with libraries/executables.
Change-Id: Id05899c83b45ed0647dfbfa6b0b2e7f61b04348b
* Fix: my_target_global_ldflags is defined in binary.mk
so they effectivelly override previous definition
Change-Id: I9c7d9bde82c3a6d25a94ae109fa71ecaa33640b0
These lines were removed in aosp in commit e2d27887b
but a bad merge conflict resolution left them in master.
Subsequent changes on master started using these variables
so they're being brought back.
Change-Id: Ic8f3c295130c47eb0d66057880f9d4f70c89af94
Change-Id: I91d6ff72629523050b4f26c2d731cac90ef49348
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Reviewed-by: Jovanovic, Radivoje <radivoje.jovanovic@intel.com>
Reviewed-by: Boie, Andrew P <andrew.p.boie@intel.com>
Reviewed-by: Kumar-mayernik, Nisha <nisha.kumar-mayernik@intel.com>
Reviewed-by: Gumbel, Matthew K <matthew.k.gumbel@intel.com>
Tested-by: Gumbel, Matthew K <matthew.k.gumbel@intel.com>
_JAVA_OPTIONS is an environment variable that
can be used to affect the behavior of java and javac.
It is currently required to get Android to build on
some configurations, where the default Java heap size
is too small. Unfortunately, if _JAVA_OPTIONS is set,
both java and javac will output its value to the console
as the first line on every invocation, including trivial
ones like java -version. This will confuse main.mk’s
version detection, which only looks at the first line of
output. Tweak the version detection to run grep before
head, so that the _JAVA_OPTIONS line is filtered by the grep.
Change-Id: I69aee52b56d27711b7d3087ec6b3ebab07ffc3af
