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
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
* 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
At line break, one offset can be mapped to two phisical
position: previous line end and next line start.
Previously, all cursor handles are placed at next line
start.
With this CL, selection end handle is placed at the
previous line end in such cases.
Test: FrameworksCoreTests
Bug: 21305922
Change-Id: I00d9f9a0cd417ca92534e93b3d3f655cd62f25d3
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: I249d464f8cdaa56017a987588b94ed685aadeb58
ActionBar keyboard navigation logic is now implemented via clusters.
Old implementation using setTouchscreenBlocksFocus and Ctrl+Shift+<
shortcut is removed.
Looking at the code, I can’t rule out existence of all 3 categories
(1) action bars with a nested toolbar, (2) action bars without a
nested toolbar and (3) Toolbars outside of action bars.
Because of this, I set “cluster” attribute both on action bar and
toolbar, and have code to avoid nested clusters in case (1).
Support lib’s action/tool bars aren’t converted, however, they
didn’t regress since Ctrl+Shift+< never worked for them. Will be
done after feature freeze.
Bug: 32151632
Test: Manual checks.
Change-Id: Ieb93980088c0fb385a9bc8a5d218ffc269b94dc5
- Explicitly split View methods into Assist and AutoFill methods, rather
than use an overloaded method that takes flags.
- Simarly, renamed ASSIST_FLAG_SANITIZED_TEXT and
ASSIST_FLAG_NON_SANITIZED_TEXT flags to
AUTO_FILL_FLAG_TYPE_FILL and AUTO_FILL_FLAG_TYPE_SAVE respectively.
- Created a AutoFillUI class to host the auto-fill bar and other UI
affordances.
- Moved the temporary notifications to AutoFillUI (eventually that
class will host the real UI).
- Moved FillData to android.app.view.autofill package.
- Split IAutoFillCallback in 2 (IAutoFillAppCallback and
IAutoFillServerCallback, residing at the app and system_server
respectively), so service cannot fill the app directly (which lets
the framework control the UI).
- Moved assist's IResultReceiver to AutoFillServiceImpl so
system_server can act as a mediator between the AutoFillService
implementation and the app being auto-filled.
- Replaced FillData and FillableInputFields by a bunch of new objects:
- FillResponse contains a group of Datasets, each representing
different values
that can be used to auto-fill an activity (for example, different
user accounts), optional id of fields the service is interested
to save, and an optional bundle for service-side extras.
- Dataset contains a name, Fields, and an optional bundle for
service-side extras.
- Fields contain an AutoFillId (parcelable) and a value (Bundle)
- Changed the temporary notifications to emulate the new workflow:
- Initial notification requests the auto-fill data but do not
auto-fill.
- Once service calls back, a new notification is shown with the
results.
- Then if the user selects a dataset, the activity is auto-filled
with it.
- It also shows a notification to emulate what can be saved.
- Created an VirtualViewDelegate for views that uses a virtual
hierarchy for assist data.
- Added new methods on ViewStructure to add children with virtual ids.
- Added 2 methods on View to support auto-fill:
- autoFill(Bundle) to auto-fill the view.
- getAutoFillType() to return how the view can be auto-filled.
- AutoFillType defines the input fields that support auto-fill:
- Text fields (like EditText)
- Toggle fields (like CheckBox)
- Lists (like RadioGroup)
- AutoFillType can also have a sub-type representing its semantic (for
now only text fields have it, and it's the same as getInputType()).
- etc :-)
Bug: 31001899
Test: manual verification
Change-Id: I2dd2fdedcb3ecd1e4403f9c32fa644cb914e186f
Adds a new get/setJustify API to TextView and StaticLayout.Builder for
justification, and fully justifies text when it's enabled.
This is based on a patch by Raph Levien (raph@google.com).
Bug: 31707212
Test: Manually done and CTS will introduced with
I0f3bbf39d60a66b71b30e1351f7c741208f05dce passes.
Change-Id: Icbfab2faa11a6a0b52e6f0a77a9c9b5ef6e191da
To understand this change it's first helpful to review Toasts.
The ViewRoot is constructed on the client side, but it's added,
to a window token controlled by the NotificationManagerService.
When we call NotificationManagerService#cancelToast, the system
will remove this window token. With the window token removed,
the WindowManager needs to destroy the surface to prevent orphaned
windows. If we destroy the Surface before removing the toast on the
client side however, we've never asked the ViewRoot to stop rendering
and we could have a crash. To solve this we just have to ensure we call
removeView before cancelToast.
Bug: 31547288
Bug: 30150688
Change-Id: Ic7e8914a7fb2134a8b9e0c2f3810d7f075c8391e
