Remove external/wpa_supplicant_8 and external/android-clat

from 64_bit_blacklist.mk.
They now build fine for 64-bit.

Change-Id: Ib73c8465b72cc7b40dae21441c3ea0bd25b7e6ba

Merge "Take libcore off the LP64 blacklist."

Merge "Generate .pb.cc/.pb.h to arch-neutral generated_sources_dir"

Generate .pb.cc/.pb.h to arch-neutral generated_sources_dir

So a library can export the proto's include path that can be used with
both archs in multilib build.

Change-Id: Ia0f92f0b40e39dc3fa426c69c52139a0a8f04077

Take libcore off the LP64 blacklist.

Change-Id: I34bc49370ecdd37f83927c3829c775e404bcbd73

Merge "Move qemud and /dev/qemu policy bits to emulator-specific sepolicy."

Move qemud and /dev/qemu policy bits to emulator-specific sepolicy.

Change-Id: I620d4aef84a5d4565abb1695db54ce1653612bce
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>

Merge "generic_x86: toggle 64bit binder ABI"

Merge "Make -rpath-link work with multilib."

Make -rpath-link work with multilib.

Change-Id: If69ea6ed6cdbb657ed4005f8217d653e29626783

Merge "Switch to LLVM 3.4 prebuilts in AOSP."

Merge "arm64: don't build emulator"

arm64: don't build emulator

There is no emulator kernel yet, so don't try to build the emulator.

Change-Id: I714f5717f439b4e48a973f4355f2c6684af79764

Merge "Include $(BUILD_COPY_HEADERS) in upper-level makefiles"

Include $(BUILD_COPY_HEADERS) in upper-level makefiles

This makes sure copy_headers.mk only be included onces, no matter
it's for the 1st arch or the 2nd arch.

Change-Id: I80a558fbdb52861f176bd27a21c302069a5cc3ce

Merge "Strip all symbols on x86"

Merge "Remove dead code."

Merge "Add missing $(combo_2nd_arch_prefix)s to mips."

Add missing $(combo_2nd_arch_prefix)s to mips.

Change-Id: I91a5f2d92cc964cbaeb1c07f27eb56ea1a0d53cc

Remove dead code.

It seems the code was meant to add the toolchain to ANDROID_BUILD_PATHS
and then export to PATH by lunch.
But now we export the toolchain to PATH explicitly in envsetup.sh and
the code is unnecessary.
This reduces the places to change when we upgrade the gcc version.
It also fixed the bug that the mips toolchain was always exported
regardless of the target arch.

Change-Id: Iee3b895b4c4e0df8971c27c01b9ecbd591848b12

Strip all symbols on x86

Strip all of the non-dynamic symbols on x86 targets,
instead of just the debug symbols.

Change-Id: Id799a6a8c8b0e8bf70977328e42e5efa23762f25

Merge "Fix x86 config file to support 2nd ARCH build"

Merge "Switch x86_64 to gcc-4.8"

Switch to LLVM 3.4 prebuilts in AOSP.

Change-Id: I064e953fb1bf69e7e321616647aab88dcc39af76

Merge "x86: set -msse2 for all builds"

x86: set -msse2 for all builds

All supported x86 processors have SSE2.

Change-Id: Ib4a0511c456fe3185b0b902390860ad557aeedcf

Merge "Add bcc to the list of PRODUCT_PACKAGES to install."

Add bcc to the list of PRODUCT_PACKAGES to install.

Bug: 7342767

As part of the process of sandboxing the online RenderScript compiler, we
need to install bcc.

Change-Id: Ia650bdcb760246f3f1e15ebb867f07d9802cdfbe

Switch x86_64 to gcc-4.8

x86 is already on gcc-4.8

Change-Id: I39b4298b705a6ad04cdaa434261c6b0d90d552ff
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>

Merge "Fix up android.core CTS tests."

Merge "changing the rules following java package renaming for external/apache-harmony."

Merge "Adding apache-harmony to cts."

Merge "add jsr166 tests to cts. Bug: 10390711"

Fix up android.core CTS tests.

Fix several wrongly configured tests that were either
looking for tests in the wrong jar (apache-harmony-tests
instead of core-tests) or using the wrong prefix.

Also, this change creates subsets of the harmony tests based
on subpackage names (java.net, java.io, java.nio etc.) instead
of the earlier harmony groupings.

Change-Id: Iea0e20d23512611d1aac92b2f8219031b6396c77

changing the rules following java package renaming for
external/apache-harmony.

(cherry picked from commit 27b4b5ffe12b179fc0d24747f9ead2d5f52c871a)

