A scrap view was retaining accessibility focus, leading to
a confusing experience for screen reader users.
Part of the problem is that views can change even when the
adapter has stable ids. This change tightens the condition
for restoring a11y focus to the same view.
AbsListView also allowed scrap views to maintain a11y focus.
While this may make sense if the views will be reused, it is
wrong if the views are not reused.
Bug: 29403113
Test: Verified that a11y focus stays put when toggling the
preference: Settings -> System -> Language & input ->
Virtual keyboards -> Advanced -> Symbol for physical keyboard
Change-Id: Ie4a15027088f158d9ed4bb3f3eeff5a288c25832
(cherry picked from commit ab4717aa2a)
Symptom:
If an application set a negative height to the popup list,
surfaceflinger is crashed with SIGABRT.
Root cause:
WindowManagerService dose not expect negative
height of ListPopupWindow. If it's negative,
WindowManagerService set the negative value to GraphicBufferAlloc,
but GraphicBufferAlloc handle the value as unsigned int,
then surfaceflinger is crashed with SIGABRT.
Solution:
Setting a negative height is a developer error.
We should throw an IAE from setHeigh(int).
Bug: 33441454
Author: Kazuki Nakayama <kazuki.x.nakayama@sonymobile.com>
Change-Id: I5887674d302e567abfe66147de4819cfdf0ef97b
- Increase the size of the text sent as context to the classifier
- Pass regex match hints to the classifer
Test: Build still works. Regex hints logged correctly. The hints won't
matter until we've actually passed in this values to native code. Native
library test will be written and I've got a tracker bug to write more robust Java tests.
Bug: 35416389
Bug: 36584397
Change-Id: I29e56189b388b36dc0cc7a8bb13ef237ff55be7b
It was checking if the weak reference pointee was null, but not for a null
weak reference per se.
Fixes: 36643768
Test: manual verification
Test: CtsAutoFillServiceTestCases pass
Change-Id: I106dfd4a91ff1d45f8cb3141a992b06cbe460367
Now the autofill UI tracks the movement of the anchor view,
both real and virtual and while still preventing the filled
app from accessing the chooser UI. This was achieved by using
a popup window in the app process to determine the window
location and adding a window presenter interface to popup
window that controls the actual window addition, removal, and
update which is implemented by the system server.
Test: all autofill CTS tests pass
bug: 36392498
bug: 35708258
bug: 34943932
fixes: 36039182
fixes: 36493078
Change-Id: I0321913b2e2e759f4b17003bf85cb873e63a467c
When a font resource is set via fontFamily, the textStyle
attribute was being ignored.
Bug: 36505747
Test: cts attached in topic
Change-Id: I6418297d9a289460a3b36c6883441ac48ea33b22
Bug: 32463283
Test: adb shell settings put secure night_display_color_temperature
XXXX, where XXXX is {0, 2900, 4000, 7000}, and the temperatures
outside the valid range are capped at the min/max, respectively.
Change-Id: I322c0a907b30742fc312a9938fd0c47f679e580b
* ellipsize is being taken into account when auto-
sizing text; the ellipsis is applied once the
minimum text size for auto-size has been chosen
as the best fit
* isolated the preset sizes configuration and used
it both in the setter and ctor => consistency
* stuffed all possible TextView attributes to the
StaticLayout we use for measurements for a more
precise result
* fixed a bug where the default granularity was
not properly applied resulting in an error in
ctor
* fixed all auto-size error messages
Bug: 33574040
Bug: 32221168
Test: attached in the same topic
Change-Id: I36fa7c242d588bf597110bb02a26c90ae1f1943a
Now setFontVariationSettings returns false if the given settings is not
effective.
Bug:35764323
Test: ran TextViewTest and PaintTest in cts
Change-Id: Ic31d9e47ec006c8e7bb2c907ff0ea2936bd71d01
- Added a requestAutofill(view,flags) method, that when passed with
FLAG_MANUAL_AUTOFILL triggers a manual request.
- Added same method for virtual views
- Overloaded existing AutofillService request methods to take a flag.
- Added an AUTOFILL context menu option on TextViews.
- Added a canRequestAutofill() that is used to enable the context menu.
BUG: 35708229
Test: manual verification
Test: existing CtsAutoFillServiceTestCases pass
Test: android.autofillservice.cts.LoginActivityTest#testManualAutofill pass
Change-Id: I1a64d40da3373774451d178b1cabf20f11120e9d
The current implementation of cascading menus is anchoring
a submenu to the top-level anchor view using a carefully
computed offset. This offset is only correct for the case when
the submenu is being shown normally, but not when it is
flipped due to insufficient space below.
More over, when the window containing the anchor is scrolled,
the pre-computed might become completely irrelevant, as
parent menus might change their above/below state.
This CL allows a PopupWindow to be anchored to a view in
another popup window (previously it was only possible to
anchor to a view in the main app window).
Cascading submenu is now tracking its parent item position
correctly.
Bug: 35768002
Test: android.cts.widget.PopupWindowTest.testAnchorInPopup
Change-Id: Id163d739de05729a9fa7e5fedebc9ec0037ed80e
throw and handle errors if the wrong value is set for a view
Test: android.autofillservice.cts.AutofillValueTest
Change-Id: Ida80da7913a210bede6c47d6b7a6f215a012a84c
Symptom:
A part of the option is displayed in the wrong location.
Root cause:
When the search item is clicked, the menu item will be
hidden. The PopupWindow will be detached from window and the
mAttachInfo property will be set to null. The anchor coordinates
will return x 0 and y 0.
Solution:
If the anchor view is detached from window, the ListPopupWindow will
not be update.
Bug: 36207919
Change-Id: I2b370c31542fae454592463e12313fdeaef25afe
1. Ensure clicking on a focused view brings up autofill if needed
2. Notify the autofill manager in a couple of cases we missed
3. Renamed the AutofillManager app facing APIs to better reflect what
they do and added a API for the app to cancel the autofill interaction
4. Fix view structure dispatch where the ordering of children for autofill
was mixed with ordering of direct view children - the autofill children
may be indirect as views can be marked not important for autofill
5. Show scrollbars only if there are more fill options than want is shown
6. Show only three fill options and the rest can be accessed with a scroll
7. Remove the list divider to allow fill items to control all fill window content
8. Renamed the autofill manager internal service classes to xxAutofillxx
9. Fixed a comment that was not addressed in a previous CL
10. Showing max three fill options - rest needs a scroll
11. Make sure fill UI shown when filter with no matches is changed
to filter with some matches
12. Make sure the fill window has a shadow
Test: Autofill CTS tests pass and manual
bug:36038929
bug:36040101
bug:36149166
bug:36034681
bug:36126001
bug:36035654
Change-Id: Ic8726146fc3c0a19d3e536becdd63fb65622136e
Registering and unregistering are expensive operations
that should not be done when the visibility of the
TextClock changes. However, we want to ensure that a
non-visible TextClock does not consume extra resources
or cause layout/redraw passes. By keeping the TextClock
registered but avoiding the side effects of onTimeChanged,
we can get the best of both worlds.
Test: manual testing
BUG: 33960344
Change-Id: I3e76246d820363766b78130231d665989fdb4265
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
Now that AutoFillType does have any logic (since the "subType" logic was moved
to AutoFillHint), it makes more sense to get rid of the type and use constants
directly.
This change creates the contants and "pseudo-deprecate" the old stuff: it's
still available because some clients are using it, but it will be removed once
they migrate.
Bug: 35956626
Test: CtsAutoFillServiceTestCases pass
Change-Id: I0efe7f0cc101c86164a18c85903bb871e1f13ba2
One of non-intuitive behaviors of InputMethodManager#showSoftInput() is
that it always fails if you pass a view that does not window focus. For
example, the following code does not show the software keyboard because
the target window is not yet focused during Activity#onCreate().
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
final LinearLayout layout = new LinearLayout(this);
layout.setOrientation(LinearLayout.VERTICAL);
final EditText editText = new EditText(this);
layout.addView(editText);
final InputMethodManager imm =
getSystemService(InputMethodManager.class);
editText.requestFocus();
// This will be ignored because the target window has not gained
// focus yet.
imm.showSoftInput(editText, 0);
setContentView(layout);
}
Some platform components, however, have worked around by this limitation
by relying on IMM#showSoftInputUnchecked(), which just bypasses internal
IME focus handling flows.
Bypassing standard event handlign flow is indeed problematic, and has
actually contributed to issues such as Bug 35903813 and Bug 31915865
directly or indirectly. In order to make IME focus handling more
deterministic and reliable, IMM#showSoftInputUnchecked() really needs to
be deprecated.
As the initial step to deprecate IMM#showSoftInputUnchecked(), this CL
removes the dependency on it from SearchView. Instead of immediatelly
issuing delayed tasks that call IMM#showSoftInputUnchecked(), this CL
uses View#onCreateInputConnection() as a signal that SearchAutoComplete
now owns IME focus.
Test: Open System Settings and tap the search icon to make sure that
the software keyboard will be shown automatically.
Test: cts-tradefed run cts -m CtsWidgetTestCases --test android.widget.cts.SearchViewTest
Bug: r.android.com/223701
Bug: 36015425
Bug: 31756425
Fixes: 35903813
Change-Id: I20983e4ce1d625e098a8c2335ce75994cfa43235
Currently if a popup menu is shown above the anchor, it
is anchored to the anchor's top edge regardless of the value of
mOverlapAnchor.
Fixing the vertical offset correction and the computation of the
vertical space available above the anchor.
Bug: 36000552
Test: android.widget.cts.PopupWindowTest#testOverlapAnchor
Change-Id: Ifb71ff1fc0aa0df58e4919fd229c2623a2bcbe3d
