Squashed commit of the theme engine support.

Updated 4.2 support for the old T-Mobile theme engine, as usual
needs the provider and switcher apps installed as well.

I'm finally dropping the 400+ commit history on this, since everybody
else keeps picking it up from CM as a single patch anyway... But
for the record, nothing of this would be possible without Josh, Ed,
and the rest of the TMo guys who wrote and maintained it until 2.2:

amit chabra <amit.chabra@t-mobile.com>
Amit Kohli <amit.kohli@t-mobile.com>
Chris Cogar <chriscogar@t-mobile.com>
Dirk Sigurdson <dirk.sigurdson@t-mobile.com>
Ed Carrigan <edward.carrigan@t-mobile.com>
Gaurav Sharma <gaurav.sharma3@t-mobile.com>
Hui Feng <hui.feng@t-mobile.com>
John Ritz <john.ritz1@t-mobile.com>
Josh Guilfoyle <josh.guilfoyle@t-mobile.com>
Mark Roberts <mark.roberts48@t-mobile.com>
Pankaj Kumar <Pankaj.kumar6@t-mobile.com>
Samuel Cheung <samuel.cheung@t-mobile.com>
Sergey Ten <sergey.ten6@t-mobile.com>

Change-Id: I7148d51be48f28a2dc4bdf9ec9018f04b268ffc4

Framework: Remove orphaned Theme related code

Change-Id: I930d4cc75e655c5bc37532e6a1425d27bd1ee661

Check themes of current user, not user 0.

Change-Id: I5d685a04289b434a12e460b4fdacc43a41ff2be1
JIRA:CYAN-1303

Fix theme provider crashing for non-primary user.

PackageManagerService's context is for user 0, so if the theme provider
for other users was invoking the getInstalledThemePackages() method, the
themes provider crashed as it doesn't have the INTERACT_ACROSS_USERS
permission.
Fix that (and simplify code) by making getInstalledThemePackages()
return the installed themes for the current user, which was probably the
intent anyway.

Change-Id: I02002cee005b74128f3b2f7cc7a93b9b8514f1f3

ThemeUtils: Retain the original package name in themed UI context

In order for themes to reflect on system elements, we're changing
their context, including the package name.

This breaks anything that tries to identify system elements,
most notably any users of the uiautomator. Trying to do
'UiSelector().packageName("android")' to find, for example,
a force-close dialog will fail.

Fixes com.android.cts.uiautomatortest.CtsUiAutomatorTest#testUiWatcher

Change-Id: Ic05c3024b20ac3772ed5597846fbfa4a184ebb0d

platform: Fix the gid for the theme manager service

It was mismatched with fs_config, resulting in attribution of the
"-1" gid

Change-Id: Ia6d55af0b39f659da2965f9bc0bda0df5c775ba4

PackageManager: Let com.tmobile.thememanager access privileged permissions

Needed for CHANGE_CONFIGURATION

Change-Id: If50b0926d77e15e18ef5e88d7efac1b7f209d6e4

ResourcesManager: Fix theme insertion at boot

This was lost during the 4.4 ActivityThread reshuffle, put it back

Change-Id: I96eadf691973e9a2daa099b55816fc103d129be7

SystemUI: Reinflate on theme change

Reflect the updated assets immediately once the config_changed
notification happens

Change-Id: I480a719fbdd45875277871af39ce65849918ec0a

Fix various broken bits from the rebase

Change-Id: Ib7737d6aebde195b2b01892d95d6ec0e7f91f731

PackageManager: Prevent themes from going into ASEC containers

Themes on ASEC cause all kinds of random timing/racey issues at boot
time, and more kinds of racey concurrency issues at uninstall/upgrade
time. Stop them from getting into containers at all.

Change-Id: Ib7737d6aebde195b2b01892d95d6ec0e7f91f731

AssetRedirectionManager: Accept redirections only for whitelisted resource types

Change-Id: Idf1ea739a81719b6a196f0114c9fc3b7c7ff428c

AssetAtlas: Fix NPE when there are no preloaded resources

Change-Id: Idf1ea739a81719b6a196f0114c9fc3b7c7ff428c

Conflicts:

	core/jni/AndroidRuntime.cpp
	packages/SystemUI/src/com/android/systemui/statusbar/BaseStatusBar.java
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
	policy/src/com/android/internal/policy/impl/PhoneWindowManager.java
	services/java/com/android/server/SystemServer.java
	services/java/com/android/server/am/ActivityManagerService.java
	services/java/com/android/server/wm/WindowManagerService.java

