Set InputMethod.updateInputMethodDisplay as default method for fixing API
check.
Since this method is @hide & we don't want to enforece user to implement.
Bug: 116662257
Bug: 111364446
Test: atest CtsApacheHttpLegacy27ApiSignatureTestCases:SignatureTest#testSignature
Change-Id: Ifb136d86d19bc4f95154a9076d42326ce12f665f
Bug: 102591313
Test: Compared settings in light & dark UI modes with
force_dark set to true. Observed that force_dark fixes
were not present when UI mode was set to dark, indicating
force_dark was appropriately globally-disabled
Change-Id: I5882829bb5871829fc8fc9911682f52a6ba5f445
Historically ViewRootImpl#mContext has been just pointing to the
Context instance associated with whatever first View instance that is
being added to a Window. In other words, ViewRootImpl#mContext is not
owned by ViewRootImpl.
This can become a problem if ViewRootImpl is moved from a display to
another display with ViewRootImpl#updateInternalDisplay(), which was
added last year to support multiple displays [1], because there is no
guarantee that the target Contaxt that is pointed from
ViewRootImpl#mContext is also updated to have the new display ID.
In order to support multi-display we need to use the right Context at
least when interacting with InputMethodManager. Hence as a short term
solution this CL introduces ViewRootImpl#mDisplayContext so that the
right instance of InputMethodManager can receive callback from
ViewRootImpl. In this way, we can make sure that the behavior change
in ViewRootImple is limited to how InputMethodManager instance is
obtained.
Longer term solution will be discussed in Bug 116349163.
[1]: I9a9501cab788623ada15a31efb53e4b2378639fe
b047b8bd7e
Bug: 115893206
Test: atest ActivityManagerMultiDisplayTests
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: Ifa0ca24e9cf764caf492ee065606680b6a06751a
The java counterpart of the JNI is now moved to external/libtextclassifier.
Test: atest android.view.textclassifier.TextClassificationManagerTest
Change-Id: Ide5e58d1c80d9a028cea4e9192a91aeac2843c71
With this CL, no one in the Framework is using
InputMethodManager#getInstance() directly or indirectly. It is time
to mark this method deprecated.
For applications that still call InputMethodManager#getInstance()
directly or indirectly via reflection, they will start seeing warnings
with stacktrace in logcat.
Except for that explict warnings in logcat, there is no behavior
change in this CL. Added a new test to make sure that
InputMethodManager#getInstance() and InputMethodManager#peekInstance()
are still working in a way we expected for such applications.
Fix: 115891476
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: Ib393086d921f91993395b5f0007b725a5db7bf22
FillCallback.onFailure() was not working as intented - it finished the session
on AutofillManagerService, but didn't update the client state on
AutofillManager.
And both of these methods were displaying Toasts to the user, which is something
the autofill services could take care of. Hence, for services target with SDK
Q, the message is ignored.
Also added a new Autofill Metric: FIELD_AUTOFILL_MESSAGE_LEN
Test: atest CtsAutoFillServiceTestCases:android.autofillservice.cts.LoginActivityTest#testAutofillAgainAfterOnFailure
Test: atest CtsAutoFillServiceTestCases # to make sure it didn't break anything
Test: time mmm -j frameworks/base/:doc-comment-check-docs
Test: m -j update-api
Bug: 112192360
Fixes: 116103297
Change-Id: I499909200980943dedf1fc8524dd1f14b49e2158
In order to stub out InputMethodManager (IMM), currently layoutlib
tries to directly update internal details of InputMethodManager, which
is really fragile and hard to maintain.
With this CL, IMM officially defines an internal concept "EditMode"
and privately exposes internal APIs to layoutlib.
There should be no behavior difference in production build.
Bug: 115891476
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: Ide6aa5bc36c14449e87bec33a4962b87809b9d77
Somehow InputMethodManager#peekInstance() has not been thread-safe.
Although we basically do not care this deprecated method, but let's
just update it for consistency.
Bug: 115891476
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I56bf05f76a7939f004efefdd956776e533bae058
This is the last step to remove the dependency on IInputMethodClient
from WindowManagerService.
With my previous CL [1], now WindowManagerService (WMS) depends on
IInputMethodClient just because it implements lifecycle management of
IInputMethodClient on behalf of InputMethodManagerService (IMMS).
This CL mechanically moves that responsibility from WMS to IMMS for
better separation of concerns. It is a bit ironic that this CL is
partly undoing my previous CLs [2][3] that removed
IInputMethodManager.addClient() though.
This CL aims to preserve the current observable behavior (e.g. when
InputMethodManager instance is being created) as much as possible.
Most likely there would be no observable behavior difference when seen
from other components.
[1]: I444077b1e4af4033f67ab72c181fac85b601e08a
41f89c3bcc
[2]: I453200fd5847e9a78876affb6a1caec221525e1d
e24ed79edb
[3]: Id91dd600120e4981aa1d9005ce644728968430c9
fffc0e53c6
Fix: 115993358
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I7726c70613ea72d6e78fa5754e9fc840f0a40f11
InputMethodManager#sInstance is a long live static object so we have to
set its field with right value, otherwise any object referenced by it
cannot be gc including potential activity context.
Now InputMethodManager#mCurRootView is set to null in
InputMethodManager#onPreWindowFocus which is invoked when app's
ViewRootImpl received ViewRootImpl#W#windowfocusChanged from WMS.
However, in the ViewRootImpl#W#windowfocusChanged, mViewAncestor is a
weak reference which get() may returns null sometimes.
One scenario is the ViewRootImpl#W#windowfocusChanged is called after
ActivityThread#handleDestroyActivity. The activity is destroyed and its
ViewRootImpl get GC'd. Then InputMethodManager#onPreWindowFocus won't
get called and InputMethodManager#mCurRootView won't be set to null.
And it is a proper time to set InputMethodManager#mCurRootView to null
when the window it served dismissed.
Fix: 116078227
Test: Break at ActivityThread#handleDestroyActivity and ViewRootImpl#W#windowfocusChanged
Change-Id: I8fabb30f14bcb2cd7019e29b6642b4562d49d248
Signed-off-by: daqi <daqi@xiaomi.com>
When taking a full display screenshot, there's no longer a need for min
and max layer. Instead, the entire display will be screenshotted. If
only some layers should be screenshotted, then use the captureLayers method
instead.
Also, condensed the methods so there is only one screenshot method for
displays that returns a GraphicBuffer. SurfaceControl can then convert
it to the desired format, like Bitmap or Surface.
Test: Rotation, adb shell screencap, power + volume down, bugreport.
Change-Id: Ia5a293e89d2cf3811fd06ffcbafeee389a32840e
This is a preparation to allow InputMethodManager to have per-display
instances rather than the current per-process singleton instance.
When I introduced InputMethodPrivilegedOperationsRegistry [1], there
was an assumption that InputMethodManager was a per-process global
singleton object.
Now that we are going to break up that global per-process instance
into multiple per-display instances, having multiple
InputMethodPrivilegedOperationsRegistry instances probably does not
make much sense, because it would likely to increases the risk of
compability issues in existing IMEs. Although IME developers soon
really need to use the right Context to obtain the right instance of
InputMethodManager anyway, unnecessarily introducing compatibility
pitfalls that can be avoided in the Framework side is not my
intention.
With this CL, following 9 methods can continue to work no matter
whether InputMethodManager is a per-process singleton or not.
This is fine because those APIs had been mistakenly exposed in
InputMethodManager and already deprecated in favor of newly added ones
in InputMethodService.
* InputMethodManager.hideSoftInputFromInputMethod
* InputMethodManager.hideStatusIcon
* InputMethodManager.setInputMethod
* InputMethodManager.setInputMethodAndSubtype
* InputMethodManager.shouldOfferSwitchingToNextInputMethod
* InputMethodManager.showSoftInputFromInputMethod
* InputMethodManager.showStatusIcon
* InputMethodManager.switchToLastInputMethod
* InputMethodManager.switchToNextInputMethod
[1]: If762714b2003fa6477e1318110f63e13968c1d7e
eec552e9e9
Bug: 115893206
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I4a61470f06ffac5f7a512536f8431489db0108f4
This is a preparation to deprecate the following two methods.
* InputMethodManager#getInstance()
* InputMethodManager#peekInstance()
Since we soon need to stop relying on the current per-process
InputMethodManager singleton model to fully support multi-display,
those two methods really need to be deprecated.
With this CL, framework code no longer depends on
InputMethodManager#peekInstance(), which is also marked as deprecated
in this CL.
InputMethodManager#getInstance() is a bit tricky because it also works
as a constructor of such a per-process singleton instance. Remaining
two call-sites of this method will be migrated in a subsequent CL.
This is a mechanical refactoring, which in theory should have no
observable logical behavior difference.
There could be a small performance regression, but it is basically not
avoidable to correctly support multi-display scenarios.
Bug: 115891476
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest CtsWidgetTestCases:android.widget.cts.EditTextTest
Test: atest CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: atest FrameworksCoreTests:com.android.internal.inputmethod
Test: atest FrameworksServicesTests:com.android.server.textservices
Change-Id: I5db31491f3d47d3ad4a621e956995135c72e007b
We need to prevent apps from trying to decorate the permission grant
requests. Hence the the permission controller app (which will become a
mainline module) will need to set the
PRIVATE_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS private window flag.
Test: Built
Bug: 110953302
Change-Id: I7dfed6aac8ec487ac0665ad33c2892cad416224a
The AccessibilityManager is a singleton, so we need to update it everytime
an activity is resumed.
Test: manual verification with Chrome (CTS test is an overkill here)
Test: atest CtsAutoFillServiceTestCases # to make sure it didn't break anything
Fixes: 112690889
Change-Id: If011db203dee96ec511da80f4e49395c0340f482
Based on some analysis, these fields/methods are likely false positives.
Set maxTargetSdk=P so that any apps using them are required to migrate off
them in future. See the bug for more details.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
Also update the two common implementations using these:
Activity and Dialog.
BUG: 78245676
Test: make
Change-Id: If7b95b73df7dedb12210819d831ba7102344facf
This affects several files beyond those mentioned in the bug.
I didn't fix some instances because the files had code
problems that blocked presubmit checks.
Test: make ds-docs
Bug: 37094741
Change-Id: I642f0384fef2b267ebc970bae1b4fb90bae667e7
Exempt-From-Owner-Approval: Docs-only change
