Rewrote SurfaceFlinger's buffer management from the ground-up.
The design now support an arbitrary number of buffers per surface, however the current implementation is limited to four. Currently only 2 buffers are used in practice.
The main new feature is to be able to dequeue all buffers at once (very important when there are only two).
A client can dequeue all buffers until there are none available, it can lock all buffers except the last one that is used for composition. The client will block then, until a new buffer is enqueued.
The current implementation requires that buffers are locked in the same order they are dequeued and enqueued in the same order they are locked. Only one buffer can be locked at a time.
eg. Allowed sequence: DQ, DQ, LOCK, Q, LOCK, Q
eg. Forbidden sequence: DQ, DQ, LOCK, LOCK, Q, Q
- The logic for emitting "FN" is wrong.
- FileWriter's "double close" problem should occur in the current implementation.
- Let VCardParser_V31.java ignore AGENT field instead of throwing an unkind VCardNotSupportedException.
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
The check for whether the release call is coming from another process was
very broken, and just happened to work by chance. It also never worked for
apps that had code running in two different processes, with one process
using a provider in another of its processes. Also a little cleanup and
debugging logs for provider management, and removal of that increasingly
annoying log about services being stopped.
Change-Id: Ibc298e674db7d35c4b6499fb32e30929a141b670
* changes:
Integrated the profiler into the framework. We run it all the time if the persist.sampling_profiler system property is set. Saves snapshots to the SD card.
Also, introducing a more advanced email filter, which will do a proper name
lookup using the normalized name and avoid returning duplicate results.
Also, upgrading the phone filter to do the same thing as the email filter
but with display names and phone numbers.
The current API requires a contact_id and a raw_contact_id
There are at least two issues with this approach I did not recognize initially:
1. Contact_id may be changed asynchronously by aggregation or some other process.
2. A raw contacts may need to be added to an aggregate before the actual aggregation pass
has gotten to it, so the client would need to wait for the aggregation to complete
before it can set an aggregation exception. That's backwards.
This is work on the transitions with wallpapers. There are now new
animations specifically for leaving the wallpaper and returning to
it, which allow us to have a consistent animation when entering home
and returning to it. I also renamed the existing animations across
wallpapers, and cleaned up some junk in the various interpolators.
This also now hides the wallpaper surface when it is not visible,
to get rid of the wallpaper flickers people complained about albeit
in a somewhat brutal way. :) (Though really returning us to the
previous behavior with the same previous bugs and name back to them
not being very visible, yay!) There is are also some bug fixes
here and there about managing the wallpaper visibility that this
change revealed.
Change-Id: I913990a9a81651728122ed2e1101b75ed2c36fcb
Rename addTitleBar to setEmbeddedTitleBar. This requires a change
to packages/apps/Browser. Also remove mTitleBar if there already
was one.
In ViewManager, call contentToViewDimension where appropriate.
Change-Id: If4d378fad192990253411924a9a80bee96e63ff2
have a bigger minPrefWidth than the screen width. So we don't want to force
the minZoomScale to be same as defaultScale. Otherwise we won't be able to
zoom out in these sites.
Fix http://b/issue?id=2090718
