Several java files had the typo {#link (for cross-references to other
Javadocs) instead of the proper {@link format. This was confusing the
new doc publish tool (Mivi) since that's the format used for {# Django
comments #}.
Fixed a couple of links that had other errors (which prevented building
once the {# -> {@ was done) and other typos.
Replaced throughout the frameworks/base project; I'll need a separate CL
for the AndroidX fixes.
(Other files were not in the public Javadocs.)
Bug: 111925950
Test: make ds-docs
Change-Id: Ia06e1fffd814671289a1caebd5962aedc18a28d7
Original Change-Id: Ia06e1fffd814671289a1caebd5962aedc18a28d7
Exempt-From-Owner-Approval: Docs-only change
- Add a new flag indicating that the display should show
system decorations, such as status bar, nav bar, home and IME.
- Automatically launches home activity on secondary display
if the display support system decorations and home
activity has multiple instances supports.
- Remove ActivityStackSupervisor#mHomeStack and move several
home stack related methods to ActivityDisplay.
Bug: 111363427
Test: atest ActivityManagerMultiDisplayTests
atest com.android.server.am
Manual test on virtual display and chromecast
Change-Id: I48fe245ad12965a19a6768f5dbb4e974ce94b01a
Let each DisplayContent has its own focused window and focused app.
This change also moves the last tapped display to the top.
Test: atest ActivityManagerMultiDisplayTests
ActivityStackSupervisorTests
ActivityStackTests
CtsWindowManagerDeviceTestCases
DisplayContentTests
PointerCaptureTest
Bug: 111361570
Change-Id: I776cabaeaf41ff4240f504fb1430d3e40892023d
The magnifier is currently behaving badly when the magnified view is
scaled and/or rotated - the content of the magnifier and its position
are wrong, as we do not take these into account when computing
coordinates for content copy and magnifier positioning. This CL is
making the magnifier remain hidden when such transformations are applied
to the magnified view or a view above it in the view hierarchy.
Bug: 112519631
Test: manual testing
Change-Id: Ibb81fdc9d2ec8ba14914166e408c92a3aad7e312
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
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
(cherry picked from commit ce40498dc2)
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
