This CL implements a mechanism to dump IME related client states into
a proto file which can later be imported to winscope to allow easy
debugging. A new abstract class ImeTracing.java declares the methods
related to scheduling, collecting and dumping logs. Two child class
implement these methods for server and client separately.
The Design Doc for the IME tracing project is: go/ime-tracing
Bug: 154348613
Test: start trace by calling "adb shell ime tracing start"
end trace by calling "adb shell ime tracing stop"
pull trace using "adb pull /data/misc/wmtrace/ime_trace.pb ime_trace.pb"
Change-Id: Ia89f11d5ef8a220ea7746191b18769cea5a8359d
The bounds on the client surface are controlled by higher levels of
the hierarchy and so the client can use whatever Surface size it wants
on its node. We move the SurfaceControl setSize call to the client,
following 3 sort of ideas:
1. Project to make relayout window async, but currently it is used as a
sync point for resizing, resizing on client, one problem solved!
2. WM Shouldn't do what it doesnt have to for clients
3. Totally move management of lowest level Surface to client
clean up lots of WM code (see WindowStateAnimator slimming project)
In the future maybe we don't need to set the SurfaceControl size at all
and the client can just set its buffer size, but it may produce some
differences in geometry handling on the server so I want to maintain
the old semantics for this CL.
Bug: 161937501
Test: Existing tests pass
Change-Id: Icebd94f8443fdbe9f0e6968bc35bbb0504a1520c
This CL removes
- mSeq
- System UI flags used to communicate between WMS and System UI
- redundant AIDL methods
- redundant fields and methods
- redundant tests
- PolicyControl
This CL also
- refines the format in DisplayPolicy#dump
- sends a boolean to InputManager to indicate if System UI is in a low
profile mode instead of sending the legacy system UI visibility
Bug: 149813814
Fix: 169105126
Test: presubmit
Test: dumpsys window displays
Test: See if the layout of ImmersiveModeConfirmation is as expected
Change-Id: I8c8df509355bebc9b560af57d5458614557bcd2f
Add support for submitting buffers in SurfaceView via BLAST using
BlastBufferQueue adapter.
Introduce a new config wm_use_blast_adapter_sv, that is disabled by
default to enable the adapter.
When enabled, the blast SC is created as a child of the main
SurfaceView SC and the main SC is set as a container layer. This layer
will continue to handle position, visibility and transforms while the
blast SC will handle buffer updates via the adapter.
Test: atest SurfaceViewBufferTests
Test: go/wm-smoke w/ & w/o adb shell adb shell settings set global use_blast_adapter_sv 1
Bug: b/168504870, b/168917217
Change-Id: I826eef39e03ea339df54400be0709eaba6c88797
This API allows the test to create
contention on AM, PM and/or WM locks.
Test: a prototype lock contention test
Bug: 168630376
Change-Id: I656b6b412d517cb3b3b16367d8712f78ccbc33d8
As CL[1] mentioned window focus behavior changes from R,
ignoring STATE_VISIBLE or STATE_ALWAYS_VISIBLE request doesn't enough
to fix unexpected keyboard visible issue when same window focused with
the above softInput flag without editor focus, since there is no
additional unspecified window focus to hide the current soft-input
as prior to R's behavior.
To fix that, we introduced new SoftInputShowHideReason to hide
soft-input when the same window focused without valid editor focus
after screen unlock, in order to align with the behavior prior to R.
[1]: I37ae6e30d1de581ba15131c2a90396b3a522a4d6
Bug: 161506356
Test: atest CtsInputMethodTestCases
Change-Id: I20e8076acc5fec3c055af0740e2e2a64b1fb6f0d
Forcing client to show system bars would clear system UI flags at the
client side. SYSTEM_UI_FLAG_LOW_PROFILE would be cleared as well in
previous Android versions. This CL makes the behavior compatible.
Fix: 167892531
Test: Steps in the bug
Change-Id: I466a05120a08ac95b619eadd8291fc546d3bb450
Bug: 166149440
Test: manual (flash automotive device with all system bars and show/hide
insets using WindowInsetsController), atest InsetsStateTest
InsetsStateControllerTest
Change-Id: I500b2fb0129739c6fc609561377d90cca6e45f7e
Bug: 165267251
Test: manual -- ensured that the time needed to hold is 0ms if the
screenshot_keychord_delay debug value is not set, and that the
delay can still be changed using
adb shell device_config put systemui screenshot_keychord_delay <ms>
Change-Id: Iab989ecf14ef379658130adbced241e084554e63
Merged-In: Iab989ecf14ef379658130adbced241e084554e63
(cherry picked from commit bf82822698)
Revert "Reland "Let InputFlinger create the server InputChannel""
Revert submission 12655292-hide-server-input-channel
Reason for revert: b/169173706
Reverted Changes:
Iefbfd9313:Reland "Let InputFlinger create the server InputCh...
I14837d545:Reland "Use new create/removeInputChannel()."
Change-Id: I2e002829ad2f077e1f118d0b09d274002b71afa9
Previously, the code would pause the renderer and then call
setNextTransaction. This was to ensure the transaction would
wait for the upcoming frame, not the previous one that may about
to get processed. This was bad becuase it slows down the renderer.
Instead, add a frameCallback listener to the renderer and call
setNextTransaction when the frame callback is invoked. This will
ensure that we only call setNextTransaction when the renderer is
ready to draw, ensuring the next frame in BLASTBufferQueue is the
correct frame to sync with the transaction.
SurfaceView doesn't need to check if VRI is in a blast sync transaction
since any call to PositionListener can be assumed to be a in a blast
sync. This is because SV requests to use blast sync when position, size,
or visibility changes.
Test: Youtube with BLAST enabled
Contains a SurfaceView that will force blast sync transaction
Test: SurfaceViewSyncTest
Fixes: 149747443
Change-Id: I3e42f87aa8473ee0ee65f23cc00db95f112b4f63
The way WM tell SurfaceFlinger not to screenshot certain layers is by
setting the window type WINDOW_TYPE_DONT_SCREENSHOT. This is a bit
confusing since window type represents the type of window. Instead, use
a new flag called SKIP_SCREENSHOT that is explicitly used to tell SF not
to screenshot this layer.
Test: Rounded corners aren't in screenshot
Test: SurfaceViewSyncTest with blast enabled
Fixes: 168943350
Change-Id: Iaafad35e7ce3d15ade25be18dde4862e2d126703
The application may get Resources instance from Resources.getSystem()
and context.getApplicationContext().getResources(). Since fixed
rotation is introduced that allows an activity to start in a different
rotation than the current display, when using getConfiguration() and
getDisplayMetrics() of these Resources instances, the orientation
and metrics need to be the same as current display is rotated.
Otherwise the app may show unexpected UI layout.
Although it is not recommended to use global resources/config for
activity. One of the goal of fixed rotation transform is to simulate
the app is started in a rotated environment, so this CL makes the
configuration and display metrics of system resources are consistent
with application and activity for compatibility.
About WindowProcessController and ActivityStackSupervisor:
The process configuration passed to LaunchActivityItem may be
associated from activity. if the sequence number of configuration
is overridden by activity, the configuration may be ignored when
launching the activity because the sequence number isn't larger
than the previous process configuration. Although there will be a
ConfigurationChangeItem later to update correct state, the app may
get the intermediate state with old configuration and metrics.
About ResourcesManager and DisplayAdjustments:
There are 2 new fields appWidth and appHeight added to
DisplayAdjustments#FixedRotationAdjustments because the display
metrics from Resources.getSystem() is independent from activity
configuration. Only window manager knows the rotated size, so
the values need to send to client and then ResourcesManager takes
the adjustment to change the global display metrics.
About WindowToken:
When fixed rotation is applied on the token, send the
FixedRotationAdjustmentsItem first so the later configuration
change can pick the adjustment at ActivityThread. And because the
registration of activity configuration only occurs on add/remove
activity, if it is only switching to another existing activity in
different orientation, the process configuration still needs to
be updated.
About ActivityThread:
The code flow for a rotated activity (DA = display adjustments):
- Launch new activity
handleLaunchActivity: override app DA
handleConfigurationChanged: adjust global display metrics by DA
performLaunchActivity
createBaseContextForActivity: override activity DA
- Resume existing activity
handleFixedRotationAdjustments: override app and activity DA
handleConfigurationChanged: adjust global display metrics by DA
handleResumeActivity
Also some minor corrections:
- Set missing rotated max bounds.
- Fix wrong display metrics adjustment that xdpi and ydpi should
not be swapped because they are physical attributes.
Bug: 167564038
Test: atest DisplayAdjustmentsTests
AppConfigurationTests#testRotatedInfoWithFixedRotationTransform
WindowProcessControllerTests#testProcessLevelConfiguration
DisplayContenTests#testApplyTopFixedRotationTransform
Change-Id: I60bedc7e09f54683d5e857ccc51402d5d144cd9e
This way we can restrict server channel in InputFlinger.
Also always use std::move() to move ownership when creating Java object
for InputChannel.
Bug: 167947395
Test: Touch events are still dispatched.
Test: WmTests:DisplayPolicyTests#testUpdateHideNavInputEventReceiver
Change-Id: I7033caf1015ec4bae65beab2c65bdeb4070f4775
Bug: 166149440
Test: manual (flash automotive device with all system bars and show/hide
insets using WindowInsetsController), atest InsetsStateTest
InsetsStateControllerTest
Change-Id: I500b2fb0129739c6fc609561377d90cca6e45f7e
This CL also refines the color view logic which checks the system bar
appearance instead of system UI flags.
Bug: 149813814
Test: atest InsetsAnimationControlImplTest InsetsControllerTest
InsetsStateTest InsetsPolicyTest InsetsStateControllerTest
Change-Id: I26d93b3508c84e436133085bd316ade54d00d76a