Conflicts:
	core/jni/AndroidRuntime.cpp
	packages/SystemUI/src/com/android/systemui/statusbar/BaseStatusBar.java
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
	policy/src/com/android/internal/policy/impl/PhoneWindowManager.java
	services/java/com/android/server/SystemServer.java
	services/java/com/android/server/wm/WindowManagerService.java

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
	policy/src/com/android/internal/policy/impl/PhoneWindowManager.java
	services/java/com/android/server/NotificationManagerService.java
Fix to NullPointerException on move back in ActivityStack.

In ActivityTask.moveTaskToBackLocked NullPointerException may occur
when moving back with only current Activity in stack. This due to a
condition that may trigger despite a TaskRecord being null and then
attempt accessing the TaskRecord.mOnTopOfHome variable.

TaskRecord task may be set to null when no resumed activity remain.

Resolved by assuring that flag mOnTopOfHome is instead set to false
for current TaskRecord in case where there are no remaining activities
above home.

The above bug has already been corrected in the following commit,
ada62fca51d314cefe2c5da4e007df5b9abf320d, but it does not set the
cottect value to mTopOfHome for the current taks, see below.

Variable mOnTopOfHome will not be set to false in situations where
stack is of size 1 or less and task is null, perhaps from already
having finished current activity.

To avoid current TaskRecord maintaining value mOnTopOfHome to true
after launching Home this variable is set to false.

Impact should not be major due to correction earlier that makes sure
that there is always a TaskRecord.mOnTopOfHome set to true above Home
activity but if not correctly set for current task still gives a
possibility of bad behavior.

Change-Id: Ie86ad99c188aaa05b0de9d58eaa16c42b6fc4341
Remove T-mobile items not used by new theme engine

Change-Id: I1e9c14e63ec25fdff61cfd2b7b8a05b1e488e558

Conflicts:
	core/jni/AndroidRuntime.cpp
	policy/src/com/android/internal/policy/impl/PhoneWindowManager.java
	services/java/com/android/server/AssetRedirectionManagerService.java

Conflicts:
	core/jni/AndroidRuntime.cpp

Conflicts:
	services/java/com/android/server/pm/PackageManagerService.java

Conflicts:
	core/jni/AndroidRuntime.cpp

Conflicts:
	policy/src/com/android/internal/policy/impl/PhoneWindowManager.java
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

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java

Conflicts:
	services/java/com/android/server/pm/PackageManagerService.java

Conflicts:
	core/java/android/app/ContextImpl.java
	services/java/com/android/server/pm/PackageManagerService.java
Runtime resource overlay, iteration 2, test cases

Add automated test cases for runtime resource overlay, iteration 2.

The test cases are a mixture of 'adb shell' commands and regular
instrumentation tests. The device is rebooted between tests to setup
different overlay scenarios for framework-res.apk.

To verify Runtime resoure overlay, iteration 2, run
    $ frameworks/base/core/tests/overlaytests/testrunner.py

For a list of supported options, run
    $ frameworks/base/core/tests/overlaytests/testrunner.py --help

Change-Id: I692aa1a7ad073efd116b24f9ec7f197dfd65dfef
Fix a variety of small publicly-reported bugs.

Possible NULL dereference in cmds/bootanimation/BootAnimation.cpp.
https://code.google.com/p/android/issues/detail?id=61556

Missing fclose in core/jni/android_os_Debug.cpp.
https://code.google.com/p/android/issues/detail?id=61546

Bad loop guards in core/jni/android_util_Process.cpp.
https://code.google.com/p/android/issues/detail?id=61557

Assignment to wrong variable in libs/androidfw/AssetManager.cpp.
https://code.google.com/p/android/issues/detail?id=61560

Missing delete[]s in libs/androidfw/ObbFile.cpp.
https://code.google.com/p/android/issues/detail?id=61549

Leaks on error in tools/aapt/Images.cpp.
https://code.google.com/p/android/issues/detail?id=61552

Two missing fclose calls in tools/aapt/Resource.cpp.
https://code.google.com/p/android/issues/detail?id=61553

Missing fclose in tools/aidl/aidl.cpp.
https://code.google.com/p/android/issues/detail?id=61554

Change-Id: I5820f3824e72d07a9acb776cf0af3e7443f5694a
Freeing frame map

FileMap memory is never released until application exit

Release it now as the texture is already loaded and the memory
used for the packed resource can be released.

