Update to 4.4.3 r1.1

Change-Id: Ifa732ec52fb582c34512cd1d09d918199ae9994e
Add OMX_AUDIO_CodingAPE and OMX_AUDIO_CodingDTS

Copied from the stagefright-plugins project.

add HEVC decoder and cleanup

Change-Id: I16342228014320161a22302a3c14df7725556cd2
Add setOrientation back

	this is needed for some tegra ICS and JB_MR0 prebuilts

Change-Id: I7b534555253ede3d0061abd09e22330d5eaf3cd9
binder: add another compat symbol

- Extend https://gerrit.omnirom.org/#/c/2324/
- Some old blobs, mainly LGE libs need this

Change-Id: Ia0370fecff24348aefa17aa7de2609535323e9b0
sensorservice: Fix init sequence for pre-1.1 API sensor HALs

The sensors API introduced a new flush() method that older binaries
won't have. For those, replace the firstFlush invocation with a
setDelay call since a lot of implementations interpreted that as
the initialization step.
We also don't want any kind of call to flush() to happen when it
isn't there, since it'll either hit a random OEM extension or
a memory address we really don't want to execute.

Change-Id: I26ce923fe385751fed7d1c483a53c074249f0620
Graphics:Add error check when create GraphicBuffer

Change-Id: Ib0ca59bf1dfe4ae0266c29c91c1dbe3d02c0904e
Author: Lingyun Zhu <lingyun.zhu@intel.com>
Signed-off-by: Lingyun Zhu <lingyun.zhu@intel.com>
Signed-off-by: Shuo Gao <shuo.gao@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Author-tracking-BZ: 50141
surfaceflinger: Consolidate display orientation compensation hooks

Dedupe rotation calculation code and make rotation a statically
available property in the DisplayDevice

Conflicts:
	services/surfaceflinger/DisplayDevice.cpp

Change-Id: Ic517ab0d2c05026cd6fa46d664aab7926be17b62
Configure dalvik heap parameters for low memory devices

Reduces after boot memory footprint by about 5-8MB
Note: This is for low memory based devices only (~512MB RAM
or less)

Change-Id: Iac45854aff687189e56f97da96e05d38adf842bf
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
Fix merge error

Change-Id: I619718509fc1ec72ce90cbf823ed274bfb1c65ed
Revert "Fix merge error"

This reverts commit 830e9cf5b562d076375d38f8d548f40afb20ef65.

Change-Id: I7e4bf89ba839fccb82d573eda0224314faffa072
Revert "Runtime resource overlay, iteration 2"

This reverts commit 53945e839c22345e315a3999987712dbaf56b1da.

Change-Id: Idacc35d3ab5e3942ee14f75a153e96adf2b357a1
Revert "New command line tool 'idmap'"

This reverts commit f3bda101d6bb5c7217d94d429601a1f2691ffc26.

Change-Id: I653a69e2560afcb36a26f5520e574efe97e52fa0
Merge "Revert "Runtime resource overlay, iteration 2"" into du44
Merge "Revert "New command line tool 'idmap'"" into du44
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: I4bdd72221a083dcc74e28b8e7d679b192a39ab98
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: Ia55e8af4acea5380ccaf727d62c60ef9cd6aac14
Theme Engine [5/7]

commit d3cd5e42d962801195bc96e3f538f24045ac009d
Author: Andy Mast <andy@cyngn.com>
Date:   Wed May 21 21:56:41 2014 -0700

    Avoid calling idmap w/ trailing whitespace [2/2]

    installd performs a buffer over-read if trailing ws is sent to it.
    No observable effect found yet for idmap, but until installd is
    fixed upstream, best to play it safe.

    Change-Id: I6789700ed34f38cf2abdf070f2f5f8e86cc4287f

commit 35fc7c2fda000f4705a40ee29976c3065cc14e77
Author: Andy Mast <andy@cyngn.com>
Date:   Wed Dec 11 13:41:23 2013 -0800

    Theme Engine [5/7]

    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: I812f2493a9fdddc066aed3f632d0ec99eebfae0a

Change-Id: I643541383713c7ded5883619370b11180efeb1ea
Merge "Configure dalvik heap parameters for low memory devices" into du44