with the current locale, not previous one, every time it is possible.
Add a unit test verifying this fix.
BUG: 2514026
Change-Id: I4dd1b047e1ab4bf399e2c3ebc0304c0cfa3a0928
AbsListView shouldn't update mLastTouchMode in onTouchModeChanged;
it's only used in onWindowFocusChanged and since onTouchModeChanged
gets called first, the current and last modes will never be different
to trigger the right code path.
Change-Id: Ic9bc454c87826622df54417801fd8f13213c480e
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
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
Shelling out to logcat from the system server makes me queasy,
so this is turned off by default -- it must be enabled individually
for each error type (system_app_anr, etc) via a secure settings
value (which I plan to poke into from gservices for internal use).
Even when enabled, it happens in a side thread, unless the system
server is about to die anyway (system server restart).
Change-Id: Id6d88bcd78d3625f0364a5fe9c771046601a5a14