Change-Id: Id08a1e466337b3a0179684eb6a444e18147ee343
New Theme Engine [1/6]

[Summary]
Took the T-mobile theme engine, replaced redirection mechanism with a modified Sony idmap and then extended the feature set.

The new theme engine allows the following:
1. Simple creation of themes by compiling on the device
2. System level icon packs.
3. Font packs
4. Swappable boot animations
5. Lockscreen wallpaper
6. Alarms
7  Of course all the things the previous engine could do including skins, ringtones and
notifications. There is also legacy support for old themes.

[Theme Format]
For the time being themes are APKs with all theme elements in the assets folder. Since these resources
are compiled at runtime there is no reason we can't change it to a zip but creating an APK is well
understood by themers.

The directory structure looks like this:

AndroidManifest.xml
src/
res/
assets/
  boot-animation/
  fonts/
  icons/
    res/ (note: same dir structure as res/ in trebuchet icon packs)
  wallpapers/
  ringtones/
  notifications/
  alarms/
  overlays/
      [target-pkg-name1]
          res/
           drawable/
           drawable-hdpi/
           ...
           layouts/
           xml/
      [target-pkg-name2]
          res/

Where [target-pkg-name] is the package of the app you are trying to overlay. For example, to overlay
facebook's app you would make a directory under overlay called "com.facebook.katana". For frameworks
resources use the target name "android".

Under each target pkg is a res/ folder which follows the same format as a typical APK's res/. During
install time AAPT will actually compiling these res/ folders individually.

There are also non-overlay folders like boot-animation, wallpaper, fonts etc.

A theme APK is identified by meta-value data in AndroidManifest.xml. Here is an example:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.me.andytheme2"
    android:versionCode="1"
    android:versionName="1.0" >
    <uses-feature android:name="org.cyanogenmod.theme" />
    <meta-data android:name="org.cyanogenmod.theme.name" android:value="My Blue Theme"/>
    <meta-data android:name="org.cyanogenmod.theme.author" android:value="John Doe" />
</manifest>

By using meta-data we do not require special new tools.

[Changes to PackageManagerService]
During install time PackageManagerService will scan meta-data values in the manifest. If it finds
a meta-data name of "org.cyanogenmod.theme.name" then it will assume the APK is a theme and mark it as such.

Then PM will find all overlays from the theme. For each overlay target it will generate a resource table
and an idmap via Installd. Aapt will also run to compile 9patch and xml files. The new restable, idmap, and compiled resources
are stored under /data/resource-cache

[Changes to aapt]
Aapt has been extended to read zip entries and accept file descriptors to work with installd.

[Changes to frameworks/core]
Most of what TMO has done already here for runtime theme changes is kept so most changes
are simply plumbing to make Sony's overlays work at runtime. Additionally changes were made
to TMO classes to support mix n match better.

[Changes to libandroidfw]
Sony's idmap concept is one overlay apk -> one target apk, but themes support multiple target apks. So
most of the changes here are for support this. Also we support runtime overlay changes so functionality
had to be added to add/remove to the resource table during a configuration change.

[Security]
We run aapt in reduced priveledges via Installd. At the moment however a theme can overlay any resource. This
includes strings and layouts so any malicous theme could cause serious crashes to the device.

[See Also]
frameworks/native
external/skia
build
vendor/tmobile/providers/ThemeManager
vendor/tmobile/libs/com.tmobile.themes

[Contributors]
Andrew Mast <andy@cyngn.com>
Clark Scheff <clark@cyngn.com>
Special thanks to the T-Mobile theme team. This would not be possible without their efforts.
Special thanks to Mårten Kongstad and the rest of the Sony team for their work in idmap.

Change-Id: I812a3757bdb56c429b5870ff922485439ae00f8d

Conflicts:
	core/java/android/app/ContextImpl.java
	core/java/android/content/Context.java
	packages/SystemUI/src/com/android/systemui/statusbar/phone/NavigationBarView.java
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
	packages/SystemUI/src/com/android/systemui/statusbar/policy/KeyButtonView.java
	policy/src/com/android/internal/policy/impl/GlobalActions.java
	services/java/com/android/server/SystemServer.java
	services/java/com/android/server/am/ActivityManagerService.java

Conflicts:
	core/res/AndroidManifest.xml

