With this change, you can package up modules while avoiding installing
them to the system.img or userdata.img.
- build/core/tasks/tools/package-modules.mk
You can use this template to package up modules into a zip file and
preserve the installed file paths.
- LOCAL_PICKUP_FILES, you can use this variable to package up extra
files/directories.
Bug: 13585955
Change-Id: I103042b24ccf17cf5dc90c016d97ed1dd293e50b
* commit '6f9166640a62f694a257a307284ea1c442f66a7b':
build: add core_64_bit.mk
build: reverse abi list when TARGET_PREFER_32_BIT_APPS is set
build: split TARGET_PREFER_32_BIT for apps and executables
* commit '735628e8d19fae51574bd5057c142db56797a2b0':
build: add core_64_bit.mk
build: reverse abi list when TARGET_PREFER_32_BIT_APPS is set
build: split TARGET_PREFER_32_BIT for apps and executables
* commit '2ff8919de339209412d9da2a524f566dfcf5847f':
build: add core_64_bit.mk
build: reverse abi list when TARGET_PREFER_32_BIT_APPS is set
build: split TARGET_PREFER_32_BIT for apps and executables
* changes:
build: add core_64_bit.mk
build: reverse abi list when TARGET_PREFER_32_BIT_APPS is set
build: split TARGET_PREFER_32_BIT for apps and executables
A separate OEM file must be specified to provide the expected
values for these properties. The list of properties comes from
the "oem_fingerprint_properties" list in misc_info.txt
Bug: b/13367676
Change-Id: I1a3eaf108492132cf6f595a5d1c9f7e0c3cb3142
If the product prefers 32-bit apps signal that preference to
PackageManager by reversing the abi list.
Also uses the absence of TARGET_SUPPORTS_32_BIT_APPS and
TARGET_SUPPORTS_64_BIT_APPS to remove those ABIs from the
ABI list.
Change-Id: I504cea21b6f800a7a9e7706b4a7123d3fb07c383
Introduce two new flags, TARGET_PREFER_32_BIT_APPS and
TARGET_PREFER_32_BIT_EXECUTABLES that individually control
compilation of apps and executables. If TARGET_PREFER_32_BIT is
set, the build system will automatically set both new flags.
Change-Id: Ibd2165e688675c2884d9e7ddf82d7dd6c28521f3
This is used for Baytrail targets.
Change-Id: I5a2fa6dbb8217a326ee09f5ea434885718ab3f0c
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
Signed-off-by: Fengwei Yin <fengwei.yin@intel.com>
external/chromium-libpac has been updated to depend on the copy of V8 in
external/chromium_org, and its makefiles updated to be multilib-safe.
external/v8 is thus unused and has been removed from the tree.
Bug: 12452053
Change-Id: I757fa187f7f67cd9a89d4b228d4ce3ed6d2858b1
The C++ version avoids the need to unsparse the image to generate
the verity image, and is much faster for images with large regions
of don't care (treated as zeroes).
Change-Id: I8396b08a5fdb93f27d8c71c9c1ac23cb75cf1f7f
Move image dependencies out of PRODUCT_PACKAGES and into direct
dependencies for the image building rules.
Fix the test for PRODUCT_SUPPORTS_VERITY, it needs to check for
the current project as the global is no longer set.
Change-Id: I811501834ae5ec658229bd505fcc48275ff578c9
To build oem.img:
- You must define BOARD_OEMIMAGE_PARTITION_SIZE in your BoardConfig.mk
- The file system type will be the same as system.img and userdata.img.
- To install a module to oem.img, use "LOCAL_OEM_MODULE := true"
- run "make -j48 showcommands oem_image dist". By default it's not
built.
Bug: 13367676
Change-Id: I1a26d4d0c61b72ecffe60279667b1b3de050780d
prebuilts/ndk/current/platforms/android-19/arch-x86_64/usr/lib
is renamed to usr/lib64 to be more consistent with rest of
lib paths in x86_64 toolchain, which is multilib
See https://android-review.googlesource.com/#/c/92441/
Change-Id: I4e59245505d0fa87ae3608e81e715ccfcecc5ec8
external/chromium_org has been updated to handle 64-bit architectures
correctly in its makefiles; remove it from the blacklist so we can start
experimenting with building a 64/32 multilib version.
Change-Id: Ieb0e4f3cfea1578e01954c4656df90cd8d36b8cc
Use LOCAL_PREBUILT_JNI_LIBS to install prebuilt JNI libraries extracted
from the prebuilt apk, or prebuilts as source, to the app specific lib path.
LOCAL_PREBUILT_JNI_LIBS accepts 2 kinds of files:
- Files like @path/to/libfoo.so (path inside the apk) are JNI libs
extracted from the prebuilt apk. In this case, all embedded JNI libs
inside the prebuilt apk are stripped.
- Files like path/to/libfoo.so (path relative to LOCAL_PATH) are
prebuilts in the source tree.
Those prebuilt JNI libs are not defined as modules in the build system,
so this works around possible module name conflict.
Bug: 13170859
Change-Id: I91bb844cc11b3621a85733bc7e8910f168957ef0
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
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
Previously html_dir_files includes every file in $(LOCAL_PATH), if
$(LOCAL_DROIDDOC_HTML_DIR) isn't set.
Change-Id: I3c249e5f4a0f52f71edd92862361c1dc4ab6bed7
Change runtime library name to keep in sync with upstream.
Enable frame pointers in instrumented code for fast stack unwind.
Change-Id: I815912bb856c56c399639ea76ad4cb6b97961840
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
LGPL projects need their source code distributed under very
similar conditions to GPL and MPL, the only difference is the
conditions under which they may be linked. It makes sense to
include them in the GPL archive tarballs.
Change-Id: I2c2df03906bfeee55566102aa688e4cdc283700b
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
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
* commit '14203772619f4b4740941de634f90b7a02231aa5':
build: remove packages/ from 64-bit blacklist
build: use TARGET_SUPPORTS_32_BIT_APPS and TARGET_SUPPORTS_64_BIT_APPS
build: add support for LOCAL_MULTILIB := 64
build: fix TARGET_PREFER_32_BIT
* commit '3221717fec6c150a24505ed392279a73da5c4e26':
build: remove packages/ from 64-bit blacklist
build: use TARGET_SUPPORTS_32_BIT_APPS and TARGET_SUPPORTS_64_BIT_APPS
build: add support for LOCAL_MULTILIB := 64
build: fix TARGET_PREFER_32_BIT
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
The OTA generation scripts need to know what system properties to
read from the OEM partition, so pass along from product definition.
Also define "thumbprint" which is only the build-specific parts of
the fingerprint. (Thumbs are smaller than fingers.)
Bug: 13367676
Change-Id: Iae051dcd2b1c67a7c8554d8ae318a4c54a86d614
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
