In particular, we now honor android:textAllCaps in the
TextAppearance specified for the switch widget itself.
(Now you no longer need to create a separate capitalized
version of your strings to get them to look like the
platform switches.)
Change-Id: Ia48222a6dddd0d0f9115e554dffb621f4d6a2b94
Fixes b/6341858 AdapterView does not properly check for null before checking empty view accessibility info
Change-Id: Ia19fdef2c7c5f3e6c3053ebc754efe6a664f9d66
Usefulness: Keep track of the current user location in the screen when
traversing the it. Enabling structural and directional
navigation over all elements on the screen. This enables
blind users that know the application layout to efficiently
locate desired elements as opposed to try touch exploring the
region where the the element should be - very tedious.
Rationale: There are two ways to implement accessibility focus One is
to let accessibility services keep track of it since they
have access to the screen content, and another to let the view
hierarchy keep track of it. While the first approach would
require almost no work on our part it poses several challenges
which make it a sub-optimal choice. Having the accessibility focus
in the accessibility service would require that service to scrape
the window content every time it changes to sync the view tree
state and the accessibility focus location. Pretty much the service
will have to keep an off screen model of the screen content. This
could be quite challenging to get right and would incur performance
cost for the multiple IPCs to repeatedly fetch the screen content.
Further, keeping virtual accessibility focus (i.e. in the service)
would require sync of the input and accessibility focus. This could
be challenging to implement right as well. Also, having an unlimited
number of accessibility services we cannot guarantee that they will
have a proper implementation, if any, to allow users to perform structural
navigation of the screen content. Assuming two accessibility
services implement structural navigation via accessibility focus,
there is not guarantee that they will behave similarly by default,
i.e. provide some standard way to navigate the screen content.
Also feedback from experienced accessibility researchers, specifically
T.V Raman, provides evidence that having virtual accessibility focus
creates many issues and it is very hard to get right.
Therefore, keeping accessibility focus in the system will avoid
keeping an off-screen model in accessibility services, it will always
be in sync with the state of the view hierarchy and the input focus.
Also this will allow having a default behavior for traversing the
screen via this accessibility focus that is consistent in all
accessibility services. We provide accessibility services with APIs to
override this behavior but all of them will perform screen traversal
in a consistent way by default.
Behavior: If accessibility is enabled the accessibility focus is the leading one
and the input follows it. Putting accessibility focus on a view moves
the input focus there. Clearing the accessibility focus of a view, clears
the input focus of this view. If accessibility focus is on a view that
cannot take input focus, then no other view should have input focus.
In accessibility mode we initially give accessibility focus to the topmost
view and no view has input focus. This ensures consistent behavior accross
all apps. Note that accessibility focus can move hierarchically in the
view tree and having it at the root is better than putting it where the
input focus would be - at the first input focusable which could be at
an arbitrary depth in the view tree. By default not all views are reported
for accessibility, only the important ones. A view may be explicitly labeled
as important or not for accessibility, or the system determines which one
is such - default. Important views for accessibility are all views that are
not dumb layout managers used only to arrange their chidren. Since the same
content arrangement can be obtained via different combintation of layout
managers, such managers cannot be used to reliably determine the application
structure. For example, a user should see a list as a list view with several
list items and each list item as a text view and a button as opposed to seeing
all the layout managers used to arrange the list item's content.
By default only important for accessibility views are regared for accessibility
purposes. View not regarded for accessibility neither fire accessibility events,
nor are reported being on the screen. An accessibility service may request the
system to regard all views. If the target SDK of an accessibility services is
less than JellyBean, then all views are regarded for accessibility.
Note that an accessibility service that requires all view to be ragarded for
accessibility may put accessibility focus on any view. Hence, it may implement
any navigational paradigm if desired. Especially considering the fact that
the system is detecting some standard gestures and delegates their processing
to an accessibility service. The default implementation of an accessibility
services performs the defualt navigation.
bug:5932640
bug:5605641
Change-Id: Ieac461d480579d706a847b9325720cb254736ebe
Add layout bound metadata to 9-patch files and make layouts take them into account.
This CL contains a proposed API for dealing with layout bounds.
This solution exposes:
1. Class: Insets - for storing layout Insets (and later possibly padding).
2. Methods: View:(get/set)LayoutInsets() - for storing layoutBounds.
3. Methods: ViewGroup:(get/set)LayoutMode() - for controlling layoutMode.
It also iuncudes the changes to GridLayout to support layout bounds.
Change-Id: I60c836b6530b61c5abf37f93ee9c44aad73573f1
When using the clipboard, ACTION_SEND, etc., you can now supply
HTML formatted text as one of the representations. This is exposed
as a set of methods on ClipData for building items with HTML
formatted text, and retrieving and coercing to HTML (and styled)
text. In addtion, there is a new EXTRA_HTML_TEXT for interoperating
with the old ACTION_SEND protocol.
Change-Id: I8846520a480c8a5f829ec1e693aeebd425ac170d
1. The reason for having this callback on the ShareActionProvider
is to notify the client that a share happened so he can update
the UI.
Change-Id: I65e8a8db8d4add0cd23d53be0286b14b4b4640b4
1. Switch was not populating the state on/off test in accessibility
node infos. It apparently has two texts, the state one and the
one it inherits from TextView.
bug:6213278
Change-Id: I9c6b1798a8b3230cfb6755cc5b088c320d991642
1. The NumberPicker scroll wheel was not updated upon value change
via an IME as well as the picker was not redraws after the change.
bug:6291879
Change-Id: I5ba30df42e38cd06fa150328399eb4deeb0b683d
1. NumberPicker was not preventing its predecessor from
intercepting touch events that are on top of it, hence
it was not flingable in scrollable containres.
bug:5661117
Change-Id: I145f59b069f479935f551bc5e841f13468a6c676
1. NumberPicker aims to reach the specified max width and height.
If the max width was not specified, the picker computes it by
measuring the widest value it will show. However, the case for
recognizing whether the max width is specified incorrect, hence
the max width was never measured.
bug:6193549
Change-Id: If67352a651e8d4a1d060868c876316e1c0e9bd0b
1. Accessibility services are the ones that choose how to
announces the checked state of a checkable control, so
CheckBox should not add strings for its state to access
events.
2. Removed some unused accessibility related strings.
bug:6241115
Change-Id: I572b961191da4b3537fb6cad529d9764d39161ec
Change View methods awakenScrollBars and scrollTo to post their
invalidation on the animation timer. Since these are often used in
computeScroll or similar to continue scrolling or flinging it should
not prevent other posted events from being processed before the frame
is actually drawn. (All changes in scroll position, etc. are
immediately reflected after the calls and do not need a draw to
present correct data about scroll position to apps.)
Don't accumulate floating point error while dragging
ScrollView/HorizontalScrollView.
Change-Id: I05b57d75f89a806488e46a8fb79b85d80f56d45d
Bug 6093695
Handle pending progress updates when a view is not attached when the
view becomes attached again. Batch pending progress updates together
rather than posting separate runnables for each.
Change-Id: I5dea671d5b9fbe1302912ca4734a63955e77ff4d
This is a new version of CL 179343 which had to be reverted.
This problem of the previous CL is that the ComposingSpan that
was part of the replacement text was correctly added during the
replace but was immediately removed because it had a zero-length
size.
Swapping the add and remove blocks solves the problem.
The new non-zero length enforcement also revealed a bug in the
spell checker where we were creating useless range spans.
Change-Id: I59cebd4708af3becc7ab625ae41bc36837f1a1cf
Also lock down the rest of the development tools permissions to
be development permissions that must be granted through an
explicit shell command.
Change-Id: I1ba216fffe1aab4bb9f83fcef108efc504f892f4
- fix bug #6163772
- use bits field and pack them as much as possible
- take care of "supportsRtl" flag from Manifest
- add visual unit tests
CTS unit tests in another CL
Change-Id: Ib77c4eb423854209af130688c5ef9977401a9c1c
Some views (such as ImageView and TextView) handle non-opaque alpha
values directly. This was originally an optimization, but we can handle it faster
in many cases without this optimization when DisplayList properties are enabled.
Basically, if a view has non-overlapping rendering, we set the alpha value directly
on the renderer (the equivalent of setting it on the Paint object) and draw each
primitive with that alpha value. Doing it this way avoids re-creating DisplayLists
while getting the same speedup that onSetAlpha() used to get pre-DisplayList properties.
Change-Id: I0f7827f075d3b35093a882d4adbb300a1063c288
1. Now the NumberPicker max height is a bit smaller.
2. The Time/Date picker add top and bottom margin to
compensate for the shorter NumberPickers.
3. The Time/DatePicker dialogs have only "Done" button
and tapping onside saves the current state.
bug:6277808
Change-Id: I4c5928debb1c3b7fe126d6cd6745e3c5eb980901
Editor specific method and fields are extracted to a dedicated Editor class.
Some private fields and methods had to be made package private so that the
Editor can see them. No change in the public API.
Other changes in this CL:
- The Blink class no longer has a WeakReference to the TextView
- EasyEditSpanController is no longer a field of ChangeWatcher.
Future work:
remove the getEditor() method in TextView and
clean whitespaces and indentation.
remove the EasyEditSpanController as a change watcher, fix spanWatcher
Change-Id: I1fbe0176b6bd27d90f556dc3a90469367f77437c
An Editable text will use a BoringLayout when the text is empty.
Fallback on the regular layout draw text method when the layout
does not support the block optimisation.
Change-Id: Ie4bdb4381f2f58b71d7c35b2f5734e544e3115ea
Bug 6241159.
onCreateInputConnection should not create an Editor but instead
should return an input connection iff the text is editable.
Change-Id: Ie9ea55b2467f5a40e6243b36f9b44fa6dfab586f
