Merge commit 'e7ef42416088235d9e220e3b031d4f612f436a06' into eclair-mr2
* commit 'e7ef42416088235d9e220e3b031d4f612f436a06':
Fix volume keys when in-call and screen is off due to proximity sensor.
Fixes bug b/2297262 (Volume keys on passion don't work while in-call and phone is pressed to my ear)
Change-Id: I775daa24295482000f87273d1f84dd796fb0f4eb
Signed-off-by: Mike Lockwood <lockwood@android.com>
When the screen is off keyguard is open but hidden by another activity
make sure that non-waking events like volume key or track ball press
do not turn the screen back on.
Change-Id: Ie6b191360b903b54388a6f65680ccc3264a51dd8
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit '5da799e012cc4427a4f656e2416bcd73c22acd83' into eclair-mr2
* commit '5da799e012cc4427a4f656e2416bcd73c22acd83':
Bug 2248173 - Tell listeners to ACTION_CLOSE_SYSTEM_DIALOGS that we're doing so because of the home
We now treat the case where the lock screen is hidden to be basically the same as
it being removed for purposes of event dispatching and other things in the policy.
Change-Id: I7386220594ad6e89e1493d643b1f0603663ae72a
Fixes b/2260437 (device wakes itself back up when camera is last application running)
Change-Id: Icdb3d0369df752a3838fa8e58c7a4bb08efe00a6
Signed-off-by: Mike Lockwood <lockwood@android.com>
Fixes my previous fix for bug b/2201585 (Pressing power button when phone ringing should mute ringer)
Change-Id: I9460e21245b9719f715818f7ad878b121857d773
Signed-off-by: Mike Lockwood <lockwood@android.com>
Fixes bug b/2201585 (Pressing power button when phone ringing should mute ringer)
Change-Id: Ief3e26044f9b0ceaf41c5dc6be52f0d1e9897810
Signed-off-by: Mike Lockwood <lockwood@android.com>
This prevents an endless stream of key repeats spamming the keyguard
if a volume key is pressed at the same time you turn off the screen
with the power button.
This is part of a fix for bug b/2198537
Change-Id: I0d7e335fee79cbebba96b2cd908458c3c94c839e
Signed-off-by: Mike Lockwood <lockwood@android.com>
Another way we could miss the application's flags is because the
system now force hides application windows behind the lock screen. So
we need to use this new API to actually take those into account when
looking for the top-most window that can specify for the lock screen
to be removed or hidden.
I have tested with pulling the device in and out of the desktop with
all kinds of random speeds and ways and this -seems- to now cover
everything. Keeping fingers crossed.
Change-Id: Ice640eea6ee06ee27f069d60856fb394c7eeae51
The issue I saw was then when plugging into the dock, we the battery
first is in the "USB" state before going to "AC". The phone window
manager would pick up the first state, but not the second.
This change reworks this code to always monitor the battery status
while plugged in to the dock, to update itself whenever that state
changes. When not in the dock, we don't monitor, since this is
only used to determine whether to keep the device on while in the
dock.
Change-Id: Ic1e8b584082a44c4e5df13ee19dab450775027f6
The lock screen's flag to force the status bar on was sometimes
interfering with the flag of the alarm behind to hide the lock screen.
Change-Id: I91368c56d09d35b03db548530aa1eb59197206bd
- Implement new window flags for dismissing non-secure lock screens.
- Implement launching of docks from the home key.
Change-Id: If29f299db47e3759c3e146983f59d0f86ed22c4c
- The window flag to hide the lock screen will now allow you to press home,
and automatically dismiss the lock screen if it is not needed for security.
- When opening the lid, if the lock screen will be shown, try to avoid
turning on the screen until it is ready. There is actually still some
problem with this.
Change-Id: I51d769b8e6cff7b439b1ffea927c0a01376427b1
Re-arrange various things to ensure that the search dialog is told about system windows being
closed before it is told about the navigation back to home.
Previously, the global actions menu was closed when the keyguard was shown, but
when the menu was shown from within the keyguard, it wasn't closed ever again
when the screen goes off. That had the result that if your pocket managed to
bring up the dialog, the menu would likely never go away on its own, and
eventually do something awful like go into airplane mode.
There was code in PhoneWindowManager from last time when
the search dialog was a system dialog that caused an exception
if the search was added to the window manager twice.
Generally there should only be one search bar, but because
window manager calls are asynchronous and don't execute in order,
we can't be sure that a call to stopSearch() has removed the search
dialog before a subsequent call to startSearch() tries to add it again.
SearchManagerTest.testSearchManagerFastInvocations() crashed the system
process before this change.
its shown. this lets the window manager to hide or unhide the keyguard based on activities that specify if they want to be displayed
inspite of the keyguard being shown or not.
