If the surface gets destroyed, return -1 to indicate such that
the client can abort the animation, instead of crashing.
Test: With Launcher in multi-window
Change-Id: I4ab11557c40ed843a4c2e985a53cc2247b18b5fd
This reverts commit 4365cef6dd.
Reason for revert: Cannot access views by resource-id via uiautomator
Bug: 72271943
Change-Id: I5e07a8c5775aa79df0c240b2133daaf62f6d460b
Adds an option to use dp instead of px when specifying the cutout bounds.
Also centers the coordinate system in the middle, making it easier to specify
the usually centered cutouts.
Also makes the emulated cutout a bit prettier.
Bug: 65689439
Test: adb shell overlay enable com.android.display.cutout.emulation
Change-Id: I3bd16af15f1dad2af204d436abaa35fb9e5ae146
Allowing accessibility services to get the tooltip text
and show and hide tooltips.
Bug: 64836990
Test: Adding CTS tests for new APIs.
Change-Id: I91265594c5ac3ecbc9ae487c7d227a460773f920
Adding the ability to mark TextView as a heading, and
to provide a heading depth. Plumbing that through to
accessibility services.
Bug: 34687453
Test: Adding CTS tests for new APIs.
Change-Id: I5262e32a2a11b2577802c68e701d2856e28abc21
The prepareDrag() call is used by apps to ask the system server to
create a surface for drag shadow. Now the app creates a surface by
itself, thus we can reduce the method.
Bug: 70818582
Test: com.android.server.wm.DragDropControllerTests,
android.server.wm.CrossAppDragAndDropTests,
manually check the drag and drop behavior on test app.
Change-Id: Iae4acbff4f9ad68faa6324beb32bf9a28dcd67be
Previoulsy a drag shadow surface is created in the system process. App needs
to call one more binder call (prepareDrag) to obtain the surface from
the system process.
The CL lets an app to create a drag shadow surface by itself. Then app
transfer the surface to system server by using reparent
API.
Bug: 70818582
Test: com.android.server.wm.DragDropControllerTests,
android.server.wm.CrossAppDragAndDropTests,
manually check the drag and drop behavior on test app.
Change-Id: I72796efffbefe78a802d7c441dea308d1cdea572
Track bounds of an ActivityView and set them as a tap exclude region,
so that taps on this area won't cause a focus switch between
hosting activity and activities inside of ActivityView.
Bug: 63902362
Test: Manual with ActivityView test app
Change-Id: I3cdafe32e0bdf414507fef0d622d9c140eee3188
To make autofill works on non-touch device such as TV, allow
fill ui window to gain window focus. Fill ui window does not
need IME. When IME and fill ui window are both shown, fill ui
window will intercept keyevent before IME.
Since autofill window will steal window focus from app window,
we no longer uses View.onWindowFocused() for enter/exit event.
Switched to use Activity onResume/onPause. When view
notifyViewEntered or notifyViewExited called when Activity is paused,
it will be ignored. Before Activity goes to pause state,
notifyViewExited() is fired on focus view, after Activity leaves
pause state, notifyViewEntered() is fired on focus view.
In CTS testDatasetAuthTwoFieldsUserCancelsFirstAttempt, the
authentication activity finishes itself in onCreate() which will not
produce onPause/onResume in app activity, but it will produce window
focus loss/gain event. Since we switch from window focus to activity
onResume/onPause, we will be missing a show fill ui when return from
the never shown authentication activity. To solve this problem,
we added special code when receive ActivityResult from authentication
activity where we check if the authenticate activity never causes
onStop event, where we should issue an extra ACTION_VIEW_ENTERED
event to show fill ui.
Test: passed all existing autofilltest CTS on sailfish
atest CtsAutoFillServiceTestCases
Bug: 70181616
Change-Id: Iafe4dca3be8f049fa6dfd34bac13ccb030c583b6
This introduces a more stable way of setting a remote animation
than using overridePendingTransition: An activity can register
a set of remote animations which is broke down by transition type.
Whenever the activity is involved into such a transition, the
remote animation will be started.
Remote animations take precedence over regular animations, and
prefixOrderIndex in the hierarchy decides precedence within
multiple apps that set remote animation definitions such that
higher apps override lower apps.
Bug: 64674361
Test: go/wm-smoke
Test: Use with launcher
Change-Id: Id300ff62d9f60966ea2609168f6a02860b3de7af
Adds the ability for another app to control an entire app
transition. It does so by creating an ActivityOptions object that
contains a RemoteAnimationAdapter object that describes how the
animation should be run: Along of some meta-data, this object
contains a callback that gets invoked from WM when the transition
is ready to be started.
Window manager supplies a list of RemoteAnimationApps into the
callback. Each app contains information about the app as well as
the animation leash. The controlling app can modify the leash like
any other surface, including the possibility to synchronize
updating the leash's surface properties with a frame to be drawn
using the Transaction.deferUntil API.
When the animation is done, the app can invoke the finished
callback to get WM out of the animating state, which will also
clean up any closing apps.
We use a timeout of 2000ms such that a buggy controlling app can
not break window manager forever (duration subject to change).
Test: go/wm-smoke
Test: RemoteAnimationControllerTest
Bug: 64674361
Change-Id: I34e0c9a91b28badebac74896f95c6390f1b947ab
Content changes to panes are reported as window
state changes.
Changes to aggregated visibility are also reported
as window state changes.
Window state changes can now have content change
types.
Bug: 37479815
Test: Adding CTS tests in linked CL.
Change-Id: I35ef946398cac869b0f736708cb39ae96ab3ddb7
Replace the FLAG2_LAYOUT_IN_DISPLAY_CUTOUT flag with a
dedicated layoutInDisplayCutout field; given the change
in behavior of SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN with respect
to the display cutout, apps that request this now also need
a way to request the same behavior as FLAG_FULLSCREEN.
Broadly, there's three categories of apps:
1) Apps that want to make dedicated use of the cutout
area -> no letterbox ever
2a) Apps that hide the status bar, but don't expect the
cutout to be there cutting into their content
-> we want those to get letterboxed
b) Some apps may only be transiently fullscreen, but always
want to get letterboxed
-> we want those to get letterboxed even if not currently
fullscreen
3) Apps that never go fullscreen, and just draw the status
bar background in the cutout area (i.e. the most common type
of app)
-> these need to get letterboxed whenever the cutout and
status bar don't coincide (under our current guidelines
that's only in fullscreen and landscape)
To cover each use case, we have:
ALWAYS: Always allow the app to draw into the cutout, never letterbox it; covers 1
NEVER: Never allow the app to draw into the cutout, always letterbox it; covers 2a and 2b
DEFAULT: Allow the app to draw into the cutout if that area is covered by the status bar
anyways. This does the right thing for most existing apps (2a and 3).
Bug: 65689439
Test: atest PhoneWindowManagerLayoutTest
Change-Id: Ib8d551251e9be4ef9d580ca2151bf40a9678acae
This is a follow up CL to a recent CL [1], which aimed to move several
APIs only for InputMethodService from InputMethodManager to
InputMethodService.
This CL removes InputMethodService#hideSoftInputFromInputMethod(),
which is exactly the same as InputMethodService#requestHideSelf() that
is already available as a public API for IME developers.
This CL also virtually renames
InputMethodService#showSoftInputFromInputMethod() to
InputMethodService#requestShowSelf(), which has existed as a
private method but not been exposed to IME developers yet.
[1]: I3163f3cbe557c85103ca287bee0874a3b4194032
d8d03a8e1b
Bug: 70282603
Test: atest CtsInputMethodTestCases
Change-Id: If6a786c5774805d041ea9672ef2721e4a38df7fc
Otherwise, Checkstyle keeps nagging us with the following lint warning
whenever we touch the lines around them.
Must include @java.lang.Override annotation when {@inheritDoc}
Javadoc tag exists.
This CL also re-format the license header just to make Checkstyle
happy.
This is purely a no-op style change. There must be no behavior change.
Test: prebuilts/checkstyle/checkstyle.py -f frameworks/base/core/java/android/view/inputmethod/InputConnectionWrapper.java
Change-Id: I3d7cef4e6c1407a6c6d8ee75c0d8b75943d8701c
Otherwise, Checkstyle keeps nagging us whenever we touch lines around
them.
This CL also re-formats the license header and keep all the lines
within 100 colmun just to make Checkstyle happy.
This is purely a no-op style change. There must be no behavior change.
Test: prebuilts/checkstyle/checkstyle.py -f frameworks/base/core/java/android/view/inputmethod/InputConnection.java
Change-Id: Ie0f43f545d8056884c5d20a601d0a501187062c7
This is a safe refactoring that should have no behavior change in
terms of semantics and performance characteristics.
Test: make -j checkbuild
Change-Id: I30b40c483e490ff42c1c707233ca5cc7b67da28f
