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
Frameworks: add a bunch of national roaming providers

Change-Id: I506bb2d50f8c0493e9f33ed45984627e60132399

Conflicts:
	core/res/res/values-mcc214-mnc05/config.xml
	core/res/res/values-mcc214-mnc19/config.xml
[ActivityManager] Ensure consistency behavior when a background activity brings another existed activity to front.

Symptom: ANR occurs on previous activity.
Root Cause:
In KK, when a background activity starts another existed background activity (bring to front),
if current focused stack is not the same as the stack of target starting activity,
it will still resume the top of target stack, even the top activity on the target stack may not the same as target activity.
And it will result incorrect focus, press back key will send to previous stack's top then popup ANR on previous activity:
"Reason: Waiting because no window has focus but there is a focused application".

By original code comment, it looks 'bring to front' should not happen in this issue case.
// If the target task is not in the front, then we need
// to bring it to the front...  except...  well, with
// SINGLE_TASK_LAUNCH it's not entirely clear.  We'd like
// to have the same behavior as if a new instance was
// being started, which means not bringing it to the front
// if the caller is not itself in the front.

If the caller and target are in the same stask, it will just deliver new intent without changing task order (the same behavior as JellyBean).
So the patch concept is just to avoid to use target stack to resume top when caller and target are in different stack.

Solution: Do not allow to resume another stack top if non-top activity try to bring existed activity to front.
It may not be a good solution, just a reminder for the issue case.

Reproduce steps:
Assume A, B, C are different app tasks.
When the application stack is like:
  Top C
      B
      A

 #Case 1: Home is foreground
  A starts B with NEW_TASK, C will resume, focus still stays at Home, and window order does not update.
  Then press back key or volumn key will result ANR on Home.

 #Case 2: App is foreground (Resumed activity is C)
  A starts Home, Home will resume, focus still stays at C, and window order does did not update.
  Then press back key or volumn key will result ANR on C.

Change-Id: If05070123b248e2335791e43a4d4ddee6db11d84
bless python versions newer than 2.6

Change-Id: Ic4bfb857586f1fd4aa9cfddf5984341a89b0cd4a
Signed-off-by: Li Li <lli5@nvidia.com>
Reviewed-on: http://git-master/r/347711
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Peter Zu <pzu@nvidia.com>
Fix keyboard layout notification missing issue

The device changed event was sent before input manager service
gets ready during boot-up, input manager handler has no chance
to deliver notification due to mNotificationManager=null

Change-Id: I5096b86b7b5879cd346b22411064f15d62bf73bb
Add null pointer check for ExifParser

Change-Id: I9a7eee8ebb571a186a57e5094e376e7a7d8ab4b8
ImagerReader: Return the buffer to queue if it fails to lock

Return the buffer to the queue when failing to lock it with the
error ACQUIRE_NO_BUFFERS, which acquireNextImage of
ImageReader will return null. Otherwise, there is no chance to return
the buffer back later since the caller can't get the new SurfaceImage
object.

Change-Id: I774e91d52f3e10c8d2dd88d835505da79086c5b2
frameworks: Rquests permission for accessing downloaded files

Allowing systemUI to share downloaded files with RecntsPanelView
via granted permission request ACCESS_ALL_DOWNLOADS.

Change-Id: If7a137639ed69c43cf7736756abe0f1b98442010

Conflicts:
	packages/SystemUI/AndroidManifest.xml
TouchExplorer: print error message instead of cause fatal exception

In stead of throwing exception to cause system server dead, printing
out error message will be more reasonable.

Change-Id: I6e9cfdbfaaed6c03972c223c46ed78bfb0e00069
Keyguard: We need to ensure that keyguard is showing as well to set the token

Google fix

https://github.com/SlimRoms/frameworks_base/commit/021806ec33f5f59567f3bb3af135b2a1d88c0951

fixes what it is meant to fix.

But still we need to ensure if the keyguard eg is disabled by 3rd party
apps or the keyguard is not showing due of other reasons to inform PhoneWindowManager over the token
not to wait to draw for the Keyguard and go ahead.

Fix:
Just check for isShowing in addition to the check if KeyGuard is disabled

Change-Id: I5f017a6ccebf12dc717fb6d44802a1c1fee15abc
Send out USER_PRESENT broadcast on screen on if lockscreen is disabled.

This makes sure to turn off the notification LED on screen on when the
lockscreen is disabled by lockscreen toggle tile.

Change-Id: Ibf2fdcd912a2719d973a253aaf3752add7a22e00
Fix visibility of camera widget on insecure lock screens with DPM

The camera widget should be visible on an insecure lockscreen even
with the KEYGUARD_DISABLE_SECURE_CAMERA policy flag set.

Change-Id: I37ff905c6325be9120b16984d3401f334ad00e4c

Conflicts:
	packages/Keyguard/src/com/android/keyguard/KeyguardHostView.java
Always call super.onCreate().  Always.

Bug 12991134

(cherrypick of commit 9d6376a1d88ab5b3a41ee4400e3aaa4c4ee69e2a)

Change-Id: Ife16ef93408253e3318a06dc0206ab4b88c7f367
Quick Record Tile

Change-Id: I32c4c440845557b88f9e8bffff19b6a1a57acb06

Images by kroz (thanks!)
Change-Id: I22f9de88d401a777e987ec2c1bbbf599dc840d5d

Conflicts:
	core/java/com/android/internal/util/cm/QSConstants.java
	packages/SystemUI/res/values/cm_strings.xml
	packages/SystemUI/src/com/android/systemui/statusbar/phone/QuickSettingsController.java