Fix issue #2493497: Stuck in the Emergency dialer - Home/Back keys doesn't work
This was another case of not updating the window focus when needed, this time
when the lock screen was hidden.
Also re-arrange the layout/animate flow to address issues where you would see
a flicker of whatever was behind the lock screen when showing a new activity that
hides the lock screen. This was because we were deciding to hide the lock screen
during the layout phase, which meant we had to do it without considering whether
it had drawn. So we could hide the lock screen before the window is shown for the
first time after being drawn. Now we can do this in the policy during animate, so
we can wait until the window is drawn and actually being shown.
The flow in perform layout is thus significantly changed, where the layout and
animate loops are both under the same repeating loop. The actual flow from this
should be the same, but it now allows the policy to request a new layout after
the animation loop is done. This actually cleans up a number of things in this
code as the complexity has increased.
Finally this includes a change to the ui mode manager when switching modes, to do
the resource configuration switch at a different time. This makes transitions
between modes much cleaner (though not yet perfect).
Change-Id: I5d9e75c1e79df1106108dd522f8ffed6058ef82b
Bug #2376231: Apps lose window focus (and back key causes ANR) if the
lock screen is dismissed while the phone is in landscape mode
This is another case where we weren't recomputing the focused window
after changing the visibility policy.
bug #2479958: Investigate source of "Resources don't contain package
for resource number 0x7f0a0000"
Um, okay, so it turns out there were bugs all over the place where
we would load an XML resource from a another application, but not
use the Resources for that application to retrieve its resources...!
I think the only reason any of this stuff was working at all was
because it typically only cared about retrieving the resource
identifiers of the items (it would look up the values later).
Bug #2401082: Passion ERE26 monkey crash - InputMethodManagerService
Add some null checks.
We now only consider a device to be a default keyboard if its name
has "-keypad". A hack, but whatever.
Also add some debug logging for the input state to help identify such
issues in the future.
This is a bunch of reworking of how configuration changes are handled:
- When orientation is changing (for whatever reason), the window manager no
longer tries to pre-emptively compute a new configuration. Instead, it
just determines change is happening and tells the window manager.
- The activity manager is now responsible for giving the window manager the
final configuration it is using. This is both so it knows whem the
activity manager is done with its configuration updates, and so the window
manager can use the "real" configuration.
- When an orientation or other configuration change is happening, freeze the
screen and keep it frozen until the activity manager has given us the
final configuration.
- The window manager can now send new configurations to its clients during
its layout pass, as part of a resize, if it has determined that it has
changed. This allows for a new View.onConfigurationChanged() API for any
view to easily find out when the configuration has changed.
- ViewRoot now also works with the activity thread to make sure the process's
current resources are updated to the new configuration when it receives one
from a window. This ensures that at the time onConfigurationChanged() and
other view callbacks are happening, the correct configuration is in force.
- There is now a sequence number associated with Configuration, which
ActivityThread uses to avoid using stale configurations. This is needed now
that it can receive configurations asynchronously from both the window
manager and activity manager.
- The hack for keeping the locale has been removed, and underlying problem
fixed by having Configuration initialize its locale to "unknown" instead of
a valid default value.
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.
