* It can not be null and before the statement rv has been already used.
Test: Make AppWidget on the front page.
Fixes: 168335785
Change-Id: If622ef693fb806a2b0d7a86182f9ccb10c80eba6
When user types space after a word, we receive a text
change event, but the suggestion span is not added to
the text yet. The spell checker adds the span after the
text change event is sent. Previously we send the event
in onSpanAdded in TextView, but we don't do anything or
update the before text for span removed. This is a bit
confusing and error prone. This change moves the send
event logic into spell checker.
Bug: b/143378480
Test: tested with talkback.
Change-Id: Ibd45843494304602b177df8da520a51058989f10
Previously, the recycling was only checked for multiple layout, as it
was assumed the AppWidgetHostView would make the basic check. However,
adapters views (e.g. ListView, ...) do not make any recycling check,
instead relying on caching using the Layout id. The caching cannot be
changed as it is common to other parts of Android.
Note, however, that some apps are already using this lack of test to
create the view themselves and use reapply to apply the RemoteViews. So
we limit the test to uses involving changing the viewId.
This CL ensures the view can be recycled when reapplied, always.
Bug: 181985606
Test: atest android.widget.cts.RemoteViewsRecyclingTest
Change-Id: Ib4f908c66a666faa4e6c27e2be38246eb7748f61
By using "squashing", each ApplicationInfo is only written to the parcel
once. Subsequent writes write only a single int as a reference.
This makes the earlier system with ELIDE_DUPLICATES unnecessary.
Squashing relies on testing for equality, and ApplicationInfo does not
implement equals, therefore I've added a shared cache based on package
name and uid so that we can force all RemoteViews of the same package to
use the same ApplicationInfo object.
There is also a mechanism to update the ApplicationInfo to a new one
(needed for dynamic colors).
This saves space for addView calls as well as RemoteCollectionItems
usage. After this change, each incremental item in a collection adds 48
bytes as a base (before this was multiple kilobytes).
This approach also supports collections with RemoteViews from multiple
packages. Each ApplicationInfo in the entire hierarchy is written at
most once.
Bug: 202831917
Test: locally, atest RemoteViewsTest, atest RemoteViewsFixedCollectionAdapterTest
Change-Id: Ie1b1dc8760247aa771451149243efd63d36da368
Revert "Add test checking view recycling is always tested"
Revert submission 16149646-betterRecycling
Reason for revert: Droidfood Blocking Bug: 205503898
Reverted Changes:
Ib01c511e4:Always check if the view can be recycled.
If11dcd323:Add test checking view recycling is always tested
Change-Id: Id08d5ea3602d9d3ca03e148e57a9f97435534e2c
Previously, the recycling was only checked for multiple layout, as it
was assumed the AppWidgetHostView would make the basic check. However,
adapters views (e.g. ListView, ...) do not make any recycling check,
instead relying on caching using the Layout id. The caching cannot be
changed as it is common to other parts of Android.
This CL ensures the view can be recycled when reapplied, always.
Bug: 181985606
Test: atest android.widget.cts.RemoteViewsRecyclingTest
Change-Id: Ib01c511e4a793cce1519157aea06e194a2d8f855
When implementing the code, it seems this was forgotten :( If the view
id of the root of the RemoteViews is changed, currently, the top-level
view will be re-used, which is an error.
Bug: 181985606
Test: atest android.widget.cts.RemoteViewsRecyclingTest
Change-Id: I5a8addb08f597ec574e3ed49d1318771e4c7c767
Currently, when SearchView is focused, the focus is moved to the
internal view. This blocks users to move the focus back to the previous
view by Shift + Tab.
Send focus to the previous view instead of the internal view when the
direction is backward.
Bug: 191405735
Test: atest SearchViewTest SearchView_CursorTest
Change-Id: I668ce13472b80da2e57e84fac4966294d7848170
TextView#onCreateInputConnection() has automatically set the following
EditorInfo flags depending on the presence of focusable elements next
to it.
* EditorInfo#IME_FLAG_NAVIGATE_NEXT
* EditorInfo#IME_FLAG_NAVIGATE_PREVIOUS
With those flags, IMEs may offer some additional UI for users to
trigger InputConnection#performEditorAction() with the following
command to achieve tabbing navigation to switch to other focusable
elements.
* EditorInfo#IME_ACTION_NEXT
* EditorInfo#IME_ACTION_PREVIOUS
The problem of the current TextView implementation is that it does not
check whether the next element is also a text input field or not. As
a result, users might be navigated to a UI element that does not
natively support InputConnection APIs, which results in connecting the
IME to a fallback InputConnection. We have actually received multiple
bug reports that the IME was still shown but not tapping its keys did
nothing.
Based on such feedback, this CL aims to narrow down the condition to
automatically set those navigation flags in TextView. With this CL,
those flags will no longer be set if the next View in question returns
true from View#onCheckIsTextEditor().
See also the corresponding CTS CL [1] to find examples of how it
behaves now.
[1]: I1b75b85f6c1fa4ff90ffa7d584f033b9510d2a36
Fix: 31099943
Test: atest CtsInputMethodTestCases:EditTextImeSupportTest
Change-Id: Id004a77453952f36a2c572697db31c87518f842f
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
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
Just a small cleanup. TextView.getText() looks like it has some logic we might not want to repeat.
Change-Id: I364458d979275ad5dff24983e4ee2b9469f91155
When user types space after a word, we receive a text
change event, but the suggestion span is not added to
the text yet. The spell checker adds the span after the
text change event is sent, but currently TextView doesn't send
any notification. This change sends a TYPE_VIEW_TEXT_CHANGED
event with the from and to index of the span, and beforeText
which doesn't have the span and afterText which has the
span.
Bug: b/143378480
Test: tested with talkback.
Change-Id: If16c2c578be5dcae20a9fd7014ff6fba2d487670
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
This is important to ensure sub-contexts know the user id used to create
the current context, or when using a work profile, a new context will be
created each time.
Fix: 197761162
Test: Manually with hand-made app widget
Change-Id: Ifb4a6dad152acbd2b2853ba8bf5cf1e131d55394
When a view is partially visible on the screen, ContentCapture reports
only the visible portion (+ a few additional lines). The offsets
calculated for this can be out of bounds if the view's displayed text
is longer from the original text.
Fix: 196414491
Test: manual - translate app to lang with more characters and trigger
a relayout (by scrolling for an app with ListView)
Test: atest CtsContentCaptureServiceTestCases
Change-Id: Iae98133c48cc67a0b00f1b0ab8b93e5adb293423
