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
Added a getVibrator() method to InputDevice which returns a Vibrator
associated with that input device. Its uses the same API as the
system vibrator which makes it easy for applications to be modified
to use one or the other.
Bug: 6334179
Change-Id: Ifc7f13dbcb778670f3f1c07ccc562334e6109d2e
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
We were going to piggyback existing DataUsageFeedback.FEEDBACK_URI,
but decided to introduce a new URI for this.
Bug 5475575
Change-Id: I6d467e5342f551142f047aa1b0b3503c5bf9b7fd
Moved the core logic of Vibrator into SystemVibrator, potentially
allowing for the creation of other Vibrator subclasses.
Fixed several places where we were creating new Vibrator
instances unnecessarily instead of getting it from the Context.
It is safe to make Vibrator abstract because its constructor
was hidden from the SDK so it was not possible to subclass it.
Bug: 6334179
Change-Id: I18ece6544c26a7efb2d5099f8346a10aef8a5e18
This change allows the InputManager to keep track of what input
devices are registered with the system and when they change.
It needs to do this so that it can properly clear its cache of
input device properties (especially the key map!) when changes
occur.
Added new API so that applications can register listeners for
input device changes.
Fixed a minor bug in EventHub where it didn't handle EPOLLHUP
properly so it would spam the log about unsupposed epoll events
until inotify noticed that the device was gone and removed it.
Change-Id: I937d8c601f7185d4299038bce6a2934fe4fdd2b3
WebStorage and GeolocationPermissions are not intended for direct use
by application code. Existing APKs using this will still work (as well
as they ever could have), but this change will cause a compile break if they
move to SDK >= 16, which should be fixed by using getInstance() instead.
Bug: 6238010
Change-Id: I75789cc260c8fe005c42942bc81483193cc54f17
Camera autofocus move callback tells the clients when
continuous aufofocus is moving. Applications can show
autofocus animation based on this.
bug:5687212
Change-Id: I3191fd447b1e9de0ccf939eb346344f0be9bcf1a
Instead of each application loading the KeyCharacterMap from
the file system, get them from the input manager service as
part of the InputDevice object.
Refactored InputManager to be a proper singleton instead of
having a bunch of static methods.
InputManager now maintains a cache of all InputDevice objects
that it has loaded. Currently we never invalidate the cache
which can cause InputDevice to return stale motion ranges if
the device is reconfigured. This will be fixed in a future change.
Added a fake InputDevice with ID -1 to represent the virtual keyboard.
Change-Id: If7a695839ad0972317a5aab89e9d1e42ace28eb7
Simplified input injection API down to just one call.
Removed all input state reading API. It was only used by the
window manager policy and required a permission that applications
could not obtain. READ_INPUT_STATE is now unused and deprecated.
Change-Id: I41278141586ddee9468cae0fb59ff0dced6cbc00
Added a new InputManager service for interacting with input
devices and configuring them. This will be the focus of
an upcoming refactoring.
Added an API for registering keyboard layouts with the system
based on the use of a broadcast receiver. Applications can
register their own keyboard layouts simply by declaring a
broadcast receiver in their manifests.
Added the skeleton of a package that will ultimately contain
the keyboard layouts and other input device related resources
that are part of the base system.
Bug: 6110399
Change-Id: Ie01b0ef4adbd5198f6f012e73964bdef3c51805c
Promote navigation helpers from the support library to the core
platform.
The support library's meta-data element has been replaced with a
first-class parentActivityName attribute. This attribute is valid
on both activity and activity-alias elements. An activity-alias
will inherit the target activity's parentActivityName if one is
not explicitly specified.
Automatic Up navigation for Activities
Add the public method onNavigateUp() to Activity. The default
implementation will use the metadata supplied in the manifest about an
activity's hierarchical parent (parentActivityName) to do the right
thing.
If any activities in the parent chain require special Intent
arguments, the Activity subclass should override onNavigateUp() to
properly implement Up navigation for the app, supplying such arguments
as needed.
If automatic Up navigation within the same task can't find an activity
matching the supplied intent in the current task stack, it will act as
an in-app "home" and return to the root activity (presumably the app's
front page) in that task. (From this state, pressing "back" with
default behavior will return to the launcher.)
Change-Id: If163e27e59587f7af36975a09c986cb117ec3bc6
This can be used by app to efficiently listen for draw passes. This listener
is guaranteed to not generate any garbage unlike OnPreDrawListener.
Change-Id: Ida40d11a3f8a5d2617bafe722906ee5c9af48602
- 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
Add Java properties for those XML attributes that don't have getter/setter
pairs. Also, link existing methods to their XML attributes where the comments
were previously missing.
This CL is worth extra scruitiny: first because it's View, and secondly
because many of the new APIs depend on subtleties in the underlying implementations
that I'm not familiar with.
Also, please consider whether it is too much to deprecate getBackgroundDrawable().
Change-Id: I0f2641926d86e5f44b92a0057736f64b59d2e9b9
This was deprecated and the replacement provided in API level 3.
Hiding it in API 16 as a step toward removing support for it in 17.
Bug: 5012841
Change-Id: Ice66a0fc1031c0d6705973dae7cbc11b028e14c9
