When Stylus handwriting mode is about to be used, automatically
subscribe IME to CursorAnchroInfo updates. This helps speed-up
stylus tasks in IME
Bug: 203086136
Bug: 210039666
Bug: 215533103
Test: atest CtsInputMethodTestCases
Change-Id: I3d6b1728d62139785593af14c24cb52bf2c91e31
Add an API for setting touchable regions. This API allows
a view hierarchy to allow touches to pass through its
surface in certain regions. Touch pass through of course
follows the regular rules about UID/PID origins and
touchable region does not effect the calculation of the
TOUCH_OBSCURED flag. Such an API has existed as @hide
since the beginning of time, via
ViewTreeObserver.ComputeInternalInsetsListener. The API has already been
wrapped in the IME system, and in VoiceInteractionSession.
Desire to make the API public is motivated by 3 use cases:
1. GameOverlayService UI code moving out of framework
required for their UX (multiple small buttons in a large
transparent overlay)
2. SurfaceControlViewHost: A common point request among
people who ask me about SurfaceControlViewHost is to be able
to embed the SurfaceControlViewHost in a SurfaceView which is
"setZOrderOnTop(false)" (hole punching) so that the host
hierarchy can draw on top of the embedded hierarchy in some
regions. This is possible today, but there will be no way
to receive input without input hole punching.
3. There may be cases where apps are using multiple Popup type
windows which could be combined in to one. In general reducing
HWC layer count this way will be a good trade off.
It was considered to ViewTreeObserver.ComputeInternalInsetsListener
directly but ultimately decided against it for a few reasons:
1. Obscure naming
2. Other fields not useful for our use cases.
Because insets/touchable region linkage not a useful API concept for
us
3. Forces dispatch model via callbacks which may or may not be
useful for a given app.
It was also considered to create a gatherTouchableRegion API mirroring
gatherTransparentRegion. Such a concept (as setting root surface
touchable regions) is not really composable though. For example
maybe a parent view requires touch regions, then a child view
one day starts removing them. The fact that input order is not
simply reverse drawing order (since parents come before children
in both) means there is no way to ensure this always cleanly composes
as expected. Given this, it's better to expose a "global" API
and require the app developer to understand how their components
are fitting together, rather than invite a View implementer
to subclass gatherTouchableRegion and allow someone to break them.
Bug: 213603716
Bug: 214239892
Test: SetTouchableRegionTest, SurfaceControlViewHostTests
Change-Id: Ie49caec964455b7129daa2aaa6990a368309f8e9
The frame number at the server side is not used anymore since BLAST.
Bug: 161810301
Test: presubmit
Change-Id: I01c6fb0750799aa94766f2582ce6ac031c9426cf
This is a step to move the layout logic to the client side. We won't
obtain the surface size from the server then.
This CL also moves the logic about adjusting the LayoutParams of
wallpaper to the client side.
Bug: 161810301
Test: presubmit
Change-Id: I3a81e174035c67a285cab449c0701ee2fe6f6a24
It was only used by ActivityView to forward IME insets, but ActivityView
is gone now. We should clean it up.
Bug: 161810301
Test: presubmit
Change-Id: Ib173112f2d668b0bb93ee2b5e639d236686846c1
This is a step to move the layout logic to the client side. We won't
invoke IWindowSession#relayout then.
Bug: 161810301
Test: atest WmTests
Change-Id: Ib5ac048a573907af0a81f3e228575d9458862cfd
This allows the app to set views as keep-clear areas, which the system
will avoid laying out floating windows over, like Pip or Bubbles.
Bug: 209577354
Bug: 209578131
Test: atest CtsWindowManagerDeviceTestCases:KeepClearRectTests
Change-Id: I02f72376b709c0534bd678b7ce66cd95cab41832
This was only in WMDisplayCutout, but it really is generic and we
plan to support rotating cutouts in the client.
Bug: 202201326
Test: DisplayContentTests DisplayCutoutTest
Change-Id: I75dc5e2296d096680e7660c98faf88b5cb1726e8
The physical key location is provided as a location keyCode pointing to a location on a US keyboard layout.
Bug: 179812917
Test: atest KeyboardLayoutChangeTest
Test: atest android.hardware.input.cts.tests -m
Change-Id: Ie1b424a0e0bfea2bc15b0b3a644f2f718f16094e
This is a step to move the layout logic to the client side. We won't
invoke IWindowSession#relayout then, and the client should be able to
set the transform hint on its own.
Bug: 161810301
Test: presubmit
Change-Id: Ib12a76fcc9906b3d9c487fb89bbe4520c682379a
Currently the API supports only starting or stopping the trace, and writes to file when the trace is stopped. However, in some scenarios we would like to maintain the trace active, and just dump the trace.
Bug: 205138504
Test: all API, check if files are created under /data/misc/wmtrace
Change-Id: Ia1d38ebcfd5a9d45e25bc7a29146aca54d4bdaf3
Previously the SurfaceControlFpsListener is a hidden API which only
allows platform code access. This patch renames it to follow the
callback convention and raises it to be a system API in order to allow
system applications to access the FPS count of a task and its children.
The FPS count access is guarded by a permission ACCESS_FPS_COUNTER.
To follow the API convention and properly check the permission, the
register/unregister callback APIs are moved to WindowManager and
permission check is done in the System Server.
Minor: Rename to SurfaceControlFpsCallback to TaskFpsCallback in order
to follow the API naming convention.
Bug: b/199920468
CTS-Coverage-Bug: b/199920468
Test: atest TaskFpsCallbackTest
Change-Id: I6b0a0ad6500278b3da09059e9c2ede28d9a743aa
This reverts commit 331be9a643.
Reintroducing ag/16366278 since it seems unrelated to b/214053959 (more details on b/214053959#comment55).
Original commit message:
Migrate unsafe parcel APIs in framework-minus-apex
Migrate the following unsafe parcel APIs in framework-minus-apex:
* Parcel.readSerializable()
* Parcel.readArrayList()
* Parcel.readList()
* Parcel.readParcelable()
* Parcel.readParcelableList()
* Parcel.readSparseArray()
This CL was generated by applying lint fixes that infer the expected
type from the caller code and provide that as the type parameter
(ag/16365240).
A few observations:
* In some classes we couldn't migrate because the class also belonged to
another build module whose min SDK wasn't current (as is the case for
framework-minus-apex), hence I suppressed the lint check
(since I'll eventually submit the lint check to the tree).
* In some cases, I needed to do the cast in
https://stackoverflow.com/a/1080525/5765705 to make the compiler happy
since there isn't another way of providing a class of type
Class<MyClassWithGenerics<T>>.
* In the readSerializable() case, the new API also requires the class
loader, that was inferred to by InferredClass.class.getClassLoader().
* Note that automatic formatting and import rely on running hooked up
to the IDE, which wasn't the case here.
Bug: 195622897
Change-Id: I272432e6e082a973f7a50492ec35d79c2b577c93
Test: TH passes
Deprecate HAPTIC_FEEDBACK_ENABLED in favor or HAPTIC_FEEDBACK_INTENSITY,
and VIBRATE_WHEN_RINGING in favor or RING_VIBRATION_INTENSITY.
Introduce hidden flag
VibrationAttributes.FLAG_BYPASS_USER_VIBRATION_INTENSITY_OFF
to represent HapticFeedbackConstants.FLAG_IGNORE_GLOBAL_SETTING in the
vibrator service. This is applied by:
- PhoneWindowManager, that converts HapticFeedbackConstants into
(VibrationEffect, VibrationAttributes).
- CellBroadcastAlertAudio, that triggers alerts using AudioAttributes
with flags FLAG_BYPASS_INTERRUPTION_POLICY (that translates to same flag
in VibratorManager, to bypass DnD) and FLAG_BYPASS_MUTE (that translates
to this new flag, to bypass the new alarm intensity settings).
The new flag is erased from request that are not from privileged apps,
similar to the other bypass flag. The public
HapticFeedbackConstants.FLAG_IGNORE_GLOBAL_SETTING has also been
deprecated in T with a documentation explaining the removal of platform
support.
Remove SysUI dependencies on the deprecated settings, it should use the
USAGE_TOUCH attribute and rely on the vibrator service to apply the user
settings.
Keep other SysUI dependencies that needs to run in older Android
versions (like Launcher3).
Bug: 185351540
Test: VibrationSettingsTest + manual
Change-Id: I0372e4db19e09523795d7e79b9f7a15ae48a8cd9
Add a new field EditorBoundsInfo in CursorAnchorInfo
and implement it.
Bug: 203086136
Test: atest CurosrAnchorInfoTest
Change-Id: I7f225fa1236534bbd18920f8ce8293df23ea2ce7
Currently, there is no way to construct a DisplayCutout with cutout
path.
Androidx and camera app need an way to create a DisplayCutout with path
data for testing and they can only access public API. For test purpose,
we add a public API for it.
Bug: 212191782
Test: atest DisplayCutoutTests
Change-Id: I3118b01447cb77df6245f76c9abcb01ef69e80ec
Create a BatchedInputEventReceiver that makes it easier to return
whether an event was handled.
Bug: 162194035
Test: build
Change-Id: I8d597189b786db6bb61f1d838a530cc573a42238
For the new style of Material 3 activity transitions (go/t-activity-transitions) we fully fade in and out activity windows to a solid background color (that of the activity's theme). This means we need to provide a way for activity transitions to show a solid background color behind the animating windows to fill any space that would otherwise be black. This ability should be available both to system transitions but also to apps that want to create transitions in a similar style without necessarily using exactly the system one.
The API provides a way to specify if a background should be shown behind
the animation or not. If a background is requested it is up to the
transition handler to drawn this background appropriately based on the
type of transition and task/activity info.
Test: atest CtsWindowManagerDeviceTestCases:AnimationBackgroundTests
Bug: 202844659
Change-Id: Iddee6583fb1ad83e3ec238a89030b8c284e04d03
