Allows custom Input Method Pickers to exclude relevant IMEs, like the
system picker does now.
Fix: 184890628
Test: atest InputMethodInfoTest InputMethodManagerTest
Change-Id: I20033de2f6679ed8cd538de66e157f737792d847
InputEventSender is used to send events to an InputChannel. On the other
side, InputEventReceiver receives the events and processes them.
There's no good way to synchronize InputEventSender and
InputEventReceiver today. If the InputEventSender object changes in the
middle of interaction with the InputEventReceiver, it will confuse the
receiver. Recently added strict checking of state in InputEventReceiver
causes the other side to crash.
In the IME case, there are dup'ed InputChannel being compared to each
other by object. Since the objects are different, the equality check
fails, even though they represent the same connection. This causes the
InputEventReceiver to receive a sequence of events like this:
incoming event seq = 1
incoming event seq = 2
incoming event seq = 3
incoming event seq = 1
incoming event seq = 2
...
If the InputEventReceiver is slow, it might only send finished signal
after it processed first event with seq = 2, but the sender has already
changed, and has already sent a new event with seq = 2. This would cause
the receiver to overwrite the state of the second event with the first
event, thus later causing a crash when it tries to ack the second event.
The events received by the InputEventReceiver should all have unique
seq. The pattern of re-creating InputEventSender breaks this contract.
To fix this issue, we check whether the provided InputChannel represents
the same connection. If the connection is the same, we do not re-create
the InputEventSender, and just keep using the same object. This ensures
that InputEventReceiver is always communicating with only one
InputEventSender and the state remains consistent.
In this CL, only a minimal change is made, and it is not rootcaused why
the 'setInputChannelLocked' call is being made for the same connection.
Bug: 183434055
Test: adb shell monkey 10000; run this test several times until it
crashes. No more crashes observed with "Abort message: 'Could not find consume time for seq=2'"
Test: use soft keyboard on device
Change-Id: If8317941dd1c6d5db77f1239b9a9f45d49997df9
And use it to conditionally enable content padding for requested views.
Fix: 179693024
Test: atest android.translation.cts.UiTranslationManagerTest
Test: adb shell dumpsys activity <ACTIVITY> --translation
Change-Id: I23fb29a60525d736f2dcf9d11b548c62332c412c
Add a new private window attribute for allowing apps to specify the max
display refresh rate. This is useful for use cases such as keyguard
where the refresh rate should be limited to preserve power.
In the next CLs the preferredDiplayModeId would be enabled for
frame rate override (60-on-120) and the preferredMaxDisplayRefreshRate
would be the alternative to control the display refresh rate (as opposed
to the frame rate experienced by the app).
Test: atest RefreshRatePolicyTest
Test: atest DisplayModeDirectorTest
Test: Launch camera app and observe refresh rate
Bug: 183226498
Change-Id: I1c5e9f6047cbea4bfb581251b8dd2b9058b3e378
1. Rename dispatchRequestTranslation().
2. Provide what should be done in onViewTranslationResponse().
Bug: 186578468
Bug: 186578311
Test: atest CtsTranslationTestCases
Test: manual.
CTS-Coverage-Bug: 177960696
Change-Id: Id90e7d68a92ec17ec302d7ff05ef67c8bfa6454b
genrated builder code.
* if Builder.setValues is called with an immutable list, future calls to
addValue will throw.
Fixes: 187542825
Test: atest CtsTranslationTestCases
Change-Id: Ie405975e1a0a8aa90bde7358afde15b8c60aa95a
If the calling thread releases the SurfaceControl passed
to SyncRtSurfaceTransactionApplier concurrently with the
applier preparing the transaction, this can lead to a
synchronization error and a crash. Once the state is
inside the transaction no further synchronization is required
as the native transaction will hold its own sp<SurfaceControl>
reference. By constructing the Transaction on the calling thread
and deferring application to the RenderThread we enable the calling
thread to not have any release synchronization requirements with
RenderThread.
Bug: 186391509
Change-Id: I585e1a9d3baf9ea384b00408b6253f34487d5037
The callback needs to set to null when thread renderer is destroyed.
Bug: 187419942
Bug: 186869429
Test: blaze test --test_strategy=local --test_arg=--device_broker_type=LOCAL_ADB_SERVER //javatests/com/google/android/testing/elizabot/internal/sanity/subscriptionleak:SubscriptionLeakTest_generic_phone_google_31_x86
Change-Id: Ic80c58f102ee5f21830542030021828f6231cc37
* Will update once we add more type values to this class.
Fixes: 187219782
Test: atest CtsTranslationTestCases
Change-Id: Ib8e9fbca70b6808370791da5bd8561dc9e8b1822
This is temporary, to avoid breaking clients that already implemented
the API before onResumed was added.
Bug: 185274258
Test: manual
Change-Id: Icd2c392e248f01c22b95e0b88ba56847ae71f10a
With the flag, dispatcher operates in physical space, so
if injecting into dispatcher, the events need to be 'un'rotated.
Bug: 179274888
Test: atest Launcher3Tests:com.android.launcher3.ui.TaplTestsLauncher3
Change-Id: I9abdfd0540354ab6e3eac34ae15b784c0fcf6e2e
This reverts commit 8b82086722.
Reason for revert: Metrics no-longer needed, we are adding compat for this.
Bug: 187153492
Test: N/A
Change-Id: I31bbe36378a2da969a094405b0e0a7b7b9cde3a0
"Root" is eliminated from the interface name as it is a property
of the object and not the interface, but remains highlighted in the
getters to express the relationship between the called and returned
object.
Bug: 185365821
Test: Existing tests pass
Change-Id: I163fc23f2c37c984ef3ffeb7514c4d8c1c1a3f90
Clarify in javadoc that ACTION_LONG_CLICK does not include coordinate
information.
Bug: 179692809
Test: manual test
Change-Id: I6a4edda48e140f9ba444fdef67feca4d3ed3d146
The locales aren't available on a RESUMED event; now they're stored on a
STARTED event. The crash happens because the default Callback impl
converts the Locale to a string to support a deprecated method.
Fix: 186392998
Test: manual - install test apk which triggers the crash. no crash with
this change.
Change-Id: Iaceca8d29f4c2b0d692c8f6780b0ab963e4e2243
--Updated HWUI holepunch logic for SurfaceView to
also apply the stretch to the hole punch
--Updated RenderNode callbacks to also include
an offset from the ancestor RenderNode that also
has a stretch configured on it
--Added new test activity to verify hole punch
logic
Bug: 179047472
Test: manual
Change-Id: Ibbaf8248a31839ba9dc352ecb9fef54e1276918e
The implementation for drag-and-drop provides two ways of taking URI
permissions: a public API that ties permissions to an activity and
an internal API that grants "transient" permissions. The latter is
used in a single code path: dropping content into an editable
TextView (implemented in android.widget.Editor).
The transient code path was previously (Android R and below)
implemented using a try/finally block in Editor.onDrop. The change
I7ae38069fb741925211b42c7ff28784eb9722ce3 had updated that logic to
tie permissions to the app process lifecycle instead, to account for
the new OnReceiveContentListener which apps can use to implement
custom drop handling (and use a background thread to do the processing
of the content). The problem with having permissions tied to the app
process lifecycle is that the app process could potentially be
long-running.
This change updates the logic to tie transient permissions to the
DragAndDropPermissions object lifecycle (release whenever there are no
more reference to the object and it is garbage collected). This
follows the same approach as used for IME permission grants
(InputContentInfo.java and InputContentUriTokenHandler.java).
Bug: 181178998
Test: atest CtsWindowManagerDeviceTestCases:CrossAppDragAndDropTests
Test: Manually verified using development/samples/ReceiveContentDemo
Change-Id: I950d4572ee19af64da1ace1572fe12e17d09c609