Change-Id: Ia5a7b2d401f23dfdc556ef1982efd441ed1d1ae2

Adding apache-harmony to cts.

(cherry-picked from commit 5fef52e9c986184796ff1e5fe54390614ba318a6)

Change-Id: I9a6595f5e8bc30654a062e0917d3ecd3ba28ebc7

add jsr166 tests to cts.
Bug: 10390711

Change-Id: I512770e98f61995fc33043d35562dc3b213a4930

Fix x86 config file to support 2nd ARCH build

Change-Id: I5f6091c555b9e742303f294b7c07a981ae5c6026
Signed-off-by: Qiming Shi <qiming.shi@intel.com>

Merge "gettop: fix symlink detection"

Merge "Fix incorrect x86 build rules."

Merge "fix build"

fix build

Include prebuilt_internal.mk for host builds.

Change-Id: I750d6f71b3a2c67b11536babb8b39060005f4ff4

Merge "add linker64 and debuggerd64 to all products"

Merge changes I2514f66f,I71fed98d

* changes:
  support LOCAL_MODULE_TARGET_ARCH for prebuilts
  Add generated sources dir to the default include path

add linker64 and debuggerd64 to all products

Add linker64 and debuggerd64 to embedded.mk.  They will be silently
ignored on 32-bit builds, and filtered out on 32-bit sdk builds.

Change-Id: I8c30ea65e2b7e224ee73cc9fbbcb7555d3be04b5

Merge "Don't check the existence for the 64-bit modules for 32-bit SDK build."

Don't check the existence for the 64-bit modules for 32-bit SDK build.

Change-Id: I0d5d6ecc07332bef6854466fd98380eb12fc08fc

support LOCAL_MODULE_TARGET_ARCH for prebuilts

Prebuilts often support only a single architecture, allow them to
use LOCAL_MODULE_TARGET_ARCH to specify it.

Change-Id: I2514f66f682ef267bbf1a1ab78510faff0a18b64

Add generated sources dir to the default include path

Change-Id: I71fed98dfbc0bf5efad069a251eee2e5ab2e5fe6

Merge "don't use LOCAL_*_arch for host builds"

don't use LOCAL_*_arch for host builds

The LOCAL_*_$(TARGET_ARCH) variables don't make sense for host
modules, only append use them for target modules.

Also complete the list of LOCAL_*_arch and LOCAL_*_32/64 to be
consistent.

Change-Id: I00c83e5c4e08ed9a844f9f99a79ce4bcc3f0bf11

Merge "make 64-bit builds into multiarch builds"

Fix incorrect x86 build rules.

combo/TARGET_x86*.mk mistakenly added TARGET_GLOBAL_CFLAGS to their
linker command lines. This results in clang builds not working properly,
since they strip some unknown flags from TARGET_GLOBAL_CFLAGS.

Change-Id: I60a1ff5df70305323134435e4ae107ea7acfe8ea

make 64-bit builds into multiarch builds

Also enable the 64-bit binder interface and make them only use ART.

Change-Id: I05de41ce348c14722c84a658f745659bde5ba423

Merge "Remove dead code."

Remove dead code.

Change-Id: Ia36a04037e15cbf296f375f3ece9a7e977fdca1e

Merge topic 'arm64'

* changes:
  HACK: add 64-bit directory blacklist
  add support for module supported or unsupported target architectures

Merge "Refactor a little bit and do the validation on also default.prop."

HACK: add 64-bit directory blacklist

Change-Id: I431e8b220db81d51930dc0b3d95995df120c179a

add support for module supported or unsupported target architectures

Add four new variables for module makefiles:

LOCAL_MODULE_TARGET_ARCH specifies that a module is only supported for
one or more architectures.  Any architecture not in the list will be
not attempt to build the module.  The expected use case is prebuilts
that are only suitable for a single architecture, or modules like llvm
that need per-architecture support.

LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH specifies that a module cannot be
built for one or more architectures.

LOCAL_MODULE_TARGET_ARCH_WARN and LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH_WARN
are the same, but warn that the arch is not supported, which is useful
for modules that are critical but not yet working.

The logic for whether or not to build an architecture is fairly
complicated, so this patch consolidates it into module_arch_supported.mk

Change-Id: I120caf4a375f484e1fd6017b60c2f53882ae01e6

Refactor a little bit and do the validation on also default.prop.

Change-Id: I76c2344d9033eadede7048689a879c9a69a05b7f

Merge "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."

Merge "Clean up dangling module names"

Clean up dangling module names

Those modules have disappeared from the source tree.

https://code.google.com/p/android/issues/detail?id=61210

