The CL moves mChildren and mChildrenCount in ViewGroup to the dark-grey
list of APIs, disabling access to them for apps targeting Q. Developers
should probably use ViewGroup#getChildCount() and ViewGroup#getChildAt()
which exist since public API 1.
Bug: 117521014
Bug: 117521406
Test: atest core/tests/coretests/src/android/view/
Change-Id: I14d3ebd1b16edc92cd7b370404b1f05cd304ab7d
InputMethodManager has been a per-process singleton object. In order
to support behavior changes for multi-display support in Android Q,
however, InputMethodManager now needs to be per-display objects.
With this CL, context.getSystemService(InputMethodManager.class) will
start returning per-display InputMethodManager (IMM) instance.
Why?
There are two major reasons.
1. To support per-display focused window.
2. To support more simplified API for multi-session IME.
Currently per-process InputMethodManager instance directly receives
callback from ViewRootImpl upon windowFocusChanged, then it keeps
track of which Window is focused by storing its root view into
InputMethodManager#mCurRootView.
This design assumes that (within the same process) at most one Window
can have window focus, which is no longer true once we start
supporting per-display focused window (Bug 111361570).
Why we need to do this to support per-display focused window:
For traditional non multi-session IME cases (e.g. apps that use
Virtual Display APIs on phones), internal state of IMM can be easily
messed up once the system starts sending per-display
windowFocusChanged events to the same process, because IMM still
doesn't know that now each display has focused window. It is hard to
precisely predict what kind of issues we would see simply because such
a use case is most likely not expected in the original design.
Why we need to do this for multi-session IME:
For multi-session IME scenarios, in addition to the above concern in
InputMethodManager, the current design allows at most one IME session
per process. This means that if a process X is showing Activities to 3
different displays, only one Activity can interact with the
multi-session IME at the same time. If we do not change the current
design, the only way to work around is to ask app developers to
explicitly use different processes for each Activity, which may
require a lot of work (e.g. SharedPreference is not optimized for
multi-process use cases). This would also make multi-session IME
development complicated because the IME cannot know on which display
the IME is interacting until startInputOrWindowGainedFocus() is
actually called, and needs to do all the preparation and cleanup tasks
whenever startInputOrWindowGainedFocus() is called for a different
display than it's currently interacting with.
Alternative solutions considered:
Another possible approach is to update InputMethodManager singleton to
be able to maintain multiple mCurRootView and mServedView for each
display. This approach was abandoned because those fields and methods
are already marked as @UnsupportedAppUsage. I concluded that touching
@UnsupportedAppUsage things would have bigger compatibility risks than
per-display instance model.
Implementation note:
* Public APIs in IMM that take View instance as the first parameter
will verify whether the given View and IMM are associated with the
same display ID or not. If there is a display ID mismatch, such an
API call will be automatically forwarded to the correct IMM instance
IMM with a clear warning in logcat which tells that app developers
should use the correct IMM instance to avoid unnecessary performance
overhead.
* As a general rule, system server process cannot trust display ID
reported from applications. In order to enable IMMS to verify the
reported display ID, this CL also exposes display ID verification
logic from WMS to other system components via WindowManagerInternal.
* isInputMethodClientFocus() in WindowManagerService (WMS) is updated
to use top-focused-display to determine whether a given IME client
has IME focus or not. This is now necessary because with a recent
change [1] each display can have focused window. The previous logic
to check all the displays that belong to the given pid/uid [2] no
longer makes sense.
* Currently per-display InputMethodManager instances will not be
garbage collected because InputMethodManager#sInstanceMap keeps
holding strong references to them. Freeing those instances is
technically possible, but we need to be careful because multiple
processes (app, system, IME) are involved and at least system
process has a strict verification logic that lets the calling
process crash with SecurityException. We need to carefully
implement such a cleanup logic to avoid random process crash due to
race condition. Bug 116699479 will take care of this task.
Also to make sure that the performance regression (Bug 117434607) we
observed after my initial attempt [3] no longer exists, here are the
benchmark results with and without this CL.
testExpandNotificationsLatency on taimen-userdebug
without this CL:
results=[55, 46, 61, 67, 50, 48, 57, 50, 55, 63]
min:46.0, max:67.0, avg:55.2, median:55.0, std_dev:6.539
with this CL:
results=[45, 55, 58, 57, 47, 60, 59, 60, 56, 53]
min:45.0, max:60.0, avg:55.0, median:56.5, std_dev:4.980
[1]: I776cabaeaf41ff4240f504fb1430d3e40892023d
1e5b10a217
[2]: I8da315936caebdc8b2c16cff4e24192c06743251
90120a8b5b
[3]: I7242e765426353672823fcc8277f20ac361930d7
c53d78e992
Bug: 111364446
Fix: 115893206
Test: atest ActivityManagerMultiDisplayTests
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Test: No perf regression in LatencyTests#testExpandNotificationsLatency()
Change-Id: I78ad7cccb9586474c83f7e2f90c0bcabb221c47b
Before P, if startDragAndDrop is invoked twice, the system goes to wired state
where:
* the system server keeps processing the first drag operation.
* the application loses the drag token but keeps the user local state.
* cancelDrag() no longer cancels the ongoing operation.
* DragEvents are still delivered with the user local state.
At P we unintentionally changed the behavior to:
* the system server keeps processing the first drag operation.
* the application loses the drag token and the user local state.
* cancelDrag() no longer cancels the ongoing operation.
* DragEvents are still delivered without the user local state.
The CL fixed the behavior so that the second startDragAndDrop() calls
does not affect the internal state of drag and drop as it's failed due
to existing ongoing operation.
* the system server keeps processing the first drag operation.
* the application keeps the drag token and the user local state.
* cancelDrag() is still able to cancel the ongoing operation.
* DragEvents are still delivered with the user local state.
Bug: 113310888
Test: Manually invoke startDragAndDrop() and ensures the user local
state delivered with DragEvents is not cleared.
Change-Id: I0a8315a44d655a8a73b7034f340e50e2f50601a8
The perf regression found in my initial attempt [1] to instantiate
InputMethodManager (IMM) for each display revieled that when a Window
gained/lost focus,
getContext().getSystemService(InputMethodManager.class)
gets called for all the View objects that belong to the Window.
This CL introduces a private utility method
View.notifyFocusChangeToInputMethodManager()
to replace existing unnecessary acquisitions of IMM in View.java,
including the most concerning one View.onWindowFocusChanged().
There should be no negative side-effect in doing this optimization.
LatencyTests results:
testExpandNotificationsLatency on taimen-userdebug
without this CL:
results=[43, 46, 58, 47, 52, 59, 55, 59, 58, 46]
min: 43.0, max:59.0, avg:54.7, median:53.5, std_dev:5.967
with this CL:
results=[41, 58, 55, 59, 60, 67, 51, 55, 55, 55]
min: 41.0, max:67.0, avg:55.6, median:55.0, std_dev:6.344
[1]: I7242e765426353672823fcc8277f20ac361930d7
c53d78e992
Bug: 115893206
Test: atest ActivityManagerMultiDisplayTests
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Test: No perf regression observed in Bug 117434607
Change-Id: I5c64b23c3f5cb16f7f3fb9cdc2be063083566050
Removing the child whose visibility changed in
ViewGroup#OnChildVisibilityChanged causes a null pointer exception since
the parent is null immediately after. This CL prevents that from
keeping the parent stored.
Bug: 117520801
Test: remove child in OnChildVisibilityChanged, observe no crash
Change-Id: Ifd20c2fcba9aee476a7714794a90c7ec9a0b3b84
Also add a special API to set them. Internally they are still just
regular private flags
Test: Built
Bug: 116798569
Change-Id: I687b751fa18c7fbcc9bf95aa44d94d8a5614a88f
Previously we have added methods to manipulate color transform for each
surface, this patch exposes this API to Java code land for WindowManager or
display service to set the color transform.
BUG: 111562338
Test: Build, flash and boot.
Change-Id: I0388eed5d72b043820786264f060cde2bd7a6aea
Adding api to get touch delegate behavior for the
represented view of AccessibilityNodeInfo.
Bug: 80061718
Test: atest AccessibilityNodeInfoTest
Test: atest AccessibilityEndToEndTest
Change-Id: I2ae65d7d44fceaf16609e512c3384f766266ecbd
MotionEvent.otain function now can specific displayId.
Test: atest view.MotionEventTest view.KeyEventTes
Bug: 117471623
Change-Id: I5887a4443df6b238a51aba2dbbac994b2327ce68
InputMethodManager has been a per-process singleton object. In order
to support behavior changes for multi-display support in Android Q,
however, InputMethodManager now needs to be per-display objects.
With this CL, context.getSystemService(InputMethodManager.class) will
start returning per-display InputMethodManager (IMM) instance.
Why?
There are two major reasons.
1. To support per-display focused window.
2. To support more simplified API for multi-session IME.
Currently per-process InputMethodManager instance directly receives
callback from ViewRootImpl upon windowFocusChanged, then it keeps
track of which Window is focused by storing its root view into
InputMethodManager#mCurRootView.
This design assumes that (within the same process) at most one Window
can have window focus, which is no longer true once we start
supporting per-display focused window (Bug 111361570).
Why we need to do this to support per-display focused window:
For traditional non multi-session IME cases (e.g. apps that use
Virtual Display APIs on phones), internal state of IMM can be easily
messed up once the system starts sending per-display
windowFocusChanged events to the same process, because IMM still
doesn't know that now each display has focused window. It is hard to
precisely predict what kind of issues we would see simply because such
a use case is most likely not expected in the original design.
Why we need to do this for multi-session IME:
For multi-session IME scenarios, in addition to the above concern in
InputMethodManager, the current design allows at most one IME session
per process. This means that if a process X is showing Activities to 3
different displays, only one Activity can interact with the
multi-session IME at the same time. If we do not change the current
design, the only way to work around is to ask app developers to
explicitly use different processes for each Activity, which may
require a lot of work (e.g. SharedPreference is not optimized for
multi-process use cases). This would also make multi-session IME
development complicated because the IME cannot know on which display
the IME is interacting until startInputOrWindowGainedFocus() is
actually called, and needs to do all the preparation and cleanup tasks
whenever startInputOrWindowGainedFocus() is called for a different
display than it's currently interacting with.
Alternative solutions considered:
Another possible approach is to update InputMethodManager singleton to
be able to maintain multiple mCurRootView and mServedView for each
display. This approach was abandoned because those fields and methods
are already marked as @UnsupportedAppUsage. I concluded that touching
@UnsupportedAppUsage things would have bigger compatibility risks than
per-display instance model.
Implementation note:
* Public APIs in IMM that take View instance as the first parameter
will verify whether the given View and IMM are associated with the
same display ID or not. If there is a display ID mismatch, such an
API call will be automatically forwarded to the correct IMM instance
IMM with a clear warning in logcat which tells that app developers
should use the correct IMM instance to avoid unnecessary performance
overhead.
* As a general rule, system server process cannot trust display ID
reported from applications. In order to enable IMMS to verify the
reported display ID, this CL also exposes display ID verification
logic from WMS to other system components via WindowManagerInternal.
* isInputMethodClientFocus() in WindowManagerService (WMS) is updated
to use top-focused-display to determine whether a given IME client
has IME focus or not. This is now necessary because with a recent
change [1] each display can have focused window. The previous logic
to check all the displays that belong to the given pid/uid [2] no
longer makes sense.
* Currently per-display InputMethodManager instances will not be
garbage collected because InputMethodManager#sInstanceMap keeps
holding strong references to them. Freeing those instances is
technically possible, but we need to be careful because multiple
processes (app, system, IME) are involved and at least system
process has a strict verification logic that lets the calling
process crash with SecurityException. We need to carefully
implement such a cleanup logic to avoid random process crash due to
race condition. Bug 116699479 will take care of this task.
[1]: I776cabaeaf41ff4240f504fb1430d3e40892023d
1e5b10a217
[2]: I8da315936caebdc8b2c16cff4e24192c06743251
90120a8b5b
Bug: 111364446
Fix: 115893206
Test: atest ActivityManagerMultiDisplayTests
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Change-Id: I7242e765426353672823fcc8277f20ac361930d7
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
