show connected devices or name of single device on Bluetooth Tile

Patchset 4: Add ACL listener to trace back connected/disconnected bt devices
            CleanUp
Patchset 5: Rebased
Patchset 6: Move ACL listener to BluetoothController

Change-Id: Ic9dda4f9123bc541753332df759cbd8534ab2e10
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
Better fix for QS layout in landscape mode

Thanks to CM
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
Keydispatching timeout while finish Activity

If there is input to be handled during finish activity we can get a
keydispatching timeout ANR. The reason is that finish activity is some
times not possible, and the activity is instead put on a finish queue.
The activity will then be finished sometime in the future. When we add
the activity to the finish queue, key dispatching is paused, and there
is an ANR timer waiting for it to be resumed again. Since it can take a
long time before the activity is actually finished, we need to resume
the key dispatching to avoid the ANR.

Change-Id: Icea4ab3b5ad05c8bfbadf8f5cece1a59ec621469
Fix to NullPointerException on move back in ActivityStack.

In ActivityTask.moveTaskToBackLocked NullPointerException may occur
when moving back with only current Activity in stack. This due to a
condition that may trigger despite a TaskRecord being null and then
attempt accessing the TaskRecord.mOnTopOfHome variable.

TaskRecord task may be set to null when no resumed activity remain.

Resolved by assuring that flag mOnTopOfHome is instead set to false
for current TaskRecord in case where there are no remaining activities
above home.

The above bug has already been corrected in the following commit,
ada62fca51d314cefe2c5da4e007df5b9abf320d, but it does not set the
cottect value to mTopOfHome for the current taks, see below.

Variable mOnTopOfHome will not be set to false in situations where
stack is of size 1 or less and task is null, perhaps from already
having finished current activity.

To avoid current TaskRecord maintaining value mOnTopOfHome to true
after launching Home this variable is set to false.

Impact should not be major due to correction earlier that makes sure
that there is always a TaskRecord.mOnTopOfHome set to true above Home
activity but if not correctly set for current task still gives a
possibility of bad behavior.

Change-Id: Ie86ad99c188aaa05b0de9d58eaa16c42b6fc4341
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>
Revert "GC triggering performance optimizations"

This reverts commit 2bc80d806fcb624254bfc3158031b0fc2a4b48d0.
Avoid duplication of AppWindowToken in created Task

When WindowManagerService creates a new Task, it passes atoken to the
Task constructor. In this case atoken is added to mAppTokens list by
the Task constructor and then it is added manually again by calling
newTask.mAppTokens.add(atoken). As a result, the same atoken is present
in mAppTokens list twice.

When another window token is added to the list, it may be placed in
beetwen duplicated tokens and corresponding window will be hidden from
the screen by corresponding duplicated windows.
From user perspective it means that some windows will not be displayed
on the screen.

The issue is fixed by avoid adding atoken to mAppTokens list manually
when it was added already in Task constructor.

Change-Id: I10628e68186160fffdde07beb7d84ab3cecb7051
Framework: Add Landscape layout for ECA

Maintainers!!!
Please test on your devices.
MAYBE google did this for a reason =P

PS2: Whitespace

Change-Id: I22829c6e5f8badf78336e5c14d3c507426da32b9
Revert "ZygoteInit: increase GC threshold amount when preloading to postpone GC"

This reverts commit 896e8ef7f5dde6fca96b4c4abdd98368cf83e2aa.
Remove unnecessary audiomanager check
http://review.cyanogenmod.org/#/c/54965/
DO NOT MERGE - [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
[ActivityManager] Fix a bug: unable to start activity after starting activities during screen off.

Symptom: Unable to start any activity.
Root Cause: ActivityStack.mPausingActivity() points to a destroyed activity of a died process, so that ActivityStackSupervisor.allPausedActivitiesComplete() always returns false.
Solution: Set mPausingActivity to null in ActivityStack.cleanUpActivityLocked().
Reproduce steps:
    a. Turn screen off.
    b. A background service starts an activity X (in process X).
    c. A background service starts a no-history activity Y (in process Y), but the main thread of Y was blocked.
    d. A background service starts Y 3~4 times --> this causes am_failed_to_pause on X.
    e. Main thread of Y is freed finally --> this causes Y crash for android.view.WindowManager$BadTokenException.
    f. Turn screen on, X is shown on screen, but neither back key nor home key can work because mPausingActivity is Y.

Change-Id: I320b3db407e2d4cc745c8ca22a6e548742234242
[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
Revert "core and telephony: Additional HSPAP support"

This reverts commit 8cda387fabf6a437a4aada1e7c62e6bc63e9227f.