Change-Id: Iab369d2f591f46eb86b9fccf2087515edf974662

Merge "Refine module name resolving in multilib build"

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.

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

Merge "Add all-S-files-under."

Add all-S-files-under.

Change-Id: I25416e2acc850c61226bc7a8e0536384f6eb2dce

Merge "fix 2nd target clang prebuilt paths"

fix 2nd target clang prebuilt paths

Change-Id: I4c196221bd377e30bbff1aafa265952e29c85cb5

Merge "Runtime resource overlay, iteration 2"

Refine module name resolving in multilib build

-- Added TARGET_PREFER_32_BIT, which sets LOCAL_32_BIT_ONLY for an
   executable, if LOCAL_NO_2ND_ARCH is not true.

Name resolving in 64-bit multilib build:
-- Name resolving in PRODUCT_PACKAGES:
   foo:32 resolves to foo_32;
   foo:64 resolves to foo;
   foo resolves to both foo and foo_32 (if foo_32 is defined).

-- Name resolving for LOCAL_REQUIRED_MODULES:
   If a module is built for 2nd arch, its required module resolves to
   32-bit variant, if it exits;
   Otherwise for executable and shared library, a required module
   resolves to the default 64-bit variant; for other module classes,
   required module foo resolves to both foo and foo_32 (if foo_32 is
   defined)

Bug: 12898862
Change-Id: I5fda1a77f58814097b10b5ad2743ee25adfaecc4

generic_x86: toggle 64bit binder ABI

Change-Id: I60b8d98ff1f1ba5f242d256279e27d780b5dabf9
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>

Merge "Add missing font files to SDK system images."

Merge "Refreshed gcc predefines __ANDROID__"

Refreshed gcc predefines __ANDROID__

Change-Id: Id76f5a7490fba8190329e5ce3c4b138976a034ce

Merge "Select the arch_variant_cflags for the 2nd arch."

Select the arch_variant_cflags for the 2nd arch.

Change-Id: Id2f9d7073a4aae3ba0fe5e5464045761f4d42b4e

Merge "Refactor llvm_config.mk and support the 2nd arch"

Refactor llvm_config.mk and support the 2nd arch

1. Following the setup of gcc in build/core/combo/,
we added the [HOST|TARGET]_<arch>.mk clang config files,
and load only the configs needed by the current product.
2. Added support for the 2nd arch.

Change-Id: I2a383418a9688a050b39492f8e489d40eeeb5f2d

Merge "don't rename 32-bit packages to *_32"

don't rename 32-bit packages to *_32

Renaming 32-bit packages to *_32 breaks PRODUCT_PACKAGES dependencies.

Change-Id: I5457c07b64885d77a6bd8fbcbba97d28393c581d

Merge "Turn 64-bit-related warnings into errors on 64-bit builds."

Merge "[MIPS64] Add mips64 target"

[MIPS64] Add mips64 target

Change-Id: Ice1621101c0d5a3314db288542ca8020e3f406bf
Signed-off-by: Duane Sand <duane.sand@imgtec.com>

Merge "Add library test makefile solutions."

Turn 64-bit-related warnings into errors on 64-bit builds.

I don't think we can realistically turn this on for 32-bit builds any
time soon.

Also, fix the arm64 stack-protector hack.

Change-Id: Ie1e7c875bbc06fb21bb372b8ca99879a23ef53d4

Add library test makefile solutions.

Change-Id: Ibc8df9b0e2342683158936bf011425780df8f02a

Merge topic 'arm64'

* changes:
  add support for more LOCAL_*_arch variables
  don't rename 32-bit executables to *_32
  remove 2nd arch from ARCH_ARM_* defines

Merge "Fix installing 2nd arch shared libraries"

add support for more LOCAL_*_arch variables

Add support for:
LOCAL_SHARED_LIBRARIES_arch
LOCAL_STATIC_LIBRARIES_arch
LOCAL_WHOLE_STATIC_LIBRARIES_arch
LOCAL_GENERATED_SOURCES_arch
LOCAL_REQUIRED_MODULES_arch

Change-Id: Iad91702e140d8dba7dcaee13f236c77b1e626a34

Fix installing 2nd arch shared libraries

2ND_TARGET_DEPENDENCIES_ON_SHARED_LIBRARIES was not set,
which was causing the later += to act like = instead of
:=, and the dependencies would disappear as soon as
LOCAL_MODULE was cleared.

Change-Id: Idea291524fc06377deafec62f37d20eaa7f93bca

don't rename 32-bit executables to *_32

