Screen reader(Talkback) will read content description first if the
developers set. We only translate TextView text, this may cause the
screen reader will not read the translated text if the developers set
content description.
To fix the issue, we also send the content description to translate.
When the translated text is shown, we also set content description
with translated content description and reset to original content
description if show original text.
Bug: 187134784
Test: atest CtsTranslationTestCases
Change-Id: I6986384260627a0539780b7293d47666c442d852
This CL revokes navigation bar control to make navigation bar visible
while IME is showing, so the button to dismiss IME would be available.
This CL also lets IME receive visible navigation bar insets, regardless
of the navigation bar visibility.
Fix: 167971834
Fix: 186789472
Test: atest WindowStateTests WindowInsetsControllerTests
Change-Id: I2e723d4fc50d006127caa473d67c2f6af0d2cbcd
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
- Switch from PhoneWindow to FrameLayout
- Ensure the Action bar is not shown on the splashscree
- Do not show the contrast scrim under the system bars
- Use the latest insets API to layout fullscreen
Test: Updated CtsWindowManagerDeviceTestCases:SplashscreenTests
Bug: 181852475
Bug: 184941669
Change-Id: Ifc04bd2227394415cc74c20d2974f4726ec9c789
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
