| 27e2da7c171afa39358bbead18fbe3e6b8ea6637 |
|
03-Jul-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Remove the accessibility focus search code.
1. In JellyBean we have added some APIs to search for next accessibility
focus in various directions and set accessibility focus from hover.
However, we have decided that there is not clean answer for how this
should behave and the APIs were hidden. Now the accessibility service
is responsible for that. The unused code is now taken out.
2. This patch also takes out the hidden attribute accessibiligyFocusable
since we moved the responsibility for implementing focus search strategy
to accessibility services and we did not need that for Jellybean which
is a good sign that this is not needed. I general this is one less thing
for an app developer to worry about. We can add this if needed later.
bug:6773816
Change-Id: I0c858d72c93a2b7ff1f8f35a08d33ec4b9eb85fd
/frameworks/base/core/java/android/view/ViewParent.java
|
| e5dfa47d84668376b84074c04570fb961870adeb |
|
09-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Improving accessibility focus traversal.
1. Now the views considered during the accessibility focus search
are the ones that would get accessibility focus when thovered
over. This way the user will get the same items i.e. feedback
if he touch explores the screen and uses focus traversal. This
is imperative for a good user experience.
2. Updated which focusables are considered when searching for access
focus in ViewGroup. Generally accessibility focus ignores focus
before/after descendants.
3. Implemented focus search strategy in AbsListView that will traverse
the items of the current list (and the stuff withing one item
before moving to the next) before continuing the search if
forward and backward accessibility focus direction.
4. View focus search stops at root namespace. This is not the right
way to prevent some stuff that is not supposed to get a focus in
a container for a specific state. Actually the addFocusables
for that container has to be overriden. Further this approach
leads to focus getting stuck. The accessibility focus ignores
root names space since we want to traverse the entire screen.
5. Fixed an bug in AccessibilityInteractionController which was not
starting to search from the root of a virtual node tree.
6. Fixed a couple of bugs in FocusFinder where it was possible to
get index out of bounds exception if the focusables list is empty.
bug:5932640
Change-Id: Ic3bdd11767a7d40fbb21f35dcd79a4746af784d4
/frameworks/base/core/java/android/view/ViewParent.java
|
| 4213804541a8b05cd0587b138a2fd9a3b7fd9350 |
|
20-Mar-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility focus - framework
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
/frameworks/base/core/java/android/view/ViewParent.java
|
| 3a3a6cfd8ec12208ca75c0d0d871d19d76c34194 |
|
26-Mar-2012 |
Dianne Hackborn <hackbod@google.com> |
Add new feature to let apps layout over status bar / system bar.
The main change is a few new flags you can supply to
View.setSystemUiVisibility(). One is a new visibility mode,
SYSTEM_UI_FLAG_FULLSCREEN, which is basically the same as
the global FLAG_FULLSCREEN option for windows, but driven as
part of the system UI state.
There are also three new flags for telling the framework that you
would like to have your application's UI ignore screen
decorations -- SYSTEM_UI_FLAG_LAYOUT_NO_NAVIGATION for going
behind the navigation bar and SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN
for ignoring full screen decorations (that is the status bar).
In combination with this you can use SYSTEM_UI_FLAG_LAYOUT_STABLE
to have the framework report consistent insets to your application.
When using NO_NAVIGATION, when the user taps the screen we now
also automatically clear ONLY_CONTENT, so that we atomically show
both UI elements. This should make it easy for apps like video
players that want to move between fully full-screen and regular
modes.
The ActionBar has also been extended when in overlay mode so
that it will adjust the system window insets to also account
for its space, and allow it to be hidden using the new
SYSTEM_UI_FLAG_FULLSCREEN.
Change-Id: Ic8db1adec49a0f420bfe40c1d92eb21307856d0b
/frameworks/base/core/java/android/view/ViewParent.java
|
| 539ee8716b4f81260bab2e9f3dc5d88d81c99985 |
|
04-Feb-2012 |
Adam Powell <adamp@google.com> |
Add transient state tracking to Views
Transient state is temporary bookkeeping that Views need to perform
that the app should not need to be aware of. Examples include text
selection regions and animation state.
Transient state is a problem for AdapterViews like ListView that do
view recycling. Unless the app takes responsibility for tracking and
restoring transient state as if it were a part of the adapter's data
set, it cannot correctly recycle views. Selections disappear when an
EditText is scrolled out of sight and animations seem to play on the
wrong views.
Views can now flag themselves as having transient state. (As the name
implies, this should be a temporary condition.) If a ViewGroup
contains a child with transient state, that ViewGroup also has
transient state.
AbsListView's recycler now tracks views with transient state
separately. Views with transient state will be retained, and until a
data set change occurs the same view will be reused for that position
instead of calling the adapter's getView() method.
The API to set and check transient state is currently hidden.
Change-Id: Idfd8eaac2c548337686d8d9f98fda4c64be5b8a0
/frameworks/base/core/java/android/view/ViewParent.java
|
| cea45132e3d5d32a6fc737abf10b8893a50f465b |
|
24-Nov-2011 |
Gilles Debunne <debunne@google.com> |
Handle animations in Views' rectangle clipping methods.
getChildVisibleRect and getLocationInWindow do not take the new
mTransformationInfo View attribute.
As a result, these methods return invalid value during an animation
Bug 5638710
Changes in Patch Set 2:
- temporary allocations removed using static thread local variables (method
calls are NOT reentrant).
- scroll should be handled *before* applying the transformation matrix.
Fixed the call order in View#getLocationInWindow()
Patch set 4: fix from comments.
Patch set 5: <p>s
Change-Id: I15dc44c0659305d9029c59a47aba3a738bb35ae1
/frameworks/base/core/java/android/view/ViewParent.java
|
| 736c2756bf3c14ae9fef7255c119057f7a2be1ed |
|
23-Apr-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Touch exploration feature, event bubling, refactor
1. Added an Input Filter that interprets the touch screen motion
events to perfrom accessibility exploration. One finger explores.
Tapping within a given time and distance slop on the last exlopred
location does click and long press, respectively. Two fingers close
and in the same diretion drag. Multiple finglers or two fingers in
different directions or two fingers too far away are delegated to
the view hierarchy. Non moving fingers "accidentally grabbed the
device for the scrren" are ignored.
2. Added accessibility events for hover enter, hover exit, touch
exoloration gesture start, and end. Accessibility hover events
are fired by the hover pipeline. An accessibility event is
dispatched up the view tree and the topmost view fires it.
Thus predecessors can augment the fired event. An accessibility
event has several records and a predecessor can optionally
modify, delete, and add such to the event.
3. Added onPopulateAccessibilityEvent and refactored the existing
accessibility code to use it.
4. Added API for querying the currently enabled accessibility services
by feedback type.
Change-Id: Iea2258c07ffae9491071825d966dc453b07e5134
/frameworks/base/core/java/android/view/ViewParent.java
|
| 3fb3d7c4e756bd32d5abde0abca9ab52d559bc84 |
|
23-Apr-2011 |
Adam Powell <adamp@google.com> |
Revert "Touch exploration feature, event bubling, refactor"
This reverts commit ac84d3ba81f08036308b17e1ab919e43987a3df5.
There seems to be a problem with this API change. Reverting for now to
fix the build.
Change-Id: Ifa7426b080651b59afbcec2d3ede09a3ec49644c
/frameworks/base/core/java/android/view/ViewParent.java
|
| ac84d3ba81f08036308b17e1ab919e43987a3df5 |
|
05-Apr-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Touch exploration feature, event bubling, refactor
1. Added an Input Filter that interprets the touch screen motion
events to perfrom accessibility exploration. One finger explores.
Tapping within a given time and distance slop on the last exlopred
location does click and long press, respectively. Two fingers close
and in the same diretion drag. Multiple finglers or two fingers in
different directions or two fingers too far away are delegated to
the view hierarchy. Non moving fingers "accidentally grabbed the
device for the scrren" are ignored.
2. Added accessibility events for hover enter, hover exit, touch
exoloration gesture start, and end. Accessibility hover events
are fired by the hover pipeline. An accessibility event is
dispatched up the view tree and the topmost view fires it.
Thus predecessors can augment the fired event. An accessibility
event has several records and a predecessor can optionally
modify, delete, and add such to the event.
3. Added onPopulateAccessibilityEvent and refactored the existing
accessibility code to use it.
4. Added API for querying the currently enabled accessibility services
by feedback type.
Change-Id: Iec03c6c3fe298de3f14cb6efdbb9b198cd531a0c
/frameworks/base/core/java/android/view/ViewParent.java
|
| 879fb6b5d66bec90d3420fad12a2a9b2fe9592f3 |
|
20-Sep-2010 |
Adam Powell <adamp@google.com> |
Text selection anchors changed to use windows
Manually cherry-picked
Change-Id: Id080dfad0e2f324fef3a5175abc78f76c8bad4c8
/frameworks/base/core/java/android/view/ViewParent.java
|
| f37df070ea84c353ff8bed4b2591932126d7e2ca |
|
18-Sep-2010 |
Adam Powell <adamp@google.com> |
resolved conflicts for merge of b39470b5 to master
Change-Id: If441c8684c576b6cbc485a37088d6869ad3fb23f
|
| b08013c312e3d849029a2f4c11889274c00f438d |
|
17-Sep-2010 |
Adam Powell <adamp@google.com> |
Added overlay support for drawing/responding to text anchors.
Overlays let views draw and respond to touch events outside of their
bounds. This allows selection anchors to be friendlier and easier to
grab. This is currently private API, pending further evaluation.
Added themes/styles for text selection anchors.
Added assets for text selection anchors as provided by UX. The
left/right anchors are currently not suitable for use. They are here
for bookkeeping and replacement later. The theme currently uses the
'middle' anchor asset for all three. This will be changed once assets
are ready.
Change-Id: I01b21e5ae90cab201f86f38f2f5eeaf2bd7f6bcd
/frameworks/base/core/java/android/view/ViewParent.java
|
| 6e34636749217654f43221885afb7a29bb5ca96a |
|
23-Jul-2010 |
Adam Powell <adamp@google.com> |
Moved context modes into view, renamed to action modes
ContextualMode renamed to ActionMode. Adds a reference to the action
bar and reduces confusion around things named "Context".
Change-Id: Ia5098b1d0799a0ece0810c34e6696eda039fb005
/frameworks/base/core/java/android/view/ViewParent.java
|
| 9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/view/ViewParent.java
|
| d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/view/ViewParent.java
|
| f013e1afd1e68af5e3b868c26a653bbfb39538f8 |
|
18-Dec-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Code drop from //branches/cupcake/...@124589
/frameworks/base/core/java/android/view/ViewParent.java
|
| 54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/view/ViewParent.java
|