Apply a simple text alpha animation when toggling between original and
translated text. The text is fully faded out, then swapped to the new
text, then the fading is reversed.
Quick toggles are handled by ending the previous animation (which resets
the alpha value) when starting a new one. If the toggle is extremely
fast (<250ms for the currently defined animation duration), the text
stays in it's original state instead of swapping back-and-forth. This is
arguably not ideal, but anyway not worth the complexity for fixing.
There is an unhandled edge case where if the color is changed by the app
during the animation, the app's change would get overridden. It should
be rare and doesn't seem very important to fix.
Bug: 178651829
Test: atest CtsTranslationTestCases
Test: manual - across several apps, while scrolling, concurrently
interacting with the app, concurrently closing the app, selecting text
during the animation (with animation speed slowed down to see the
effect).
Change-Id: I08a26de2253bb345f01186a6748b2d0ff6c2a419
Reverting ag/13435448.
The bug that the change fixed was that TextView invokes classifyText
when the selection is going to be dimissed due to an ACTION_UP event.
The fix was that we only call showFloatingToolbar() if users are
dragging the selection curosr when we get an ACTION_UP event.
QA has found a bug recently.
When user selects some text and then scrolls the TextView, we hide the
floating toolbar temporarily. When user finishes scrolling, TextView
does not reshow the toolbar immediately due to the fix.
I don't have a fix that I feel comfortable to get into S given
that we are pretty late in the process, so reverting the fix.
Some more details:
IMO, the fix should be calling showFloatingToolbar() only if
TextView has a selection(i.e. TextView.hasSelection()) when we are
processing the ACTION_UP event in updateFloatingToolbarVisibility().
Sadly, it does not work because the selection is not actually dismissed
yet when we are trying to update the visiblity of
the floating toolbar in updateFloatingToolbarVisibility().
The selection is actually dismissed when Editor.onTouchUpEvent is
called to handle the UP event, but updateFloatingToolbarVisibility() is
called before that :/
Moving around the code so that updateFloatingToolbarVisibility() is
called after Editor.onTouchEvent() may work, but I am not comfortable
to get in a risky change like this at the moment.
Reason for revert: b/187862341
Bug: 187862341
Change-Id: Ic49c6792dc86c01fcc78a4d3bc5bfd85b7772197
Bug: 188531406
When an EdgeEffect is flung past 0 into negative values, it
shows a stretch from the other side. To prevent this, the EdgeEffect
animation is now terminated when it reaches 0. I also made it so
that dragging to a value of 0 releases the EdgeEffect.
I also fixed the nested scrolling so that the stretch release
of ListView occurs before the onNestedPreScroll().
Test: new tests and manual testing
Change-Id: Ia20a6b96d25cf31ef143511828ddce5c33cee804
Currently, TextView uses its default implementation even developers
uses setViewTranslationCallback() to set their customized
ViewTranslationCallback, we should only set default TextView
implementation if developers don't set it.
The onViewTranslationResponse() will call getViewTranslationCallback
instead of getting TextView default implementation directly. This can
make sure we can get the expected ViewTranslationCallback.
Bug: 183467275
Test: manual
Test: atest CtsTranslationTestCases
Change-Id: I41417140f8985aec6c80f1bca3cfba804727d5df
When the unchecked length of the current sentence is too long, the
spell checker should check the first MAX_SENTENCE_LGNTH characters of
the unchecked part. In this case, detectSentenceBOundary should return
[textChangesStart, textChangeStart + MAX_SENTENCE_LENGTH)
Fix: 188875278
Test: manual test
Change-Id: I31847aed2d564f7bc1ff43c83adae3bb7c99c0d1
The the text is changed, we need to remove all affected SpellCheckSpan.
However, the previous check logic can not work correctly, and may
leave some out-of-date SpellCheckSpan, which causes problem when the
SpellChecker tries to apply suggestions on those spans later.
Also fixed the bug that the offset is not calculated correctly when we
validate spell checker suggestions.
Fix: 188107864
Change-Id: I8dc806d96b6a75255277d6de013305557835cb6d
Test: atest CtsInputMethodTestCases:SpellCheckerTest
Test: atest android.widget.cts.TextViewTest
instead of everytime visibility changes
> Adding a broadcast receiver makes a synchronous system API call
which can delay draw pass
> Also removing TIME_TICK broadcast, instead using an internal timer
to aboud unnecessary calls while app is stopped
Bug: 188574817
Test: Manual
Change-Id: I37677aa40189bf4fb75e7e2372bda81ea3e6fda3
If an application caches an ApplicationInfo and uses it to call
Context#createApplicationContext, the app will not get the most recent
version of the overlays for that application. To make things worse, the
LoadedApk stored in ActivityThread#mResourcePackages is updated using
the old ApplicationInfo causing further uses of the cached LoadedApk to
return outdated information.
Deprecate Context#createApplicationContext, convert all internal uses
to Context#createPackageContext(String packageName, ...) and log
whenever any one calls Context#createApplicationContext with an
outdated ApplicationInfo to detect debug issues in using old infos.
Bug: 188059515
Test: change wallpaper and observe widgets get reloaded with most
recent overlays
Change-Id: I2aeefa8c0e66264859109975a54c4f73f76ad710
Screen reader(Talkback) will read content description first if the
developers set. We only translate TextView text, this may cause the
screen reader will not read the translated text if the developers set
content description.
To fix the issue, we also send the content description to translate.
When the translated text is shown, we also set content description
with translated content description and reset to original content
description if show original text.
Bug: 187134784
Test: atest CtsTranslationTestCases
Change-Id: I6986384260627a0539780b7293d47666c442d852
Fixes: 158448787
When the day is earlier in than the minimum date, but
the year is later, then the year is changed, the date
gets set to a day that is earlier than the minimum date.
This CL ensures that the year change can't bring the
date outside of the range of minimum to maximum dates.
Test: manual testing
Change-Id: I0034bd513275267ecf9554f673533852e68dd854
This addresses rounding of the seconds hand fraction to avoid
advancing by inconsistent amounts.
It also moves to a less janky 30FPS update rate.
This also optimizes seconds ticking to only schedule callbacks as needed
and avoids spurious updates to the content description.
Also, potential NPE fix and dead code removed.
Bug: 186099601
Test: Local testing with sample app
Change-Id: I771b4c3f1d18f7836cd42202810a1495d25a9db5
A ClipData can contain multiple items, for example:
```
ClipData clip = ClipData.newPlainText("label", "ONE");
clip.addItem(new ClipData.Item("TWO"));
clip.addItem(new ClipData.Item("THREE"));
```
When a clip like this is pasted, the TextView impl inserts a newline
between each item. When the same clip is inserted via drag-and-drop,
no newlines are inserted.
This change makes the behavior of drop and paste consistent by updating
drop to match the paste behavior (since pasting has been around longer
and is more common).
Bug: 187428338
Test: atest CtsWidgetTestCases:TextViewReceiveContentTest
Change-Id: I08f30e619b858a4586ab9b4ed287be28b218231e
When a ProgressBar is set to indeterminate, we assign a default
state description of "in progress" to AccessibilityNodeInfo. We
only assign default state description to AccessibilityNodeInfo,
but not to View. If the developer
sets a custom state description through either View API or
AccessibilityNodeInfo API, the custom state description will
be used for both indeterminate and determinate progressbar instead
of default ones.
We put the "in progress" in state description instead of content
description to prevent accessibility services like talkback from
automatically assigning a state description when the state description
is null or empty.
Fix: b/182582617
Test: tested manually with a material linear indeterminate progressbar
with talkback. It says "In progress, progress bar".
Unit tests added.
Change-Id: I24477622bf8992f80a19b8df3a6032bac7f9d5bd
This ensures that adapters have their caches filles and other benefits
such as lists maintaining their scroll positions
Bug: 183503469
Test: validated with local app that service is not called on drag for
colors changing and that flicker is removed
Change-Id: I043d1d7a547b012f7a12eb555b35854a9bb7109b
Bug: 186430321
ListView should accept a fling while stretching.
Test: New test
Test: manual testing
Change-Id: I67221e06818d9953882e16d1c72f2d9e6b191ebb
