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
ListView historically uses View#hasFocusable to change signifcant
behavior around the clickability of items: an item view with any
focusable children could not be clicked via an item click
listener. Many apps therefore have sub-views in list items that are
deliberately clickable, but not focusable. This comes up in cases like
overflow menu buttons on list items.
Now that we have auto-focusability triggered when a view is set as
clickable, the expectations of apps using this pattern have changed.
Create an overload of hasFocusable that optionally can filter out
auto-focusable views in its results. Have ListView use it to preserve
its previous behavior. This isn't public API for now, but perhaps it
should be if this pattern shows up in practice in places other than
ListView.
Bug: 34756767
Change-Id: Ie71ee6e388449f634b30f9162a8b3fa578e32db8
This change implements the loading and parsing
of xml type font resources, and makes sure it is
used properly by TextView styles.
Test: run cts -m CtsContentTestCases -t android.content.res.cts.ResourcesTest
run cts -m CtsWidgetTestCases -t android.widget.cts.TextViewTest#testFontResources*
Change-Id: I5a2930b3ba7dad67d9607e9036a5dde6bab0c5a4
Removes all explicit casts from android.widget classes. Also @removes
methods on ListView that were overriding @hidden methods and should
never have been exposed as public API.
Bug: 24137209
Test: make
Change-Id: I6ccfc6f001b355c4880f2b54e1a5474df78d6228
* Encapsulated application-level auto-fill logic on AutoFillSession.
Currently, Activity.java directly manages the IAutoFillCallback binder
object used to auto-fill its views, but this logic need to be
extended so Views can use it to draw the auto-fill bar.
* Pass auto-fill id and boundaries to requests
So AutoFillUI can display its affordance in the right places.
* Uses a new auto-fill id on View (instead of reusing accessibility's).
That allows moving the logic on whether a new request should be made or
the existing UI moved to the service side.
* Split service methods in 2, for shell cmd and app
And applied the right permission check on both.
* Removed CancelationSignal from onSaveRequest()
Since it's not really needed.
* Etc...
¯\_(ツ)_/¯
BUG: 34637800
BUG: 31001899
Test: CtsAutoFillServiceTestCases passes
Test: manual verification
Change-Id: Ibd0cb2cfff6d0f6bb6b697a423ed5e89df687b82
- Created an AutoFillManager class, which provides methods to show
the auto-fill bar for views and virtual nodes.
- Automatically launches an auto-fill request when the IME is shown
(and an AutoFillService is set for the given user) on TextViews.
- Updated VirtualNodeListener to use this new API.
BUG: 31001899
BUG: 34171325
Test: CtsAutoFillServiceTestCases passes
Test: manual verification
Change-Id: Id72ce97da70217081b5823cfc7b138412634fcf3
Rename to TextClassifier
Move to android.view.textclassifier package
Adds getTextClassifierInfo(...)
Changes addLinks(...) to getLinks(...)
This CL also integrates this interface with framework components
and passes a context to TextClassificationManager.
Test: Tests will be added with implementation.
Bug: 34661057
Change-Id: If9e90f034ebb702c1f78e72b6a844f39eebf738f
This method returns the ListView representing the menu.
It is required to test the actual contents of a PopupMenu.
Bug: 34076597
Test: android.widget.cts.ToolbarTest#testItemViewAttributes,
android.widget.cts.PopupMenuTest#testItemViewAttributes
Change-Id: Id72a8f482048d724d4fde15b126e0d08e1d18390
Contains:
* getters/setters for all auto-size config attributes
* verbose JavaDocs
* isolated and reused the setup part of auto-size
* some variables had to become instance fields
* clarified some variable names
In a few words, whenever a configuration setter is
called, the value is assigned and setupAutoSizeTextXY()
gets called. The latter tries to build all the
intermediary values that it needs, attaches default
values, etc. If it is successful then it makes a call
to autoSizeText(), else it throws a runtime exception
with an appropriate message.
Bug: 32221168
Test: attached in the same topic
Change-Id: I448454ef4490102c8cc2b19e0e16e998aeb45cd0
New android:focusable attribute value "auto" and corresponding constant
FOCUSABLE_AUTO specifies that the framework can determine a view's
focusability. For now, the only "auto" logic is that focusable = clickable.
This has the effect of making clickable views focusable by default
unless the developer has explicitly set them focusable=false.
Bug: 31963283
Change-Id: Icce768fa701966970ea6b3469b33a4ef97ebc3ea
Test: Added CTS test, related CTS passes, made a test-app which
enumerates all clickable/focusable combinations to verify
When DynamicLayout is used, max line is not set for
computing layout even if TextView has the limit. So, we
still need to use getLineTop in getDesiredHeight.
This bug was introduced by I1e1cae31cf33d503a8cf.
Bug: 34279529
Test: manually tested
Test: android.widget.cts.TextViewTest
Change-Id: I9b7a3c46e7671a84e6a830eb962a49d2b0856eab
This will hopefully avoid blaming sysui for ANRs when the system
is hosed.
Test: Manual, build, push, wait for time to change
Change-Id: I1661ac1a997ad8917b449dd175229d8b77f583c9
Using textSize as maxTextSize for autosizing is buggy and
unclean. Introduce and use new autoSizeMaxTextSize attribute for
TextView.
Also while doing this optimized the auto-size process by removing
unnecessary computations:
1. If auto-size is enabled than setTextSize(...) is no-op.
2. After setting the text size internally and from the auto-size
context onMeasure() will stop doing another round of redundant
measurements..
Bug: 33449596
Bug: 32221168
Test: atttached in the same topic
Change-Id: Ieecaea6df0aebb4c182bdd1114e3c6fc5066bed1
