Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
bit CtsWidgetTestCases:android.widget.cts.EditTextTest
Bug: 62271937
Change-Id: Ib3447281f3bd1abc811a25fc55ad55e34e155bbb
* splits the auto-size setup part from the execution
function:
** in TextView CTOR we only setup and we leave the
actual auto-sizing execution to happen in the
view||text layout phase
** encapsulated the conditions needed to start
applying auto-size in the execution function
* introduces a private way to set the text size
without requesting a new layout pass; auto-size
always uses this practically setting the text
size on the paint object and creating a new
layout
* calls execution autoSizeText() from within
TextView#checkForRelayout() if not requestLayout()
is needed => this makes sure that auto-size will be
performed even if a view layout is not requested,
but only a text layout
* fixes the calculation of the sizes available for
auto-size when configured via granularity
Bug: 62050646
Bug: 38409622
Bug: 38440435
Bug: 62109627
Test: run cts --test android.widget.cts.TextViewTest -m \
CtsWidgetTestCases
Test: manually tested the new behaviors in demo apps
Test: new test attached in topic
Change-Id: I4ccaa0a0afa3b5aa47213442d0029da2c74e7eb4
This commit specially checks isDefaultFocusHighlightNeeded for
ImageView. We should also check with the content drawable of the
ImageView besides its foreground or background.
Bug: 62141891
Test: cts-tradefed run singleCommand cts --skip-device-info
--skip-preconditions --abi armeabi-v7a -m CtsViewTestCases -t
android.view.cts.View_DefaultFocusHighlightTest#testIsDefaultFocusHighlightNeeded
Change-Id: Iaf12a5863d7760d9361d0196a46de07a9ccda74e
This CL early returns from auto sizing text if the view is not measured
yet.
Test: run cts --test android.widget.cts.TextViewTest -m CtsWidgetTestCases
Test: Added cts.TextViewTest#testAutosizeWithMaxLines_shouldNotThrowException
Test: Manual test with sample app for the failing case.
Bug: 38440435
Change-Id: Ic03c991f33a2b7701623f00f44cba7fb6cdfce46
Use the looper from the TextView's thread for the helper
Bug 62043115
Test: Manual, type on edit field and select text
Change-Id: I501430a500016a81963a9f9fa636474b708b9b36
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
We decided its better for tab to do something than to have no
tab navigation within GridView.
Also fixed a small bug that made backwards focus order not work
right.
Bug: 38264959
Test: Manually tested in test-app. Added basic CTS for tab keys
Change-Id: I8236deed26e6d8b8cae0130359b104af4d9a244d
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
