This change list:
- simplifies the UI design to reduce the number of
on-screen items by combining Alarm status with the date line.
- updates many of the layout files to match closer to the
final design.
- Simplifies the logic for showing Status1 info. It's now
more predictable and robust.
- updates the layout for tablets
- contains a modified alpha to work well with different backgrounds
(Tested: white, gray, and dark backgrounds)
- updates the tablet icons to something closer to the final size.
Manual merge from Change-Id: Ifb349dfa778e9c91b0649c8d95229607be5af8e5
Change-Id: Ia2a9a2d285102d0208b3a7fcead58d6454d116ae
Some restore passes bring an ancestral dataset to the application, but
others instead act to bring an app back into sync with its own most-
recently-saved data. In the latter case the state file written by the
app after the restore is a correct basis for generating future backup
deltas, but in the former case it is not.
The app should not be required to distinguish between these cases;
the framework has all the information necessary to handle the saved
state correctly following any flavor of restore operation. This
patch makes the Backup Manager properly cause a full backup pass
following an ancestral-dataset restore. After a current-set
restore the saved state file is an accurate description for
purposes of continued backup operations, so is preserved.
(Cherrypick from master to gingerbread)
Change-Id: I4bc4e8782a168ecc0795107a340bdbb35060730e
The public API is not supposed to require the BACKUP permission in order
for an application to restore its own last-known-good backup data. However,
as currently implemented, BackupManager.requestRestore() [the public API
in question] depends on private Backup Manager methods that *do* enforce
that permission. The net result is that the method cannot be successfully
used by third party applications: it will throw an exception if attempted.
This CL restructures the permission checking involved.
First, the underlying beginRestoreSession() operation can now be passed a
'null' transport name; if this is done, then the restore session is begun
on whatever the currently-active transport is. Looking up the name of the
active transport is one of the permission-guarded actions that was required
with the initial implementation.
Second, a package name can now be passed to beginRestoreSession(). If
this is done, then the restore session can only be used to perform a
single-package restore of that one application. The BACKUP permission is
not required if the caller is tying the restore to its own package name.
In combination, these changes permit BackupManager.requestRestore() to
function without the calling app needing to hold any special permission.
The no-permission case is intentionally quite narrow: the caller must
hold the permission unless they both (a) pass 'null' for the transport
name, thereby accepting whatever the currently active transport is, and
(b) pass their own package name to restrict the restore session only
to their own app.
External bug http://code.google.com/p/android/issues/detail?id=10094
Internal bug 3197202
(Cherrypick from master to gingerbread)
Change-Id: Ie20b0bd2420345ce6eda178f854680b558f6372a
The reason we need a separate latch is that
AsyncTask will post onPostExecute/onCancelled
_after_ executing mFuture.get(). The previous
implementation would only wait for mFuture.get()
to complete and not the entire task.
Change-Id: I96964591980965148eb09af38b5838bfa5d28277
There was already a mechanism for sending out events for LayoutTransition
when animations started or ended, but the implementation only sent out events
for the appearing/disappearing animations. This fix provides callbacks to
listeners for the CHANGE_APPEARING and CHANGE_DISAPPEARING transitions, too.
Change-Id: Icfb8cc1c20d2df3e4a817255e96c9d0e94c1d8c4
