Creating a new Boolean is wasteful since there's already a static
Boolean.TRUE and Boolean.FALSE. Using Boolean.valueOf will return one of
those static objects and reduce memory usage a bit.
Change-Id: Id497f951c8a894ec03ac6c3181e6055b56db9db4
There's a static Boolean.TRUE and Boolean.FALSE that can be used without
instantiating a new Boolean object unnecessarily.
Change-Id: I30a6c6514faae0ebeb6b571bf741db6814b8cc78
In the init loop, when all the accessories are detected the
state of previous accessory is overridden by the state of the
next accessory. Adding the one line change keeps the state of
all the detected accessories intact.
Change-Id: I4347d8daa27800426dcfb23aac199bed4add67de
Signed-off-by: Praveen Bharathi <pbharathi@motorola.com>
Move the check for selecting text before calling
the parent, so that the context menu isn't an
available option.
bug:3205306
Change-Id: I5d2c3f6b71c74cda56153fbc773eb5be98e44be7
This is the Holo version of the existing public Theme.Wallpaper.NoTitleBar.
It's needed for the video chat incoming call notification that comes up
when the device is asleep or locked. Bug 3202912
Change-Id: Idbef01541c4a7e5a6bbb678c7dedd6c95de1909d
Bug:3174399
If the page requests to scroll beyond the edge of the
screen, we send a message to try again on a draw, in case
our picture is out of date and the page should be larger.
However, sometimes we get stuck in a loop of retrying the
same scroll position over and over again. End this loop.
Change-Id: I53fcd4c2fa70c7ef63d4537d8b24eabb6b924b0b
The reason for this is that the CookieSyncManager might not be
initialized right after a webview is created since the initialization
is done with a message.
If someone creates a webview and tries to access a cookie right
afterwards that would cause an unintended exception.
This requires a change in external/webkit
Bug 3172863
Change-Id: I4f4f162253e2af09f63ee582bfce9f75ccf4037b
also add another public method to return mimetype for the given downloaded file
change is related to bug:3198355
Change-Id: I90bae443eec36968e0d533d9b07a514df369ac29
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
