DisplayDevice: Backwards compatibility with old EGL

From 4.1 to 4.2, the display subsystem was reworked to
use SurfaceTextureClient/BufferQueue instead of
FramebufferNativeWindow for the framebuffer itself.

Unfortunately, some legacy EGL libraries make assumptions
that any framebuffer device will be FramebufferNativeWindow.

These EGL libraries will fail when used in 4.2 as if the
framebuffer is not FramebufferNativeWindow, they will
try to dequeue more than one buffer at a time, which
will cause a hang of the graphics subsystem.

This allows use of FramebufferNativeWindow to keep
legacy EGL implementations happy.  Confirmed EGL
implementations that need this include but are
not limited to:

Set BOARD_EGL_NEEDS_FNW to use

Tegra2/3 ICS EGL
Mali400 ICS EGL (Allwinner A10)
Mali400 Jellybean (4.1) EGL (Samsung Exynos4)
Adreno Jellybean (4.1) EGL (legacy qcom devices using PMEM)

Original implementation by OndraOrg of XDA:
http://forum.xda-developers.com/showpost.php?p=34469675&postcount=19

Change-Id: If7c455035a002f272fa1a8af1cfcc60eb7ade894
sf: Enable swaprect optimization by default only on QCOMs

 * This is confirmed to cause problems at least on i9500.
 * Only enable it by default on QCOMs, other devices can opt
   in using the system property.

Change-Id: Ic00137201f4a5383877f4033473c1ea5ac32a3a7
SF: Add flag for swaprect status in HAL

We need to check in HAL whether swap rect
is enable or disable to calculate wormhole region.

Change-Id: I4fbff4119856e41694e2065141b40fdd7a15f375
SurfaceFlinger: Change to support framebuffer flip for 2D blitters

- Surfaceflinger does not flip framebuffers when there are
  no layers marked for HWC_FRAMEBUFFER
- This change checks for the HWC_BLIT flag and will request a flip
  to a new FB_TARGET buffer even if there are no FRAMEBUFFER layers

Change-Id: I1cb44389a05c9ec049d7f0d39c288feccb11a91c
Display: Define new composition type for blit composition

This change defines a new flag 'hasBlitComp' to identify
blit composition. This flag is used to enable the swap rect
feature for blit composition cases.

Change-Id: Ic523e19796a893efbfc3bff300d1f982cba5ddfa
Revert "Add sessionId metadata with every buffer queued through Surface"

This reverts commit 85743373ed7d4eb6cb58412bda6c74f9ee29f06f.
This change is no longer needed

Change-Id: Ia5612b42f081236db65ac8eef9d359dfd23f4117
surfaceflinger: Conditional compilation for swaprect feature

 * Since this now calls into the HAL, we can only support it on
   devices which use the new version.

Change-Id: I231d70ac3d17fd2198f3929057c1edb0f158c099
Do not just silently fail if surface creation fails

Some apps do not check if they actually got a surface (e.g. bootanimation)
So this helps the track crashes down to the cause.

Change-Id: I6e74bdb52ad7ebe260b0ec1777c585781f6bbd42
[2/2] Speed up booting on multicore devices.

Add multithreading support.

Change-Id: I13630de9d75d13c0368d261b3564b787067b65b1
SF: Fix invalid reduction of transparent region from a layer.

Reduce transparent region from a layer only if the transparent
region has valid intersection with the layer. Otherwise, reducing
a transparent region lying completely outside of the layer leads to
invalid sourcecrop values for the layer.

Change-Id: Iee9ba53a8072c21c9ba8a6d58cb14ca30f8600ba
CRs-Fixed: 620973
sf: Determine if virtual display can use HWC for composition

For HWC virtual display using V4L2 approach:
1. HWC virtual display implementation doesn't send output buffer
   back to Surface Flinger.
2. For non-wfd virtual displays(e.g. Simulated Secondary Displays,
   Screen Record, CTS etc..), configure VDS to use GPU for
   composition on output/sink buffer.
3. For wfd virtual display (a.k.a hybrid wfd), use
   Framebuffer surface (similar to external display mechanism).

For HWC virtual display using VDS approach:
1. HWC is allocated for first virtual display connection.
2. Subsequent virtual display sessions will be composed by GLES driver.
ToDo: Modify VDS component to allocate hwcDisplayId based on
mForceHwcCopy (which is based on Usage Flags)

Change-Id: Ib7d2c00ca5fa07908b2eac8085654f8d2cd9af0b
Extend installd to support SELinux restorecon function.

Implement new restorecondata function which will allow
the relabeling of /data/data and /data/user directories.
This is needed in the case of certain OTAs. Not every
boot will apply this relabeling however. Consult change
I77bf2a0c4c34b1feef6fdf4d6c3bd92dbf32f4a1 for
clarification on this issue.

Change-Id: I05e8b438950ddb908e46c9168ea6ee601e6d674f
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
restorecon /data/media when re-creating it for multi-user upgrade.

Change-Id: I112c61863f2104d1962697c54cff25106e9b48a0
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Proper security labeling of multi-user data directories.

Add seinfo paramater to appropriate make directory
functions. This allows proper labeling for multi-user
scenarios.

Change-Id: Iaba7c40645bc7b6cc823d613da0c3782acf6ddd5
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
Convert all selinux_android_restorecon and _setfilecon calls to new API.

libselinux selinux_android_restorecon API is changing to the more
general interface with flags and dropping the older variants.

Also get rid of the old, no longer used selinux_android_setfilecon API
and rename selinux_android_setfilecon2 to it as it is the only API in use.

Change-Id: I1e71ec398ccdc24cac4ec76f1b858d0f680f4925
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
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