Revert submission 19246592-accessibility-tool-only
Reason for revert: Jank regression b/242267091
Reverted Changes:
I0685e6dd4:CTS tests for the accessibilityDataPrivate propert...
I1c02af88c:Limit off-label accessibility access using a new p...
Change-Id: I701b811fd4fb2634872a759134356736a7e8b7dd
IWindowSession#relayoutAsync is similar to IWindowSession#relayout, but
the former is an oneway method which just sends the layout attributes to
the server. Since the client can compute its own window frame, it just
needs to send attributes to the server without getting blocked for
receving the window frame.
In somes cases, the client still needs to obtain things from the server.
Such as:
- When view visibility is changed. The client maybe not be able to
receive the latest insets state while it is INVISIBLE or GONE. In this
case, the client needs to obtain the frame and the insets state. Also,
the client need to obtain the surface control when it becomes VISIBLE.
- When the insets state is stale but the config is up-to-date. This can
happen when WindowProcessController sends the new config to the client
before WindowState does. In this case, the client needs to obtain the
window frame from the server.
- When the position and the size of the frame are both changed. This
will trigger a BLAST sync, and the client needs to obtain the sync seq
ID.
For cases above, the client needs to call the original relayout method.
Bug: 161810301
Bug: 175861051
Test: Seamless rotation, fixed rotation, and regular rotation.
Merged-In: Ifb365789fa08103773fd3180e486ba1d92042fc5
Change-Id: Ifb365789fa08103773fd3180e486ba1d92042fc5
Ensure that all uses of TRANSITION_ANIMATION_SCALE setting are bounded
between 0 and 20.
Bug: 238178261
Test: adb shell dumpsys window windows | grep "Animation setting"
Change-Id: I01aeeeddcbcdce0824d61db6b8f4a8946595131d
This reverts commit 9e3cd0533f
and commit 74c760394a.
Initially we made a change to address a performance issue
in SurfaceView caused by holding the mSurfaceLock whenever
we went though the updateSurfaces loop. This had a side
effects of causing an ANR since the locking order changed.
The followup fix removed the lock but broke some API
contracts around lock and unlock canvas.
Subsequent fixes, which never went into QPR, introduced
new issues. Changing the locking order is too risky
QPR so lets revert and try to rework the locking
mechanism in U.
Test: app in b/234006724 does not ANR
Test: app in b/235188096 does not crash
Test: app in b/239895124 does not ANR
Test: app in b/239142077 does not crash
Test: atest SurfaceViewTest
Bug: 235188096
Change-Id: I99c5bb707ecad7c8d3c1fbd8b4105a77d58c145d
The toolbar should set the theme to the app's theme. Because the
service cannot get the application context, we should pass this
information from application to service.
Bug: 218833400
Test: manual. Use light/dark theme for app, the toolbar shows with
the same theme
Test: atest TextViewIntegrationTest
Test: atest android.widget.TextViewActivityTest
Change-Id: I6d4e4e117c680ce57e760a87987059eded09b2bc
1. reset ViewRootImpl#mLastClickToolType for KeyEvents
2. move EditorInfo#mInitialToolType initialization so we dont
explicitly hold lock for one line of code.
Bug: 233108064
Test: atest CtsInputMethodTestCases
Change-Id: I76d3c4c14928a2eb4c1cda48dd3b9a866963d06f
In [1] & [2] we introduce auto-subscription for editor bounds to IME. However,
it is actually better for IME to do it due to following reasons:
1. Simpler for IMEs do it. Easier state management in IME as to
what is subscribed.
2. IME can subscribe to CusrosAnchorInfo as early as onStartInput(), which
delivers required CAI even sooner to IME resulting in faster
Handwriting startup.
3. We cannot predict what data IME may need. e.g. IME may not
implement Rich handwriting gestures and hence may not need line
bounds (Line bounds will be added in near future).
This CL essentially mechanically reverts [1] and a small part of [2]
No user observable behavior change.
[1] I3d6b1728d62139785593af14c24cb52bf2c91e31
[2] Ibba06e9a2533ca91c5cc215dfb18d21c9a74fb73
Fix: 238970465
Bug: 203086136
Bug: 210039666
Bug: 215533103
Test: atest CtsInputMethodTestCases
Change-Id: Ia72a9fe0ceac1798ee1989eaae3906e8e1b696bf
There are 2 cases that will seeing IME jumpcut when IME insets animation
is controlled by the app during IME prcocess being killed & restarted:
1) When IME process been killed for some reasons
(e.g. force-stop package ), during IME restarting,
DC#computeImeTarget will select the remote insets target as the control
target and deliver IME leash to WM shell. If the focused window is
not in multi-windowing mode, it may have a timing that IME surface
may unexpectedly shown when starting insets animation from the remote.
2) Previously CL[1] fixed an IME surface visiblity issue when enabling
shell-transition that related to somehow IME insets source visibility
out of sync with the actual IME surface visiblity. The CL fix is
setting IME surface alpha value according to the requested visiblity in
InsetsSourceConsumer#setControl as a workaround. However, this may
cause a side-effect that after IME restarted and leash updated,
when the app requests showing IME animation, system calls setControl to
the client to set the same leash after IME onPostLayout, then
applyRequestedVisibilityToControl will be called before the
insets controller calls setInsetsAndAlpha for the animation, if the
IME requested visibility has visible, IME jumpcut will happen.
To fix this issue:
For 1), returning null control target in DC#computeImeTarget for
the above special case.
For 2), with CL[2] can fully fixed IME visiblity issue by letting the
client know the initial visibility of an InsetsSourceControl and
correctly animate insets when delivering the new leash or the
visibility change of the InsetsSourceControl. for delivering same
leash to request animation case, adding a check to call
applyRequestedVisibilityToControl only when there is no running
animation.
[1]: Iaacdf5f57e68b928e2a19036cbd8a137cf320497
[2]: I2c02e97e191ebd83238c0c54908e861d200d4c8d
Fix: 239808087
Bug: 209064170
Test: atest DisplayContentTests InsetsSourceConsumerTest
Test: manual test steps in b/239808087#comment2
Test: manual test as steps in b/209064170
0) Enabling shell-transition
1) Launching camera app
2) Swiping camera app to launcher
3) Verify status bar appear animation works
Change-Id: I242517a9214b36049d94e89d1ee63ffe505b91ac
IWindowSession#relayoutAsync is similar to IWindowSession#relayout, but
the former is an oneway method which just sends the layout attributes to
the server. Since the client can compute its own window frame, it just
needs to send attributes to the server without getting blocked for
receving the window frame.
In somes cases, the client still needs to obtain things from the server.
Such as:
- When view visibility is changed. The client maybe not be able to
receive the latest insets state while it is INVISIBLE or GONE. In this
case, the client needs to obtain the frame and the insets state. Also,
the client need to obtain the surface control when it becomes VISIBLE.
- When the insets state is stale but the config is up-to-date. This can
happen when WindowProcessController sends the new config to the client
before WindowState does. In this case, the client needs to obtain the
window frame from the server.
- When the position and the size of the frame are both changed. This
will trigger a BLAST sync, and the client needs to obtain the sync seq
ID.
For cases above, the client needs to call the original relayout method.
Bug: 161810301
Bug: 175861051
Test: Seamless rotation, fixed rotation, and regular rotation.
Change-Id: Ifb365789fa08103773fd3180e486ba1d92042fc5
Naming of SoftInputShowHideReason#{SHOW,HIDE}_MY_SOFT_INPUT
constants may not clear enough to indicate its semantics.
Improve show/hide reasons of InputMethodService by:
-. Update constants naming to {SHOW,HIDE}_SOFT_INPUT_FROM_IME.
-. Introduce respective reasons to indicate different hide request
cases within IME process.
Bug: 224565148
Bug: 241890033
Test: presubmit
Test: atest CtsInputMethodTestCases and observe logs
Change-Id: I8b148e9b5ab05ff7b827c6b8fe23008ca30a8c4b
Merged-In: I8b148e9b5ab05ff7b827c6b8fe23008ca30a8c4b
Test: atest CtsContentCaptureServiceTestCases, observed events reported only once on scroll and stop as well as on fling
Bug: 211899037
Change-Id: Id67fcc360bf63fcab1d9f345c31d2bf7b9a173d6
In particular, these are to try and narrow down why the app window isn't
drawing in b/235463625 where the draw state for launcher is stuck in
DRAW_PENDING.
- mLastReportNextDrawReason: the reason the last draw was requested,
maybe useful in telling if wm is not requesting a draw if not set
- mLastPerformTraversalsSkipDrawReason: the reason perform traversals
returned without drawing (includes wm/predraw cancel reasons)
- mLastPerformDrawSkippedReason: the reason perform draw returned
without drawing
- mLocalSyncState: extra logging to confirm that the last sync actually
completes
Bug: 235463625
Test: dumpsys -T 60000 activity -v all
Test: dumpsys activity activities
Change-Id: I10118470fe62075920e9ce29fe449b0cfc8570c9
Merged-In: I10118470fe62075920e9ce29fe449b0cfc8570c9
WindowManager.LayoutParams doesn't override equals(). It returns
false if the instances are different. So after writing/reading
from parcel, even if the fields are identical, the comparison
of Arrays.equals(paramsForRotation, o.paramsForRotation) always
returns false.
This is the first step as a signal to decide whether the screen
configuration needs to be recomputed according to if there is a
layout change from decor windows.
Bug: 238399969
Test: atest FrameworksCoreTests:android.view.WindowParamsTest
Change-Id: I82582ff48064bbf009403d2c0980a69157860f90
In particular, these are to try and narrow down why the app window isn't
drawing in b/235463625 where the draw state for launcher is stuck in
DRAW_PENDING.
- mLastReportNextDrawReason: the reason the last draw was requested,
maybe useful in telling if wm is not requesting a draw if not set
- mLastPerformTraversalsSkipDrawReason: the reason perform traversals
returned without drawing (includes wm/predraw cancel reasons)
- mLastPerformDrawSkippedReason: the reason perform draw returned
without drawing
- mLocalSyncState: extra logging to confirm that the last sync actually
completes
Bug: 235463625
Test: dumpsys -T 60000 activity -v all
Test: dumpsys activity activities
Change-Id: I10118470fe62075920e9ce29fe449b0cfc8570c9
