Fix for http://b/issue?id=2511581
Also call delete instead of deleteHistoryWhere, since we are only
considering non bookmarks anyway.
Change-Id: I00c052db3d27d61592688e7a160e721d5f82b210
There is a potential threading issue where an app could call release()
on two threads. This hack adds a static lock object that serializes
access to the Java fields that contain the pointer to the native
AudioRecord object and weak reference to the Java object. Also
modifies finalize() to call release() so that both use the locking
scheme.
Change-Id: I09dcb19b7f501dc582e40e8718142b493eba2518
Bug description:
1) Start Car Dock app.
2) Drop phone into Desk Dock
3) Press back to quit Desk Dock app.
Car Dock Notification doesn't go away if I select it from the shade.
Change-Id: I9d3ad4dbbe8f886fc8d523d104676194c3943473
compiler built-ins so this change should not negatively effect the
generated code. However, a forthcoming commit will remove the
implicit include of strings.h from stdlib.h and bzero will no longer
be visible in these translation units without additional includes.
Change-Id: I8080fbcaabad4ff280163515168e4af5cd0a7112
Fixes bug #2507582 by doing the following:
- Un-@hide the FLAG_ALLOW_BACKUP, FLAG_KILL_AFTER_RESTORE, and
FLAG_RESTORE_ANY_VERSION mask constants in ApplicationInfo. These
correspond, respectively, to the <application> manifest tag's
android:allowBackup, android:killAfterRestore, and
android:restoreAnyVersion attributes.
- Remove the android:restoreNeedsApplication attribute and the
corresponding FLAG_RESTORE_NEEDS_APPLICATION constant [which was still
marked @hide]. We now always use the application's own Application
class when performing a normal restore. In the future when we support
an externalized full-filesystem backup/restore operation, we will use
an OS-defined agent class with a base-class Application instance, but
this will not happen until a future release.
Also expands real documentation on the above ApplicationInfo constants;
that work is part of bug #2465360
Change-Id: I735d07a963ae80a01343637d83bef84e4c23fdcc
This change removes the legacy notification of orientation and configuration changed events
from KeyguardUpdateMonitor and moves them into the individual activities. This was necessary
to guarantee order of events.
In addition, to minimize discrepencies due to notification lag, Keyguard screens (LockScreen,
PatternUnlock, etc.) are now responsible for handling onConfigurationChanged() notification and
forwarding them to LockPatternKeyguardView by a call to recreateMe() with the new configuration.
Change-Id: I703daf3e91bc6588e87c844a3ed3d259a6b8ecdf
Bug shows we lost contact with the phone service. We used to leave the notion of enabled alone
in this case, but that can lead to being out of sync (the mobile data connection may be
alive or come alive but if we think it is dead we ignore it). Changing our
notion of its enabled-ness to 'enabled' means we'll pay attention to its messages going forward,
and since after a reboot it starts enabled we'll actually be in sync.
bug:2323057
Change-Id: Ie080b50d764e6879e712507aceb68f585f12f94e
Fixes issue #2437252: Starting activity by means of startActivityForResult
causes 5 seconds delay if "android:windowIsTranslucent" is true
The optimization to avoid showing an activity window when a new
activity is being started was a little too aggressive. Now it
avoids doing this if there is not actually a fullscreen activity
on top to cover it.
Change-Id: I630e37a1f1d3b874b5a25572cbf887cebc2e3e91
Added a onDestroy method to do the callbacks cleanup.
Apologies for the line end whitespaces my editor removed
automatically.
Bug:2090959
Change-Id: Id3ea4b8fc38e55c1b1ef78b3ec5b81cb02ab5b69
In change I5776324a I made DataConnection.reset asynchronous.
That was a mistake as callers to cleanUpConnection assumed
it was synchronous. Added DataConnection.resetSynchronously
as a fix, someday the trackers will become asynchronous and
this won't be necessary.
Change-Id: I4669901e5c47a712212bb388c35fbb9f9ff603a7
