Fix Floating Window
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
[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
Always call super.onCreate().  Always.

Bug 12991134

(cherrypick of commit 9d6376a1d88ab5b3a41ee4400e3aaa4c4ee69e2a)

Change-Id: Ife16ef93408253e3318a06dc0206ab4b88c7f367
[ActivityManager] Reduce report ANR on wrong activity.

Symptom: ANR report on wrong activity.

Root Cause:
  KK changed resume behavior that will not update focus when only resume,
if the activity blocked, it may report ANR on previous focus.
  By original concept, it will try to correct the ANR target,
but the stack of waiting(waitingVisible=true) activity may
different with current top stack.
  If it gets key dispatch timeout, mResumedActivity and mPausingActivity
of its stack will be null becuase it is not top stack.
Then it is unable to change ANR target to the real no response activity.

Solution:
 Use focused stack to get the real culprit.

Reproduce steps:
1.Launch an Activity X from launcher, press home key.
2.Launch X from launcher again, X blocks(sleeps 15sec) in onResume, press back key in the beginning of blocking duration.
3.ANR dialog shows launcher is no response.

Change-Id: I99416ad91e349096f995990f2240a97616fbaf28
frameworks/base: Fix aliasing violations

Fix violations of strict aliasing rules

Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Work around uint16_t vs. char16_t confusion

Change-Id: I188e5a82b2dba821710eaea85d6cbef2ae004ce9
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
frameworks/base: Fix build in ISO C++11 mode

Fix various incompatibilities with ISO C++11:
- Assumption that char16_t is defined to uint16_t
- constexpr usage
- macro constructs that could be interpreted as string literals
- enum typesafety

Change-Id: I3642537d3995c3766f69362bbd54ebcc05a9864c
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
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
frameworks: translation - RU

Idec8ea425ea46ff0ebfda37451c521b08d2d4979

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