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>
...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
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>
Do not cancel screen brightness animation in forceUserActivityLocked unless screen is turning off.
Also not turn the screen on if PowerManager.preventScreenOn(false) is called while proximity sensor is active.
Fixes b/2254818 (dim display) where due to a race condition the screen is stuck in a dim state.
Change-Id: If6f805609c8d463631b9e22805e5242714ce34c0
Signed-off-by: Mike Lockwood <lockwood@android.com>
This prevents the device from sleeping while a deferred proximity sensor
event is pending.
Fixes b/2260005 (Proximity sensor can fail due to missing wakelock)
Change-Id: Ia4825f548b5b7d8a0b184f720b32c2f21b77b96e
Signed-off-by: Mike Lockwood <lockwood@android.com>
The goal of this change is to allow the Package Manager to look for native
shared libraries corresponding to the CPU ABI reported by ro.product.cpu.abi2
if none was found for the CPU ABI given by ro.product.cpu.abi
This is used to support both ARMv5 and ARMv7 native code on modern ARMv7-based
devices. Typically, such a device would report a primary ABI of 'armeabi-v7a'
and a secondary one of 'armeabi', to indicate that it can run the binaries
generated for both.
The headset state indicated by HeadsetObserver in the broadcast intent ACTION_HEADSET_PLUG was not 0 or 1 as specified in the java doc but contained a bit field indicating the type of headset connected.
Modified HeadsetObserver to broacast a state conforming to java doc.
Added an extra to intent ACTION_HEADSET_PLUG to indicate if headset has a microphone or not.
Removed handling of non standard headset indications from HeadsetObserver.
Removed platform specific devices from output devices defined in AudioSystem.
Modified AudioService to use new ACTION_HEADSET_PLUG intent extra instead of bitfield in state.
Also reworks this intent protocol a little bit to be much more efficient, only
requiring one broadcast per package.
Change-Id: I580de4843ebd3c7f2e6df7295a2f80d2937cef7c
You can no longer receive CONFIGURATION_CHANGED in a manifest, which is really really
bad (launching apps every time the screen is rotated!). A new LOCALE_CHANGED broadcast
is sent that you can receive in a manifest.
Change-Id: I80022375f0716db2e672382a29db3cea1af74702
This adds a history of the last 100 broadcasts that is printed in the
debug log, to be able to see what recently happened at the time the
bug report was taken. Also does some optimization of the printing of
the broadcast records to make it feasible to print this number of
entries. (We kind-of need to do this because there are some broadcasts
like SIG_STR and SYNC_STATE_CHANGED that are being broadcast a LOT.)
Change-Id: I775e1ec0f63369c8bca8c83cee27b95ddc5ec450
The fact that the phone is losing power will do this anyway,
and this fixes (or works around) bug b/2250075
(Desk dock clock app sometimes doesn't exit when removing a sleeping droid from the dock)
Change-Id: I7b8b6cfb44ca16d2d9eb67589cb9d9a108a8de82
Signed-off-by: Mike Lockwood <lockwood@android.com>
Make sure to deliver events to the wallpaper until the final up.
Also fix behavior in the case where a window goes away while the pointer is still
down in it, which is a fairly novel situation introduced by the new lock screen.
Also add infrastructure for delivering motion events during preview.
Change-Id: I0de7979be27e00caf0b1eff794ea899a815142f6
This allows the driver to behave differently depending on if the lighting is being
managed by the light sensor or by a user preference.
Change-Id: I4b9325f82b7aded0ce5cfc6c07658666bbdae331
Signed-off-by: Mike Lockwood <lockwood@android.com>
This is part of a fix for bug b/2248320 (Lock screen does not time out after
Change-Id: Iba7f8a7b9997ecb0e4da37667600055f9a35531c
Signed-off-by: Mike Lockwood <lockwood@android.com>
This ensures that we do not get cheek presses immediately after a call is ended.
Fixes bug b/2246824 (prox sensor subtleties when call ends)
Change-Id: I97d39b7689d9ea2e94ea9aceeb93bf15228ec095
Signed-off-by: Mike Lockwood <lockwood@android.com>
when processing light and proximity events.
This should fix loss of 2 second hysterisis for light sensor (b/2243521)
Change-Id: Ia3ce331e67d803eb5e51810cb7161b7c528312d7
Signed-off-by: Mike Lockwood <lockwood@android.com>
Fixes bug b/2202165. The light sensor was interfering with the screen off animation.
Change-Id: I1bc566a164af689b60b066e6cb3dcbf7959bc50a
Signed-off-by: Mike Lockwood <lockwood@android.com>
This allows us to adjust immediately when we receive a correct light sensor reading
after the screen turns on.
Change-Id: I627047365640761727348e577c9164a6d6be2772
Signed-off-by: Mike Lockwood <lockwood@android.com>
