Gets rid of setting auto-size configuration
items one by one and instead provides setter
constructs that take all the params needed
to auto-size. This version is much closer to
how this feature can be set up from XML
attributes and also provides no doubt about
validation failures.
Bug: 32221168
Bug: 34494052
Test: in attached topic CL
Change-Id: Ic70ad43d5c6739ee312ea24984534a35c49c17dc
Currently the icon defined by the host AbsListView is displayed
over the fast scroll area.
Bug: 35424111
Test: manual
Change-Id: Ia9897a44550922f16573b97337841c3f6ae263da
This cl also updates label strings, renames an internal method,
and fixes some bugs in TextClassifierImpl caught by tests.
Test: See: I31ee94177e58c986e61e9b24c6c5816fa4b022e1
Bug: 34778263
Bug: 34922928
Change-Id: Ibf60d345d462dfc8a13dead6f01053f1ae50f35a
Doing this allows us to annotate integer values that should corresponds
to WindowManager.LayoutParams#softInputMode.
Test: There should be no behavior change. RetentionPolicy.SOURCE
annotation should change nothing in production code.
Test: checkbuild
Bug: 32784563
Bug: 35079353
Change-Id: I96300b090edce327d0515c740183abe91ded6bac
Reverts the change which adds a gesture detector in
TextView for detecting clicks on ClickableSpans. A click
is considered MotionEvent.ACTION_UP. Revert needed because
the singleTapUp refactoring has a potential to break
existing apps.
Bug: 23692690
Test: attached in the same topic
Change-Id: Ife47fd0608480130123091bc60a7e9dd1efe8785
The current PopupWindow implementation might call
the anchor view's getLocationInWindow even if the anchor
is currently detached from the window (and the location is
a meaningless (0,0)). This results in the popup jumping to
the top of the screen.
This patch is adding tracking of the anchor's attachment state.
The position is never updated while the anchor is detached.
When the anchor is re-attached, the popup position is updated.
Bug: 34853580
Test: manual (see bug)
Change-Id: Icca1b9b558a70ee3edbe6236e076d2d08a1f8f11
This CL is no-op (cosmetics only)
* renames autoSizeText type "xy" to "uniform"
* renames attribute "autoSizeStepSizeSet" to "autoSizePresetSizes"
* renames "AUTO_SIZE_TEXT_TYPE_XY" to "AUTO_SIZE_TEXT_TYPE_UNIFORM"
* renames public TextView#getAutoSizeTextPresetSizes() to public
TextView#getAutoSizeTextAvailableSizes() because this method can
return either preset sizes or computed sizes (via min/max/step)
Bug: 34923754
Bug: 32221168
Test: associated test renames in the same topic
Change-Id: Ifacccf21ca014b6c0a07322fa02b7859ee53e387
1. Menu groups are now separated by dividers
2. Update to menu item spacing as specified in new UX mocks
3. TextView-Editor now passes the "assist" menu as a group
4. "Share" menu reordered after "Cut/Copy/Paste" as per UX mocks update.
Test: Manual tests.
Bug: 34777048
Bug: 34777833
Change-Id: I3d435d8a38e5b146a54706f12dbf3ff629c504bf
* getter/setter for predefined sizes
* reads and configures from XML at construction time
* fix for an ugly bug where the sizes were missing an
entry in certain cases, e.g: min = 10; max = 20;
step = 2 would have produced [10, 12, 14, 16, 18]
instead of [10, 12, 14, 16, 18, 20]
* fix using getHeight()/getWidth() instead of
untrusted getMeasuredHeight()/getMeasuredWidth()
and move the auto-sizing triggering to
onLayout() instead of onMeasure() (while manually
testing discovered missing or extra pixels and
sometimes resizing being skipped - it's all fixed
now)
* fix using deceiving getTotalPaddingBottom()/...Top()
and replaced with getExtendedPaddingBottom()/..Top()
(getTotal... was removing the whitespace height but
auto-size needs to know about it so it can fill the
space)
Bug: 32221168
Test: attached in the same topic
run cts-dev -m CtsWidgetTestCases -t \
android.widget.cts.TextViewTest
Change-Id: Id5a31d0d32b2b4082af45b4bd65af8cb85bdc92e
Existing apps have copies of ListView behavior that expects the old
hasFocusable behavior of only reporting explicitly focusable views.
Use targetSdkVersion to give the old behavior to existing apps.
Add hasExplicitFocusable method to View to offer the old behavior
to apps that need it. ViewCompat method required in support library
to shim through to hasFocusable pre-O.
Bug: 34946284
Test: CTS
Change-Id: I65503fa2c5fe4cb8b635efa464e653bbf5e7f821
Text selection is now started/updated using AsyncTasks that first get
a result from the TextClassifier before actually starting/invalidating
the actionMode on the UI thread with the result.
Bug: 34778899
Test: cts-tradefed run cts-dev -m CtsWidgetTestCases -t android.widget.cts.TextViewTest#testSmartSelection
Change-Id: Ie7eda04bb64335744d88b8874363d46af4f94742
This is yet another big refactoring:
- AutoFillManager keeps track of its current AutoFillSession.
- Views call AFM.startSession(View) when they can trigger autofill.
(virtual views can call it as well). At this point, the manager
sets an AutoFillSession, gets the activity token, and passes it to
the service.
- Subsequent calls to AFM.start() will be ignored since the session
is set.
- When the Activity is gone, it calls AFM.finishSession().
- Simlilarly, virtual views could call it as well.
- Added getAutoFillValue() to View.
- Removed AFM.updateAutoFillInput(childId): virtual views should now
call startSession(childId) to start a session, and use the
VirtualViewListener callbacks for updates.
- Change AutoFillValue to use String (which is immutable) instead of
CharSequence for text values.
- Check if view is enabled before auto-filling.
- Removed 'cmd autofill fill' since it would require the appCallback
- Automatically dismiss the snack bar after 30s
- Moved the "don't change autofill value when autofilling" Inception
logic into the service side.
- Etc...
BUG: 34819567
BUG: 33269702
BUG: 31001899
Test: manual verification
Test: CtsAutoFillServiceTestCases passes
Change-Id: I5fad928d4d666701302049d142026a1efa7291cd
Previously (post Android N) we decided to introduce
a gesture detector in textView and trigger the onClick()
over a clickable span when onSingleTapConfirmed was
called. The problem is that onSingleTapConfirmed also
waits for double tap timeout to make sure (to confirm).
This has a chance to break some apps so relax the
rule to only look for onSingleTapUp.
* the bug for which the initial change was made is
still fixed
* slightly amended the ClickableSpan JavaDoc to
specify that the onClick gets triggered if the
span is selected when clicked (note that this
behavior is unchanged since ClickableSpan exists,
added just an extra hint to devs)
Bug: 23692690
Test: in the attached CL (same topic)
Change-Id: Iead434aa558301d61879c27edc48dc4148ca187f
Gracefully handles situations where a default app cannot be found
to handle the intent.
1. If we can not find any app to handle the intent,
do not include an "assist" menu item entry to fire the intent.
Also, do not linkify the entry.
2. If we do not have a default app to handle the intent,
show a generic title for apps that will handle the intent
and do not include an icon.
In the ideal case where we find a default app to include the intent,
show the app's (preferably activity's) title and icon.
Test: Manually tested. There's an AI to write more automated tests.
Bug: 34777322
Bug: 34927631
Change-Id: Ia94efbbdda3da8f181fac9228cd2d3a76cb727d3
Currently, the onProvideAutoFillStructure() methods can be called
twice: to auto-fill an activity and to save the activity's data
in the service.
The problem with this approach is that when the save workflow is
called, the activity might have been gone. Hence, a proper approach
is to keep the initial AssistStructure data in the system_service
memory, watch for view changes, and then passed the new structure
back to the AutoFillService.
A side effect of this change is that we need another way to determine
if the view is sanitized or not. For "standard" views, that will be
defined based on whether the view content come from a resource or not,
but that logic is not implemented yet (for now, all views will be
considered sanitized, except for TextView passwords). For "custom"
views (such as WebView), this logic is responsibility of the view
implementation, through the newChild() method, which now takes a
flag (whose value could be AUTO_FILL_FLAG_SANITIZED for sanitized
views).
The SaveCallback.onSuccess() method was simplified: it does
not need a list of saved ids anymore the auto-fill UI will not use it
anymore.
Another side effect is that the Save notification is gone - until
it's attached again, it can be test by using:
adb shell cmd autofill save
Finally, hook AutoFillUI on ACTION_CLOSE_SYSTEM_DIALOGS events.
BUG: 33269702
BUG: 31001899
Test: manual verification
Test: CtsAutoFillServiceTestCases passes
Change-Id: I907a7e21d1b3cd1ab6dec3a08d144a52655da46f
The wrong TypedArray was being used to retrieve the value.
Bug: 34818260
Test: run cts -m CtsWidgetTestCases -t
android.widget.cts.TextViewTest#testFontResources_setInXmlStyle
Change-Id: I09334710b9b21f1397bc02d92d14b41fbc96178f
getRelatedView(int[] rules, int relation)
is stuck in the loop, when a view is GONE, and references itself.
There is already a check in:
getSortedViews(View[] sorted, int... rules) {
to make sure there are no loops of ViewA -> ViewB -> ViewA
BUT, there was a change made in findRoots(int[] rulesFilter)
to "Remove exception throw when a view has a self dependency
inside a RelativeLayout." so this means we must allow this case.
Other change git commit sha: da3003e1d7
Bug: http://b/android.com/231353
Change-Id: Icc26b86ebbb19e482c3afe6a39db996ec493586d
Testing utilities want the ability to know whether things in the UI
are in flux and they need to wait before testing on-screen values.
These changes (a subset of what's needed, but will have to do for
a start) allow querying of ActivityTransitions and ProgressBar, two
common/difficult pieces in the puzzle.
Test: CTS tests at ag/1835467
Bug: 30978257 Provide view transition Api to prevent flaky tests
Change-Id: If63b3d0dde2178d826ac1dbfad0fc50e5ed9a780
This is 2nd attempt of I249d464f8cdaa56017a987588b94ed685aadeb58.
The original CL was reverted due to conflicting with another CL submitted
before.
Nothing has changed except for following class name changes.
Here is the original commit message of reverted change.
This CL enables developers to specify axis values to the underlying
font collection. The specification of the font variation settings is
the same as the CSS font-variation-settings attribute in CSS working
draft as of 2016-11-30.
Code example: Here is an example to set width 100 and weight 1.5.
TextView tv = (TextView) findViewById(R.id.textView);
tv.setFontVariationSettings("'wdth' 100, 'wght' 1.5");
Bug: 33062398
Test: Manually done. Ran FrameworksGraphicsTests, CtsGraphicsTestCases
and CtsWidgetTestCases
Change-Id: I9cdfbdecc87c995d805096883ef2652768c6c21e
