Alternate Default App Picker (1 of 2)

This will allow an alternate Default App Picker
much like the old GB style of a checkbox for Use Always.

ICS/JB instituted this new picker that requires the user to either select
Just Once or Always.  This style will launch the app with a single click,
but provide the 'Always' check box like in GB.
Needs ROMControl commit too.

Patch 2: fix NPE logic derp & tweak layout
Patch 3&4 - Layout tweaks

Change-Id: I63787f1ade7ffd6d44cf2df3d4d724afac3705a3
Signed-off-by: Zaphod <mwilson@acesappraisal.com>
Updated simplified Chinese translations

Change-Id: I2b22478aaa730e3a88e7caa4fb6d21b0a928743a
Add simple caching to XML compilation

XML compilation stage will perform many (expensive) resource ID
lookups - for the same entries. Adding this simple cache can
dramatically improve performance of this stage (often a bottleneck)

Change-Id: I61356b6b3f0d90b7ac549b781e3ac8dd02282559
Updated: fixed for Mac OS X (also tested on Windows, Linux)
Merge "Add simple caching to XML compilation" into jb
ril: avoid sending null aid string in getIMSI

Change-Id: Ia68671ee368a91391b54b1c840d0f752e7dc8731
Merge "Alternate Default App Picker (1 of 2)" into jb
Merge "ril: avoid sending null aid string in getIMSI" into jb
Debug RILJ wakelocks on Smdk4210Ril:

Original author's commit message:
------------------------------------
There is a battery drain due to a wakelock being held for an unspecified
length of time. BetterBatteryStats shows it to be RILJ holding the wakelock.
I've narrowed it down to a RIL request named RIL_REQUEST_SET_TTY_MODE. I
dumped out RILJ.mRequestsList during the held wakelock and I see this request
staying around and waiting for a response from the RIL. It's as if the RIL
is not responding to this request and I don't see RILReceiver processing a
response to this request.

One thing to note is that RIL_REQUEST_SET_TTY_MODE is generated when we see
EVENT_TTY_PREFERRED_MODE_CHANGED from PhoneApp. This happens when the phone
boots up and also when you plug in a pair of headphones. Thus this wakelock
can be reproduced by plugging in a pair of headphones.

To work around this, I've added logic to perform a lazy removal of RILRequests
that haven't received a response in the existing wake lock timeout
(60 seconds.)  The removal itself is done as part of
findAndRemoveRequestFromList().  Since new RIL requests are appended to this
list, we're guaranteed that the stale TTY requests will eventually be removed
either when the existing timeout fires, or through this new lazy removal
------------------------------------
Additional comments from Andrew Dodd:

There seem to be all sorts of things that can cause similar behavior.

Rather than purge requests known to have issues, we just print them
so we can fix root cause.

Change-Id: I0a80ba8fb5a1811ab1d8f78e3b8d1bcbfc627377
Merge "Updated simplified Chinese translations" into jb
Menu UI Overflow Toggle (2/2)

Adds the ability to show the Menu UI Overflow (3-dots) within apps, regardless of navbar being present or not

Signed-off-by: BMc08GT <bmc08gt.teamb00sted@gmail.com>
Smdk4210RIL: block unsupported requests to avoid RIL wakelocks

Change-Id: I54fa04be9389b6a2a5843ffcd074c64d24dfc03a
ime switcher notification: remove reboot requirement (1/2)

patch set 2: fix uri, remove old comment, add handler

Change-Id: Ie21fed15c2cc865ae2d164fa485cc44d69ef5452

Conflicts:

	services/java/com/android/server/InputMethodManagerService.java
Merge "Menu UI Overflow Toggle (2/2)" into jb
Merge "ime switcher notification: remove reboot requirement (1/2)" into jb
Merge branch 'jb' of https://github.com/AOKP/frameworks_base into aokp_jb