SlimRecents: Adress the 50ms touch unsresponsive issue

User reported that if the screen is fully animated in that the touch
detection is not working for about the first 50ms. For user who are working
fast this is indeed an issue. Especially due that the recent screen speeds
up the workflow much already.

Problem is our third loading stage due that after the recent screen animates in
it calls getView on all elements which rebuilds the touch listeners and cause to
the slight timeframe where it is unresponsive.

Well the third loading stage was a left over from the first optimizations when
we started to develop this feature. Other optimizations are into place now so we
do not really need the third loading stage at all. So instead of handling now
the fix in the getView implementation of the arrayadapter we simply just remove the
third loading stage completely.

PS:
- small other optimization

Change-Id: Ibf46fbe393de4f9d6b867e6bdb9c331dff1dd38e
Base: Check ProcessesReady before broadcast

Most of the time testIsSystemReady is used to know if we are allowed to broadcast intents.
But in broadcast intent method we check mProcessesReady flag (not mSystemReady).
If we broadcast after systemReady flag but before ProcessesReady flag, system will crash

Adding condition to check if system & processes are ready fix that race condition
Signed-off-by: Fabien DUVOUX <fabien.duvoux@gmail.com>

Change-Id: I2eec1c4f280daf29f4741919a7636b02da341e32
Insufficient ProcessRecord cleanup when persistent process is killed

When persistent process with Service restarts, ActivityManagerService
does not reset ProcessRecord#hasClientActivites to false
(because ProcessRecord of persistent process is continued using
after killing).

It disturbs updating LRU list in ActivityManagerService, and then,
when new process calls ActivityManagerProxy#publishContentProviders,
SecurityException happens because of no entry in the list.

Bug: 13517358

Change-Id: I46b064f71a4f7025ade1bf117801352a7ab22e6a
AudioService: Fix absolute volume for AVRCP

Avrcp.java uses max volume obtained by getStreamMaxVolume() when
converting to AVRCP levels and it returns non-scaled volume index.
For this reason volume index needs to be dispatched to Avrcp before
scaling as otherwise Avrcp will convert volume level incorrectly,
i.e. max volume index for music stream is 15 and any volume index
>1 (>10 after scaling) will result in setting *MAXIMUM* volume level
on headset which is not safe for listener.

Change-Id: Ia799eec578ed2326ec18b69f2ee4f2a60c664514
Audio: Fixed system/call stream volume can't adjust with HS connected.

Issue Description:
When headset connected, the system/voice call stream volume can't be
adjusted from Volume bar.

Root Cause:
Currently adjustStreamVolume is applied to stream type alias and the
device for the stream alias. So when headset connected and adjust
volume for SYSTEM_STREAM, the operation will be applied to RING_STREAM
(which is aliased by SYSTEM_STREAM) and speaker. As headset is returned
from getDeviceForStream(SYSTEM_STREAM), but speaker for RING_STREAM.

Solution:
Change the adjustStreamVolume to apply volume to the stream alias and
the device for the stream type exactly.

Change-Id: Icd226d9eb197017cd3c186a0096edaed755680ec
Signed-off-by: Guo Xie <gxie@marvell.com>
Lockscreen: Add chinese string for airplane mode

There is no chinese string resource for lockscreen_airplane_mode_on.

Define the chinese string for airplane mode.

CRs-Fixed: 561393

Change-Id: I59d2fd42f8b3140a934614a4977dc7ade0332c6d
base: Fix screen on stats after a boot

Prior to this change, the following sequence:

  * Turn the display off
  * Issue a reboot via adb
  * Unlock the device (after rebooting) before the screen turns off

results in the screen being on but the battery stats not reflecting
this fact.

In general, the mismatch occurs when either there is no serialized
battery stats state or when it is serialized in a state where the
screen is off.

Change-Id: I17374553fae6a08a1be8fdf445967509474177a9
Fix problem where PhoneWindowManager waits for keyguard to draw

This fixes a problem where PhoneWindowManager times out waiting
for keyguard to draw when it's disabled.  Instead, we pass a null
token back which allows PhoneWindowManager to continue.

Fixes bug 11190932

Change-Id: I041ea1d88dca681476d9477a3aab54559976b312