Conflicts:
	core/java/android/app/ContextImpl.java
	core/java/android/content/Context.java
	core/res/AndroidManifest.xml
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
	packages/SystemUI/src/com/android/systemui/statusbar/policy/KeyButtonView.java
	policy/src/com/android/internal/policy/impl/GlobalActions.java
	services/java/com/android/server/InputMethodManagerService.java
	services/java/com/android/server/SystemServer.java
	services/java/com/android/server/pm/PackageManagerService.java

Conflicts:
	core/java/android/app/ContextImpl.java
	core/java/com/android/internal/os/ZygoteConnection.java

Conflicts:
	core/java/android/app/ContextImpl.java
	core/java/android/content/Context.java
	core/jni/AndroidRuntime.cpp
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
	packages/SystemUI/src/com/android/systemui/statusbar/policy/KeyButtonView.java
	services/java/com/android/server/InputMethodManagerService.java

Conflicts:
	policy/src/com/android/internal/policy/impl/GlobalActions.java
Style previews [1/3]

Change-Id: Ifed0ef7829eb61492a39395e8140b99f01c5e6a3
Keyguard: smooth background change.

Change-Id: Ia0e4d0000db72b5cdb6fede03791805e34fa311d
Frameworks: Lockscreen custom wallpaper (1/2)

kitkat now has code for a custom wallpaper image.

Using that code set a switch case to set the custom background between
  - Custom Wallpaper
  - Default background

This way allows the same overlay shadow thats set on the keyguard when
its the defualt way.

Change-Id: I98fde63ef9f3c0a5f334cd9a97b237a6f99c57f6
Lockscreen: Fix SystemUI crash on initial selection of Custom Background.

Change-Id: I8df4984f4b90d211baa888d380a95fc00a85d1ad
framework: Allow specifying max wallpaper width

For some devices with very high-res screen (1920x1200), the wallpaper
width suggested by the launcher may be too large for the GPU and so
we need to limit it. (2048 for the above mentioned screen)

We don't need to limit the height since that's the height of the
screen.

Change-Id: I5b25bd931db0b2610e260921f28b92d8b0966aa6

Conflicts:
	core/res/res/values/config.xml
	core/res/res/values/symbols.xml

Conflicts:
	core/res/res/values/symbols.xml
Don't recreate keyguard for MCC/MNC changes.

https://github.com/CyanogenMod/android_frameworks_base/commit/8f3abc06fc9d62734f40a2eb1cf69fe5f137ed0b

Fix

...
Keyguard: more consistency with the new lockscreen wallpaper

* In the case when the screen was off and setCustomDrawable()
was being called, and the use wallpaper is null, then we could be
setting the color filter on a null drawable.

* Fix logic when old custom background was null and the new one is also
null (but could be the user one) and the func was being returned, thus not
clearing out the current media album art.

* Move resetting the shouldShowWallpaper() flag to the show() method
so it is not being called every time the screen is turned on.

* Fix user image not showing up on first boot if it exists

Change-Id: I567c2ec8920df627835defb822c2ea25be7b3cab
Signed-off-by: Roman Birg <roman@cyngn.com>
Keyguard : Fix album art sticking after playback is stopped

newIsNull should be populated by what is currently being set and not by
what the user's custom background is, since otherwise you end up a in state
where the user has no custom background set, music stops, no album art via arg is provided and you simply return.

Change-Id: Ifaea1cae176faaba6b32a711071f3b75ccacdd63
WallpaperCropper: Fix crash when set .gif as wallpaper

It returns an equivalent scaled cropBounds as true
crop bounds, then it set the rounded rect by rounding
"out" the true crop rect, this make the rounded crop
rect may out range of the original bitmap, then an error
will happen.

We change to check the rounded crop rect, if it is out
the range of original bitmap, we set the original bitmap
bounds as rounded crop bounds.

CRs-Fixed: 622582

Change-Id: I215ef2a0165adaaadb05c62dee741a8ea6926144
Keyguard: fix NPE setting lockscreen wallpaper

After boot the view might not be laid out and so getWidth() and
getHeight() return 0 and will cause a NullPointerException in
createBitmap().

Change-Id: Ibacf4199a69709dc34d21695732c2a5360533a23
Signed-off-by: Dirk Rettschlag <dirk.rettschlag@gmail.com>
SystemUI: Allow theming battery via theme chooser

Change-Id: Iebea2dab0ed89baa14c0f18a4c8f487cdb8313a6

Conflicts:
	packages/SystemUI/res/values/colors.xml

Conflicts:
	packages/SystemUI/res/values/colors.xml