base/TR: Allow Mock SMS

Change-Id: I292a8dc45938b7600001251d7c14d67ad90afc27
Status bar brightness control on lock screens

The status bar brightness control does not work on lock screens,
altough it would be useful when you try to type your password
or pin code – e.g. in bright conditions.

Patch Set 3:
- Remove the unnecessary "else" in "if" statement
- Use mViewDelta in brightnessControl method as is in the original code

Change-Id: Idf086f35d9952a892c932780be2192a26a4b38fa
frameworks_base:
Minor fixes and some new translations

Change-Id: I4ef01c88d0226813fee4d6bede0d16b339ede4da
Update Russian Translation-Mock SMS-CM10

Added Russian Translation-Fix typo-CM10
PackageManager: Restrict system packages to protected storage

Don't allow packages signed with the platform key to be
installed into user (or app) controlled storage

(cherry-picked from 64fa8092090d067d78163b8ebce45baa1123ce9d
 with changed file path)

Patch set 2: Fix compile error due to changed function name

Change-Id: I7390b3bdf5289411f7a335c69635bed9f74bbfb3
Merge "frameworks_base: Minor fixes and some new translations" into jellybean
Merge "base/TR: Allow Mock SMS" into jellybean
ril: avoid sending null aid string in getIMSI

A change to how getIMSI works in JB causes null aid strings
to be sent.  The result for RILs older than v7 is a corrupt
ril response in SIMRecords::fetchSimRecords.  This corruption
ends up setting mImsi to null (in SIMRecords) and that causes
havoc w/ 3g/4g data connections.

This patch avoids sending null aid strings and has fixed
data connection issues on several Motorola devices.

This new patch is implemented as an opt-in old ril feature

Change-Id: I6682ea10c8b216e2adc5abffbcc50f3cb6c9d7b8
Merge "Status bar brightness control on lock screens" into jellybean
Merge "Update Russian Translation-Mock SMS-CM10" into jellybean
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 branch 'jellybean' of git://github.com/CyanogenMod/android_frameworks_base into jb-mv