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
Change-Id: Ibc9d652323f2da03727d850f991b4096af6520d2
Rename method that was missed in previous ActionBar
refactoring. Deprecated previous version for compatibility for apps in
development.
Change-Id: I2c466aed8ed620aec5056026257e131fadf8843e
for programmatic scrolls
Allow for onScrollStateChanged implementations that end up changing
scroll state again.
Change-Id: I53105f5be708bacc0d3ec8e76ba1cc22f4131467
launch a new fragment on the same call.
There were some problems with the API design where you could do
things in such a way that a back stack entry that was not at the
top would get popped. Ouch. Hopefully this change prevents that
from being able to happen.
Change-Id: I8cbc952e12ddd231ff6c84b6e9bbf5125f449f04
The different bandwidth streams may not all start on the same seqnum, so switching bandwidths may fail lateron if we start playing from the very beginning.
Change-Id: I03df8d1f44b3f7b4713d381a3d97847997e3ee59
related-to-bug: 2368598
The audio mode MODE_IN_CALL signals the system the device a phone
call is currently underway. There was no way for audio video
chat or VoIP applications to signal a call is underway, but not
using the telephony resources. This change introduces a new mode
to address this. Changes in other parts of the system (java
and native) are required to take this new mode into account.
The generic AudioPolicyManager is updated to not use its phone
state variable directly, but to use two new convenience methods,
isInCall() and isStateInCall(int) instead.
Change-Id: Id744cd26520ea1d1a4795eabe6a1f0c58789af76
Programmatic scrolls fail when the scroll has not had a chance
to start. In this case, the current position equals the last
position; the logic erroneously cancels the scrolls, assuming
that in this case the scroll has finished.
Also, new scrolls should cancel the old velocity whether they
are animated or not.
This has a companion change in external/webkit, which is not
required, but makes tap initiated scrolls work more reliably.
bug:1331125
bug:3099569
Change-Id: I80ae8e8cdefce2d8d09532f79d1b2e1ae4738fa6
