Since the display cutout is a type of insets and the display cutout can
be obtained from WindowInsets, it makes sense that InsetsState has the
display cutout instance. In this way, we can send the display cutout to
client via W#insetsChanged instead of W#resized.
This can be a step to remove the class of ClientWindowFrames, and can
also be a step to make client compute its window frame locally.
Fix: 175858810
Bug: 161810301
Test: atest WindowAddRemovePerfTest ImeInsetsSourceConsumerTest
InsetsControllerTest InsetsStateTest ViewRootImplTest
WindowInsetsControllerTests ActivityRecordTests
DisplayPolicyLayoutTests LaunchParamsControllerTests
TaskSnapshotSurfaceTest WindowMetricsActivityTests
WindowMetricsWindowContextTests WindowMetricsTest
WindowFrameTests WindowStateTests WmDisplayCutoutTest
Change-Id: I9a930b1d2f7df3cea2b29629b767a4a5f31bca17
This change dumps information through IME tracing for the getter methods
exposed by the InputConnection interface. The dump is done through the
ImeTracing interface and is triggered by events in the wrapper classes
used to handle InputConnection implementations corresponding to:
- different apps
- InputMethodService
The new data is available under inputConnectionCall in the clients
output proto.
Bug: 154348613
Test: flash a device
start IME tracing by calling "adb shell ime tracing start"
end IME tracing by calling "adb shell ime tracing stop"
pull generated trace files and visualize in Winscope
or start tracing directly through ADB Connect and visualize traces
Change-Id: Iabd6af1b858803030848a0ef5e7dd9ecfc562716
Add InputConnection information to IME tracing. This change adds
only information about the text associated with an
EditableInputConnection instance: editable text, selected text, text
before and after the cursor (for a preset length) and cursor caps mode.
Test: flash a device
start IME tracing with `adb shell ime tracing start`
stop IME tracing with `adb shell ime tracing stop`
visualise the traces in Winscope and see the inputConnection information
Change-Id: I4dc6147fb7baa2cea413d2c44226e8c84c056c37
This change adds IntDef annotation to the gravity field in LayoutParams.
Bug: 173682107
Test: run `mp :framework-minus-apex-intdefs` and see that the Gravity
mapping was generated
Change-Id: I030241f72b07aeea0c625e5b557dfcc800f537d9
This change moves from dumping information of all Input Method client
instances to dumping only the current client, which is the one in which
the triggering event happened.
Bug: 154348613
Test: flash a device
start IME tracing by calling "adb shell ime tracing start"
end IME tracing by calling "adb shell ime tracing stop"
pull generated trace files and visualize in Winscope
or start tracing directly through ADB Connect and visualize traces
Change-Id: I46460d3d08947c7d37a8969a2fed6539f35aaf91
Optimized the tracing logic for the IME clients information. The
clients trigger a tracing dump through the new method triggerClientDump
exposed by the ImeTracing interface. This change was done
to be able to support custom dump for clients information and
custom dump from IMS.
This change only covers the clients information. The IMS and IMMS
information will be dumped in next changes.
Bug: 154348613
Test: start IME tracing by calling "adb shell ime tracing start"
end IME tracing by calling "adb shell ime tracing stop"
pull trace using "adb pull /data/misc/wmtrace/ime_trace_clients.pb ime_trace_clients.pb"
Change-Id: I499cb5f45a3e78912b09b9c6cedf1ce5443e797a
Added IntDef annotations to fields that missed them in
WindowManager LayoutParams: input_feature_flags,
system_ui_visibility_flags and subtree_system_ui_visibility_flags.
Bug: 160129453
Test: Run 'mp :framework-minus-apex-intdefs' and check if mapping files are properly generated
Change-Id: I66d6dcbff3b41175827c84c9fda68be92877925a
This CL removes a TODO comment from the IME trace proto because
there are no current plans of following with it.
Bug: 154348613
Test: nothing to be done
Change-Id: I629c4ced5aa1596be42f5550f5aef3b580ee4ac1
This CL adds proto2 files which declare the structure of IME related
server states dumps. These files are compiled into individual classes
which contain a fieldId for every field to be saved in the proto
dump file.
The Desing Doc for the IME tracing project is: go/ime-tracing
Bug: 154348613
Test: make and flash to see compiled classes
Change-Id: I673fb71d96ba5de2e8946f160d47ffe82198baa4
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
This CL adds proto2 files which declare the structure of IME related
client states dumps. These files are compiled into individual classes
which contain a fieldId for every field to be saved in the
proto dump file.
Bug: 154348613
Test: make and flash to see compiled classes
Change-Id: Ie11fae6be4abeaf00871c382fda43b033c321721
With Hierarchical animation, the animation layer will no longer
be a fixed fullscreen layer but animate on the parent container's surface.
In order to run a remote animation, the animation controller needs to
know bounds of the target relative to both its parent and the screen.
The CL includes:
1) RemoteAnimationTarget changes:
- Add localBounds field for indicating the target bounds which
the coodiates relatives to its parent.
- Add screenScreenBounds field to replace souceContainerBounds
to reflect the target bounds relatives to the screen.
- Mark position & sourceContainerBounds as deprecated.
2) Modified related places to set correct localBounds information.
Test: build / run, make sure installing the old version of launcher on
the this new platform change still compatible without crash.
Test: manual as follow steps:
- Launching app from launcher to split-screen secondary stack
- Swipe up to overview screen and drag TaskView to see if the TaskView
surface is shfted, expected is not.
Bug: 148780840
Change-Id: Id9dbf6de193ab73fe94bc24ef6a27edc93380a14
Introduce new APIs in Window/WindowManager.LayoutParams for developers
to decide which types of insets at which side a window should avoid:
setFitWindowInsetsTypes(@InsetsType int types)
setFitWindowInsetsSides(@InsetsSide int sides)
setFitIgnoreVisibility(boolean ignore)
The existing logic in DisplayPolicy.layoutWindowLw uses combinations of
window types, window flags, and system UI flags to decide what frames a
window should have, which is very complex, difficult to maintain, and
should be replaced with the new APIs.
Bug: 118118435
Test: atest InsetsSourceProviderTest InsetsStateControllerTest
InsetsPolicyTest WindowStateTests CommandQueueTest
RegisterStatusBarResultTest InsetsFlagsTest
LightBarControllerTest RegisterStatusBarResultTest
ViewRootImplTest DisplayPolicyLayoutTests
DisplayPolicyInsetsTests DisplayPolicyTests
TaskSnapshotSurfaceTest
Change-Id: I06ddc9d0d2887ba4ded7bb8adbf9c9c0da4bf7b4
FLAG_PRIVATE information is needed for cts on physical private display
Bug: 133794475
Test: -Build and flash (make -j framework; aae flash 1s)
- Add "Log.d(TAG, display.toString())" in code to print out detailed
information about display. (Note: Display class is imported from
android.server.wm.WindowManagerState.Display)
- Check "mFlags=.." is printed
Change-Id: I6481dff51b140d3a9320e1e92b06fff531ba34e9
Creates 2 APIs for apps to control system bars:
setSystemBarsAppearance - controls the appearance of system bars
setSystemBarsBehavior - determines how the bars behave when being hidden
by the application
Bug: 118118435
Test: manual - check if the appearance and behavior can be printed as
expected with dumpsys
(plan to add automatic tests later)
Change-Id: Ia6fe5f594960f218ff4e94ff481f514660dd5066
This adds a new transition classification for apps which are
switching between 2 visible states. The primary example of this
is windowing-mode change.
This new classification is mChangingApps in DisplayContent and
there is a transition type for TASK_CHANGE_WINDOWING_MODE.
The mode-change transition is scheduled when AppWindowToken
detects a windowing-mode change. It immediately creates
a snapshot and temporary leash to "freeze" the visuals of
the app until the animation starts (all transitioning apps
are ready).
The transition itself is a blend of fading, scaling, and
cropping based on whether the end-state is bigger than the
start state.
The RemoteAnimationTarget now includes a startBounds and an
extra "snapshot" leash for controlling the snapshot overlay
relative to the AppWindowToken. If either of those is
populated, the client of the RemoteAnimation can assume it
is animating a change and is responsible for transforming
the leash from the startBounds to its final state.
Bug: 113253723
Bug: 111762928
Test: go/wm-smoke + RemoteAnimationControllerTests
Change-Id: I8654656124b888950e55e31d88ce7a4101e935f8
A new value was added (26) and they were moved to WindowManager.java so
it makes sense to update the protos accordingly.
Bug: 112053626
Test: Android builds
Change-Id: Ia18287cc1d7cc77e132c24de7e79e65b412df763
Note: It is currently only safe to renumber the fields because we have
not started using them yet.
* animationadapter: added in http://ag/3709688, but was not following
the indentation policy or the unit naming policy. The durations that
have documentation in
frameworks/base/services/core/java/com/android/server/wm/ state that
they're in milliseconds. These durations didn't have documentation, but
I'm assuming they're in the same units.
* batterystats: was not following the indentation policy
* jobscheduler: AppIdleController was removed in http://ag/3699210 and
the proto was only partially updated
* powermanagerservice: BatterySaverStateMachineProto added in
http://ag/3763026 but was not privacy tagged and the indentation was off
* surfaceanimator: was not following the indentation policy
* remote_animation_target: was not following the indentation policy
* others: weren't following the indentation policy
Bug: 74975371
Test: flash device and run 'test CtsIncidentHostTestCases'
Change-Id: Id012f4690b1d58816fef096523e1a0ea2bccadb0
I left out the protos that aren't officially used in incident.proto in any way.
The notification captions are set in NotificationManagerService and
ConditionProviders. They're not set by the app at all.
Bug: 72393215
Test: flash device and check incident.proto output
Change-Id: I4b36e066740fa1e6755eb946e2bcfa4959d9f9db
For frameworks constants that don't have intrinsic meaning (i.e. their actual
value and order don't matter), so that it is unlikely that their values
will be changed:
This cl introduces proto enums representing some constants found in
the Android codebase, and connects the two.
By using the Proto enum as the source-of-truth, it means that Java and
proto can be kept in sync. Otherwise, when the Java frameworks code
changes, it silently breaks the protos from working properly, since the enums
are wrong. By having the Java code reference the proto enums, it ensures
that everything is in sync. The values of the constants are unchanged.
But future changes to these constants will need to be done in the proto
file, which the Java file merely references.
The protos are necessary for incidentd and statsd and, in the future,
possibly dumpsys. In this way, the logging mechanism is much less likely
to get broken when new constants are added, and we can be ensured that
the logging accurately reflects the underlying codebase.
Bug: 69478930
Test: cts-tradefed run cts-dev -m CtsStatsdHostTestCases
Test: cts-tradefed run cts-dev -m CtsIncidentHostTestCases
Change-Id: If79032c34b2799db1e3e70cb47b1312fd72092b9
Moving to the proto/.../server directory since PowerManagerService is in
com.android.server.
Extracting enums from other components into their own files.
Bug: 65750826
Bug: 65750806
Test: flash device and check incident.proto output
Change-Id: Ib91b7c08142fa66adf18b6e85106d4cbb5adf660
The rationale for this change:
1. When defining enum values for platform, we want to use the current
integers, in some cases zero is not defined, but proto3 enforces a zero
default value.
2. Android Metrics Team uses proto2 on server-side
3. When copying .proto to server-side, the known issue of dropping
unknown fields might affect if using proto3
4. Not much benefits from using proto3
Bug: 67110257
Test: manully generate incident report and it looks normal
Change-Id: Ia63e39de549a46683e9f80fcb74f1d771782b7f4
Implement enough functionality in protobuf dumpsys to replicate
old functionaltiy in android.server.cts.WindowManagerState
Test: cts-tradefed run commandAndExit cts-dev --module CtsWindowManagerHostTestCases
cts-tradefed run commandAndExit cts-dev --module CtsServicesHostTestCases
Change-Id: Ib527ab3f44620a08cf03b77c37c2bae883d90e13
