A module can declare "LOCAL_SDK_VERSION := system_current" to build
against the android system stubs generated from source.
For now this is only supported in platform build.
Change-Id: I1e9bbd159886bc0ea3a02b1dc4cbcb1a56e9cb15
- Support TARGET_USERIMAGES_USE_F2FS.
- Support BOARD_USERDATAIMAGE_FILE_SYSTEM_TYPE.
- Support "userdata_fs_type" in the prop dict.
- Update build_image to recognize f2fs and call the correct command.
Change-Id: If31cc8bd235f93a4c7814fab36e6e2d13d3037ad
Signed-off-by: JP Abgrall <jpa@google.com>
* commit '423242b59ea01dffbb7f79c7c045528f7c351c4b':
set a prebuilt directory name for the 2nd arch
add vendor directories to gdb shared library search path
add 2nd arch gcc to the path
fix paths when 2nd arch gcc is a different version
* commit '828b518377f69516ea6cbb9ad160d81ced6980d5':
set a prebuilt directory name for the 2nd arch
add vendor directories to gdb shared library search path
add 2nd arch gcc to the path
fix paths when 2nd arch gcc is a different version
In order to install 32-bit gdbserver on a 64-bit build,
prebuilts/misc/Android.mk needs to know the prebuilt directory name
for the 2nd arch.
Change-Id: Ibc943b758eb9404f7f5f9fbbd8720cc67f6a6f01
If the VM is libart and DEXPREOPT is enabled,
- For a Java library and the boot image, we build for both 1st arch and
2nd arch.
- For an app, we build for the multilib arch the module is targeted for.
The odex file will be in <arch_name>/<module_name>.odex inside the same
dir where the jar/apk file gets installed.
Nothing changed if it's built for libdvm.
Bug: 14694978
Change-Id: I45118a83758b41d52d6c9e38f93f0ba2775a6c74
This change basically ported our target multilib to the host side.
It supports 2 host build modes: x86 and x86_64 multilib build.
For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64
multilib build. Later we'll default to x86_64 build and have a flag
to force 32-bit only build, which may be needed by SDK build.
In host module definition, like in target ones, you can use the
following
LOCAL variables to set up multilib configuration:
LOCAL_MULTILIB: can be "both", "first", "32" or "64".
It also supports the same set of arch or 32-vs-64 specific LOCAL
variables.
By default, it builds only for the first arch.
To keep path compatibility, in x86_64 build files are still output to
out/host/linux-x86; Both 32-bit and 64-bit executables are in
out/host/linux-86/bin;
In x86_64 build 32-bit shared libraries are installed to
out/host/linux-x86/lib32
and 64-bit shared libraries are installed to out/host/linux-x86/lib;
32-bit object files are output to out/host/linux-x86/obj32 and 64-bit
object files
are output to out/host/linux-x86/obj.
Bug: 13751317
Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
* 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
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
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
