Actually being able to configure a wallpaper relies on additional
work in the launcher and wallpapers that will be in another change.
Also note that this breaks all existing wallpapers, since they now
need to include a meta-data item about themselves. This also
will be fixed in another change.
Change-Id: I97d2c2bd07237abc32f92b9147c32530a2f73c71
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
* 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.
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
It first looks to see if there is an activity that is managing the dialog, and if not,
follows the context / contextwrapper chain to find an activity if possible.
Fixes http://b/issue?id=2064772.
Remove the old notions of changing the viewing mode
resulting in changing the visibility of the title bar.
Instead, attach the title bar to the top of the page.
Change contentToView() to contentToViewY() (and an X
version; same change for viewToContent), to account
for the title bar's height. Adjust the parameters
for drawing the scroll bar to account for the title bar.
Requires a change to packages/apps/Browser.
Change-Id: Ic0f7d6e0a1cce58ba2bca87337cf72a8194e9aa4
This is needed to allow the BugReportService to start the dumpstate service.
Change-Id: I12cab23767c919592da102c654b6b80416717661
Signed-off-by: Mike Lockwood <lockwood@android.com>
