This is yet another big refactoring:
- AutoFillManager keeps track of its current AutoFillSession.
- Views call AFM.startSession(View) when they can trigger autofill.
(virtual views can call it as well). At this point, the manager
sets an AutoFillSession, gets the activity token, and passes it to
the service.
- Subsequent calls to AFM.start() will be ignored since the session
is set.
- When the Activity is gone, it calls AFM.finishSession().
- Simlilarly, virtual views could call it as well.
- Added getAutoFillValue() to View.
- Removed AFM.updateAutoFillInput(childId): virtual views should now
call startSession(childId) to start a session, and use the
VirtualViewListener callbacks for updates.
- Change AutoFillValue to use String (which is immutable) instead of
CharSequence for text values.
- Check if view is enabled before auto-filling.
- Removed 'cmd autofill fill' since it would require the appCallback
- Automatically dismiss the snack bar after 30s
- Moved the "don't change autofill value when autofilling" Inception
logic into the service side.
- Etc...
BUG: 34819567
BUG: 33269702
BUG: 31001899
Test: manual verification
Test: CtsAutoFillServiceTestCases passes
Change-Id: I5fad928d4d666701302049d142026a1efa7291cd
This allows an AccessibilityService to set a flag in its
AccessibilityServiceInfo that triggers the navigation bar to show an
Accessibility Button and observe callbacks when the button is clicked
or there are changes in the visibility of the navigation bar.
Test: Manual (Created a sample AccessibilityService) + CTS
Bug:29231271
Change-Id: I03d653d85bc37df28ed71d8bba94b7c75fe56e43
1. Move management of the remote fill service in a dedicated
class that abstracts away the async and ephemeral nature
of the binding.
2. Update auth to move fingerprint out of the platform and
allow response and dataset auth.
3. Cleaned up the fill and save callback classes.
4. The UI is now shared among all sessions and cleaned up.
5. Reshuffled the remote callbacks to have cleaner separation.
6. Cleaned up and tightened the reponse and dataset classes.
7. Added API to support communicationn with intent based auth.
Test: CTS + manually
bug:31001899
Change-Id: Idc924a01d1aea82807e0397ff7293d2b8470d4d6
Fixes a few follow up bugs from the colorized
notification CL.
This also allows media notifications with a media
session to be colorized by default.
Test: existing tests pass
Bug: 34469375
Change-Id: I36348591a84fcd39d103d0ae3f64720f2fca2cf2
Gracefully handles situations where a default app cannot be found
to handle the intent.
1. If we can not find any app to handle the intent,
do not include an "assist" menu item entry to fire the intent.
Also, do not linkify the entry.
2. If we do not have a default app to handle the intent,
show a generic title for apps that will handle the intent
and do not include an icon.
In the ideal case where we find a default app to include the intent,
show the app's (preferably activity's) title and icon.
Test: Manually tested. There's an AI to write more automated tests.
Bug: 34777322
Bug: 34927631
Change-Id: Ia94efbbdda3da8f181fac9228cd2d3a76cb727d3
- Introduced TYPE_APPLICATION_OVERLAY window type. Can be used by apps
to display windows on top of other app windows, but below critical
system windows.
- Deprecate alert window types TYPE_PHONE, TYPE_SYSTEM_ALERT,
TYPE_SYSTEM_OVERLAY, TYPE_PRIORITY_PHONE, and TYPE_SYSTEM_ERROR.
Apps should now use TYPE_APP_OVERLAY for this.
- Apps targetting O or greater are not allowed to add the old alert
window types.
Apps targetting less than O can still add the old types.
Apps with permission INTERNAL_SYSTEM_WINDOW (system signature apps) can
still add the old types.
- Z-order old alert windows types below TYPE_APPLICATION_OVERLAY if
they are added by an app without the INTERNAL_SYSTEM_WINDOW permission.
Test: android.server.cts.AlertWindowsTests
Bug: 33256752
Change-Id: I12170955a7a333151d3387c169b51c53c32164fc
This is a preparation CL for fixing Bug 32343335, where we aim to
avoid unnecessary reconstruction of InputMethodInfo objects by caching
immutable part of those metadata by APK revisions.
The reason why we have had to pass additional subtypes not just as
List<InputMethodSubtype> but as Map<String, List<InputMethodSubtype>>
to create an instance of InputMethodInfo is that how to compute
so-called IME ID is not exposed from InputMethodInfo even as @hide
method.
In practice it has been calculated as
new ComponentName(packageName, serviceName).flattenToShortString()
and those IDs are already stored here and there including secure
settings. It is almost impossible to change the rule anymore hence
we should consider them to be a kind of public API.
This CL adds a @hide static method InputMethodInfo#computeId() to
make it clear. This also enables us to simplify the constructor
of InputMethodInfo finally, because we have used IME IDs as keys
in subtypes.xml, where additional subtypes are stored.
Test: Manually verified that addtional subtypes still work
Test: checkbuild
Bug: 32343335
Change-Id: I1deaa470e042eac749e7a847933d14448a0d9e03
Currently, the onProvideAutoFillStructure() methods can be called
twice: to auto-fill an activity and to save the activity's data
in the service.
The problem with this approach is that when the save workflow is
called, the activity might have been gone. Hence, a proper approach
is to keep the initial AssistStructure data in the system_service
memory, watch for view changes, and then passed the new structure
back to the AutoFillService.
A side effect of this change is that we need another way to determine
if the view is sanitized or not. For "standard" views, that will be
defined based on whether the view content come from a resource or not,
but that logic is not implemented yet (for now, all views will be
considered sanitized, except for TextView passwords). For "custom"
views (such as WebView), this logic is responsibility of the view
implementation, through the newChild() method, which now takes a
flag (whose value could be AUTO_FILL_FLAG_SANITIZED for sanitized
views).
The SaveCallback.onSuccess() method was simplified: it does
not need a list of saved ids anymore the auto-fill UI will not use it
anymore.
Another side effect is that the Save notification is gone - until
it's attached again, it can be test by using:
adb shell cmd autofill save
Finally, hook AutoFillUI on ACTION_CLOSE_SYSTEM_DIALOGS events.
BUG: 33269702
BUG: 31001899
Test: manual verification
Test: CtsAutoFillServiceTestCases passes
Change-Id: I907a7e21d1b3cd1ab6dec3a08d144a52655da46f
Check resolved focusability for hasFocusable and not just the
configured value.
Bug: 34855238
Test: CTS
Change-Id: I57af9e6c3a0ccd07058bcd0b2256a14878b8707c
Specifically, tab focus should travel completely through all
views within a given viewgroup before traveling to a sibling
viewgroup. At each hierarchy level, viewgroups are sorted
according to the existing rectangle-based algorithm.
This is only the first of a couple focus-order tweaks to
adhere to the new keyboard navigation ux spec.
Bug: 33848452
Bug: 34084573
Test: Checked in a sample-app that focus order adheres much
more closely to our keyboard navigation spec. Also
verified that existing FocusFinder CTS tests still pass.
Change-Id: Ia0e59a2e0dd8b9773796e0aaebfca0deb3c14a3c
Testing utilities want the ability to know whether things in the UI
are in flux and they need to wait before testing on-screen values.
These changes (a subset of what's needed, but will have to do for
a start) allow querying of ActivityTransitions and ProgressBar, two
common/difficult pieces in the puzzle.
Test: CTS tests at ag/1835467
Bug: 30978257 Provide view transition Api to prevent flaky tests
Change-Id: If63b3d0dde2178d826ac1dbfad0fc50e5ed9a780
As another preparation CL to work on Bug 7254002, this CL cleans up
miscellaneous minor coding style issues that do not cause any
user-visible problems.
- Add final keyboard to classes that are not intended to be extended.
- Add static keyboard to nested classes if possible.
- Fix a typo in log message.
- Remove a redundant synchronized keyword in method signature.
- Remove unused class fields.
Test: checkbuild
Bug: 7254002
Change-Id: I3b54179116a74cafc99a3dfd3f2a429a7111c12e
ListView historically uses View#hasFocusable to change signifcant
behavior around the clickability of items: an item view with any
focusable children could not be clicked via an item click
listener. Many apps therefore have sub-views in list items that are
deliberately clickable, but not focusable. This comes up in cases like
overflow menu buttons on list items.
Now that we have auto-focusability triggered when a view is set as
clickable, the expectations of apps using this pattern have changed.
Create an overload of hasFocusable that optionally can filter out
auto-focusable views in its results. Have ListView use it to preserve
its previous behavior. This isn't public API for now, but perhaps it
should be if this pattern shows up in practice in places other than
ListView.
Bug: 34756767
Change-Id: Ie71ee6e388449f634b30f9162a8b3fa578e32db8
This allows VrWindowManager to identify things like permission
dialogues in the list of SurfaceFlinger layers that show up while a
VR application is running and display them without leaving VR mode.
Bug: 30984984
Test: Run VR application, request permission at runtime, observe and
accept permission in VrWindowManager without leaving VR mode.
Change-Id: I347313b5fcd08dea3cd6fddfaeb15640938e3a87
Fixes: 34361503
Test: CTS: android.view.cts.ViewGroupTest
APCT: android.view.ViewInvalidateTest
Simplify and unify HW accelerated invalidate/damage codepaths, since
both simply walk up to ViewRootImpl and schedule a traversal.
Adds a new overridable method 'onDescendantInvalidated' for observing
subtree rendering updates.
Change-Id: I7ef1f914c3411317692451787b3810b23e019591
Removes all explicit casts from android.widget classes. Also @removes
methods on ListView that were overriding @hidden methods and should
never have been exposed as public API.
Bug: 24137209
Test: make
Change-Id: I6ccfc6f001b355c4880f2b54e1a5474df78d6228
This adds new flag to virtual display that changes its
behavior when keyguard is shown, but can be dismissed without
entering credentials. This can be applied only to private
virtual displays.
Bug: 34280365
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testVirtualDisplayHidesContentWhenLocked
Test: #testShowWhenLockedVirtualDisplay
Test: #testShowWhenLockedPublicVirtualDisplay
Change-Id: I9c19d36295e62f59bd1db1352af707d54ea51667
- Virtual displays might have hdr capabilities not initialized,
which lead to exception when checking.
- Dynamic stacks were mistakenly considered an invalid launch stack.
Test: android.server.cts.ActivityManagerDisplayTests
Change-Id: I20356d6e25cf9e5fa4a3d7bd3699a8e82a73f21a
