- Remove mTopCallback field
- Cleanup compat and default callbacks
- Remove the callback held by WindowState when the window is removed.
Bug: 218328707
Test: atest packages/apps/Launcher3/tests/src/com/android/launcher3/ui/TaplTestsLauncher3.java
Test: atest frameworks/base/core/tests/coretests/src/android/window/WindowOnBackInvokedDispatcherTest.java
Change-Id: I38fd760a617500c874aef10bc8de165880837008
For pre-T apps, the default back callback dispatches KEYCODE_BACK to the
application's root view.
For T+ apps, the default KEYCODE_BACK listener invokes the registered
OnBackInvokedCallback.
Test: m -j
Bug: 195946584
Change-Id: I62342b249e6cd6f8b036f7e950cc3f9754418ee4
This CL enable OnBackInvokedCallback to be saved in a WindowState and
queried by the BackNavigationController to be returned when
ATM.startBackNavigation() is called.
The DecorView provides a PendingOnBackInvokedDispatcher that can receive
callback registration before being added to a ViewRootImpl.
Test: atest FrameworksCoreTests:BackNavigationTest
Bug: 131727607
Change-Id: I01528a22ea4a6583a56ade4eab69136d727855d0
This reverts commit 5f415e6190.
Reason for revert: Fixed the underlying issue
BUG: 217335654
Test: verified on forrest
Change-Id: I599ed7c6ed8f3483b68653cfb35ddb1effb01efb
Bug: 162194035
Test: manual: "adb shell am crash com.android.systemui" and observe its
gesture monitors are removed through dumpsys input
Change-Id: I02a480dd8e4b98a9911d976de2684d283c9e7d8b
Change the wording of the method's Javadoc to be clear and align with other comments for similar methods (like View#setHapticFeedbackEnabled).
Change-Id: I51f45f98ea5ae0a58a6e6a03dcc9e5b96f33a3a1
Test: N/A - comment change only
This is required for the go/t-activity-transition (https://direct.googleplex.com/#/spec/241720001&247800001) which we want to use as the default transition for T
Test: atest FlickerTests
Bug: 202844659
Change-Id: I316ddfb937953cf462ac999b8d27ae4cb0128847
Provides an API for windows to extend themselves outwards during
animations. In contrast to the scale animation the activity is not
distorted but rather the surface is extended outwards by the specified
amount without modifying the original window. The new "extension" space that is added is filled by clamping the edges of the surface. In the future the API could be extended to support different modes of filling the extension areas if required.
This API allows for the extension amount of the window to be animated
much like a scale or cliprect animation is, by providing a starting
amount for the extension and transitioning to the end amount by the end
of the animation.
This is required for the go/t-activity-transitions (https://direct.googleplex.com/#/spec/241720001&247800001) which we want to use as the default transition for T.
Test: atest CtsWindowManagerDeviceTestCases:AnimationEdgeExtensionTests
Bug: 202844659
Change-Id: Ic21e139fe329c271e71abdc6e77714c49365d5d6
As discussed in Bug 201375975, the nevigation bar handling for
floating IMEs is a bit tricky.
This CL tweaks DecorView behabior only when
InputMethodService#canImeRenderGesturalNavButtons(),
is true and the IME is floating in the gestural navigation mode.
Fix: 215550296
Test: Manually tested with ThemedNavBarKeyboard sample
1. Build aosp_coral-userdebug and flash it
2. adb root
3. adb shell setprop \
persist.sys.ime.can_render_gestural_nav_buttons true
4. adb reboot
5. make -j ThemedNavBarKeyboard
6. adb install -r \
$OUT/system/app/ThemedNavBarKeyboard/ThemedNavBarKeyboard.apk
7. adb shell ime enable \
com.example.android.themednavbarkeyboard/.ThemedNavBarKeyboard
8. adb shell ime set \
com.example.android.themednavbarkeyboard/.ThemedNavBarKeyboard
9. Open the Dialer app
10. Focus in the top edit field.
11. Tap "FLOATING MODE" mode
12. Make sure that the navigation buttons are visible.
Change-Id: Ia54499a3c2ac6e33e72f625eba3477fd81649d32
This is a follow up CL to my previous CL [1], which introduced a
hidden callback method into Window.Callback.
This CL does not change any observable behavior but consolidate that
hidden callback into a newly introduced Window.DecorCallback
interface. In this approach, we no longer need to worry about
accidental method name collision in Window.Callback implementations
classes.
Here is the new callback chain.
ViewRootImpl#performTraversals()
-> DecorView#onSystemBarAppearanceChanged()
-> Window.dispatchOnSystemBarAppearanceChanged()
-> NavigationBarController.Impl#onSystemBarAppearanceChanged()
[1]: I08566034bebfafff6777ce0152cd6ca1f66f6cad
678ddce11c
Bug: 215549533
Test: Manually tested with ThemedNavBarKeyboard sample
1. Build aosp_coral-userdebug and flash it
2. adb root
3. adb shell setprop \
persist.sys.ime.can_render_gestural_nav_buttons true
4. adb reboot
5. make -j ThemedNavBarKeyboard
6. adb install -r \
$OUT/system/app/ThemedNavBarKeyboard/ThemedNavBarKeyboard.apk
7. adb shell ime enable \
com.example.android.themednavbarkeyboard/.ThemedNavBarKeyboard
8. adb shell ime set \
com.example.android.themednavbarkeyboard/.ThemedNavBarKeyboard
9. Open the Dialer app
10. Focus in the top edit field.
11. Tap "EXTENDED LIGHT NAVIGARION BAR" mode
12. Make sure that the navigation button color is optimized for light
navigation bar.
13. Tap "STANDARD LIGHT NAVIGARION BAR" mode
14. Make sure that the navigation button color is optimized for light
navigation bar.
Change-Id: I5168f76dfc9526e925c565dbfa87597b5543fcdc
Adding API and changes to incorporate boot-time resolution HAL APIs
Bug: 209598222
Test: atest CtsBootDisplayModeTestCases
Change-Id: I7081af903d8259cf7c0009238e7968d458ff3325
Normal applications should have restrictions on how big/many keep-clear
areas they can set. This is to prevent malicious apps from misusing the
API and causing unexpected effects (like the Pip moving unexpectedly or
too much around the screen).
System apps, however, can be trusted to set any keep-clear areas.
In this CL we introduce a new permission to allow system apps to set
unrestricted keep-clear areas. We send two lists to Shell - one with
restricted, the other one with unrestricted keep-clear areas. When
moving floating windows away, the Shell can decide to always take into
account unrestricted keep-clear areas and be more restrictive about the
restricted ones.
Bug: 209578131
Bug: 209577354
Test: atest CtsWindowManagerDeviceTestCases:KeepClearRectsTests
Test: atest WindowStateTests
Test: atest DisplayContentTests
Change-Id: I68804c50fb81173b0795cf30dd71ea91abd02229
How it leaks: When a session is destroyed, mDirectServiceInterface is
set to null. If an event is added to the buffer after this, it cannot be
flushed because of that. But the flush() call will still keep
rescheduling itself regularly (to handle the case of
mDirectServiceInterface not being ready when the session is created).
The flush message holds a reference to the session, which holds the
Context that created it (the Activity). The message effectively stays
forever in the handler queue, preventing it from being GC'd.
When destroyed, the mDestroyed flag is set which prevents new events
from being queued (through isContentCaptureEnabled()). However,
setContentCaptureContext() is missing this check. This cl adds it there.
Note: There is possibly a race condition if ContentCaptureSession calls
happen on different threads (Framework code always calls these methods
on the main thread). This will be fixed separately.
Bug: 204891006
Test: atest NexusLauncherTests:com.android.quickstep.StartLauncherViaGestureTests#testStressSwipeToOverview --iterations 5
Change-Id: If69a17e828d928007232db76af6e0cac16502875
ACTION_SET_SELECTION is needed on all TextView nodes to reset the
cursor. But some non-edit texts are selectable and need to be
identified by a11y services. ACTION_SET_SELECTION has been on these
nodes for years so to avoid the complexity of breaking this, add a
node property.
Services should use ACTION_SET_SELECTION for nodes where
property=true
Bug: 62058901
Test: atest AccessibilityTextTraversalTest, TextViewTest cts and
core (TextViewTest#testCutShouldNotThrowException keeps failing but
it's unrelated to this change)
Change-Id: Ia825dd806824e663e7fa7d274f51c6bf44f0c2c4
With this CL, the IME switcher icon becomes visible only when
necessary, even if InputMethodService renders the back button and the
IME switcher button in the gestural navigation mode.
Implementation idea:
InputMethodManagerService#shouldShowImeSwitcherLocked() is the source
of truth about whether the IME switcher visibility should be shown or
not, and it internally depends on the following conditions:
A. com.android.internal.R.bool.show_ongoing_ime_switcher
B. Whether the IME switcher is already shown or not.
C. Whether the IME is perceptible or not.
D. Whether one or more hardware keyboards are attached or not.
E. Keyguard state.
F. What IMEs and their subtypes are enabled.
Here are what those conditions would mean for this project.
* A is considered to be a per-device constant value.
* B, D, and F can happen at any time outside of the IME lifecycle
events such as startInput().
* C is no longer relevant if those buttons are rendered by the IME.
* E is considered to be constant throughout each startInput() cycle.
This CL uses the following 3 IPCs to notify when the IME switcher
visibility is changing.
1. IInputMethod#initializeInternal()
2. IInputMethod#startInput()
3. IInputMethod#onShouldShowImeSwitcherWhenImeIsShownChanged()
1 and 2 will be used to provide the "initial" value to avoid potential
flickers. 3 is still necessary to take care of async changes
triggered by B, D, and F.
Fix: 215551357
Test: Manually verified with for the following scenarios:
* Enabling/disabling multiple IMEs
* Attaching/detaching a hardware keyboard
* Showing/hinding the IME switcher
* Showing an IME on the lock screen
Change-Id: I5de9ac0dc8670842edf66306bb4c281c77cea376
* changes:
Add bottom sheet fill UI for Autofill
Implement actions on client and service for bottom sheet
Notify Autofill while activity started
Adds APIs for Autofill bottom sheet UI
Implement the client communication with service and service side logic.
Bug: 210926084
Test: Manual
Change-Id: I69a0784d9ba0ff17219f40d5e1bb92a9b1eba581
After activity started, if there is any field that is autofillable,
notify autofill to do a fill request to get ids that require a
special prompt UI.
Bug: 210926084
Test: Manual
Change-Id: Ia1058de63affc98065eeeb4808d4c3f8bae22d03
In order to propagate the information about whether the IME is using
light navigation bar or not from
android.view.ViewRootImpl
to
android.inputmethodservice.NavigationBarController
within the same process, this CL adds a new @hide method to
Window.Callback
as follows.
ViewRootImpl#performTraversals()
-> DecorView#onSystemBarAppearanceChanged()
-> Window.Callback#onSystemBarAppearanceChanged()
-> SoftInputWindow#onSystemBarAppearanceChanged()
-> NavigationBarController#onSystemBarAppearanceChanged()
Button color transition will be implemented in a subsequent CL.
Bug: 215549533
Test: Manually tested with ThemedNavBarKeyboard sample
1. Build aosp_coral-userdebug and flash it
2. adb root
3. adb shell setprop \
persist.sys.ime.can_render_gestural_nav_buttons true
4. adb reboot
5. make -j ThemedNavBarKeyboard
6. adb install -r \
$OUT/system/app/ThemedNavBarKeyboard/ThemedNavBarKeyboard.apk
7. adb shell ime enable \
com.example.android.themednavbarkeyboard/.ThemedNavBarKeyboard
8. adb shell ime set \
com.example.android.themednavbarkeyboard/.ThemedNavBarKeyboard
9. Open the Dialer app
10. Focus in the top edit field.
11. Tap "EXTENDED LIGHT NAVIGARION BAR" mode
12. Make sure that the navigation button color is optimized for light
navigation bar.
13. Tap "STANDARD LIGHT NAVIGARION BAR" mode
14. Make sure that the navigation button color is optimized for light
navigation bar.
Change-Id: I08566034bebfafff6777ce0152cd6ca1f66f6cad
* changes:
Handle touch focus when clicking toolbar window transparent area
The client implementation for remote selection bar
The service implementatoin of selection toolbar
We clone most the render logic from LocalFloatingToolbarPopup to the
DefaultSelectionToolbarRenderService to render the menu items in the
system process. When the rendering is done, the system will notify
the application process events to let the application to position
the rendered content.
The changes also removes unused file SelctionContext. We punt the TC
part to the next release, the file is unnecessary now.
This change is only for the service implementation, the client side
implementation will be done on the next change.
Bug: 190030331
Bug: 205823018
Test: manual.
Merged-In: I3915e8165b4d371700cb5fb9e7eb23d46f39bd5c
Change-Id: I2e704432b1e149ce8dd6853fcad6850cf02b60bb
Use of SurfaceControlViewHost requires the embeder and embedee to
establish a side-channel in order to exchange the SurfacePackage
containing the embedded hierarchy. In recent commits, SurfacePackage
has grown a built in side-channel, useful for exchanging info from
the host back in to the embedee. In this CL we make two of these APIs
public. The general motivation for making them public is as follows:
1. onDetachedFromWindow: While public API provides a manner
to tear down a SurfaceControlViewHost, it seems that almost
every user will have to include an IPC method for this in their
bespoke side-channel. Since it's required for every use case
it seems to make sense to provide some convenience.
2. onConfigurationChanged: At the moment there would be no way
to change the configuration of the remote
SurfaceControlViewHosts. Client apps are instead forced to
create their own configuration update side-channel and recreate
the whole SurfaceControlViewHost each time.
Bug: 200284683
Test: SurfaceControlViewHostTests
Change-Id: I6f33f0953224d7ff60dc819560d54564250bbe3f
Augment the "apparent" display information in configuration
from just the display bounds (maxBounds) to also include the
display rotation and cutout. Like maxBounds, these will be
expected to always be set as basically "the display that this
configuration was built against".
This heavily simplifies fixed-rotation since now we don't
need to deal with the "are we overriding?" question and also
don't need extra activity servertransactions. The configuration
is also in sync (since it is the source of truth used by
resources). Additionally, this means that even the current
legacy fixed-rotation model should work with in any
mixed-rotation situtaion, not just fullscreen.
Bug: 202201326
Test: atest DisplayTest
Change-Id: I6232f74c74324b70b1b0c9f46448c509c2694310
We add support for forwarding InsetsState over SurfacePackage
to reach embedded ViewRootImpl. As a next step we hook up
forwarding of insets from the main visible window of a task
with overlays, to said overlays. We provide a frame so that
the remote ViewRootImpl can interpret the insets relative
to this frame. In the TaskOverlay case everything in the
remote SurfaceControlViewHost is in a world relative to the
task bounds, and so we send the task bounds. Transient insets
are also forwarded via this channel. This is due to the
specific requirements of game service overlay, but seems
to make sense in general for overlays, who will need to be able
to intelligently handle immersive mode.
Bug: 213603716
Bug: 214239892
Test: SurfaceControlWindowInsetsTest
Change-Id: I22e22050a5dec71d8120ef4fea4a1c9bc452e02f
The original CL only updated one of the two implementations of
grantEmbeddedWindowFocus, and for as of yet unknown reasons
presubmit did not detect the failure until after it landed.
Bug: 215912712
Test: SurfaceControlViewHostTests
Change-Id: Ie278f678f12f50c32f142a4260ff7d1c2a9ca57c
New filter modes for InputConnection#requestCursorUpdates(mode) to allow
partial data in cursor/anchor updates.
Selective data helps with speedy CursorAnchorInfo updates.
Test: atest InputMethodServiceTest
Bug: 203086136
Change-Id: Ibba06e9a2533ca91c5cc215dfb18d21c9a74fb73
