Force the event-target bookkeeping to reset when an app explicitly
acknowledges event receipt. Furthermore, notify the event dispatcher
whenever a new window is created, even if there is nominally an
existing event target window.
These changes in tandem address a subtle race bug in which the event
dispatcher believes that there is an event recipient that it is still
waiting for even when the event in question has been acknowledged;
this results in a spurious ANR. There were checks in the existing code
that wound up doing the right thing in the case of windows becoming
hidden, but the case of non-fullscreen activities floating over them
[unavailable for input but still visible] exposed the race condition.
Bug: 2432828
Change-Id: I29fb741aace34736b029f9ba43f2c43184366258
Merge commit '1e90ab542d675616e9370ab7e5add99d7af12587'
* commit '1e90ab542d675616e9370ab7e5add99d7af12587':
Fixs the incorrect message for SecurityException
Default RotateDrawable's pivot set to (50%, 50%)
when injecting a Key, Pointer and Trackball events into the UI across
applications, the corresponding methods throw SecurityException with
incorrect permission message.
INJECT EVENT permission should be INJECT_EVENTS
Add new ALLOW_LOCK_WHILE_SCREEN_ON window manager flag, which when set
causes the window manager to put up the lockscreen after the
normal screen timeout has elapsed.
Add plumbing to pass PowerManager.userActivity() to the window manager policy.
Change-Id: I05adc52bad39c56031a08e8ec3cbcf5c2d9b9827
Signed-off-by: Mike Lockwood <lockwood@android.com>
This was caused by the launchers new hidden surface on top. The
algorithm for determining whether an activity was visible assumed
that all windows would want to be visible. Now it ignores ones that
have explicitly requested to be hidden.
Yet more special casing for the window manager... try really hard,
if we are performing an activity transition that is behind an
opaque window (like say the lock screen or status bar) to just not
do it. And, just as important, do a reasonable transition away from
whatever is on top.
Examples:
- If the lock screen is up, and you get a call or press the
emergency dialer button, we fade from the lock screen to the
new UI, instead of fading to the animation going on between
the old and new.
- If you are in something hiding the lock screen, like the
in-call screen, and that is hidden, then fade back to the
lock screen.
- If you select an item from the status bar, then have the
new item displayed behind it as the status bar rolls up
rather than seeing a second animation. (In fact this can't
always be done because we may not start the transition to
the new thing until the status bar is already going away.
But for most cases we can do this with just one anim.)
Merge commit '47c38f00ab464a8fdb6ae2d819ae189c17b72410'
* commit '47c38f00ab464a8fdb6ae2d819ae189c17b72410':
Issue #2335763: Cant dial emergency number on my device
This may fix the issue, but we have no repro steps so no way to
make sure.
What appeared to be going on was that the emergency dialer was
created, but still had the starting preview window above it. We
were stuck in this state because the preview window didn't have
the "hide lock screen" flag set, so the lock screen would never
be removed, and thus we would never take care of finishing the
show of the emergency dialer (because it was not visible) and
thus not remove the starting window.
The solution here is to simply propagate the lock flags up to the
starting window.
Change-Id: I6da9f6494537f0661d9d230664ebf745c293ea7d
Merge commit '9b52a2184e99565bcd7f77effb321c95a2a4837e' into eclair-mr2
* commit '9b52a2184e99565bcd7f77effb321c95a2a4837e':
Fix#2269582 Sometimes camera preview screen is truncated
There were a few places in the window manager where we wouldn't cause
a layout after making a window visible. This would leave it using
whatever size and position it last have since we don't layout windows
when they are not visible.
Also includes a little part I missed in the security issue that
allowed wallpapers to see input on the lock screen.
Change-Id: Icd7e037ad9a67ac936bc7039d87ed68f49502d73
The system_server process is deadlocking between event dispatch and window
manager code. This change fixes the lock scoping to eliminate the deadlock.
Change-Id: I00f029e4d51d7432119ad3aeec260df215b52546
...in setup wizard ->Wifi setup screen.
We were stopped waiting for the wallpaper to draw, which it would never do
because it had been obscured and thus hidden.
Change-Id: Ia48b3f2a46ca970f143cbaee99f5f2a054378986
Merge commit 'e851cdc6c48c977d05096847001a0601d892fd55' into eclair-mr2
* commit 'e851cdc6c48c977d05096847001a0601d892fd55':
Fix#2313382: SECURITY: Live wallpapers get touch events through the lock screen.
This is a quick and dirty hack to not deliver touch events to the wallpaper when
they are being sent to the keyguard. Perhaps we should have a separate window
flag for this, but... bleah. Maybe later. Or maybe I'll use that secure flag.
Or something.
Change-Id: Ifd95b9f5b10db24a0854a93b925a833b24331b4c
We can now locate event log tag definitions in individual packages
(and java constants for the tag numbers get auto-generated), so move
all the tags used by the system server into the package.
Merge commit 'abf7fed21bfa7eb899be558477d928a7c9f3e1f6' into eclair-mr2
* 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>
...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
The new backlightBrightness field works similarly as the existing WindowManager.LayoutParams.screenBrightness field
Needed for bugs:
b/2233655 (under low ambient light the touch keys remain illuminated during video playback and never timeout)
b/2221079 (Backlight for home/search/back/etc buttons should turn off when in dock in night mode)
Change-Id: I60dfecdc7bb653b0db38094464de651220b3d438
Merge commit '8abd5f0d519afa787e7c64e429df17ccc661ce75' into eclair-mr2
* 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>
Merge commit '48515f495b29c01b473579825d5ba5e690ff5db7' into eclair-mr2
* commit '48515f495b29c01b473579825d5ba5e690ff5db7':
Fix issue #2170897: wallpaper touch-up event not seen when exiting lock screen
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
Merge commit '11cff8cd30f03b5adb137e985532543da5e960c4' into eclair-mr2
* commit '11cff8cd30f03b5adb137e985532543da5e960c4':
Add a way for wallpapers to know the delta between virtual screens.
Merge commit '3cba72880b78b81cda2868136462c9e261a3e403' into eclair-mr2
* commit '3cba72880b78b81cda2868136462c9e261a3e403':
Expose PowerManager.isScreenOn in the public api.
Merge commit 'bf50200ba494db0ac2ce655a95f76640f49355ee' into eclair-mr2
* commit 'bf50200ba494db0ac2ce655a95f76640f49355ee':
When tasks are moved to top or bottom, the app tokens are being rearranged.
The window token rearrangement is defered if an animation is
underway. Force a focus recomputation when the window tokens are finally
rearranged so that we have a valid focused window.
Merge commit 'a47a1e77a4dc9510187f57d5cdf12f5ecf6b3ab0' into eclair-mr2
* commit 'a47a1e77a4dc9510187f57d5cdf12f5ecf6b3ab0':
Check that the window which wants to force hide is visible before setting the flag forceHiding to true. If we do layout the surfaces
again this flag gets set no matter what since the keyguard window is always present in the list of tokens and this hides the window which would
have become visible since the keyguard just got dismissed.
This causes unnecessary focus changes due to changes in visibility of current window.
This will resolve issues related to current focus and time outs when dispatching key events.
Because of the asynchronous behavior of keyguard, and incall explicitly
disabling keyguard, sometimes the window manager would wind up in a state in
which the "correct" app and activity window were shown, but focus was
recalculated "too soon," at a time when keyguard was just about gone but not
quite, and incall was not yet fully shown. In this case there was no currently
valid event target, but the final show of the incall window would not prompt a
focus recalculation, so that "no current focus" state would incorrectly persist,
resulting in spurious ANRs until some other phone activity forced a focus
update.
We now detect the problematic case when windows are shown, and make sure to
recalculate focus explicitly thereafter. This change does *not* fix the
underlying race conditions that have been resulting in mismatched state within
the window manager, but it does force a validation pass that puts things in
order so that normal operation can continue.
Change-Id: I8e7f5f0795f0042a0da074aeed385e3fbc210360
Fiddle around with the offsets of wallpapers to have better defaults, and
update the offset when the currently wallpaper target is not setting an
offset itself.
Change-Id: I1864d098fb4813fb0c67857af8ebf398b35e6876
