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
TokenWatcher.acquire() synchronizes on mTokens, not this,
so we need to synchronize on mKeyguardDisabled in disableKeyguard()
to synchronize properly with reenableKeyguard().
This should fix b/2180142 (Stuck in enable keyguard when receiving phone call)
Change-Id: Iad66a2748c7fbf2c516fdb8a00988696719ea80c
Signed-off-by: Mike Lockwood <lockwood@android.com>
There was another way we could ignore the application windows flags
while the lock screen was displayed. This is the infrastructure to
deal with that.
Change-Id: Id8c9cb2f7081df6757ccb797a7cde618e82f7b38
There was a bug with the starting window where it could be added to
the app window list twice, so the buddy list would end up with one
left over after all was done. This would result in visibility
changes not being delivered to it correctly, delaying the dispatch
of onStop.
Change-Id: If1993eaf9cfbba1f523ce5aaa478be0239d0c7db
Windows with a negative Y position can end up in createSurfaceLocked()
with mFrame containing a negative height, causing SurfaceFlinger to go
crazy when asked to create the surface. This change simply guards
against such a situation by instead asking for a 1x1 surface and relying
or later layout operations to resize the window to the appropriate size.
Change-Id: I66f2058f4cd1cf069b12d3d23e6fd340dc76b74e
I think when we were scanning the updated app in the system image,
from an older version on the data partition, we were not setting
the existing package to have the system flag, so not auto-granting
any new permissions.
This also includes some other cleanup in the package manager to
remove old files in various places, and tighten up logging.
Also similar logging cleanup elsewhere.
Change-Id: I6d113c7cf7e736ab9be512d6d7c94c806a24199a
Now that we can have a non-app-window cross-wallpaper animation,
we need to make sure to not access a null app token.
Change-Id: Ia00debd4b2b431d15bd074927a9035e1bc0a6445
The APIs for checking whether keys are held down now also look
at virtual keys.
However it turns out there is less than a second between the time we
start the input thread and check for safe mode, so there is not enough
time to actually open all of the devices and get the data from them
about the finger being down to determine if a virtual key is down.
So now you can also hold DPAD center, trackball center, or s to
enter safe mode. Also give some vibrator feedback.
Change-Id: I55edce63bc0c375813bd3751766b8070beeb0153
This was introduced when I did the fading of the lock screen,
which relies on setting the policy visibility of the windows behind
it to be hidden. As a result, when the orientation changed or
the activity was restarted, they wouldn't be resized or reported
as drawn, and the activity manager would wait until its timeout
before unfreezing the screen.
We now have a new method on WindowState to find out if a window
has drawn itself, which is used in the appropriate places.
Change-Id: If05f8b1947d3029917f62ad0f89b43544bd0a4dc
- The lock screen now fades in and out.
- Fixed a bug where we would accidentally freeze the screen when switching
to an activity with a different orientation than the current (but
the screen itself is in the current orientation). This would mess up
the animations on the car dock.
- New API to force a particular animation for an activity transition
(untested).
- New wallpaper animations.
- Resources now uses the next API version when in a development build,
to help applications being developed against such builds.
Change-Id: I2d9998f8400967ff09a04d693dc4ce55f0dbef5b
Lot of infrastructure for more things to go away when "clear system dialogs"
happens, and now do this when we turn on the lock screen.
Change-Id: I567130296fe47ce82df065ed58ef21b37416ceaf
- New meta-data you can add to a dock activity to have it launched by the
home key when the device is in that dock.
- Fix a deadlock involving ActivityThread's internal content provider lock.
- New window flag to have a non-secure keyguard entirely dismissed when a
window is displayed.
- New WindowManagerPolicy APIs to allow the policy to tell the system when
a change it makes during layout may cause the wall paper or
overall configuration to change.
- Fix a bug where an application token removed while one of its windows is
animating could cause the animating window to get stuck on screen.
Change-Id: I6d33fd39edd796bb9bdfd9dd7e077b84ca62ea08
Add API to skip the animation for a particular start activity, so that
a latter better one can be used.
Fix Theme.NoDisplay to actually work.
Fiddle with various animations: don't do a different animation for task
switching, try a scale animation for switching in/out of the wallpaper.
Adjust the animation duration so that at normal speed we have something
more like the slower animation option (so slow is now the default).
Change-Id: Ieba9f3db0bd9a762a19b327a3ecccbc7b547893d
This also takes care of the problem of system dialogs like the
crash dialog causing the status bar to dim behind the lock screen.
On the down side, the fade transition from the lock screen is
now gone, and I'm not sure how likely it is for it to return.
Change-Id: I7f9e6d0f3510a1fdbbe6ad252d986bd85a16475d
This was a problem with not hiding the starting window when it got
transfered to an activity whose window (instead of token) animates
when displayed.
Change-Id: I9eb58faa6e27d53144687952a715fc083a5c5842
This implements support for devices whose hardware can hide
their navigation keys. It works much like the existing keyboardHidden
configuration, and for compatibility uses the same configuration
change bit.
Also add FLAG_TURN_ON_SCREEN for windows, which has the system
cause the screen to be turned on when the window is displayed.
Great fun when used with FLAG_SHOW_WHEN_LOCKED!
Change-Id: I0b867f19af85cfd8786a14cea194b34f7bdd9b7a
This introduces a new activity that you can derive from to implement
a wall paper configuration activity. This is supposed to select
a theme based on whether it is being run to configure a real wallpaper
or a preview, but this is going to be more difficult to do than I
thought. :(
Also fix a problem in the white theme where the list view's background
was being set to white, so it wouldn't work on a transparent bg.
Change-Id: I26d5a8695a3c878a1664eb09900eded57eaff990
This takes care of allowing us to cancel the back button. The
back button is a bear because it is strewn all over the place --
everywhere you can close something, there is some code looking
for the back button that now needs to deal with being canceled.
The main things changed are activity (of course), dialog,
input method, search dialog. There are some other misc places
in the framework (and some I missed here that I will get in a
second pass).
To facility all of this, the key dispatching APIs now provide
a lot more support for dealing with looking for cancelled keys,
and incidentally also provide an actual API for catching long
key presses. This also helped clean up the code in PhoneWindow
where it deals with all of the combinations of key pressed and
releases. (And also allows people to override
Activity.onKeyLongPress() to provide a different long press
action for a standard key like search.)
And while I was doing this, I reworked how we detect long
presses by having this be part of the key event delivered by
the window manager. This should greatly reduce (hopefully
outright eliminate) the problems with long presses being
mis-detected when an application is being slow.
Change-Id: Ia19066b8d588d573df3eee6d96e1c90fdc19f57d
First, fix some issues with the final wallpaper bitmap
we use: ensure it is always 16bpp, and make sure dithering
of its bitmap is turned off. We take of dithering
when loading, to make sure we don't use it when drawing.
Also add new APIs to return the wallpaper with the equivalent
of Launcher's old FastBitmapDrawable. As doing this, also load
the default wallpaper the same way as custom ones, taking care to
resize it as needed at load time.
Finally implement a mechanism for the window manager to wait
for the wallpaper to redraw at its new position before returning
from the application's call to change the offset. This ensures
that the wallpaper better tracks the application. Note that there
is a timeout in this wait that is relatively short, and if it
expires we will run for a while without waiting.
Change-Id: Ife449437746da85958bd447e0a6cf3d2223b398c
Some more tweaks and fixes to wallpapers. Make sure wallpapers are
told they are not visible when the screen is off. Add some new animations
for transitions across tasks, and fiddle with many of the existing
animations. Clean up the relationship between translucent activities
and animations. Add new API to start a PendingIntent from an
activity.
Change-Id: Ie0bf45fe44081bb6982c75361257a55d9cd9d863
ViewRoot was using Surface.clear(), which has different behavior
in different processes -- in the system process it would kill the
surface, causing all windows in that process to immediately disappear
instead of animating away.
This change makes Surface.release() public and uses that instead. It
also renames Surface.clear() to Surface.destroy().
Also fixed some issues in the window manager that were causing the
wallpaper to not get immediately resized when the orientation changes
and its target window is removed and re-added.
Change-Id: I2a992e365cf5747511f0bf1193db32dc2525b218
