| bdbde55592792efe350acd6a46733f439f6a3f3d |
19-Dec-2017 |
Aurimas Liutikas <aurimas@google.com> |
Annotate an assortment of coretest with @LargeTest
Non-annotated tests do not run, thus adding @LargeTest to an assortment
of tests that were missing annotations.
Found these classes with:
fn "*Test.java" | xargs grep -L "@LargeTest" | xargs grep -L "@MediumTest" | \
xargs grep -L "@SmallTest" | sort
Bug: 70846562
Test: make -j80 FrameworksCoreTests
Change-Id: Ifd466251b92728f9bbfa3cbd8fd21d34490f4eb1
orizontalFocusSearchTest.java
erticalFocusSearchTest.java
|
| adf5bec523c8215b03d3ca8f4f76c7a319f0f58e |
19-Oct-2017 |
Evan Rosky <erosky@google.com> |
Fixed several core and CTS tests
Fixes in framework include:
- ListPopupWindow requests focus for itself so it can receive
MENU key.
- PopupWindow uses setTransitionVisibility to avoid losing
focus upon enter transition.
- First-traversal will explicitly handle FOCUS_AFTER_DESCENDANTS
on the current focus if applicable -- details in code comment.
Fixes in tests usually just required focusing what they expected
to have initial focus; however, there were a couple tests that
had been broken for other reasons for a long time.
app.cts.ActionBarTest
app.cts.ToolbarActionBarTest
android.view.DisabledLongpressTest
android.widget.scroll.arrowscroll.ShortButtonsTest
android.view.VisibilityTest
android.widget.listview.ListScrollListenerTest
android.widget.listview.arrowscroll.ListOfThinItemsTest
andorid.widget.listview.arrowscroll.ListWithNoFadingEdgeTest
android.view.LongpressTest
android.widget.focus.ScrollingThroughListOfFocusablesTest
android.widget.gridview.GridScrollListenerTest
Bug: 67467972
Test: Failing tests should pass now.
Change-Id: I9e2fbfeb183eb777f35c67eca53e1f70809b7670
crollingThroughListOfFocusablesTest.java
|
| 51efddbd3bb304de2dd47fa8cd1114ac555958bb |
05-Apr-2017 |
Alan Viverette <alanv@google.com> |
Remove unnecessary casts on calls to findViewById
Just frameworks/ this time. More paths to come.
Bug: 24137209
Test: make -j32
Change-Id: Iff27abd26fa43296ac2fff8f534fc6742d2ae80c
escendantFocusability.java
ocusAfterRemoval.java
inearLayoutGrid.java
istWithFooterViewAndNewLabels.java
equestFocus.java
|
| 9df5d4f715f2ba5670753b78a236ff98eff34cfb |
06-Mar-2017 |
Paul Duffin <paulduffin@google.com> |
Replace usages of littlemock with mockito
Littlemock appears to have been created as an alternative to
Mockito that would work on Android. Given that Mockito does
now work on Android and Littlemock has had no activity since
Aug 2012 it seems prudent to switch over to use Mockito instead.
https://code.google.com/archive/p/littlemock/
This is being done as part of the work to upgrade Mockito.
Bug: 32912773
Test: Build and install affected APKs, test using am instrument
Change-Id: Id0e57880ea66c5681b664bbfb534c96410544665
equestFocusTest.java
|
| 7bee548aa64436f0bfe51cfb0b8e2d9367569464 |
05-Aug-2015 |
Abodunrinwa Toki <toki@google.com> |
Suppress flaky framework core tests.
Change-Id: I61f8f5ec7cd73cff1bebe5f606cb41681881d1de
istOfButtonsTest.java
|
| aac0d4ed026d1cfbcf3fa81c6e4eb96f4347ca17 |
20-Jul-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Replace left/right with start/end for Gravity / LayoutParams / Padding
- see bug #5429822 UI should be mirrored for RTL locales (Arabic, Hebrew, farsi)
Change-Id: Id9af5375fb9b0edeae5232c77e52ecd497bd2e67
erticalFocusSearch.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
istOfButtonsTest.java
|
| b36a0ac9709e9e1c7098559c0435cfbdc09e6c46 |
15-Feb-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Incorrect behavior of View clear focus v2.0.
The framework tries to have a focused view all the time. For
that purpose when a view's focus is cleared the focus is given
to the first focusable found from the top. The implementation
of this behavior was causing the following issues:
1. If the fist focusable View tries to clear its focus it
was getting focus but the onFocusChange callbacks were not
properly invoked. Specifically, the onFocusChange for
gaining focus was called first and then the same
callback for clearing focus. Note that the callback
for clearing focus is called when the View is already
focused.
2. If not the first focusable View tries to clear focus,
the focus is given to another one but the callback
for getting focus was called before the one for clearing,
so client code may be mislead that there is more than
one focused view at a time.
3. (Nit) The implementaion of clearFocus and unFocus in ViewGroup
was calling the super implementaion when there is a
focused child. Since there could be only one focused View,
having a focused child means that the group is not focused
and the call to the super implementation is not needed.
4. Added unit tests that verify the correct behavior, i.e.
the focus of the first focused view cannot be cleared
which means that no focus change callbacks are invoked.
The callbacks should be called in expected order.
Now the view focus clear precedes the view focus gain
callback. However, in between is invoked the global
focus change callback with the correct values. We may
want to call that one after the View callbacks. If
needed we can revisit this.
Change-Id: I8cfb141c948141703093cf6fa2037be60861cee0
equestFocus.java
equestFocusTest.java
|
| 73eb97f628b298c7bd032aa9db11dadf05f5b539 |
15-Feb-2012 |
Amith Yamasani <yamasani@google.com> |
Revert "Incorrect behavior of View clear focus."
This reverts commit c6fd88e213703a581fe4680259981f09ae0444f2
equestFocus.java
equestFocusTest.java
|
| c6fd88e213703a581fe4680259981f09ae0444f2 |
26-Jan-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Incorrect behavior of View clear focus.
The framework tries to have a focused view all the time. For
that purpose when a view's focus is cleared the focus is given
to the first focusable found from the top. The implementation
of this behavior was causing the following issues:
1. If the fist focusable View tries to clear its focus it
was getting focus but the onFocusChange callbacks were not
properly invoked. Specifically, the onFocusChange for
gaining focus was called first and then the same
callback for clearing focus. Note that the callback
for clearing focus is called when the View is already
focused. Also note that at the end the View did not
clear its focus, hence no focus change callbacks
should be invoked.
2. If not the first focusable View tries to clear focus,
the focus is given to another one but the callback
for getting focus was called before the one for clearing,
so client code may be mislead that there is more than
one focused view at a time.
3. (Nit) The implementaion of clearFocus and unFocus in ViewGroup
was calling the super implementaion when there is a
focused child. Since there could be only one focused View,
having a focused child means that the group is not focused
and the call to the super implementation is not needed.
4. Added unit tests that verify the correct behavior, i.e.
the focus of the first focused view cannot be cleared
which means that no focus change callbacks are invoked.
The callbacks should be called in expected order.
Now the view focus clear precedes the view focus gain
callback. However, in between is invoked the global
focus change callback with the correct values. We may
want to call that one after the View callbacks. If
needed we can revisit this.
Change-Id: Iee80baf5c75c82d3cda09679e4949483cad475f1
equestFocus.java
equestFocusTest.java
|
| 36a561b4ee35911fd6594c1592aab134be22f0f7 |
26-Jan-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing failing focus tests
Change-Id: I3df6a72f6340cbf2e42ce4913e28471e9358088b
istOfInternalSelectionViews.java
equestFocusTest.java
crollingThroughListOfFocusablesTest.java
|
| 136b1637f89e493b29cc130d1fff066f981ce3e9 |
14-Jun-2011 |
Steve Block <steveblock@google.com> |
Fix use of WebView.loadData() to avoid passing invalid encoding
No change in behavior, as invalid encodings have always been ignored.
Bug: 5125738
Change-Id: I23f21ca65a6b14501c74dc2189a55643f1e33c33
istWithMailMessages.java
|
| c6cc0f8c19d9eccf408a443fa2bf668af261dcd0 |
12-Apr-2011 |
Joe Onorato <joeo@google.com> |
Rename ViewRoot to ViewAncestor.
ViewRoot is about to be a new public class for poking at ViewAncestor.
Change-Id: Ie95d707c6d8bbb48f78d093d7b2667851812a7d5
equestFocusTest.java
|
| 1d3165f10b12165f02b7015ac1a817c5f60e6399 |
12-Jan-2010 |
Neal Nguyen <tommyn@google.com> |
Phase 2 of test file cleanup: relocating test files from FrameworkTest closer to their sources in core.
In addition to the file moves, the package names of the tests have been updated and adjusted to match their new locations.
djacentVerticalRectLists.java
escendantFocusability.java
escendantFocusabilityTest.java
ocusAfterRemoval.java
ocusAfterRemovalTest.java
ocusChangeWithInterestingRectHintTest.java
oneParentFocusedChild.java
oneParentFocusedChildTest.java
orizontalFocusSearch.java
orizontalFocusSearchTest.java
inearLayoutGrid.java
inearLayoutGridTest.java
istOfButtons.java
istOfButtonsTest.java
istOfEditTexts.java
istOfInternalSelectionViews.java
istWithFooterViewAndNewLabels.java
istWithFooterViewAndNewLabelsTest.java
istWithMailMessages.java
equestFocus.java
equestFocusTest.java
crollingThroughListOfFocusablesTest.java
erticalFocusSearch.java
erticalFocusSearchTest.java
|