This will allow us to point other directories at these files for OWNERS
and make it easier to update after future team changes.
Test: N/A
Bug: 202714830
Change-Id: Iaaf5b8eb7568be4ebfd1b30abae0b757153f0391
(cherry picked from commit 7443751dd9)
Fixes the bug if the translation service spending more time to deal
with the translation but user switches back to original lauguage
quickly, we will show translated text.
When the response back, if the translation state is finished, we drop
the result. If the state is pause, we update the response but we do
not call onShowTranslation to translated text.
Bug: 200251777
Test: atest CtsTranslationTestCases
Test: manual. Try to send request late and switch back original
language, it keeps original. Then it works fine when switch between
the source and target languages.
Change-Id: I780456f091884c61e5801ead3ff021531fee87b4
When starting the remote animation, before
RemoteAnimationController#goodToGo, WM will traverse all windows to
perform mApplySurfaceChangesTransaction to prepare showing the window
surface if needed.
Howerver, in issue case, IME surface accidientally being in traverse
window list and shown on the screen even Gpay didn't request show IME.
As IME window now is being in ImeContainer, to apply IME surface change
transaction, in WindowState#forAllWindows -> applyInOrderWithImeWindows
-> applyImeWindowsIfNeeded that has logic to apply for IME window when
the traversing window is non-split-screen IME layering target.
However, this logic didn't cover the case if the last IME input target
that interact with IME is not drawn.
For issue case, the last IME input target is the Message app
and invisible because it has obscured by lockscreen.
So during launching the Gpay activity, even Gpay activity is layering
target, since the last IME input target is not visible, in that case
we should not apply IME surface preperation.
As the result, the fix will be:
- Add a check in WindowState#applyImeWindowsIfNeeded to ignore applying
callback for IME window if the IME input target is not drawn.
Fix: 201987724
Test: atest RemoteAnimationControllerTests#\
testLaunchRemoteAnimationWithoutImeBehind
Test: manual steps as below:
0-1) Set secure unlock method (e.g. pattern)
0-2) Install "Google Pay" app
0-3) Add a payment method instruction
1) Start Message app
2) Click search window and wait IME window appears
3) Hit power button to lock the device
4) Tap screen to show Lockscreen
5) Tap GPay icon
6) See animation and expect there is no IME flickering behind
Change-Id: I57357ba85501397fa5926ab4dee116c42df24506
There will receive another onAnimationStart/onAnimationEnd callback
when calling ValueAnimator#end if the animation is not running, which
is not necessary if the animation was finished already.
Bug: 195736656
Test: atest SplashscreenTests
Change-Id: Ifbbf2f799e3e69624626b16e08f40b562fe483a8
The check has to be done in RemoteViews and in AppWidgetHostView right
before creating the context used to inflate the app widget. Further, the
APK is cached potentially in two places: in the APK with code and the
APK without codes, so both places are updated if present.
Test: manual, see bug for details
Fix: 202369942
Change-Id: I5718f67711a3332a942d3c037eef7f30379549a4
This allows to use different timeout according to transition type.
Also
- Avoid indeterminate timeout by scheduling for individual windows,
or a new window joins the sync-group lately.
- The standalone sync request from applyWithNextDraw won't be mixed
with the control of sync-group.
Bug: 199836343
Test: atest TransitionTests#testTimeout
Test: setprop persist.debug.shell_transit 1;
Launch an activity or change display orientation while the
UI thread of the activity is no response, the transition
should execute eventually within the timeout e.g. 5s and 2s.
Change-Id: Iafecc01818193504ea3fd393817691e1b5e9f084
