See Ia9081d92ae9aea50d863455be770eecd0c73be1a for multi-selection
counts.
Test: Manually checked logging happens as per go/tron-howto and verified
nothing is broken in related classes by running:
bit FrameworksCoreTests:android.widget.TextViewActivityTest
bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Bug: 32572232
Change-Id: I4ceab136ab73a20c6bc56732f7606ed103fe64d3
Fix a bug where the internal date/time picker views reused view IDs
causing state save/restore bugs when placed within AlertDialogs and
other places. Since the pickers already save/restore their state at a
higher level leaving this enabled was redundant.
Bug 32654446
Test: manual
Change-Id: I3df2fc932ac5296ab6eb0a5013dddef8d1117635
Previously, onDragEvent() tried to set the anchor even if
the text was not Spannable. Now we check to make sure it is
Spannable before trying to set the selection.
Test: cts-tradefed run cts-dev --module CtsTextTestCases
Change-Id: I835bf3d6024bf3c85e1d248458829eef496ad93d
Fixes: 37261326
Running cancel after toast is shown and adding some UI stress (or sleep
on UI thread) causes a crash from toast when trying to add the toast
window to the display. The toast must be triggered from app that is
above N MR1 (25).
The steps that crash the app are:
1. Show toast (Toast.makeText(...).show()), window token is created
2. Immediately cancel toast (Toast.cancel()), window token is removed
3. Stall UI thread (Thread.sleep, heavy task), both show and cancel
events are queued to UI thread from window manager
4. Crash trying to add toast but no window token exists
In Toast:handleShow(), the mNextView is required to add the toast to
display, if the mNextView is null before posting to window manager, then
when handleShow() runs later, it will ignore adding the toast to
display. The issue before is that mNextView is set to null after cancel
runs back from window manager in UI thread but the show post will always
happen first. Therefore set mNextView to null at the beginning of
cancel will ignore adding the toast to display and avoid the crash.
Bug: 37606432
Test: manual - write an app to Toast.show(), Toast.cancel(), then
Thread.sleep(), set app's sdk usage above 25 (N MR1) and show the
toast
Change-Id: I352e296c47b1b8776c78b6b0943b1dc809963026
Previously the icon was an event icon, but a clock icon is
more appropriate so we are switching to that instead.
Bug: 37351390
Test: Open time picker
Change-Id: I47e6caf3c341c10264168004628288fd00e4601a
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Change-Id: I0b5ebb8d6f1af1a9938151f758a2feedb14fcb9f
Fixes: 38244876
Some apps were relying on TextView favoring focusable over
focusableInTouchMode when they were explicitly set to
opposite values in XML (usually because they start with an
EditText and only set focusable=false). This behavior is
undefined (and is, in-fact opposite to every other View).
In order to keep backwards-compatibility, this restores
the old behavior.
Bug: 36497135
Bug: 37916052
Test: Tested those apps and they behave like they used to.
TextView CTS still passes.
Change-Id: I65bd1b343a6dfb087f41c9fc8af4b5c1e4c71493
Logs:
- Smart selection occured
- TextView menu item activated on smart selection
- Smart selection reset
- Smart selection modified
Test: Manually checked logging happens as per go/tron-howto and verified
nothing is broken in related classes by running:
bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
bit FrameworksCoreTests:android.widget.TextViewActivityTest
Bug: 32572232
Change-Id: Ia9081d92ae9aea50d863455be770eecd0c73be1a
When configuring a TextView to auto-size via min/max/granularity
do the calculations in float pixels and only convert to int (via
rounding, see TypedArray#getDimensionPixelSize) to produce the
final text size values to be used by the auto-size algorithm.
This is because the previous version where the values were
initially directly converted to pixels and only after used in
calculations was losing precision and was not consistent with how
we deal with preset configuration (and the developer
expectations).
Practically
textView1.setAutoSizeTextTypeUniformWithConfiguration(10, 20, 2,
TypedValue.COMPLEX_UNIT_SP)
and
textView2.setAutoSizeTextTypeUniformWithPresetSizes(
new int[] {10, 12, 14, 16, 18, 20},
TypedValue.COMPLEX_UNIT_SP);
produce exactly the same values in pixels to choose from when
auto-sizing (on any device) =>
(TextView#getAutoSizeTextAvailableSizes())
Bug: 38185233
Bug: 37265610
Test: attached in the same topic
Change-Id: I95cbbf4674e98f080d7752ae350df26b4adf31b4
My change to remove "speak passwords" set things up as if
the user had permanently enabled speaking of passwords.
That mode seems to go too far, though. It would speak the
password content even if it wasn't shown on the screen.
This change reverts a small part of ag/1900438 to avoid
populating text changed accessibility events with the plain
text of a view that is concealing that text from users who
are looking at the screen.
I'm tempted to populate the event instead with the
transformed text, but I'm concerned that corner cases may
exist where the transformed text is not valid in the
beforeTextChanged callback. This change seems safer, as it
is just going part way back to the pre-O behavior.
Bug: 38172502
Test: Verified that letters in the WiFi password are no
longer read out when they are deleted.
Change-Id: I1a000ee7f87c334a0d38248ce9ad120f43d12256
If other's child is added to ListView as header/footer, it may crash
while layouting. To notify users invalid use case, the CL adds warning.
Bug: 37726743
Test: Manually inspect logcat after adding other's child as header.
Change-Id: I1a66fa9a74e4f15e9d8a696a3957db88fc5bbfbe
Using the same method as getBoundsInScreen.
Bug: 35095925
Test: Manually verified location with test app, ran a11y cts
Change-Id: I1eee2a4eb23912698be61c9030d92bbade1d743a
classifyText() is used to generate a menu item in the selection toolbar
to handle the selected text. In this cl we avoid calling classifyText()
when the selection is changing but instead call it when we are about to
show the toolbar.
Previously, we depended on invalidateActionModeAsync() to classify text
after a call to startActionMode(). Now that we've introduced
invalidateActionMode() we need to be able to tell
startSelectionActionMode() that we also want the text to be classified,
hence the introduction of an input parameter, "adjustSelection", to
startSelectionActionModeAysnc().
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Bug: 34966796
Change-Id: I5b9fc9e8ab443f024f8ca461df5a4bcc6485d26b
This reverts commit 358d0d3297.
This CL resulted in b/37933333 regression, so it'll have to re-land with a target API check.
Change-Id: I1c2e4de43a15c1851d98f6aff432585ada80fb5b
- Sending scroll events for accessibility.
- Sending text update events when state changes.
- Blocking text updates during fling to reduce number of events.
- Making widget focusable by default, which keeps focus from
moving to the rest of the UI when the text box becomes invisible.
- Managing visibility of the text box alongside IME state, so the
IME won't decide to display the password keyboard during a fling.
Bug: 21494380
Bug: 37016501
Test: Ran NumberPicker CTS
Change-Id: I459d37d4a54c91e1cb5c7ec68fe0f012b25fb740
Currently VideoView.onTouchEvent and VideoView.onTrackballEvent do not
call super. This completely disables several useful View features
such as long click, context menu or tooltips.
Bug: 37755662
Test: manual
Change-Id: I0c82c32da36e4ca7cacc78027daed2fa298a6b58
