Also change DataSpace from long to int (HAL & native are both ints)
Bug: 217776226
Fixes: 218320444
Test: make && SurfaceControlTest#testSurfaceTransaction_setDataSpace
Change-Id: Ic2b9ccb1d0ba3c1d049839310b4fef0881a3d2e2
BufferStateLayer is the now the default interface to SurfaceFlinger
and BufferQueueLayer code path is obsolete and non-functional.
Test: presubmit
Bug: 217973491
Change-Id: I0d083230f3a27d4b0380a1d958fdc5c1b6c3aa51
RA#onAnimationFinished() has been called from the UI thread when
animations finish, causing missed frames (in at least 7 isolated places
in SystemUI.)
On top of that, this method returns void, and it doesn't seem like
there's good reason for halting the main thread until it finishes.
IRemoteAnimationFinishedCallback should follow the same pattern that
IRemoteAnimationRunner does, not blocking the caller.
Bug: 191971782
Test: https://ui.perfetto.dev/#!/?s=556228b5c78df93f1721f62b97a2715d9dd579602bc2c9c0c9812265bdfaec9
Change-Id: Ia257dc4cff64ced20727de9e514fffe3e0ec6186
- When a drag is not dropped or the drop is not consumed, the system will
play a canned animation to the origin of the drag. However, there are
scenarios where this is not sufficient (ie. dragging from a folder or
all apps in the taskbar, which are closed once global drag starts). As
a result, the return animation will return to the wrong location.
The CL adds a hidden flag DRAG_FLAG_REQUEST_SURFACE_FOR_RETURN_ANIMATION
which only SysUI can request (protected by START_TASKS_FROM_RECENTS)
which indicates to the system that when a return animation is to be
played, it should defer to the calling app to animate the surface
instead.
The surface will be returned with the DRAG_ENDED event only if the
result is false (a return animation), to ensure that it does not
collide with the DROP animation by the Shell. The system will
also continue to schedule a timeout to clear the surface if the
caller does not handle it correctly.
Bug: 179390870
Test: atest DragDropControllerTests
Change-Id: I65d749f9fba186a0e43e155bebb136926642a90a
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
android.view.TransactionCommittedListener sounds generic
& broad, but this is really very specific to a single
callback in SurfaceControl. So move the listener there.
Test: make
Bug: 217776226
Change-Id: Ib51a525c5b5ca5fd5c08b667ade6742774047131
The current mTag is ViewRootImpl[name] which can be very long. Shorten
ViewRootImpl to VRI since this is a common acronym.
Test: Log tag and BBQ name is updated
Bug: 217621394
Change-Id: Ibcd0ac72733a74dade64491d853a7c98700eb60d
I inferred nullability annotations in Jetpack based on the guaranteed
behavior of the platform, so now I'm propagating those inferences back
to the platform as annotations.
Test: nullability presubmit checks
Fixes: 206801689
Change-Id: I78a1997faeecdafc51d303b0fc766369938b9101
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
Fixes an issue where if the mServedView gets detached, but a different
view was already set as the mNextServedView, the next served view gets
mistakenly cleared as well.
Fixes: 216548832
Bug: 211105987
Test: atest ImeFocusControllerTest
Change-Id: I3fe42bcb5b08158cbdbf261ba0227075464ffe4c
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
