Frameworks: add a bunch of national roaming providers

Change-Id: I506bb2d50f8c0493e9f33ed45984627e60132399
Volumes in Settings/Sound is slow to start

There is a delay after pressing volume menu item
there is a delay until the Volume popup is shown.

The reason for this is that the initialization of
the different seekbars is slow and run in the main
thread. More specifically the call to get the
ringtone from the RingtoneManager is causing this
delay.

Moving the call to the ringtone manager to the
handler thread used to play ringtones to make
the launch of the volume dialog a bit snappier.

Change-Id: I76da0226592468debd542d67164b37b2b59897c7
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
Don't confuse stat and stat64.

Bug: 11865851
Change-Id: I45e65036d86c58943b9c273777f3f8be79a6966f
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
Prevent Lockscreen album art from activating FLAG_KEEP_SCREEN_ON

This is a small fix to the showWallpaper method, in which a power
consumption problem has been introduced. This showWallpaper method
toggles the window flag FLAG_SHOW_WALLPAPER, when album art is being
shown in Lockscreen. It is important to set pixel format to
PixelFormat.OPAQUE if flag FLAG_SHOW_WALLPAPER is not being set.

If not, an application that uses window flag FLAG_KEEP_SCREEN_ON
will prevent the keyguard from going to sleep and drain battery.

Change-Id: I1808be28047977ae5ac4dd1168ea25cac8a55a78
Solve three memory leaks related to PatchCache

A Patch can be fairly large, holding bitmap data, but
is also frequently leaked which adds to the severity.
The feature is used in many important processes such
as Home, SystemUI and Chrome.

The following leaks are solved:

1. The Patch itself was not always freed.
PatchCache::removeDeferred() can mark patches to be
cared for by PatchCache::clearGarbage(). But
mCache.remove() would only destroy the container
and the pointer, not the Patch object itself.

2. The vertices stored in the Patch at Patch::createMesh()
would always leak. The empty/default destructor in Patch
would not properly destroy "vertices" since it's just a
pointer.

3. A BufferBlock that's added to the mFreeBlocks
in PatchCache could leak. The leak happened when a
patch later needed the entire free block, because the
object was removed from the list but never deleted
in PatchCache::setupMesh().

Change-Id: I41e60824479230b67426fc546d3dbff294c8891f
Do not show Home behind full screen activity

When ensureActivitiesVisibleLocked goes through foreground activity
stack and reaches non-fullscreen activity, it sets showHomeBehindStack
variable to true.

If there is a fullscreen activity behind, showHomeBehindStack remains
unchanged, which causes Home application to be displayed anyway.
In this case user will see a fullscreen activity and Home activity
simultaneously.

To fix the issue we set showHomeBehindStack to false when we reach
fullscreen activity in the activity stack.

This was made visible by the following commit:
446ef1de8d373c1b017df8d19ebf9a47811fb402

Change-Id: I535c1283a4e26f5cf606375b837d4b7195324af0
Reduce warning verbosity in aapt

- Attributed source of problems to the correct file.
- Only verify string localizations against valid
  locales.
Bug:13140015
Change-Id: I9dabc5efa0510649caee8af0c8ebb803d6f48269
GlobalActions: Fix Airplane Mode on/off issue

Issue: Unable to turn off Airplane mode from power button
       after phone reboot

Fix: Initialize mHasTelephony before the PhoneStateListener is
     registered to the TelephonyManager so that correct value
     of mHasTelephony is reflected when onServiceStateChanged
     callback is called.

Bug: 13697360
Change-Id: Ide8afd9c16ea90b98b5912dbff440c5fd67b178d
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
Base: Mirroring layout on RTL languages [1/2]

When Force RTL layout (in developer options) is sellected on RTL language (Arabic, Hebrew, etc) - mirror back to LTR.
There is another commit (same name but with [2/2]) which just changes the strings to match the new meaning for RTL languages.

Change-Id: Ib051b976db4e15dab9caddcd0d49276b5ada3f13
Make SurfaceView layers captured by screenshotApplications()

Since SurfaceView layers are located below application layers,
SurfaceView is not captured by screenshotApplications()
when the application is running in fullscreen.

Moreover, ws.isFullscreen(dw, dh) returns mostly true
on the devices which do not use the navigation bar.

Change-Id: Ia1036c79054950384a97504714929fd85c8147de
Signed-off-by: Sangkyu Lee <sk82.lee@lge.com>
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
frameworks/base: Fix the random UI corruption

On low memory device, when a view goes to background. Its HW layer cache
will be destroyed to release memory. There is a very rare case that the
hardware render is not valid when destroy the layer, so the layer is not
destroyed and reused when the view comes to foreground. But the GL
context has changed, so the view is not rendered correctly due to its
HW layer cache. To fix this issue, destroy the layer in a safelyRun. Make
sure the layer is destroyed correctly.

Change-Id: I1c714e1d53db7353d5169e874a7cd0f527c3f67b
CRs-Fixed: 623239
SystemUI: Chamber string edit

Let the user know that the setting simply may not
	exist in the settings database yet on failure
	to parse the key.

PS2: Use only for settings database mismatch (not
	values toggled)
PS2: Dependency

Change-Id: Idec8ea425ea46ff0ebfda37451c521b08d2d4979
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