gettop: fix symlink detection

Summary: We must use the -P flag for pwd to properly get $PWD from the environment *with* symlinks. Otherwise symlink
detection is broken and anything we do using $(gettop) at the top of a symlinked path won't work properly. I noticed this
issue while running on a system that has a SSD RAID symlinked to my android build home directory, which is ~/ssd_storage.
The top in this instance is a symlink, which means that gettop() returns my home path, or the path above the symlink
directory (but not the symlinked directory). This is a major issue in case developers choose to use $(gettop),
$ANDROID_BUILD_TOP, or $T (doesn't really matter either way).

Test Plan: Create a symlink and sync android source into the path. Open up the symlink, run envsetup.sh, and check
$(gettop) output.

While this isn't the best solution, it fixes an issue without creating new issues.

Change-Id: I65bc345753805e6161098d2af6e0bee0b07d37b1
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
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
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
don't rename 32-bit executables to *_32

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

Change-Id: I53d89991633ef4af03c4e618c463769937a70e38
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
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
Merge "Fix installing 2nd arch shared libraries"
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
Add library test makefile solutions.

Change-Id: Ibc8df9b0e2342683158936bf011425780df8f02a
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
Merge "Add library test makefile solutions."
[MIPS64] Add mips64 target

Change-Id: Ice1621101c0d5a3314db288542ca8020e3f406bf
Signed-off-by: Duane Sand <duane.sand@imgtec.com>
Merge "[MIPS64] Add mips64 target"
Merge "Turn 64-bit-related warnings into errors on 64-bit builds."
don't rename 32-bit packages to *_32

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

Change-Id: I5457c07b64885d77a6bd8fbcbba97d28393c581d
Merge "don't rename 32-bit packages to *_32"
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 "Refactor llvm_config.mk and support the 2nd arch"
Select the arch_variant_cflags for the 2nd arch.

Change-Id: Id2f9d7073a4aae3ba0fe5e5464045761f4d42b4e