The ArrayEquals, ArrayHashCode, ArrayToString, and
ArraysAsListPrimitiveArray errorprone findings were
demoted from errors to warnings. Fix existing
occurrences of them so they can be made errors again.
Bug: 242630963
Test: RUN_ERROR_PRONE=true m javac-check
Change-Id: Ia6f216cc36ad0a5758f39fd9b34962cd4adf9d8e
The original patch reverted as commit
bc0d5539e6.
This patch only includes the part of refactors to make the calculation
of configuration around insets easier. The actual change of making extra
navigation bar treated as navigation bar and the fix of the UiDevice in
ui automator is in a separate patch to avoid being blocked and blocking
other changes for long.
Test: PlatformScenarioTests
Test: TaplTestsQuickstep, ThemeIconsTest, TaplTestsLauncher3
Bug: 238981445
Bug: 238985243
Bug: 238581838
Bug: 233945217
Change-Id: If966bcc8125300d47d5cd631f7db17ff027e5261
This passive window inset animation control listener
is used to for logging purpose when hide, show
method is called.
Test: atest InsetsControllerTest
Bug: 240192346
Change-Id: I399268ead9d04b356f10cc3e9ac1da9e31306e86
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
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
(cherry picked from commit 8945b5bcfc)
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
CL[1] changed toggleSoftInput behavior with checking the last IME
requested visibility by using
ImeInsetsSourceConsumer#mRequestedVisible to toggle IME.
However, ImeInsetsSourceConsumer#mRequestedVisible will be updated only
when:
1) The IME insets is controllable for the app.
2) The caller uses WindowsInsetsController#{show, hide}
Since by design when the app is in multi-window mode, SystemUI will
take over the insets control for synchronizing task resizing / IME
animation concern, so it ends up making the app unable to receive IME
insets control then affects toggling IME visiblity.
Even though toggleSoftInput has been deprecated since Android S, we
still requires to support its functionality for old apps run in some
platforms by default in multi-window mode (e.g. ARC++ in freeform
windowing mode).
To fix the issue, replace the check logic with
getRootWindowInests().isVisible(ime()) to check the last IME visiblity
from the root window the served view.
[1]: I390dc029e7bcc30c200926a9bfbbbd0268a1f714
Bug: 240886131
Test: atest KeyboardVisibilityControlTest#testToggleSoftInput in ARC++
Change-Id: Iaf7ccc17a7c02711000983db0d65ad095fe9f8fa
The getSfInstance usage on ViewRootImpl is target to reduce jank
when moving split divider, but legacy split is going to be depracated
and it didn't used on new split too so we can remove whole related
codes safely.
Bug: 222696368
Test: build pass
Change-Id: Id492c738942c2e01fce85c231350d16ef88242f5
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
