| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Having a hidden abstract method for a class that can be extended
means that public implementors cannot implement these hidden methods
posing a risk that custom implementations will not have required
abstract methods resulting in an exception.
Bug: 151134792
Test: make update-api
Change-Id: I758d12465fabc671be19bedeeceb16885de23c87
Exempt-From-Owner-Approval: large scale suppression of existing issues,
no-op in terms of behavior
|
| |
|
|
|
|
|
|
|
| |
If they were null, then the Parcelable would fail to work.
Bug: 126726802
Test: manual
Change-Id: I7929ffa2f20e5de1c8e68e8263cca99496e9d014
Exempt-From-Owner-Approval: Trivial API annotations
|
| |
|
|
|
|
| |
Bug: 111439551
Test: make -j
Change-Id: I72997a87122f38b32e38e42a690385acc7d0e521
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Removed default implementation of onProvideAutofillVirtualStructure() that
was using accessibility API (it's useless because without the View calling
AutofillManager.notifyViewEntered(), it would never be triggered).
- Fixed obsolete TODOs.
- Removed obsolete service class name constant.
- Removed unused debug constant.
Test: CtsAutoFillServiceTestCases (on oc-dev) pass
Test: manual verification (on oc-dev)
Bug: 37078783
Bug: 33197203
Bug: 33802548
Bug: 35956626
Change-Id: I834d34b8af8bf0d781dc7e0ffcd6e600bfa2d183
|
| |
|
|
|
|
|
|
| |
Fixes: 37330022
Test: CtsAutoFillServiceTestCases pass
Test: manual verification using app from bug 37327881
Change-Id: I66260131c7ef0d5b3c2b20514f29efd5eb10057e
|
| |
|
|
|
|
| |
Test: CtsAutoFillServiceTestCases pass
Change-Id: Ic94e6686e291fed60ef6715bd160f9b568bf0ea6
|
| |
|
|
|
|
| |
Change-Id: I60634d0990d1d5bc33703abd41997e560f59ec77
Fixes: 36589254
Test: CheckoutActivityTest.testAutoFillDynamicAdapterWithNullItems()
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example log from
android.autofillservice.cts.LoginActivityTest#testAutoFill#testAutoFillOneDatasetAndSave
(translated from numbers of human readable string):
AUTOFILL_SESSION_STARTED
package=android.autofillservice.cts
AUTOFILL_REQUEST
type=TYPE_SUCCESS
package=android.autofillservice.cts
FIELD_AUTOFILL_SERVICE=android.autofillservice.cts
FIELD_AUTOFILL_NUM_DATASETS=1
AUTOFILL_FILL_UI
type=TYPE_ACTION
package=android.autofillservice.cts
FIELD_AUTOFILL_NUM_DATASETS=1
FIELD_AUTOFILL_FILTERTEXT_LEN=0
AUTOFILL_DATASET_APPLIED
package=android.autofillservice.cts
FIELD_AUTOFILL_NUM_VALUES=2
FIELD_AUTOFILL_NUM_VIEWS_FILLED=2
AUTOFILL_SAVE_UI
package=android.autofillservice.cts
FIELD_AUTOFILL_NUM_IDS=2
AUTOFILL_DATA_SAVE_REQUEST
type=TYPE_SUCCESS
package=android.autofillservice.cts
FIELD_AUTOFILL_SERVICE=android.autofillservice.cts
AUTOFILL_SESSION_FINISHED
package=android.autofillservice.cts
Test: Ran auto-fill tests and looked at event log.
Change-Id: I58aaa58e4435e7d04c8cd91878411943d3eb13de
|
| |
|
|
|
|
|
| |
throw and handle errors if the wrong value is set for a view
Test: android.autofillservice.cts.AutofillValueTest
Change-Id: Ida80da7913a210bede6c47d6b7a6f215a012a84c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change will affects 2 types of apps: autofill service implementations
and apps that use autofill APIs.
Since just the former is known to be used at the moment, we're not trying
to keep backward compatibility with the latter.
Bug: 35956626
Test: CtsAutoFillServiceTestCases pass
Test: android.provider.SettingsBackupTest pass
Change-Id: Ia720083508716deae9e887f9faa7ae7c5a82f471
|
| |
|
|
|
|
|
| |
Test: CtsAutoFillServiceTestCases (with new tests) pass
Fixes: 35840787
Change-Id: Iaa2c1907c8383b4a820fd7204e67fa2d276ad2b8
|
| |
|
|
|
|
|
| |
Additionally this CL removes spaces at the end of the line.
Test: code still compiles.
Change-Id: I1ce98b4e70aa3ae614f87966c3bc6181fa4389a4
|
| |
|
|
|
|
|
|
|
| |
Restrict restoring the selected position when AdapterView
gets restored for Spinner instances only.
Bug: 26991402
Bug: 23619366
Change-Id: Ib002eac5ed0b8810a3e9988ad36f03450cb03b9b
|
| |
|
|
| |
Change-Id: I031443de83f93eb57a98863001826671b18f3b17
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce new AssistData class that contains all data
the framework automatically generates for assist. Currently
populated with a very simple tree structure representing
the app's view hierarchy.
Reworked how we populate the class name for accessibility
info, so this is provided through a new method call on View
that subclasses can override. This method is also used
to populate the class name in AssistData.
Change-Id: Ibd0acdc8354727d4291473283b5e4b70894905dc
|
| |
|
|
|
|
|
|
| |
Removes the popup context setter, since this property cannot change
after inflation without losing data from the AttributeSet.
Bug: 19046761
Change-Id: I622f50d1752446a5b5793706c388e67a46ad06da
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ensures that delegate code is run last. Previously, calling the super
method from an accessibility delegate set on a widget would only run
code in the widget's parent. Next, the delegate code would run. Finally,
the widget's code would run. As a result, the widget code would override
any data supplied by the delegate.
By moving all overridden code to internal methods, we ensure that the
call chain for super includes the widget's parent code followed by the
widget's code. The delegate code will always run last.
BUG: 17641433
Change-Id: Ib9d403156c1fc4fb04f65f3c126d1277a44b3740
|
| |
|
|
|
|
|
| |
Also updates the constructor of every class that extends View.
BUG: 10676369
Change-Id: Ifaf27bf82028d180afa4931c0e906df88d858ac3
|
| |
|
|
|
|
| |
See bug #8159072 Spinner widget should be RTL'ized
Change-Id: I3f9368f242a027852bf13a7ce4b760de1e1c2fb2
|
| |
|
|
|
|
|
|
|
| |
Also fix a bug where anchored Spinner popups would not properly move
during a layout update.
Bug 7555978
Change-Id: If8dc22b0b40b14789a4e3bdecdeb376984923899
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to only framework classes.
AccessibilityEvent and AccessibilityNodeInfo have a property className which is set to the source
Java class. This is problematic since leads to leaking private classes which would allow an
accessibility service to load classes from other packages. This is strongly undesirable since
not trusted code can be loaded, and hence executed, in the accessibility service. To address
that the class name is set to the most concrete framework class extended by the info/event
source.
bug:5878943
Change-Id: I7b3114ece8772ea2773f5151e21b8a6f2006882a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This extends the view hierarchy's measure pass to allow view to
propagate up to their parent additional information besides just
their measured size. They can now report that their measured width
and/or height should be larger than the size their parent is
limiting them to (even though by definition they need to contrain
their reported measurements to the limits imposed by the parent).
ViewRoot uses this information to determine if it should remeasure
the window with a larger size limit to try to make it fit.
Change-Id: I90af3b7a8ec45d0a5c003fb009857025209d83eb
|
| |
|
|
|
|
| |
Bug #196253
Also do a little bit of syntax cleanup, remove unused code, etc.
|
| |
|
|
| |
Bug: #2361749.
|
| | |
|
| | |
|
| |
|