This is a follow up CL for a recent attempt to minimize
the number of default enabled IMEs.
- part1: I831502db502f4073c9c2f50ce7705a4e45e2e1e3
- part2: Ife93d909fb8a24471c425c903e2b7048826e17a3
- part3: I6571d464a46453934f0a8f5e79018a67a9a3c845
- part4: I871ccda787eb0f1099ba3574356c1da4b33681f3
This CL removes following deprecated hidden public methods
from InputMethodUtils as planned.
- isSystemImeThatHasEnglishKeyboardSubtype(InputMethodInfo)
- isValidSystemDefaultIme(boolean, InputMethodInfo, Context)
- containsSubtypeOf(InputMethodInfo, String, String)
This is a pure code refactoring with preserving the current
logic. Hence no behavior change is intended.
Change-Id: I1ff994cbbdef83e1e907a0d88aa9ae09d45263b4
This CL adds the ActionMode.Callback2 abstract class and the rect
invalidate method needed to add the content rect API for Floating
Toolbars. It also extends the existing ActionModeCallbackWrapper in
DecorView to handle the case when ActionMode.Callback is provided
instead of Callback2, falling back to a default implementation.
Change-Id: Ia918ddfcfdf73d0e4cafd24c4a0573245d497cfe
We do not want to accidentally disable the user's currently-enabled
accessibility service(s); presumably they turned them on during
setup for a reason. We now merge the prior + current states rather
than simply replacing the current state with the former.
Bug 19427367
Change-Id: I96eb47df57318c88066c5da6862f23f656639148
We now back up & restore the set of enabled notification listeners. Post-
restore, a listener that had been enabled on the ancestral device will be
enabled on the current device as soon as it's installed, matching the
user's previous configuration. After this has happened the enable/disable
state for that app is not "sticky"; disabling it again will work as
expected.
The infrastructure for accomplishing this is general: it can be leveraged
by any ManagedServices derivative. There's a bit of extra wiring in the
settings provider to support the restore-time information flow as well.
This is because ManagedServices -- like many other parts of the system --
monitors writes to the settings provider and does work in response to new
writes of the elements that it cares about. Unfortunately this means that
there is no way to use the BackupAgent's restoreFinished() hook to post-
process the restored data: by the time it is run, the ManagedService's
observers have already executed and culled any unknown components from
the description that was just pushed into settings.
As of this patch, the settings provider's restore logic knows that a
particular settings element will require a message to interested observers
about the restore-driven change. The message is delivered as a broadcast,
and is sent after the new value has been committed to the settings db.
Adding other system ManagedService handling that parallels this will only
require adding a new corresponding entry to the table of individual settings
for which the relevant "this settings element is being restored" broadcast
is sent, found in SettingsHelper.
(It isn't sent for all settings elements because very few settings elements
have semantics that require it; 3rd party code won't be running yet during
platform restore anyway; and sending up to hundreds of broadcasts during
setup & restore is far from ideal.)
Bug 19254153
Change-Id: Ib8268c6cb273862a3ee089d2764f3bff4a299103
When an AudioPolicy with an AudioPolicyFocusListener gets registered,
notify it automatically of the current focus owner, i.e. the
top of the stack, if there is one.
Bug 19194917
Change-Id: I66fa141ce9550349d107288fc36ddab50898dc45
Suppress "automatic index on" warnings unless verbose logging is enabled.
Also suppress any notices.
Bug: 19773765
Change-Id: I4a4160e81e2cccf5119770182a64d6bbd9cc3505
Use themed context to inflate the action bar when AppCompat is used.
Also fix minor issues exposed as a result.
- Set project callback when LayoutInflater is created by
LayoutInflater.from(context).
- Remove duplication of code to get base context from context wrapper.
Bug: http://b.android.com/159711
Change-Id: I379ba2ba71c0ef547460987c3aa5db521c7de967
Also add API for voice interaction service to control
whether the system should hold a wake lock while it is
working with an activity (and actually *do* hold a wake
lock while doing so, duh!).
And while in there, clean up the launching wake lock to
correctly give blame to the app that is launching.
Change-Id: I7cc4d566b80f59fe0a9ac51ae9bbb7188a01f433
The constructor was public API, doh. Gotta do this differently.
This reverts commit 33c5b2a62f3e62382c41e24c6b527119978816a0.
Change-Id: Iadca87fe6a8866a8bd9d6f2a91578ec0d4c44691
