PT-BR: Translations for SMS Mock

Change-Id: I66066c68b530667851e8aeae08b4510953371383
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
am: Allow more hidden apps on devices with lots of RAM

 * If more than 1.5GB is present, allow up to 40 hidden apps.
 * Number is somewhat arbitrary, but was found to work well on D2.
 * Also look at the sys.mem.max_hidden_apps value if given.

Change-Id: I2d3cf6e0dad1bc0b482cc37bf9c61ed2f2b4be51
Frameworks/base: Updated italian translation

	Added strings for mock SMS messages

Change-Id: I5842dd5c3f24604ca02e713d1c6541f0edf5ec2c
frameworks/base: updated romanian translation

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

Change-Id: I4ef01c88d0226813fee4d6bede0d16b339ede4da
telephony: reconcile Sony RIL with QualcommShared

Change-Id: Iec8013ebce671ab126efd3228de2c9b76583ccc6
Fix automatic brightness

Broken in Iddcbee98f6588bba428c4059e786d946d7ce2298

- Brightness is now handled in handleLightSensorValue instead of
  onSensorChanged, but the previous patch copied the old handling
  code into onSensorChanged in addition to calling handleLightSensorValue.
  This patch integrates the brightness filter change from
  onSensorChanged into handleLightSensorValue.
- onSensorChanged called mHandler.removeCallbacks(mAutoBrightnessTask)
  every time a value is received from the sensor ensuring that the
  task never get ran! (We schedule it 2 seconds into the future
  but receives a value from the sensor every second.)
  This patch removes the call.

(Note: similar to http://review.cyanogenmod.com/11341)

Change-Id: Id3e4f0f02f91f27c7c12cb2e274e0c13213d4774
Merge "frameworks/base: updated romanian translation" into jellybean
Merge "Frameworks/base: Updated italian translation" into jellybean
Merge "PT-BR: Translations for SMS Mock" into jellybean
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