It is possible the developer calls pauseTranslation() to show the
original text but it calls startTranslation() to show translated
text. Ideally the developer should call resumeTranslation but it
also make sense to call startTranslation() to show translated text.
When receiving translation response, we avoid showing transaltion
if the view already has the response and it's the same. But it is
good to also check if the view is showing translated text or not.
If the view is not translated text, it is possible developer calls
startTranslation() instead if calling pauseTranslation() to show
translated again, the fixing can resolve this case.
The issue case can be fixed by this change. But there is a deeper
problem about it's useless the caller call finishTranslation(). This
is planned to be fixed in next release.
Bug: 201238016
Test: manual. The issue case is fixed.
Test: manual. Test some chat apps, it still works fine.
Test: atest CtsTranslationTestCases
Change-Id: I699d0fa1d60ac96db094adcc6e17f4203df03214
If a view is detached before being removed (which seems common with some
recycler list views) then no content capture view removed event is sent
(notifyAppearedOrDisappearedForContentCaptureIfNeeded does nothing
if mAttachInfo is null).
Fix: 200166989
Test: Manual verification using AiAi logging
Change-Id: Ic04af005bb4ad425ba8398439f1f47bb6bcb334c
The opaque flag is necessary for the compositor to blend the layers
correctly and prevent translucent pixels from showing the layer
underneath during animations.
Test: manually punch holes in apps and verify opaque apps don't show the layer underneath
Test: automated tests to follow
Bug: 198924563
Change-Id: I1116c51b2efd4e9c0fe2acbca080291f3950245c
Because the background attribute used to have a different use some apps still set it and it means we could run transitions with unexpected background colors
Test: Existing
Fixes: 200763116
Merged-In: Id42f52760cb9a681c6c33f3c261d7db5e2f71af3
Change-Id: Id42f52760cb9a681c6c33f3c261d7db5e2f71af3
Update to feel less flickery with the new task transition animation
We want to try and have the navbar transition right when the animation is in between the two tasks
Bug: 200674544
Test: Existing tests
Change-Id: If99965c4b4776c902a3c6b32a3fcdb0b65811407
To be used for new task transtion animations
(go/android-new-task-motion) to set a background color behind the
animations instead of showing the wallpaper.
Test: atest FlickerTests:TaskTransitionTest
Bug: 199507257
Change-Id: I7fabfdcaf90be63c11eb3b18d65259c620570cab
It is possible the existing text is changed that triggers a new
translation. We cache the translation response when onShowTransltion
is called. We should keep the translation response is updated if this
is a new translation result.
Bug: 200232741
Test: atest CtsTranslationTestCases
Test: manual. The issue app works fine.
Change-Id: Iaf7423cd35d4484e33de84e478256b77a000f390
The system will add requested view reference into cache but it is
possible the requested translation view is a viewgroup, we don't add
this into view reference list that cause the translation doesn't work
on ViewGroup.
Bug: 200233857
Test: atest CtsTranslationTestCases
Test: manual. Use a sample code to request translation for a
viewgroup and make sure it is added into view reference list.
Test: manual verify with issue client app, it works.
Change-Id: Ie593a1a436fd046373412ae2955a78057d22b892
WindowContext relies on WindowTokenClient#onConfigurationChanged after
calling WMS#attachWindowContextToDisplayArea.
However, it took some time to wait for onConfigurationChanged callback
from the server side so that we may get a stale value right after
creating WindowContext.
This confuses developers especially when the foreground activity is in
size compat mode or freeform because the process config is overridden
by activity's config.
This CL makes #attachWindowContextToDisplayArea return DA's configuration
and applies to WindowContext direcly.
It also benefits WindowProviderService because it can obtain DA's
configuration before onCreate() based on [1] and this CL.
Bug: 190019118
Bug: 190745506
Bug: 198298520
Test: manual - 1. launch an Activity in size compat mode
2. create a WindowContext and verify if WindowMetrics
matches DA bounds.
Test: atest WindowContextTest WindowContextTests
Test: atest WindowContextControllerTest ContextGetDisplayTest
[1]: dd4a748af0
Change-Id: I8dd3987b731662502bc01e9d2ed67e718ada5f46
SurfaceView clients may hold on to surface references. In S this means
they would extend the lifetime of the SurfaceControl resulting in
"leaking" buffers until the references are cleared or the app is
terminated.
Fix this by calling a new destroy function on Surface which will
explicitly remove references to the SurfaceControl and BBQ it holds.
This is safe because SurfaceView controls the lifecycle of the Surface
and knows when the Surface will become invalid. Once invalid, the Surface
cannot become valid again.
Test: repro steps in bug
Bug: 198133921
Change-Id: I5c7e43736f025fc0965eae2f19719ba40df3cb70
Merged-In: I5c7e43736f025fc0965eae2f19719ba40df3cb70
1. Provide more detailed information for UiTranslationManager.
2. Clarify the difference for VTC#onClearTranslation and
VTC#onHideTranslation.
Bug: 178044703
Test: n/a. Change javadoc not change code.
Change-Id: I4b2ef1a6c39c3bbbb85d0dcda519d286f10deb25
The issue will occur when the view is removed from the hierarchy by
the time the translation response returns. Do a null check to make
sure the view still exists.
Bug: 196933332
Test: atest CtsTranslationTestCases
Tese: manual. not see the crash when scrolling the apps.
Change-Id: Ifee933a802385750d431800ef50f6f2c306ccc0f
There are some issues TranslationService already sent the response
but the View onResponse doesn't be called. The reference seems to be
gone. If we don't fix the problem, we will missing the ui translation
even the service already give us the response. To fix the problem, we
change it to strong reference.
The change is low risk, the only risk is if TranslationService doesn
not release the reference to the callback properly causing a memory
leak for apps but this can recovered by app update.
Bug: 194973014
Test: atest CtsTranslationTestCases
Test: The translation for chat apps work fine. The memory is decreased
after receiving the responses for a while.
Change-Id: Ib3956b2250c54a29acf9f7d51f51e8191fe8aba2
This cl solves a couple of issues:
1. Render thread workers and UI thread share the surface size. They work
on different frames (UI thread sets up the next frame while render
thread is working on the current frame. Accessing the surface size is
unsafe and can result in flickers.
2. UI thread is changing the geometry on size change which might
conflict with render thread causing flickers. This is because of
unsafe accesses as the one mentioned above and the UI thread may
not have the up-to-date position of the view.
This cl fixes the issues by only applying geometry changes in the
UI thread when creating the surface, otherwise the render thread
workers are responsible for updating the geometry. The RenderNode
position update listeners are updated whenever the surface size
changes in order to capture the new size and accompanying changes
which must be applied with the new geometry changes.
Note: updating the position update listeners will trigger a
position update callback so we are guaranteed to apply the
changes in scenarios where the fixed size changes but the view
size does not change.
Test: atest SurfaceViewSyncTest#testSurfaceViewChangeFixedSize
Test: atest SurfaceViewSyncTest#testSurfaceViewChangeFixedSizeWithViewSizeChanges
Test: go/wm-smoke
Test: repro steps from b/190449942
Fixes: 190449942
Change-Id: I076321c853f9a0f6cbf169637e3f3ede60361d60
This CL fixes one of the issues with SurfaceView parent frame and
content syncing.
With BLAST, we have two surface controls each setting a scale. The
parent surface control sets a scale based on the requested surface
size and the SurfaceView layout size. The BlastBufferQueue surface
control scales the buffer to the requested buffer size if the buffer
has the appropriate scale mode.
The destination frame controls the second scaling and it must be
applied with the parent surface scale changes. This cl fixes flickers
where the requested fixed surface size changes without any view size
changes. This cl allows the caller to pass in a transaction to
BLASTBufferQueue#update which is updated with the destination frame
changes. This transaction can then be applied with the parent
surface changes.
This also fixes an issue where destination Frame was being set on
every buffer update and when we updated the BlastBufferQueue size.
Since buffer transactions can be queued up on the server side, a
stale value maybe applied for a few frames causing flickers.
Fixes: 194458377
Test: bug repro steps
Test: atest SurfaceViewSyncTest#testSurfaceViewSetFixedSize
Change-Id: I118bd1c3942b389e3951c3fd7389403895fc7b31
This CL aims to clarify on what the return value of
InputConnection#setImeConsumesInput()
means for both the IME authors and editor authors [1][2].
In short, the semantics is exactly the same as
InputConnection#performSpellCheck()
hence this CL reuses its @return section.
Other than clarifying an API doc, this CL changes nothing.
[1]: Ic04cacfd73f1f4cb254bb16caf6b04c00c91a318
30fe6aa964
[2]: I8ac1ea4d53f747b0086ed415ff90793dfc6155bc
66b21086e3
Bug: 175362887
Fix: 194099171
Test: presubmit
Change-Id: Ibdfe81a9dd1448856797aaed2f14de1314da1cac
Merged-In: Ibdfe81a9dd1448856797aaed2f14de1314da1cac
(cherry picked from commit f9ca70be57)
- Exposes a method to set that a certain part of the SF hierarchy is
trusted, and sets this state for tasks in PIP.
Bug: 191529039
Test: Manual, try using permission dialog while PIP is active
Change-Id: I170cb5a7d22ef569eb36de21cc0bcbef60dd385e
Transform hint should only be updated when creating the
surface or the view is visible. If the view is not visible, BBQ
will be null. This fixes a NPE in SurfaceView.
Test: go/wm-smoke
Fixes: 193618182
Change-Id: I98a463ae23a93d89ac803e2c2d80ecfd56ca97d2
The logic we are using to handle the params == null case doesn't make
sense, params=null just indicates nothing was changing on this relayout
and so we avoid passing to WM, not that we should default the format. We
can just use mWindowAttributes directly to avoid this problem.
Test: Existing tests pass
Bug: 190483641
Change-Id: I4a765914eb8ca33a432fc808af96847bb78fb054
When we receive RELAYOUT_RES_BLAST_SYNC from the WindowManager, we
trigger reportNextDraw, incrementing the pending draw count by one.
At the moment we unfortunately do this after dispatching callbacks
to SurfaceView. In the span of these callbacks, SurfaceView may
increment and decrement pending draw count, once it reaches zero
we will notify the WM of draw early, terminating the sync operation
without ever waiting for the ViewRootImpl to draw. By processing
RELAYOUT_RES_BLAST_SYNC before emitting the SurfaceView callbacks
we can avoid this issue.
Bug: 191921061
Test: Existing tests pass
Change-Id: I2f1096c9cdc79b89413c3f0bfd9b3054ef45f2d2
If the appearance or the behavior are not controlled by APIs,
InsetsController will still return the default values, but the
internal logic will access the real value.
Fix: 192635471
Test: Open an app which hides system bars with
SYSTEM_UI_FLAG_IMMERSIVE_STICKY, but not
BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE.
Change-Id: I1c2f947e3707fcb4c151c1ad19c9cd16527e11d9
Disable end-to-end input latency metric to reduce the
number of JNI WeakGlobalRef acquires per-frame.
Bug: 189738006
Test: Observe trace section no longer appears in calculator
Change-Id: I062dad8e7cec93cca5599e51d2b0b1a1b6e39a07
When a new SurfaceControl was created, the java object's transform
hint was not updated. This created a mismatch between the java and
native objects resulting in the client getting an incorrect transform
hint. Fix this by making the native object the source of truth for
transform hints.
Test: in landscape mode, dismiss apps and check launcher does not reject buffers
Bug: 191841127
Change-Id: Icc87b8cf8158eedb87eea886392a0460a76c6443
These are needed to have a workaround fix for a11y cache filled with
stale data before android T.
NoNonSdkCheck: set maxTargetSdk to S in UnsupportedAppUsage is not allowed yet.
Bug: b/192110374
Test: it builds fine.
Change-Id: Iaa0f68b2b8e4702f6b638cb3060714a22850af7e
This CL logically reverts recent CLs [1][2][3][4][5][6][7][8][9] to
switch back to the previous sync IPC approach in IInputMethodManager
except for the following two IPCs.
* reportPerceptibleAsync
* removeImeSurfaceFromWindowAsync
Reason for revert:
We need more time to understand its performance implications.
[1]: If4b40244a2e0e3b11c38c1da9340ba8e5166ad64
b9590fa1e1
[2]: If79e063641a01b325c63eb9f871f5b992d7c0b72
5a5648dcb5
[3]: I1547b98b2aacf764e33aadc9ab784f2013f58f2f
d833f0dab4
[4]: I646ef4ae0570aae1812ea267f309441fdec6938d
38fd020616
[5]: Iaa63e01453da4ff0e3f446eac036b3be3180cb73
4a820ccc41
[6]: Id516fd1c961f43ac3e139c88d7ed004c188d458b
0a32fd21ef
[7]: Icb396ae5d74060af69c4ecb16723b2e37b9f2067
c4663ba6a9
[8]: I3eafbc28ed3acf3ba859885bf201cb06b3149b94
f226a79fee
[9]: Ic584203c1221fbae17f5e2d8f09e3992df061646
5e2d9f271d
Bug: 163453493
Bug: 174892351
Fix: 190486491
Test: atest CtsInputMethodTestCases
Change-Id: If16ac0de536d9089eb04f6e07b1ee47378124658
Merged-In: If16ac0de536d9089eb04f6e07b1ee47378124658
1. We save Translator WeakReference in ServiceBinderReceiver.
It has a chance the reference is gone even the session is still
alive. Save Translator instead of WeakReference.
2. Fix not access TranslationManager mTranslators, mTranslatorIds in
the lock.
3. Fix protential NPE of resultData access in ServiceBinderReceiver.
Bug: 192205945
Test: manual. The function works.
Test: atest CtsTranslationTestCases
Change-Id: I158901db4bbcd76203c705ab2a34f1e0b37c7565
