This is a follow up CL to our previous CL [1], which had an off-by-one
bug when determining the return value of
EditableInputConnection#endBatchEdit().
According to the API document of InputConnection#endBatchEdit(), the
following test should pass.
EditText editText = new EditText(context);
EditorInfo editorInfo = new EditorInfo();
InputConnection editableInputConnection =
editText.onCreateInputConnection(editorInfo);
assertThat(editableInputConnection.beginBatchEdit()).isTrue();
assertThat(editableInputConnection.beginBatchEdit()).isTrue();
assertThat(editableInputConnection.endBatchEdit()).isTrue();
assertThat(editableInputConnection.endBatchEdit()).isFalse(); // (*)
assertThat(editableInputConnection.endBatchEdit()).isFalse();
However, the last assertion marked with (*) actually fails due to an
off-by-one bug. This CL finally fixes it.
The risk of app compat breakages because of fixing this long standing
bug is supposed to be low, mainly because:
* the system has not relied on this return value yet.
* Widgets like WebView have correctly implemented this API.
* IME has always received true no matter what the app returned, which
is the same behavior as other async InputConnection APIs.
This CL adds several notes to InputConnection#endBatchEdit() document
to help developers correctly implement and use this API.
[1]: I1ec5518fdc16fb0551fbce9d13f5d92eb4bc78c0
c478c171e9
Fix: 209958658
Fix: 210165648
Test: atest -c CtsInputMethodTestCases:EditTextImeSupportTest
Change-Id: Ibc40072fa11a4d6e3c24b8d7860c914ccdbcbc8a
Merged-In: Ibc40072fa11a4d6e3c24b8d7860c914ccdbcbc8a
(cherry picked from commit beda2b7f76)
EventLog function can handle string,integer class and long class. (in android_util_EventLog.cpp)
If menu title string are used bold tag(like <b>test</b>), it'll be android.text.SpannedString.
therefore any android activity using tag menu string(like <b></b>) can be crashed by IllegalArgumentException.
Bug: 208862322
Change-Id: I2432b0cd28c8f5fcb07cdf3e29560bf6b6c0f7b6
Signed-off-by: chenchaoli <chenchaoli@xiaomi.com>
Found a memory leak on ViewRootImpl. If the view wasn't been set
to the VRI successfully, there would keep the registed listeners to the
AccessibilityManager and DisplayManager forever because there didn't
need to deatch anything from window.
Another reasonable way is to register all listeners after setView
success.
Bug: 200843755
Test: manual, hard code to force addWindow fail and monitor no more
ViewRootImpl object leaked to AccessibilityManager and DisplayManager.
Change-Id: I3c9cc52d0ca4595c74c1dc3c51d286d9e6e3897f
Merged-In: I3c9cc52d0ca4595c74c1dc3c51d286d9e6e3897f
(cherry picked from commit d69deffd35)
Merged-In:I3c9cc52d0ca4595c74c1dc3c51d286d9e6e3897f
Many TV remotes have direct keys to launch the specific
application such as Netflix. KEYCODE_APP_X are
intended to be used for such a purpose and to be handled
by GlobalKeyManager.
Categorized like below.
- KEYCODE_VIDEO_APP_X
- KEYCODE_FEATURED_APP_X
- KEYCODE_DEMO_APP_X
Prevent KEYCODE_APP_X from being sent to the apps.
Bug: 182532772
Test: atest KeyEventInterceptTest
Change-Id: I13c469c92da97014be5c76c230806331f0602b54
Merged-In: I13c469c92da97014be5c76c230806331f0602b54
Query the surface flinger property
ro.surface_flinger.primary_display_orientation to determine the
primary display's install orientation. If the window is on the
primary display, then update the transform hint passed on to the
client.
Bug: 196167822
Test: check initial buffer transforms on displays with a different
install orientation
Change-Id: Idf010cd6be73172ba708820f87046c3ba3cf8001
Merged-In: Idf010cd6be73172ba708820f87046c3ba3cf8001
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
