This CL reworks my previous CL [1], which let
InputMethodManagerService report whether the IME switcher icon needs
to be shown or not to the IME process by using IInputMethod IPCs.
It turns out that we need to propagate one more boolean value in order
to address Bug 219820813. It'd be much clearer if we use bit flags
rather than adding a new boolean parameter to each IPC method. Thus
this CL rewrites my previous CL by using a bit flag defined in a newly
introduced InputMethodNavButtonFlags.
This is a purely mechanical refactroing. There should be no behavior
change.
[1]: I5de9ac0dc8670842edf66306bb4c281c77cea376
75b935a12b
Bug: 215551357
Bug: 219820813
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: I81cb062a08d484ec8ce5d7b2fea64ce19028f82e
This reverts commit 3ccd2488c5.
Reason for revert: Blocking issues have been addressed,
ready to reland. See bug.
Bug: 213425347
Change-Id: I91a29949f87a0d27188b323bf302400ee19e964d
Fix: 217730256
Bug: 222537368
Test: Added test in EditTextTest (will merge later when reviewed).
Merged-In: I78354a0f1d955c5b7c1ead044ea49086b3479841
Change-Id: I78354a0f1d955c5b7c1ead044ea49086b3479841
(cherry picked from commit e1f392d171)
This reverts commit 0de71ca543.
Reason for revert: Don't yet have a use for the definitions,
and will likely reimplement them differently. This is an adjusted
revert to account for a resource finalization error
Test: Is a reversion.
Bug: 222537368
Merged-In: I99a71551069069d117039af4708030772b741cea
Change-Id: I99a71551069069d117039af4708030772b741cea
(cherry picked from commit 65e5bf07c2)
These warnings triggered on ag/16873530. The warnings are like:
[AndroidFrameworkRequiresPermission] Method addKeyguardLockedStateListener() annotated {allOf=[android.permission.SUBSCRIBE_TO_KEYGUARD_LOCKED_STATE]} but too wide; only invokes methods requiring [none]
public void addKeyguardLockedStateListener(@NonNull @CallbackExecutor Executor executor,
^
If calling an AIDL interface, it can be annotated by adding:
@JavaPassthrough(annotation="@android.annotation.RequiresPermission(...)")
Bug: 216630470
Test: n/a
Change-Id: I479063de6b591da44c474e4aa93e0466104d2a9a
This allows tests to check the behavior of automatically reporting the
focused View as a keep clear area.
Test: atest KeepClearRectsTests
Bug: 218494300
Change-Id: I602406572a540c4b5f77164efab28376faec2701
Use the android.os.InputConfig flags to control input window behavior in
InputWindowHandle. This consolidates the old boolean flags and
inputFeatures flags into one set of flags so that the InputConfigs are
the sole set of flags that change change how an input window behaves.
After this change, InputFeatures and LayoutParamsFlags are specific to
WM, which is responsible for converting them into InputConfig flags.
Trivial conversions between these flags are done in InputConfigAdapter.
The LayoutParams type and flags are still part of the this API to send
these attributes to native code. However, they are no longer used by
input.
Bug: 216806304
Test: manual: verify touch functionality
Test: atest WindowStateTests
Change-Id: I5b384770272c111680783ee8ab01ecd6e03f42be
The feature is punting to QPR1, disable feature by flag first. The
feature will strip from the build in the follow up change.
Bug: 190030331
Test: manual. Clear flag and make sure the feature is disable.
Change-Id: Id5e0efeff0465890a5d26ef10b6e54359f569317
InputFeatureFlags are now a WM-only flag, but is temporarily used by
InputWindowHandle until the cleanup is completed.
Bug: 216806304
Test: atest libgui_test
Test: atest inputflinger_tests
Change-Id: I1260431e99d2c50261dc8b0356dc3e21ba76d39f
Re landing with the following changes:
We initially cloned the SurfaceControl handle to avoid locking when
accessing the SurfaceControl from the position listener callbacks
running from RT workers. But this meant the last reference to the
layer handle would only be released by GC. If SurfaceViews are
created and destroyed rapidly, we would be at the mercy of GC to
release buffers.
Original change:
There are three transaction queues that can submit SurfaceView
changes.
1. Buffer updates via BBQ apply token
2. SCC apply token
3. ViewRootImpl BBQ apply token
It makes sense for most SurfaceView changes to be synchronized with
ViewRootImpl draws since the caller can optionally synchronize the
change with main window content.
This change eliminates the tmp transaction that is applied directly
via the SCC apply token and instead applies them with the ViewRootImpl
draw transaction.
Also take the opportunity to scope down mSurfaceControlLock usage.
Test: atest SurfaceViewSyncTest
Test: go/wm-smoke
Test: run mem tests via forrest
Bug: b/217973491, b/221631942
Change-Id: Idba712d146e62d7346920dc4f060cba92d47fada
Content recording relies upon a class describing current state.
rather than passing around details from media > display > wm.
WMService keeps track of the session in ContentRecordingController.
ContentRecordingController manages hand-off between different
DisplayContent instances, as the session details are changed.
Manually tested that fold/unfold handling when screen recording
from QS tile still works, and that taking over a screen cast
with a screen recording works.
Refactoring logic from DisplayContent into new recording
delegate will come in a future change.
Bug: 216756854
Test: atest FrameworksCoreTests:ContentRecordingSessionTest
Test: atest WmTests:DisplayContentTests
Test: atest WmTests:ContentRecordingControllerTests
Change-Id: Ib4f125dd703d362ac13fcbe469d00b345827e706
Modified SurfaceView and ViewRootImpl to provide callbacks when syncing
a transaction instead of sending transactions. This will ensure a clear
ownership of the transaction object since it will be provided in the
callback when BBQ adds a buffer into the transaction. Modified JNI to
add compatibility for native functions.
Test: Manual testing from go/wm-smoke.
Test: BLASTBufferQueueTest
Bug: 210714235.
Change-Id: I1f872d6b2846b0d64d5b33b8866d0b2ec7126c8c
Originally, View was implementing onBackInvokedDisptacherOwner, but now
only Activity and Dialog and since back event are related to the
window, it makes sense to move them into the android.window package
This follow up comment at:
ag/c/platform/frameworks/base/+/16764116/comments/e131f3ef_e3e1d2e0
Test: atest BackNavigationTests
Bug: 221401221
Change-Id: Ia2f26162beb6a41b6e162b31e599e882f8bf7320
