Report to developers if active network is "metered" and define it
as the user being sensitive to heavy data usage.
Bug: 3001465
Change-Id: I855ca3cd3eb1de3c4814148d70ccf24957af898a
Fixes b/6341858 AdapterView does not properly check for null before checking empty view accessibility info
Change-Id: Ia19fdef2c7c5f3e6c3053ebc754efe6a664f9d66
The unit tests were eating failure reasons. Remove some assertions so
the useful messages percolate up to the JUnit report.
Change-Id: Ica8efe403ca3eb4f0c4f2a18939a22085f74a08f
All the APKs in the FrameworkCoreTests's res/raw directory should be
built by source.
This change makes one more built from source that was causing test
failures with mismatched certificates.
Change-Id: I1baed15477ee39c45d3d77f9b02b81f771a16ca2
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
This change unhides the new SurfaceTexture and TextureView APIs that were added
to allow transferring ownership of the SurfaceTexture from the UI framework to
the application.
Change-Id: Ic4b781d907a59e99ff1a5974009305c1f9aee36a
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
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
Allow some messages to be ignored and allow the subclass to
add additional information. In particular, the information
can be used to decode the msg.what to a string.
Change-Id: I4f53becc6f0cb77399f99702084efef9d8785d67
This change updates the SurfaceTexture API docs and modifies the behavior of
the updateTexImage to produce an IllegalStateException when not attached to a
GLES context.
Change-Id: I5a0875927785108960985c567d571d5f7033256a
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
