To match Contacts edit UI mocks, the user long-presses on
the photo or display name to select a new primary. This
change provides the hooks needed over in Contacts.
This currently only works for a wallpaper that is larger than the
screen. Set the scroll position with the new wallpaper API. Right
now only does jump scrolls.
When performing a set of batch operations, some callers need
to enforce that a query has specific values. For example,
when persisting edited Contact values, we need to assert
that the RawContacts.VERSION matches the version we read out
through queryEntities().
This change adds a new TYPE_ASSERT that uses withValues()
and withSelection(), and checks all values when applying the
batch operation, bailing if any values don't match.
This adds a new theme for having a wallpaper, and fixes up the window manager
to do the right thing when transitioning between a windows with and without
wallpapers (between two windows with wallpapers is not yet addressed).
The wallpaper API now has callbacks to tell you when to start/stop animating.
Also fiddle the image wallpaper to be a little more interesting.
This is all of the basic pieces:
- The WallpaperService now creates a surface with the window manager for its
contents.
- There is a simple service that displays a bitmap.
- The wallpaper manager takes care of starting and stopping the service.
- The window manager knows about wallpaper windows and how to layer them with
the windows that want to be shown on top of wallpaper.
Lots and lots of issues remain, but at this point you can actually write a
wallpaper service, select it in the UI, and see it behind an activity.
* changes:
Mods to the ContactHeaderWidget to be able to have it display strings as passed in by the caller. For example we may want to use this in the case when there is no contact in a given circumstance.
Without this, it's really hard to debug exceptions coming
over from a ContentProvider. This is lightweight logging
that is only triggered by an exception, and doesn't write a
full stacktrace.
When RemoteViews inflates a layout and set of actions, it
uses a cloned remote Context so it can fully access the
resources needed to complete the inflate. However, in one
specific case when inflating the root view, LayoutInflater
calls back to the soon-to-be parent view to request the
correct set of LayoutParams through generateLayoutParams().
The default implementation of generateLayoutParams() uses
the Context of the /local/ View instead of the remote
Context being used for the inflation, which means that any
LayoutParam references in the root view are unresolved.
To fix this, we internally create our own copy of the target
remote Context. This way, when the remote LayoutInflater
calls generateLayoutParams(), we inflate it using the remote
Context to correctly resolve any references.
This change is required as part of http://b/2038594
Also, giving Presence.RAW_CONTACT_ID and Presence.DATA_ID unique ids to allow easy joining. The main rationale for this is that SQLite does not allow cross-database joins in VIEWs, so we cannot hide this join inside a VIEW.
