With this CL, EditText#setText() actually starts using
InputMethodManger#invalidateInput(),
which does not block the UI thread.
See the previous CL [1] about how that API actually works.
There should be no observable changes from the viewpoint of IMEs.
Note that this CL was once reverted due to Bug 208941904, which was
caused by a misbehaving InputConnection#endBatchEdit() implementation
as a combination of the following bugs:
* Chromium (crbug.com/1277732)
* EditableInputConnection (Bug 209958658)
Now those two bugs were addressed. We have also implemented a
safeguard [2] against the same type of app issues so that the system
can gracefully fall back to the previous behavior as needed.
[1]: I3161755779080f98bcef0e47dd0c5247d8a3a256
daa6695c2e
[2]: I109e0c26d8249fc2e01323e3e1cb36395fa7cc97
60c7c55c36
Bug: 203086369
Fix: 209008342
Test: atest CtsInputMethodTestCases
Change-Id: I2ce4be729e23ef686e128f832f8cf7debdcd551e
Migrate the following unsafe parcel APIs in framework-minus-apex:
* Parcel.readSerializable()
* Parcel.readArrayList()
* Parcel.readList()
* Parcel.readParcelable()
* Parcel.readParcelableList()
* Parcel.readSparseArray()
This CL was generated by applying lint fixes that infer the expected
type from the caller code and provide that as the type parameter
(ag/16365240).
A few observations:
* In some classes we couldn't migrate because the class also belonged to
another build module whose min SDK wasn't current (as is the case for
framework-minus-apex), hence I suppressed the lint check
(since I'll eventually submit the lint check to the tree).
* In some cases, I needed to do the cast in
https://stackoverflow.com/a/1080525/5765705 to make the compiler happy
since there isn't another way of providing a class of type
Class<MyClassWithGenerics<T>>.
* In the readSerializable() case, the new API also requires the class
loader, that was inferred to by InferredClass.class.getClassLoader().
* Note that automatic formatting and import rely on running hooked up
to the IDE, which wasn't the case here.
Bug: 195622897
Test: TH passes
Change-Id: I11a27b9bdab7959ee86e90aa1e1cbebd7aaf883c
The system received the same multiple translation responses in a very
short time. We use a isShowingTranslation flag to determine if the
duplicated responses to call onShowTranslation. However the
isShowingTransation flag is set in a post runnable, this may cause the
system allow the duplicate responses can call onShowTranslation
because the isShowingTransaltion isn't set true yet.
Use multiple flags isShowingTranslation and a new isRunningAnimation
to check if the same translation response should skip to call
onShowTranslation.
Bug: 207457172
Test: manual
Test: atest CtsTranslationTestCases
Change-Id: I7003b7f49fc0a8ce2e909228bcb89acedee6d3d0
If the BitmapCache is not copied when cloning RemoteViews, then Bitmaps
will be dropped.
Fix: 208865678
Test: cts, verified locally
Change-Id: I7547ab3a60ac3ee16b9cfb8d592988d0e410172d
when we have overlapped SuggestionSpans, the
range of text being replaced can change depends on
the number of suggestions in the SuggestionSpans, so
accessibility services need to know the text being replaced.
We send text change event with the before text doesn't have the
SuggestionRangeSpan and after text has the SuggestionRangeSpan,
so a11y services can inform the user about the text being
replaced.
Other ui toolkits like compose can convert their style indicating
text being replaced to SuggestionRangeSpan.
Bug: b/143378480
Test: tested the event is sent.
Change-Id: I6d0d33e46f7c8ac9dbcc177ab54718184e715fb6
Bug: 206526994
When items are added to a ListView, any current stretch
should be released and a new touch should scroll and not
stretch.
Test: new tests. manual test
Test: If426eddf2e582169090e5e5e5694668c583288dc
Change-Id: I1f0ae1aa38b064dbb399e46869d8f14ac9d22a92
And implement it for editable text to show the popup
window for typo correction.
Bug: b/143378480
Test: tested with modified talkback.
Change-Id: I8bb1ec87f6bb2177fb4b8fb9a88bfbe10b374173
* 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
With this CL, EditText#setText() actually starts using
InputMethodManger#invalidateInput(),
which does not block the UI thread.
See the previous CL [1] about how that API actually works.
There should be no observable changes from the viewpoing of IMEs.
[1]: I3161755779080f98bcef0e47dd0c5247d8a3a256
Bug: 203086369
Test: atest CtsInputMethodTestCases:EditTextImeSupportTest
Change-Id: I8d2e0be22454b106ded15c78c876b55dc6e60a13
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
