The surface size and thumbCenterX/Y use app's coordinate space, which
need to be scaled up on the server side.
Bug: b/239478191
Test: atest DragDropTest DragDropCompatTest
Test: am compat enable DOWNSCALED com.android.dragsource
am compat enable DOWNSCALE_30 com.android.dragsource
Change-Id: Id36caee8aa38885a95f8d237766ac968ef6c8f85
The native VelocityTracker has been refactored to allow support of axes
beyond X and Y axes. To conform to this change, we are updating calls to
the native VelocityTracker. Furthermore, to support independent velocity
tracking for separate axes, we are updating the native/JNI methods
accordingly. With these changes, supporting new axes for velocity
tracking would only require changes at the native VelocityTracker level
only (besides creating a public API for our clients).
Bug: 32830165
Test: android.view.cts.VelocityTrackerTest unaffected; touch fling works
Change-Id: Ib0be0fc38c315ade2475cd53597a846e58016d14
When window is removed, there can be a race between a11y and wm,
and sometimes A11yManagerService#sendA11yEvent cannot get a correct
display id.
There's also a case where a11y events for windowless windows don't have
a display id.
This change fixes the issue by populating display id in
A11yWindowManager#DisplayWindowsObserver for windows change events.
Bug: 240888087
Test: AccessibilityWindowManagerTest
Test: CtsAccessibilityServiceTestCases
Change-Id: I441d98e4431913ae24ab354423828d2a031b27b4
System apps can now register an InputDeviceBatteryListener on a
per-device basis to be notified of battery changes.
- InputManager manages registration of the binder callback with
InputManagerService to ensure that there is only one battery
listener per process.
- The battery listener is invoked immediately upon registration
to provide the initial battery state for the device.
- The callbacks are removed automatically when the process dies.
- This CL does not yet identify changes in battery state for monitored
devices.
DD: go/inputdevice-battery-notifications
Bug: 243005009
Test: atest FrameworkServicesTests
Test: atest FrameworkCoreTests
Change-Id: Idf2b06a099155a6f5cc13b55dcd40852f54aa56c
Basically, this removes an excuse for apps to use TextureView for video
playback or one-off HDR images prior to HDR UI being ready everywhere.
The idea is that for Z-above, applying alpha is easy, because the
surface just needs to be have alpha modulated. Z-below is a little bit
more creative - the alpha is applied to the hole punch and drawn using
DST_OUT blending semantics. This allows for views underneath the
SurfaceView to blend with surface, while being occluded by views on top
of the SurfaceView.
There may need to be some complex view hierarchies that would be useful
to test, but simple view layouts seem to work.
Note that this is guarded with a target SDK check, to defend against
applications that are propagated alpha to child views while expecting
opaque SurfaceViews.
Bug: 241474646
Test: HWAccelerationTest doesn't look broken
Change-Id: Ibc14b18f1ce6f25250318db50275c6b8c972bade
This a preperation CL before refactoring ImeFocusController.
To make dumpviewInfo can also be used in other IME related files
like ImeFocusController.
Also, removed unused method InputMethodDebug#objectToString.
This is just a mechanical refactoring and should not have any behavior
change.
Bug: 244504062
Test: build
Change-Id: I9d1a0c2b06e676e40b0e844edb18e8422a67b0ad
The existing Keyguard Occlude Animation Runner doesn't match the spec
for Dream in. It animates activity expanding from the center of the
screen. For Dream in, we have:
- Dream fading in
- DreamOverlay complications fading in slightly delayed, with each part
starting at different times.
This CL adds dedicated AppTransitionType and remote animation runner,
which animates Dream fading in. It doesn't implement the separate
animation for DreamOverlay complications.
Bug: 222507937
Bug: 240477956
Bug: 242864189
Fix: 240477956
Test: on device, wait for Keyguard to time out to Dream.
Change-Id: I5517ded2eea77ea962ca1551ed51dd997ff09993
Add @GuardedBy("mH") annotation for those Locked methods
which should be guarded by mH in InputMethodManager.
Bug: b/236937383
Test: presubmit
Change-Id: I271f78bc54c7cd406d56775aef0db9d6c4084ee0
In CL[1], we added @GuardedBy("mH") annotation for some
fields which should be guarded by mH for lock annotation
improvement.
Annotate more fields we miss in CL[1].
[1]: I3b345da25841b328358d16695e3a29ee65ae8d83
Bug: b/236937383
Test: presubmit
Change-Id: Ibee725dff3ff3d52f5b4d58e8bf2d8837dba665e
In InputMethodManager, we used the "mH" as a lock to
protect some fields and methods for thread safe.
Some of them are already protected with this lock but
they didn't have the annotation yet.
Add the annotation for those fields to prevent unexpected
behavior change and increase the readability.
Bug: b/236937383
Test: presubmit
Change-Id: I3b345da25841b328358d16695e3a29ee65ae8d83
When the program is run to unlockCanvasAndPost method,
if mSurface.unlockCanvasAndPost throws an exception,
the mSurfaceLock.unlock() will not getting the chance to execute.
If an app executes unlockCanvasAndPost in a catch and does not handle the exception,
it will remain locked for a long time after the next execution of mSurfacelock.lock.
make sure the msurfacelock.unlock is executed after unlockCanvasAndPost
bug:245050059 in partnerissuetracker
Change-Id: Ib849c840c61ac261cfaab0daefa7ae2afdbfcba3
Signed-off-by: xiaoxin <xiaoxin@xiaomi.corp-partner.google.com>
This stores the computed decor insets and frame excluding insets.
So it can save 99% time of recomputing the insets every time during
starting an activity. E.g. dozen times of "prepare display info/frame,
compute window layout of insets source windows, calculate insets"
becomes "get result from array".
The saved decor insets will be updated when:
- Display metrics is changed (DC#updateBaseDisplayMetrics).
- Insets provider is added/removed/changed.
Also
- Use DisplayCutout rather than WmDisplayCutout to simplify
passing the cutout between methods.
- Optimize getSourceProvider to avoid unnecessary object allocation.
This also fixes an issue that the display doesn't compute the latest
configuration when navigation mode is changed. Now it is fixed by
checking if the insets provider has layout changes and then recompute
screen configuration.
Bug: 238399969
Bug: 159103089
Test: atest DisplayPolicyInsetsTests DisplayPolicyLayoutTests
DisplayPolicyTests#testUpdateDisplayConfigurationByDecor
Test: Change navigation mode or display size (density) in Settings.
And then swipe-up or press home key, there won't be a
frozen effect (display configuration change).
Change-Id: If6c28a89939372e6362b92f469ef7d793e8ec215
Add visible line bounds to CursorAnchorInfo for IME to improve
scribe rich gesture recognization accuracy.
Bug: 215533103
Bug: 239843501
Test: manually tested
Change-Id: I7039b75388ae34d24feb38d18d8da9a91df89504
This provides a sandbox-like scaled environment on client side.
- This prevents the metrics and config from being scaled multiple
times because the entry points are only called from server side,
there won't have reentrancy for applying the scale.
- App's configuration callback method can get scaled config.
- If override scale is enabled, the legacy compat mode will be
skipped. That avoids mixing different approaches of scaling.
- Legacy compat mode is to simulate a 320dp x 480dp screen
size with density 160 (the surface scale and config scale
are different).
- Override scale is to downscale the app for better performance
(the surface scale and config scale are the same).
Bug: 238416387
Bug: 240335717
Test: atest ActivityThreadTest#testOverrideScale
Test: atest CtsWindowManagerDeviceTestCases:CompatScaleTests
Test: am compat enable DOWNSCALED $pkg
am compat enable DOWNSCALE_50 $pkg
Change-Id: I0ddf333996f229063511273f8aeb3867c9ba8bda
