There are some Parcelables which offer to perform Binder calls, and
when these are delivered via Intent extras they fallback to
ActivityThread.currentAttributionSource(), instead of being tagged
based on the relevant app component.
This change begins using Intent.prepareToEnterProcess() as a hook to
fix-up AttributionSource when those extras finally land in the
destination process. It uses the relevant AttributionSource based
on the Activity or Service the Intent is delivered to, which
developers have control over via AppComponentFactory.
In the case of <receiver> manifest elements, this change applies the
first android:attributionTags value to the Context used for that
BroadcastReceiver.
Bug: 187097694
Test: atest AttributionTest
Change-Id: I8f5197db7e8d7277d34f0ef2bb90bfdf1871186a
Allows custom Input Method Pickers to exclude relevant IMEs, like the
system picker does now.
Fix: 184890628
Test: atest InputMethodInfoTest InputMethodManagerTest
Change-Id: I20033de2f6679ed8cd538de66e157f737792d847
- Launcher will create a new surface which is faded in over the app,
and as it finishes the recents animation, we transfer the overlay
from the leash to the task (as with the transform), and when the
pip task organizer receives it, it can fade out and remove the
surface
- Fixes flash of status bar colors when going from light status bar
to home (dark status bar) by deferring whether a task affects the
sysui flag until it enters pip (only for autoenter)
https://recall.googleplex.com/projects/e3f080d7-2818-43f0-a087-405000b8fdf5/sessions/971a84c8-a622-4b34-a9de-4e595595da42
Bug: 184703546
Test: Swipe up from app with auto-enter but no source hint rect
Change-Id: I0a00cdb98d0a599ef065206e0cd2cfc0e6cc72b1
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
Try to submit the 'Check mInputEventReceiver' patch again.
This reverts commit 35fccc4535.
Reason for revert: Added a check to ensure that only valid data is
getting sent. Now, the InputChannel will not be closed because all
InputMessages will always be valid.
Added logging to help investigate the reason why the present time is in
the past of the gpuCompletedTime.
Original commit message:
Previously, it was possible to receive a FrameMetrics callback after the view was already detached from window. In that situation, the mInputEventReceiver is set to null and the object is disposed.
But InputMetricsListener used to store another reference to mInputEventReceiver. So it's own object was never set to null. We would then try to send the timeline to native input receiver, and crash because the native object has already be deleted by the earlier dispose() call.
So the sequence of events was:
dispatchDetachedFromWindow
mInputEventReceiver.dispose()
native input receiver is deleted
InputMetricsListener::onFrameMetricsAvailable
mInputEventReceiver.reportTimeline
try to access a native object using a null pointer
crash
A few options to fix this were investigated:
1) Unregister the observer when mAttachInfo.mThreadedRenderer is set to null.
This is good to do, but it's not sufficient. The problem is that the native call to RenderProxy 'removeObserver' is not serviced immediately, but is posted to be completed sometime in the future. Therefore, the crash would not be fixed by it.
Still, we should always register the observer for the active threadedRenderer, which is done in this CL.
2) Keep a weak reference to mInputEventReceiver inside InputMetricsListener. This would allow InputMetricsListener to check on the status of mInputEventReceiver. When it's disposed, it would be also set to null, so the weak reference resolution would fail.
Unfortunately, 'mInputEventReceiver' is not the only reference to the object of WindowInputEventReceiver. It turns out that the receiver is also stored inside the queued events (see class QueuedInputEvent { private InputEventReceiver mReceiver }). From reviewing ag/153113, it should be OK to remove the receiver from QueuedInputEvent and simply keep track of whether the event is synthesized or not.
But, that change would be too significant to make in this CL. Also, weak references have performance impact, so this may not be desirable anyways.
3) Do not store mInputEventReceiver in InputMetricsListener
The chosen option is to simply use the variable mInputEventReceiver from the outer class. If the receiver is null, we don't notify about the metrics.
Bug: 169866723
Bug: 184255546
Bug: 184771626
Bug: 185015591
Bug: 186664409
Test: verified on fold 2 device, open/close the phone, touch remains
operational
Test: atest InputEventSenderAndReceiverTest
Change-Id: I01076d771e9432f08a3b5f8426c14759b56f3e12
Change-Id: Ie71c9ed38051e3e5ec9cb089951d759f52937fdd
* Will update once we add more type values to this class.
Fixes: 187219782
Test: atest CtsTranslationTestCases
Change-Id: Ib8e9fbca70b6808370791da5bd8561dc9e8b1822
