New command line tool 'idmap'

Introduce a new tool 'idmap' to handle generation and verification of
idmap files. The tool is modelled on 'dexopt', and is intended to be
used similarly, notably by 'installd'.
See cmds/idmap/idmap.cpp for further documentation on 'idmap'.

Note: this commit is interdependent on a commit in project build/ to add
'idmap' to PRODUCT_PACKAGES.

Note: the changes to androidfw are only stubs. The actual implementation
will be provided in Runtime resource overlay, iteration 2.

Change-Id: I7131b74ece1e46c8a9c0a31d103e686aa07da2bb
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 [2/6] CM11 Themes

See frameworks/base themes commit for full summary.

[SUMMARY]
1. Modifies idmap binary to include target APK in filename. Needed so one theme apk can have multi targets.
2. Allows aapt to be called via installd. Needed to compile resources found in a theme apk's assets folder.

[IDMAP EXAMPLE]
OLD: vendor@overlay@overlay.apk@idmap
NEW: vendor@overlay@overlay.apk@system@app@target.apk@idmap

[CONTRIBUTORS]
Andrew Mast <andy@cyngn.com>
Clark Scheff <clark@cyngn.com>
Special thanks to Mårten Kongstad and the rest of the Sony team for their work in idmap.

Change-Id: I0cb15830109ac36780c015e61348c00ec08d24a1
Revert swaprect feature for new upstream implementation.

Revert "Display: Define new composition type for blit composition"

This reverts commit 835f0ad6da60ad5cd5f8d6d872c5665aae6f5584.

Revert "surfaceflinger: Conditional compilation for swaprect feature"

This reverts commit 5e9e33ac72e608d584b13bea176f8fc7f30d88e7.

Conflicts:
	services/surfaceflinger/DisplayHardware/HWComposer.h

Change-Id: I83e3b5a66b9ea7c3bae008d6a7e84c1358c512bc

Revert "SF: Add flag for swaprect status in HAL"

This reverts commit 4fd75c0a371d4ee04e0f583d790b576494257ea8.

Conflicts:
	services/surfaceflinger/DisplayHardware/HWComposer.cpp

Change-Id: Ibd8714a49e09653bf34da466db17fbe4b20c6c8d

Revert "sf: Enable swaprect optimization by default only on QCOMs"

This reverts commit 0438f810c7e8e3c53850874c7bdb74ac43b2ec88.

Revert "Display: Add swaprect feature for MDP composition."

This reverts commit 9b5ef3793b6012e979c10e4cc9a7e091092a4a57.

Conflicts:
	include/gui/Surface.h

Change-Id: I6d276ee82f8f0b4214e79c91cd9675fcbfd57dd4
frameworks/native: Propagate dirty region in hwc_layer

This change propagates dirty rect value of each layer down to HWC
in hwc_layer structure.

Change-Id: I91d87facf4a321b92539de5353faf09b553d4919
egl: Addition of eglGpuPerfHintQCOM

This patch implements a wrapper that hooks into the QCOM
functionality.

Change-Id: Ifcb77e90ba137a4dede7d25663b032df6acc799d
SF: Add known programs to cache.

First open/close application after boot creates
shaders and compiles them we can cache these
programs at initialization, to avoid CPU work
at open/close application and JANK in SF.

CRs-Fixed: 615960

Change-Id: I4837e83941db903e84f195aa052e9e9dab6ff81e
CM11 Themes: Store hash codes for target and overlay in idmap

Due to some system packages always having the same last modified
time stamp of 08/01/2008 we must use some other unique value to
determine that the contents of either the target or the overlay
have changed.  This unique value will be passed down from the java
layer and written to the idmap header.

This change requires the following patch from frameworks/base
http://review.cyanogenmod.org/62565

Change-Id: I0adcafaca96110268766d6e3349414364ecea4c3
GFX-3D: Hold the BufferReference of GraphicBuffer in BpGraphicBufferAlloc

BZ: 86716

In WIDI usage, BufferQueue is outside of SurfaceFlinger. If BufferQueue
allocates a GraphicBuffer from SurfaceFlinger, BnGraphicBufferAlloc will
create a BufferReference to hold a last ref to the GraphicBuffer, but
when the transction finishes, the parcel used in the transaction will be
destroyed and the BufferReference will be freed which caused the last
ref of the GraphicBuffer in SurfaceFlinger side goes away and then
destroy the GraphicBuffer. This leads to the buffer state between
BufferQueue and SurfaceFlinger out of sync, because in BufferQueue side,
the GraphicBuffer was just created and will be used later.

This patch add a sp<IBinder> of BufferReference for each GraphicBuffer
when created in BpGraphicBufferAlloc, this will make the BufferReference
in BnGraphicBufferAlloc stay still when the transaction finishes, which
also leads the GraphicBuffer be held. When BufferQueue free a
GraphicBuffer, the sp<IBinder> BufferReference will be set to 0 which
will free BufferReference and then GraphicBuffer in
BnGraphicBufferAlloc/SurfaceFlinger side, and will not lead to memory
leak.

In normal use case, since the BufferQueue and SurfaceFlinger are in the
same process, there will no Bp side exist. Thus, this patch will not
affect the normal use case.

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

Change-Id: I812bbf046fd592a6dca1e4d157b459c9654835fb
Signed-off-by: Lingyun Zhu <lingyun.zhu@intel.com>