Renaming 32-bit executables to *_32 breaks PRODUCT_PACKAGES
dependencies.

Change-Id: I53d89991633ef4af03c4e618c463769937a70e38

remove 2nd arch from ARCH_ARM_* defines

Users of ARCH_ARM_* defines don't care about first vs. second arch,
set ARCH_ARM_* regardless of which arch is arm.

Change-Id: I2ae83ec5c3f839ff91a0e352c95d76ec2cbd5dc5

Add missing font files to SDK system images.

This adds a few missing font families to SDK system images.
This allows, in particular, support for the Korean language.

Note that this depends on other patches under device/generic/
to fix some board and product configuration files, otherwise
this change will have no effect.

See http://b.android.com/40340

Change-Id: Idba6471de32232833f511a4da97fd652906fec51

Merge "Add new rs directory to list of Java subdirs of fw/base."

Merge "Dedup the targets and dependencies of required modules."

Dedup the targets and dependencies of required modules.

For whatever reason, two modules may have the same file as their
installed module. In that case circular dependency is created if the two
modules have requited-by relation.

Change-Id: I15ed271ca3f3c343e4662182ded5ccc63d6c42cc

Add new rs directory to list of Java subdirs of fw/base.

Change-Id: I3213a314e7700162e781526c0450678495442759

Runtime resource overlay, iteration 2

Support any number of overlay packages. Support any target package.

UPDATED PACKAGE MATCHING
------------------------
In Runtime resource overlay, iteration 1, only a single overlay package
was considered. Package matching was based on file paths:
/vendor/overlay/system/framework-res.apk corresponded to
/system/framework-res.apk. Introduce a more flexible matching scheme
where any package is an overlay package if its manifest includes

    <overlay targetPackage="com.target.package"/>

For security reasons, an overlay package must fulfill certain criteria
to take effect: see below.

THE IDMAP TOOL AND IDMAP FILES
------------------------------
Idmap files are created by the 'idmap' binary; idmap files must be
present when loading packages. For the Android system, Zygote calls
'idmap' as part of the resource pre-loading. For application packages,
'idmap' is invoked via 'installd' during package installation (similar
to 'dexopt').

UPDATED FLOW
------------
The following is an outline of the start-up sequences for the Android
system and Android apps. Steps marked with '+' are introduced by this
commit.

Zygote initialization
   Initial AssetManager object created
+    idmap --scan creates idmaps for overlays targeting 'android', \
           stores list of overlays in /data/resource-cache/overlays.list
   AssetManager caches framework-res.apk
+  AssetManager caches overlay packages listed in overlays.list

Android boot
   New AssetManager's ResTable acquired
     AssetManager re-uses cached framework-res.apk
+    AssetManager re-uses cached 'android' overlays (if any)

App boot
   ActivityThread prepares AssetManager to load app.apk
+  ActivityThread prepares AssetManager to load app overlays (if any)
   New AssetManager's ResTable acquired as per Android boot

SECURITY
--------
Overlay packages are required to be pre-loaded (in /vendor/overlay).
These packages are trusted by definition. A future iteration of runtime
resource overlay may add support for downloaded overlays, which would
likely require target and overlay signatures match for the overlay to
be trusted.

LOOKUP PRIORITY
---------------
During resource lookup, packages are sequentially queried to provide a
best match, given the constraints of the current configuration. If any
package provide a better match than what has been found so far, it
replaces the previous match. The target package is always queried last.

When loading a package with more than one overlay, the order in which
the overlays are added become significant if several packages overlay
the same resource.

Had downloaded overlays been supported, the install time could have been
used to determine the load order. Regardless, for pre-installed
overlays, the install time is randomly determined by the order in which
the Package Manager locates the packages during initial boot. To support
a well-defined order, pre-installed overlay packages are expected to
define an additional 'priority' attribute in their <overlay> tags:

    <overlay targetPackage="com.target.package" priority="1234"/>

Pre-installed overlays are loaded in order of their priority attributes,
sorted in ascending order.

Assigning the same priority to several overlays targeting the same base
package leads to undefined behaviour. It is the responsibility of the
vendor to avoid this.

The following example shows the ResTable and PackageGroups after loading
an application and two overlays. The resource lookup framework will
query the packages in the order C, B, A.

        +------+------+-     -+------+------+
        | 0x01 |      |  ...  |      | 0x7f |
        +------+------+-     -+------+------+
            |                           |
        "android"                Target package A
                                        |
                       Pre-installed overlay B (priority 1)
                                        |
                       Pre-installed overlay C (priority 2)

Change-Id: If49c963149369b1957f7d2303b3dd27f669ed24e