[HAX] Allow per-target dtbTool

 * Revert this when fixed

Change-Id: I97ecb0448ae7bd5859454be290c5dde6248b2859
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
Include privileged apps with app zip file.

Include apps that appear under /system/priv-app
to also be included with the zip of all the apps.

Change-Id: If4687cf4c471877f11d78b68bad96f1842e49d87
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
sdkgen: logging: coloured output and indication of completion

Change-Id: Iba754e9c277bdcabab992f31905af964836059c4
Signed-off-by: Arnav Gupta <championswimmer@aokp.co>
add gcd funtion to envsetup.sh

  gcd - cd to any tracked git project from any other
  path in the build tree.

Change-Id: I8fde827dc51ac4006030712239f9ee6593b07c4c
Use -mcpu=cortex-a15 for krait

Based on https://android.googlesource.com/platform/build/+/d195c6d14e027f12f63508afed245a1ce469c936

Change-Id: Ib409c915c5302cdb44d49978456b7d1cc6a2a250
Signed-off-by: Dirk Rettschlag <dirk.rettschlag@gmail.com>
Allow devices to specify certain ro. props via TARGET_UNIFIED_DEVICE

This modifies buildinfo.sh to not set model, name, description, and
fingerprint in build.prop. These can then be set via custom init
lib.
This also fixes ota_from_target_files to function without these
props being preset.

Change-Id: I5dc6fa19267a0e5374b07fc04db0766661da492d
Signed-off-by: Arnav Gupta <championswimmer@aokp.co>
Store the path to the ota file generator where it can be reused

Change-Id: I8896713c79a751b79fbbcc75f6ba30dad4ea9fac
Store the value from TARGET_OTA_ASSERT_DEVICE to a file

This is needed so it can be read in when re-signing a package to
allow for the proper device asserts.

Change-Id: I8f3bb491bbbaa4d2b827a45ef83f12c6c83e6712
Store the value from BOARD_CUSTOM_BOOTIMG_MK to a file

This is needed so it can be read in when re-signing a package to
use the proper boot image.

Print notice when using a custom bootimage makefile

Change-Id: I6baab9f8964ce5d4fa9487f2859af9c385d7b21b
releasetools: don't create prebuilt_dir path if it exits

This path may already exists from previous build tasks. Attempting
to create it again will cause an error.

Change-Id: I4baad8bc846470b99f6ce9207c0682401406decc
Fix droiddoc generation.

We want javadoc generated from the standard libraries
we supply and not the host standard libraries.

This also has the side effect of fixing javadoc generation
for java7 APIs that android introduced, while compiling
with java6.

bug: 8992787
Change-Id: Idebc7e12c7743a43b425ef4971f4482719fd480d
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
New Theme Engine [4/6]

Adds aapt for on device compiling of theme assets

Change-Id: I2f9f4b3e27ddf32b339694f9c6d3b75a12b700d9
sdkgen: add android-common

Change-Id: I4dbef9ed04c137880b3651490f8a66cb82664101
Signed-off-by: ChampionSwimmer <championswimmer@aokp.co>
build: Set ccache base to build top

This enables ccache sharing between different build tree paths.

Change-Id: I99636bdd2779a6ccf0649f027e35cf67df44b6ae
show ccache information in dumpvars

Change-Id: If3064e8d76d8cffd6302f72e4077678f0ab49b11
Signed-off-by: Dirk Rettschlag <dirk.rettschlag@gmail.com>
Merge "sdkgen: add android-common" into kitkat
Merge commit 'ac876e5321900085d8fa5df3b1ab435c3881f598' into kitkat