- 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
Seems more appropriate as this more mirrors the normal release path.
I think everything gets release eventually either way.
Bug: 149591513
Test: Existing tests pass
Change-Id: I6f21d2723e06dbae4e09421efc352c179115bc40
We release the SurfaceControl assosciated with a Surface package
when accepting a new SurfacePackage, or at time of detached-from-window
this way we don't rely on the finalize method.
Bug: 149591513
Test: Existing tests pass
Change-Id: Ic0f7259394836ee094ed49db73b5986b778b450f
Adds more comprehensive callbacks and getters for the WindowInsetsAnimationController,
to make it more straight forward to properly use.
Test: atest InsetsControllerTest PendingInsetsControllerTest
Fixes: 151707442
Change-Id: Ida55f609112396c0f6de4c5c4431e0793c2e315e
Oversight, the SurfacePackage holds a reference to the SurfaceControl
which is protected by a close-guard. We need a way to close it
explicitly. Going to follow up with a patch to have SurfaceView
manage the lifetime when the SurfacePackage is consumed, but want
to make sure this explicit release gets in ASAP.
Bug: 149591513
Test: Existing tests pass
Change-Id: I7276a2440c38cc6d859b79b4c3ee57bc122ce2a6
We introduce SystemTCMetadata in ag/10605740 which centrializes the
needed information for the TCMS to process the requests. Because we
change the getPackageName() logic to return the calling package name
of SystemTCMetadata and the SystemTCMetadata is only created if the
event is from the SystemTC not other TCs. The tests fail because the
SelectionEvent.packageName is not populated.
This cl contains the following changes:
- Return the package name that the SelectionEvent or
TextClassificationContext originated from
- Fix incorrect javadoc of TextClassificationContext.getPackageName
- Always verify the calling package name for onSelectionEvent and
onTextClassifierEvent
Bug: 151614815
Test: atest TextClassifierServiceTest
Test: atest FrameworksCoreTests:android.view.textclassifier
Test: atest FrameworksCoreTests:android.widget.TextViewActivityTest
Test: atest CtsTextClassifierTestCases
Change-Id: Iabe1691d63e3ec6ac834984cf79b60faf9c0e765
The API requestUnbufferedDispatch allow View could receive the event in
unbuffered way. But doing processUnbufferedRequest in onInputEvent is
too late for the first event. Instead, we should pass the source of
the input event up to onBatchedInputEventPending, and then we can
use that to determine whether we could consume event immediately or not.
Bug: 149715123
Test: atest ViewUnbufferedTest
Change-Id: I4344a99de77d3758cc7d1df155394c89fa828f2e
1. libtextclassifier and libtextclassifier-java are no longer built
into framework/base.
2. Removed local text classifier code
3. Removed local text classifier test code.
All of them should be already moved to libtextclassifier/tcs side.
4. Unify all the TC related log tags to "androidtc".
BUG: 147412216
Test: mts-tradefed run mts-extservices
Test: atest frameworks/base/core/java/android/view/textclassifier
Test: Sanity test: Smart selection
Change-Id: Icb1076153f51d5674c8a6c58681ffed5aa772149
