This addresses a few parts of the bug:
- There was a small issue in the window manager where we could show a window
too early before the transition animation starts, which was introduced
by the recent wallpaper work. This was the cause of the flicker when
starting the dialer for the first time.
- There was a much larger problem that has existing forever where moving
an application token to the front or back was not synchronized with the
application animation transaction. This was the cause of the flicker
when hanging up (now that the in-call screen moves to the back instead
of closing and we always have a wallpaper visible). The approach to
solving this is to have the window manager go ahead and move the app
tokens (it must in order to keep in sync with the activity manager), but
to delay the actual window movement: perform the movement to front when
the animation starts, and to back when it ends. Actually, when the
animation ends, we just go and completely rebuild the window list to
ensure it is correct, because there can be ways people can add windows
while in this intermediate state where they could end up at the wrong
place once we do the delayed movement to the front or back. And it is
simply reasuring to know that every time we finish a full app transition,
we re-evaluate the world and put everything in its proper place.
Also included in this change are a few little tweaks to the input system,
to perform better logging, and completely ignore input devices that do not
have any of our input classes. There is also a little cleanup of evaluating
configuration changes to not do more work than needed when an input
devices appears or disappears, and to only log a config change message when
the config is truly changing.
Change-Id: Ifb2db77f8867435121722a6abeb946ec7c3ea9d3
* changes:
Make new attribute EXTRA_CHANGED_COMPONENT_NAME in broadcast intent ACTION_PACKAGE_CHANGED public so that apps like launcher can find out the changed component name when loading changes made in components.
* changes:
For intent ACTION_PACKAGE_CHANGED, there could be a lot of broadcasts related to enabling/disabling components by apps which could result in thrashing on the PackageManager. For apps that do not want to be restarted when such a broadcast is sent, we can just aggregate these broadcasts and handle them at one go. Changes include: New structure to hold pending broadcasts by class name. If a component is enabled or disabled frequently aggregate component enabled/disabled settings in this structure in a 10 second window and then send out the accumulated list of broadcasts to the ActivityManager. A new Handler implementation handles this message Add new attribute name EXTRA_CHANGED_COMPONENT_NAME in broadcast intent Intent.ACTION_PACKAGE_CHANGED for additional information for apps like Launcher. Rename a couple of parameters, the names were too jarring.
Merge commit 'c804efe278fa33555e6e836504a467cb14505eb3' into eclair
* commit 'c804efe278fa33555e6e836504a467cb14505eb3':
Update 4.xml to the most recent APIs.
In practice, no one ever writes an apostrophe in an aapt string with the
intent of using it to quote whitespace -- they always mean to include a
literal apostrophe in the string and then are surprised when they find
the apostrophe missing. Make this an error so that it is discovered
right away instead of waiting until late in QA or after the strings have
already been sent for translation. (And fix a recently-introduced string
that has exactly this problem.)
Silence the warning about an empty span in a string, since this seems to
annoy people instead of finding any real problems.
Make the error about having a translated string with no base string into
a warning, since this is a big pain when making changes to an application
that has already had some translations done, and the dead translations
should be removed by a later translation import anyway.
