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
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
When Stylus handwriting mode is about to be used, automatically
subscribe IME to CursorAnchroInfo updates. This helps speed-up
stylus tasks in IME
Bug: 203086136
Bug: 210039666
Bug: 215533103
Test: atest CtsInputMethodTestCases
Change-Id: I3d6b1728d62139785593af14c24cb52bf2c91e31
Add an API for setting touchable regions. This API allows
a view hierarchy to allow touches to pass through its
surface in certain regions. Touch pass through of course
follows the regular rules about UID/PID origins and
touchable region does not effect the calculation of the
TOUCH_OBSCURED flag. Such an API has existed as @hide
since the beginning of time, via
ViewTreeObserver.ComputeInternalInsetsListener. The API has already been
wrapped in the IME system, and in VoiceInteractionSession.
Desire to make the API public is motivated by 3 use cases:
1. GameOverlayService UI code moving out of framework
required for their UX (multiple small buttons in a large
transparent overlay)
2. SurfaceControlViewHost: A common point request among
people who ask me about SurfaceControlViewHost is to be able
to embed the SurfaceControlViewHost in a SurfaceView which is
"setZOrderOnTop(false)" (hole punching) so that the host
hierarchy can draw on top of the embedded hierarchy in some
regions. This is possible today, but there will be no way
to receive input without input hole punching.
3. There may be cases where apps are using multiple Popup type
windows which could be combined in to one. In general reducing
HWC layer count this way will be a good trade off.
It was considered to ViewTreeObserver.ComputeInternalInsetsListener
directly but ultimately decided against it for a few reasons:
1. Obscure naming
2. Other fields not useful for our use cases.
Because insets/touchable region linkage not a useful API concept for
us
3. Forces dispatch model via callbacks which may or may not be
useful for a given app.
It was also considered to create a gatherTouchableRegion API mirroring
gatherTransparentRegion. Such a concept (as setting root surface
touchable regions) is not really composable though. For example
maybe a parent view requires touch regions, then a child view
one day starts removing them. The fact that input order is not
simply reverse drawing order (since parents come before children
in both) means there is no way to ensure this always cleanly composes
as expected. Given this, it's better to expose a "global" API
and require the app developer to understand how their components
are fitting together, rather than invite a View implementer
to subclass gatherTouchableRegion and allow someone to break them.
Bug: 213603716
Bug: 214239892
Test: SetTouchableRegionTest, SurfaceControlViewHostTests
Change-Id: Ie49caec964455b7129daa2aaa6990a368309f8e9
Currently we send the input (channel) token from the embedded
view hierarchy to the remote embedding process via SurfacePackage.
This is used to call grantEmbeddedWindowFocus. However this could also
allow the host process to invoke updateInputChannel, which is not
desirable. To fix this we rework updateInputChannel to work in terms
of a focusGrantToken, which only carries this 1 capability.
SurfacePackage is modified to not include the input token, but rather
include this focus grant token.
Bug: 215912712
Test: Existing tests pass
Change-Id: Ia9153c54e3e36e73c2b56763b96afab9e9f20d40
The frame number at the server side is not used anymore since BLAST.
Bug: 161810301
Test: presubmit
Change-Id: I01c6fb0750799aa94766f2582ce6ac031c9426cf
This is a step to move the layout logic to the client side. We won't
obtain the surface size from the server then.
This CL also moves the logic about adjusting the LayoutParams of
wallpaper to the client side.
Bug: 161810301
Test: presubmit
Change-Id: I3a81e174035c67a285cab449c0701ee2fe6f6a24
