Preparing for migration from stlport to libc++. STL selection is done
with LOCAL_CXX_STL (valid values are default, none, libc++,
libc++_static, stlport, stlport_static, bionic).
The selection of the STL is as follows:
if LOCAL_CXX_STL == 'default'
ifdef LOCAL_SDK_VERSION
Use whatever STL the other NDK options have selected.
else
Use bionic's libstdc++ for target, GNU libstdc++ for host. This
is compatible with the existing build options.
endif
else
if LOCAL_CXX_STL == 'stlport'
Use stlport.
else if LOCAL_CXX_STL == 'libc++'
Use libc++.
else if LOCAL_CXX_STL == ''
Don't use any STL.
endif
endif
Bug: 15193147
Change-Id: If712ba0ae7908d8147a69e29da5c453a183d6540
The AOSP bootimage format allows the use of a second stage image
however the BuildBootableImage function does not allows the "second"
optional argument. This patch adds the support of this argument.
Change-Id: I8ed9d9e56449945c2d42fc908269921c394f68c0
Signed-off-by: Benoit Fradin <benoit.fradin@intel.com>
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
When signing an APK, make the SignApk tool align the stored entries to
(by default) 4-byte boundaries. This obviates the need to run the
separate zipalign tool, which currently does this job.
The alignment byte count can be specified with the -a option. OTA
package signing (with -w) never does alignment.
The order of files in the output APK is changed so that all stored
files come first in the output, followed by all non-stored files.
This is not expected to have any impact in practice.
Change-Id: Iaeef89b2a7283e25fadb99c0a0f0641f682d76b8
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
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
Add a (read only) system property that is a comma
separated list of ABIs supported by the device in order
of preference. For example, typical arm-v8 device might
define:
ro.cpu.abilist = arm64-v8a,armeabi-v7a,armeabi
For most purposes, a single flattened list like the above is
probably more useful than the parallel system of variables
TARGET_CPU_ABI{2} / TARGET_2ND_ARCH_CPU_ABI{2} that we use
in the build system.
Change-Id: If9102669ad9f5f8fd89a8bcc5bf88cca1acadc3c
* commit 'de90b0307a603449354bb2d265c5b2315b7b6850':
A build property's value is returned empty in runtime when its length exceeds 92 symbols (91 valid symbols + \0). It is better to catch that issue on earlier stage, i.e. fail the build with an appropriate message.
exceeds 92 symbols (91 valid symbols + \0). It is better to catch that
issue on earlier stage, i.e. fail the build with an appropriate message.
For developer's build, show warning message instead of failing the build
(in the latter case, as developers do not usually care about build properties
too much).
Change-Id: I03ced7b486d43a71b1921e0a9c48b43aa30727c7
Sometimes it is useful to be able to tell ota_from_target_files
to not sign the output zip file. For instance, the private
release key may not be available when ota_from_target_files
is executed; similarly the release tools may not be available
or executable where the private key is stored.
This change adds an option, '--no_signing', to simply output the
unsigned OTA zip file, instead of spuriously signing it with the
test key even though the zip file would need to be re-signed later
with a different key.
Change-Id: I1f3c4dc8ffa35ce85478f848b147aff3d40fe283
* commit 'bf9d72ff4d6952c0546a2bf249938dfbe4f7768e':
set fixed height for header div to ensure the next/prev links in the training bar are always aligned with TOC
* commit '078160410ad4209fb78f59ae8e04a6118914cdb5':
set fixed height for header div to ensure the next/prev links in the training bar are always aligned with TOC
