This reverts commit 90bd36363c5738b3f526aa1f1d44f432236300a0.
Seems that the semantics of InputConnectionWrapper#setTarget() is more
complicated than I thought. At least the following cases have worked
fine.
case 1:
InputConnectionWrapper wrapper =
new InputConnectionWrapper(null, false);
wrapper.SetTarget(ic);
...
case 2:
InputConnectionWrapper wrapper =
new InputConnectionWrapper(null, true);
wrapper.SetTarget(ic);
...
case 3:
InputConnectionWrapper wrapper =
new InputConnectionWrapper(ic, true);
wrapper.SetTarget(null);
wrapper.SetTarget(ic2);
...
The previous code did not intended to break existing code. Let's revert
it we decide how to deal with above cases.
Bug: 27407697
Change-Id: I8bc84d484ab0b27a02e74f11110430f70646e69a
The default value of bluetotoh contact sharing is true.
So we should save when it is false.
Bug: 27410265
Change-Id: Icaf4ceeda09eca46d160acfecc53834819b66a18
bug:27381362
Also rejects ops with empty clip at record time, and short circuits clip
intersection, when one is empty.
Change-Id: I842612da14ad8fd9f1ba5e9e4fd027ba4e08d365
This CL makes it clear that InputConnectionWrapper does not support null
target. In other words, the semantics of null InputConnection can never
be emulated by a non-null InputConnectionWrapper.
This is particularly problematic when app developers are just forwarding
the return value of super.onCreateInputConnection() to
InputConnectionWrapper or its subclass, because there are many chance
that super.onCreateInputConnection() starts returning null, e.g. when:
A. the application is extending a Framework class, and the Framework
class is updated by OTA.
B. the application is extending system WebView, and the WebView is
updated.
C. the application is extending a 3rd party library, and the app
developer creates a new build with a new version of the 3rd party
library.
To make it easy to catch these kind of bugs, this CL lets the
constructor of InputMethodWrapper throw NullPointerException when target
is null. Bugs like crbug.com/571229 should be caught by developers
more easily.
Bug: 27407697
Change-Id: I83875bea886d4784f9507c930050efc29708d9db
...isUserAMonkey for testing purpose
Add an argument for the caller to specify if they are a poo flinging
monkey.
Change-Id: I0e149a8d78776abaf07517bd4ae886047b7f4252
Preference allows override of AudioPolicyManager.
Lets user force or prevent use of AC3 and DTS regardless
of what the EDID says.
Bug: 26373761
Change-Id: I21440f2b90af9a369a36b7b07724e992501bce6d
Signed-off-by: Phil Burk <philburk@google.com>
To allow static initialization of a number of View classes based
on TextView, refactor the initialization of the font cache to be
explicit from the zygote.
Bug: 27265238
Change-Id: I1b71086d3f49d8b3e72eea2bf8359351d25fc0fd
We don't have a vold connection early in the PackageManagerService
constructor, so we can only migrate the system user at boot. We now
migrate other users only after they're explicitly unlocked by
UserManagerService.
Bug: 27330415
Change-Id: I29f21714acf65a598b8df496af0f7d2cb1d247c4
Put the native allocation support into a holder class. This allows
statically initializing the classes in the boot image.
Bug: 27265238
Bug: 23130675
Change-Id: I857aebfdbaec39067a5eb58afceb49630176af98
Sometimes pointer change request is delivered after view is detached from its
ViewRootImpl. E.g. when popup is present click outside to close it.
Bug: 27292939
Change-Id: I925728af334a1e1ae53f7e530d639e50b0c37f2b
This CL updates the circular reveal animation to originate
from the gear and and done button in the inline controls.
Bug: 22451710
Change-Id: I050413c980a8c9e73fe2e9a789567051d3119373
The Keystore should be unlocked by the work challenge when
the work profile has its own lock, and should not be unlocked
by the device lock in this case.
Tested use cases:
When unified, both users have the password key set to the parent's
Setting a work challenge changes the work profile's password key to its
own
Unifying causes the work challenge key to be set to null first and then
when the device password is reset right after that it is reset to the
same as the parent
Unlocking when locks are unified unlocks both using the same password
key
Unlocking the device when not unified only unlocks the parent
Unlocking the work challenge only unlocks the work profile
Bug:26817206
Change-Id: I99dca279687f4f77636992e355dbdb607bbf7b6d
