This error showed because DecorContext uses application context
to get WindowManager. This CL changes to use context to do so.
Also rename fields in DecorContext because we actually can pass any
context in "activityContext."
Note that most cases of misuse WindowManager is covered by [1].
We can guarantee that WindowManager can be obtained by mContext.
[1]:I52aa0c4a02b7da018aa10f1473e1616564296e41
Bug: 150632074
Test: manual - enable strict mode and check the error log not shown.
Test: atest DecorContextTest
Change-Id: I558a2819e5928a802b897a130cfc3262115b9935
Old APIs are kept and marked as @hide + @removed to maintain
compatibility.
Bug: 151262653
Test: manual verification
Change-Id: Ia50a1f87c194211be5256e948d43fb54c1cbf941
references during the Content Capture Sharing.
Motivation: if the remote app is killed, we don't want a possibility of
system server holding a stroing reference (through a reference chain)
to large objects in that app. Therefore what's send in the binder has to
be a weak reference. And we will store a hard reference to those objects
in the client app's static context.
Storing hard references to objects in system_servier is less critical, because that is not going to be killed.
Bug: 148265162
Test: covered by CTS tests
Change-Id: Ie561aab6019d191cf8659fb350e045089e7781ed
(cherry picked from commit 13f65b2974)
* So that autofill manager service can use it to control the IME
visibility to better support the inline suggestion workflow
Test: m -j, also manually verify with local changes
Bug: 152082216
Change-Id: I5c4b236bedeced8ff714090effce46161ee1170a
- Do not reset system bar visibility when changing control target
- Do not apply hide transaction when gaining control, because that
may result in a single-frame flicker because it will conflict with
the animation
- Check requestedVisible instead of InsetsState.isVisible in
DecorView to avoid drawing the bar backgrounds transiently
- Abort transient mode when focused win changes.
Bug: 150195782
Bug: 152014877
Change-Id: I8bc9cdc89ce7364984ade8146e12a706ad5e8edb
On the other hand, since we won't be able to get the callback from
TaskOrganizer when an activity (used to be in PiP mode) is removed,
reset of the reentry bounds is kept in WM.
Bug: 152549281
Test: manually enter/exit PiP
Change-Id: I8b4b7f87c4a7601d8bdf32af8105a68450012a87
Before, the documentation said that the passed context is an application context, which is incorrect to get the density, window metrics, and window manager. We should use visual context to get these instead.
Bug: 151474461
Test: StrictModeTest#testIncorrectContextUse_GetViewConfiguration
Change-Id: Iea28d727cafbb3ec8536742c6a0e594f73fe5a51
This patch introduced setCaptionInsets, and set the Insets in
ViewRootImpl when dispatch the insets if there's a caption.
Modification is made in Window and DecorCaptionView to make caption
overlay with the app content, and pass the value to ViewRootImpl to
apply when dispatch. It is necessary to trigger a dispatch when caption
enabled status chanaged, otherwise sometimes it will not be updated.
Because caption is now updated locally on the client side.
Some old logic to deal with the overlay caption without insets are
removed, including the touch event dispatch override, the color
override.
Bug: 134531136
Test: go/wm-smoke
Test: Manually change the value in dispatchApplyInsets, can observe a
blank content area when there's a caption bar.
Test: atest InsetsStateTest
Test: atest InsetsControllerTest
Change-Id: I356344a13c8569512d8f51f7ea19a5603f778252
- This prevents a flash of black if we show the surfaceview again
after it is hidden
Bug: 152134983
Test: Ensure no flash if previous background color was set and it is
made visible again
Change-Id: I04d0222521c902da6d29e99ccdbd0aa8ad49917e
...otherwise developer will get onApplyWindowInsets which don't
match end value of animation. Super confusing
Test: InsetsControllerTest
Bug: 152071027
Change-Id: Ic1819512a5ce78843433bf7c231d062e12de0e7b
Normally we rely on the Activity stack to set this for us. Many use
cases require acceleration to be usable, we don't want
to expose the layout params in the public API so instead we just make
HARDWARE_ACCELERATION the default.
Bug: 152103238
Test: SurfaceControlViewHostTests
Change-Id: I767d351b0e5278642ae61074b47f01d185c026c8
Use case: Jetpack WM will use them to get the location of windows on
screen and compute the display feature positions in window coordinate
space.
Bug: 150908045
Test: atest FrameworksCoreTests:WindowMetricsTest
Test: atest CtsWindowManagerDeviceTestCases:WindowMetricsTests
Change-Id: Ia08950cd5df35971408e8b17bb27d97d29d0ab9b
Exempt-From-Owner-Approval: API change
- Prevent unnecesary dispatchApplyInsets caused by legacy system
also requesting inset changes
- Make insetsModified oneway. It's safe to do so because we
absolutely don't care about interleaving with other WindowSession
methods.
- Do not trigger layout if nothing relevant has changed
- Only trigger requestFitSystemWindows if state actually changed
Test: Systrace. Automated perf test will be added
Bug: 151865131
Change-Id: I24944875e739e4a74606e3a02bbf14585c1c13db
Window management files on the client side have normally been dumped in
either android.view or android.app package. This CL starts to
centralized them in android.window package so there is better
separation.
Test: they pass
Bug: 147406652
Bug: 152113464
Bug: 152117221
Change-Id: I4d64bd256e9b3581af0ccf9396f7dd2454132719
If long press timeout is not 'short', we disable deep press.
Also InputManagerService.java will now be responsible for keeping track
of the feature state.
In ViewConfiguration, we update the default value to 400 to match the
value in the settings (b/30159825)
Bug: 148311342
Bug: 30159825
Test: see the description in the frameworks/native change
Change-Id: I88b933e9e863d40e383afdc990e09b848e23192e
Merged-In: I88b933e9e863d40e383afdc990e09b848e23192e
This reverts commit 4f6b8ec056.
Reason for revert: Can not repro memory regression in R, b/134695730
Test: atest google/perf/memory/memory-test
Bug: b/119839070, b/73813813
Change-Id: Ibe560942949d3b37cd6d43ab49148cbf401e0e39
Based on feedback from developers (GBoard) there are cases
where they want the app UI to cover the suggestions during
animations (keypress popup should cover the suggestion area).
This change adds a dedicated InlineContentView that is
returned when a suggestion is inflated. This view has APIs
to dynamically move its surface above/below the host window.
Also the new InlineContentView has no public constructors
as these are always created by the system via other APIs.
Finally, the InlineContentView only exposes the surface
control of the inlined UI which is useful for reparenting
to achieve clipping of multiple such views in a given area
on the screen.
When the content surface is below the app window it is not
be interactive and all touches go to the hosting app. In this
state the app can draw on top of the suggestions. When the
content surface is above the app window it is interactive
and the hosting app cannot render on top of it.
While at this this also fixes the case where a surface can
cover the suggestion surface even if it was on top of the
app window. Now if the embedded content surface is covered,
even partially, by another one the embedded UI is not
interactive.
bug:15140337
Test: atest AutofillTestCases
Change-Id: If1db185506ae6916b9d655ab647dd59b626cf61e
