Merge commit '9ae9763b7e5dd872619b13c889b72b0df176f956' into eclair-plus-aosp
* commit '9ae9763b7e5dd872619b13c889b72b0df176f956':
DO NOT MERGE Reverting change I53e91db7.
Merge commit '9d3cb9bfc6d7a5f340d2dd8132b201b933687564' into eclair-plus-aosp
* commit '9d3cb9bfc6d7a5f340d2dd8132b201b933687564':
Fix updating Bluetooth icon on status bar and for Wifi.
Accidentally submitted into eclair instead of eclair-mr2.
I apparently rebased my mr2 working dir to eclair by mistake.
Do not merge this so the desired change will survive on mr2 as intended.
bug: 2265222
Status bar uses the SINK_STATE_CHANGE intent to determine the icon.
This intent also has the device. Thus, we can get this intent for any
device and we update the icon wrongly. The same problem is with Wifi.
This was not commonly observed till now, but with the car dock changes
its easy to reproduce as we can get an incoming connection from the
car's bluetooth system. For Wifi, this will cause coexistance issues
especially with desk docks.
Dr No: Eastham
Bug: 2133530
Merge commit '90d1b745ec4a7ccd15cdcc185420bf2000b4f7a3' into eclair-plus-aosp
* commit '90d1b745ec4a7ccd15cdcc185420bf2000b4f7a3':
Filter out minor Connectivity Notifications.
Don't send a connectivity change notification if the change is in detailed state only.
IE, Disconnect/Idle -> Disconnect/Scanning should not trigger a connection change
notification.
bug: 2265222
Merge commit 'ae952b3bcc3eb744cceb5cd0ae65b2c7a83f9de7' into eclair-plus-aosp
* commit 'ae952b3bcc3eb744cceb5cd0ae65b2c7a83f9de7':
If the usage stats file doesn't exist in the first place there is no need to
Merge commit '8c411fb13923d1fa28fcd98452bf3d17b8b1a338' into eclair-plus-aosp
* commit '8c411fb13923d1fa28fcd98452bf3d17b8b1a338':
Add support for Car Dock.
Merge commit '678c2e35768a5426b4ad8f67c836008e7751a353' into eclair-plus-aosp
* commit '678c2e35768a5426b4ad8f67c836008e7751a353':
Add WindowManagerPolicy.OFF_BECAUSE_OF_PROX_SENSOR to indicate screen was turned off by the proximity sensor.
Part of a fix for bug b/2300622 (Proximity sensor always blows up the lock screen while in call)
Change-Id: I9ef888638b19540a78a34507d52ff522f505102f
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit '19a4157ce40f4ab77b60445b8e73069c5877bb8a' into eclair-plus-aosp
* commit '19a4157ce40f4ab77b60445b8e73069c5877bb8a':
Make the notification panel send the position as well.
Merge commit '9b7dba936c24fa7959561ddf1a0c8ba4d2165782' into eclair-plus-aosp
* commit '9b7dba936c24fa7959561ddf1a0c8ba4d2165782':
Implement new notification LED blinking logic:
1) Do not pulse notification LED when screen is on.
2) Pulse once on new notification if Settings.System.NOTIFICATION_LIGHT_PULSE is false,
otherwise pulse persistently while screen is off.
Fixes part of bug b/2238250 (trackball should pulse occasionally to indicate new email)
Change-Id: Icc49422a4e9d14412fc159a8e2596503a85bac51
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit 'abf7fed21bfa7eb899be558477d928a7c9f3e1f6' into eclair-plus-aosp
* commit 'abf7fed21bfa7eb899be558477d928a7c9f3e1f6':
Fix more of bug 2290852: Don't wake screen when bluetooth headset is connected or disconnected.
This fixes another case where the screen would turn on when the keyguard is open but hidden by another activity.
Change-Id: I2b7c8a329036401709e96ded4f4c138041192a71
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit 'bb3bb57a6330f71323fcd7e93e88dbdab55daec3' into eclair-plus-aosp
* commit 'bb3bb57a6330f71323fcd7e93e88dbdab55daec3':
Fix issue 2192673: Music Pausing Even when notifications are set to silent.
...Binary XML file line #37: Error inflating class <unknown> after adding a secondary account
The problem was that we weren't dealing well with the situation where we start a transition
from activity A to B, then transition back to A before B is shown (it finishes before being
shown), then transition from A to C. At this point we had some state showing that we
were in the process of showing A from it being hidden (due to the middle transition from
B to A), which would cause the layout pass to ensure its window is hidden before the
transition starts.
The solution is to detect the case where we are showing a token and it is already actually
shown, and in this case not do all of the token setup for it to wait for its windows to
be displayed before it is shown. This isn't needed, the windows are already displayed
or the token is already set up to wait for them to be displayed.
Change-Id: I16925b91e1e2449dd65ade162a5758173c6e2695
Merge commit '0d631b9b58db54bee58da717b38b8020bc3d0437' into eclair-plus-aosp
* commit '0d631b9b58db54bee58da717b38b8020bc3d0437':
Add logging of headset events to help debug issue.
Merge commit 'a0f9a4f73579c2afa4dd82499a69abce94a3f23f' into eclair-plus-aosp
* commit 'a0f9a4f73579c2afa4dd82499a69abce94a3f23f':
Fix issue 2265111: Loss of downlink audio while listening, and get a MT call.
Merge commit '8abd5f0d519afa787e7c64e429df17ccc661ce75' into eclair-plus-aosp
* commit '8abd5f0d519afa787e7c64e429df17ccc661ce75':
Fix issue #2267665 IME keyboard appears as Blank in compose view...
If reenableKeyguard() is called before the previous disableKeyguard() call is processed,
then TokenWatcher.sendNotificationLocked() will cancel the request, resulting in neither
the TokenWatcher acquired() or released() methods being called.
In that case, reenableKeyguard() will hang waiting for released() to set
mWaitingUntilKeyguardReenabled to false. Now we only wait in reenableKeyguard()
if the TokenWatcher acquired() method is called and the keyguard has actually been disabled.
This should fix bug b/2270192
Change-Id: Id886fb28df607dbb4543124f2db6997121d6a682
Signed-off-by: Mike Lockwood <lockwood@android.com>
Fixes b/2244560 (Time Stamp On Bug Reports And Pictures Is One Hour Off)
Change-Id: I69324a33f80e41ce68a0e6fdba08b80ed9453e19
Signed-off-by: Mike Lockwood <lockwood@android.com>
The cause of the problem is that under certain circumstance the HeadsetObserver receives unexpected connection events. For instance,
when removing a bad quality 3.5mm stereo jack without mic the following events can be received:
1 connection of a headset with mic
2 removal of a headset with mic.
The result is that the no mic headset is never disconnected and audio policy manager considers it is still present. Then the music or downlink call audio is always routed to headset even if none is connected giving the impression that audio is lost, except whne you reconnect a headset of enable speaker phone.
The fix consists in adding more checks in HeadsetObserver to reject illegal transitions in headset state received from event observer.
Add optional flag to Wakelock.release() to specify whether we should wait for proximity sensor to go negative before turning on the screen.
Clear the "waiting for proximity sensor to go negative" state when the power key is pressed.
Part of the fix for b/2243198 (Black screen lockup after ending call)
Change-Id: I813fdb7aa4192cd3384a25be9e59d7d4b90da53a
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit 'df7dbb68d330eae88c1ca6d03390dc8c18386871' into eclair-plus-aosp
* commit 'df7dbb68d330eae88c1ca6d03390dc8c18386871':
Fix bug 2252145 - Notification panel not closing completely when a call comes in
