Commit Graph

4 Commits

Author SHA1 Message Date
Dianne Hackborn
2c84cfc001 Various performance and other work.
- IME service now switches between visible and perceptible depending on
  whether it is being showm, allowing us to more aggressively free its
  memory when not shown.

- The activity display time is no longer delayed by the activity
  transition animation.

- New -R (repeat) option for launching activities with the am command.

- Improved some documentation on Loader to be clear about some methods
  that apps should not normally call.

- FrameworkPerf test now allows you to select individual tests to run.

Change-Id: Id1f73de66dc93d63212183958a72119ad174318b
2011-10-31 16:52:34 -07:00
Dianne Hackborn
bc1aa7bbc7 Fix issue #5312624: Lock screen very flickery
The key thing was to fix isVisibleOrBehindKeyguardLw() so that it
wouldn't count a window as not visible if it was just currently
in the process of drawing due to an orientation change.

Also improve logic in deciding when to turn screen on to better ensure
the screen is in a stable state, in particular treating screen off
as a frozen screen and not allowing it to turn on until the
update of the screen due to any config change is done.

Change-Id: If82199f3773270b2d07f9c7de9da2dad8c7b28d7
2011-09-20 11:20:31 -07:00
Jeff Brown
9302c8796f Refactor input dispatcher use of window/app handles.
This change moves the cached window and application input state
into the handle objects themselves.  It simplifies the dispatcher
somewhat because it no longer needs to fix up references to
transient InputWindow objects each time the window list is updated.

This change will also make it easier to optimize setInputWindows
to avoid doing a lot of redundant data copying.  In principle, only
the modified fields need to be updated.  However, for now we
continue to update all fields in unison as before.

It turns out that the input dispatcher was inappropriately retaining
pointers to InputWindow objects within the mWindows InputWindow
vector.  This vector is copy-on-write so it is possible and the
item pointers to change if an editing operation is performed on
the vector when it does not exclusively own the underlying
SharedBuffer.  This bug was uncovered by a previous change that
replaced calls to clear() and appendVector() with a simple use
of operator= which caused the buffer to be shared.  Consequently
after editItemAt was called (which it shouldn't have, actually)
the buffer was copied and the cached InputWindow pointers became
invalid.  Oops.  This change fixes the problem.

Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-14 04:11:21 -07:00
Dianne Hackborn
6e1eb76f02 Explode WindowManagerService.
Change-Id: I3d73ed4c9a1b5d730aeffeb2df24ce5e6117d698
2011-02-17 16:14:16 -08:00