Do not ramp volume if the first frame of a track is processed after the track was stopped.
In the case of very short sounds, the track stop request can be received by AudioFlinger just after the start request before the first frame is mixed by AudioMixer. In this case, the track is already in stopped state and initial volume is applied with a ramp for the first frame processed which should not be the case: initial volume change is always applied immediatelly.
Merge commit '2a2058f5a31e3bace3d0284fb1259a9ddcbec3a5' into eclair
* commit '2a2058f5a31e3bace3d0284fb1259a9ddcbec3a5':
Add updated API diff based on 4.xml.
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.
