To diagnose race conditions like issue #25373872, we want to track
which input method client corresponds to IMMS#mCurFocusedWindow.
Note that IMMS#mCurClient does not always correspond to
IMMS#mCurFocusedWindow, because input method clients can report the
window focus gain only, without requesting to be bound to IME.
Bug: 25373872
Change-Id: Iad121669c0f3db4461245dc80ff3fdee469abb79
ContentProvider is a singleton of the process. So it may live longer
than Service. We could not close database when the service is destroyed.
BUG=25730042
Change-Id: I591250c1a1e7c5705eb2585c71cac2598c0c0fb9
Suppose the following case:
1. Launch an activity.
2. Focus in an EditText on the activity. IME is shown up.
3. Kill the activity process in a not graceful way, e.g.,
'adb shell kill'
After step 3, IMMS#removeClient(client) is immediately called back from
com.android.server.wm.Session, which is good, but we forgot to clear
IMMS#mCurClient to null.
Basically not clearing IMMS#mCurClient there is not so critical, because
1) we already have bunch of RemoteException check for the case where
IPC target is already dead, and in theory we cannot avoid this kind of
runtime error anyway, and 2) in most of cases new input method client
gains focus.
That said, in conjunction with other focus-related issues such
as bug #25373872, not cleaning that can result in the following error
message in 'input_method:' section of bugreport, which might be a bit
confusing.
Input method client dead: android.os.DeadObjectException
The primary goal of this CL is to make bugreport less confusing. Any
user/developer-visible changes beyond that is unintentional.
Bug: 25373872
Change-Id: Iee001ad9cce0c8c6324e3c0984be1e6f0e641d05
unhide ActivityOptions APIs for setting launch bounds for
an activitiy so apps can use it. Only works on devices that
support PackageManager#FEATURE_FREEFORM_WINDOW_MANAGEMENT.
Bug: 25499677
Change-Id: I75424681f25cbb9fe92f2ed73e6afbab765dab29
For light idle mode, our maintenance window is pretty short (1 minute).
Usually we have nothing to do in it... but sometimes we may want to
do a sync or download that takes more than a minute, and it would be
nice to not take the overhead of breaking that up in to multiple
windows.
So now we have a flexibile window, from 1 minute to 5 minutes. We
start out with 1 minute, and any window that uses less than 1
minute increases the available window by that amount for later use.
If we later use more than 1 minute, we correspondingly decrease
the next available window.
Change-Id: Ie273dbd5843b3aa4a3d5d9b2e420cda75517340f
The "appops" shell command is now just a wrapper around doing
"cmd appops", no more need to launch a Java VM!
Change-Id: I06fc68762d0ab95a016fb24db0affb0d91197588
When the configration changes there are two modes to handle it:
1. do through a onDestroy - onCreate cycle
2. declare that your activity can handle certain changed and handle them
in onConfigurationChanges
For most apps (1) is zero effort to implement, hence it is the default
behavior. You only want to do (2) if recreating your activity is
expensive.
As recreating the printActivity is expensive (and currently even
impossible) we want to handle the configuration change gracefully. There
is no code to be added as handling portrait mode / landscape mode switch
is not different from an orientation switch.
Bug: 25727559
Change-Id: Iac5b854c9dd080a4432957bc4551162dc3d480e9
'dumpsys input_method' does not generate useful information for
InputMethodManager#mIInputContext. It is currently just a default
output of Object#toString().
This CL overrides ControlledInputConnectionWrapper#toString() so that
we can easily understand whether this connection is accepting API calls
from the IME or silently droping those API calls. Note that
ControlledInputConnectionWrapper is not exposed to developers so
overriding #toString() has no effect for application developers.
Bug: 25373872
Change-Id: I89b9d4e15bc1569817bab4d1be429ac6e0462f14
The provider is installed early in ActivityThread to ensure that no
TLS objects are created in the application before the provider is
installed.
Change-Id: I5f77addfa75a4ee19301de54e01507d8dca33657
Introduced PathData in Java, which is effectively a thin layer around the
native instance. PathData holds the verbs and points which is being used
in path morphing/interpolation. The verbs and points can be interpreted
into skia path commands, which is now done in native and therefore saves
a handful of JNI calls during path creation.
Removed the old PathDataNode mechanism and changed the PathEvaluator
to use PathData instead.
Also added tests and a microbench. Also ran CTS tests for VectorDrawable
and AnimatedVectorDrawable, and passed all of the existing tests.
Change-Id: Ia166f5172ff031fe18b154327967f911a62caec1
