For now it's a "1-to-1" refactoring that keeps the same
functionalities, but soon SaveInfo will be expanded to
allow the AutoFillService to customize it.
Bug: 35727295
Test: CtsAutoFillServiceTestCases pass
Test: m update-api
Change-Id: I5aaa705be2b32590048f70ed0142437e05df94b7
When activity that is moved between displays handles all configuration
changes, it won't be restarted. This CL adds a callback to the client
to notify it about display change. Usually it will be followed by
onConfigurationChanged, except when configuration didn't actually change.
When activity is recreated, it won't receive onMovedToDisplay.
Bug: 34862802
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testOnMovedToDisplayCallback
Change-Id: I9a9501cab788623ada15a31efb53e4b2378639fe
* Fix a layering issue where auto-fill manager which is in view
depended on activity which is in app
* Moved auto-fill classes to view or service based on their
purpose and removed dependecy on the classes in view to the
classes in service
* Push state to local auto-fill manager whether auto-fill is
enabled to avoid making IPC for every focus transition if
the user did not enable the feature
* Remove unnecessary offload to messages when handling calls
to auto-fill manager service as these are made over a oneway
interface and in general they do almost no work and typically
we do these on the binder thread
* Removed id from data set and fill response as the provider
can embed everything it needs to id them in the auth pending
intent
* Enforce the auth UI to be only an activity as this will work
with multi-window, recents, and back and also does not require
draw on top of other app special permission
* Authentication also no longer requires passing a remotable
callback to the auth activity but the activity handles the
request as if called for a result
* Handling stopping of a user to clean up in-memory state as
well as handling when a user gets unlocked as a provider may
be non-direct boot aware
* User the correct context when creating an auto-fill manager
* Move the receiver that listens for requests to hide system
windows to the manager service as the UI is a singleton and
no need every per-user state to register its own
* Removed extras from dataset as the only case a provider needs
to associate state with a dataset is for auth and the provider
can embed this data in the auth pending intent
Test: manual and CTS
Change-Id: I4bc54c13cf779d7f6fdb3ab894637f9fac73f603
- Add a new stack that is not resized with multiwindow, and
appears above the fullscreen and docked stacks, but below
the pinned stack
- Add a method on VoiceInteractionSession to allow the assistant
to launch activities into this new fullscreen stack.
- Also prevent any activities in the assist stack from the
fetching of the on screen assist data.
Bug: 30999386
Test: android.server.cts.ActivityManagerAssistantStackTests
Change-Id: I22ab7629b5f758cf1e66d7d1c26648af6bc887c9
Auto-fill has a shell command that is useful for development
which is currently exposed as a remote method allowing any app
to call it reflectively. Since only case this method is called
is when handling a shell command there is no need to expose it
to IPC over binder.
Test: manual
Change-Id: Iac20b4a39c7065e254f8aa277d1f2fd1c38b24a8
This allows the session to turn off all of its UI. Use it
in onCreate() to prevent the session from ever creating any
of its UI. Switched the window creation and initialization to
happen lazily to support this.
Test: New test added to android.assist.cts.LifecycleTest
Bug: 30999386
Change-Id: I8eacb3697c8ac9908c50b9577abea2d20597b016
Currently, TextServicesManagerServices uses an AIDL interface called
ISpellCheckerService when binding to a spell-checking service.
However, this interface uses synchronous (blocking) binder calls
rather than asynchronous (oneway) calls. As a result, there are
situations where the system process has made a blocking binder call
into untrusted application code from its main looper thread.
As general policy, the system process must never allow its looper
threads to block on application code.
This CL addresses the above issue by converting ISpellCheckerService
into oneway interface, which instead takes a result receiver
ISpellCheckerServiceCallback so that spell-checking services can
return results asynchronously.
Note that the above protocol issue was also the root cause of
Bug 5471520. Hence we can also logically revert the previous CL [1]
for Bug 5471520.
[1]: Iedf2c2cdd8d4834545d06d72ade3ce211b104b1d
4e713f1441
Test: Ran `adb shell dumpsys textservices` to check the
"Spell Checker Bind Groups:" section in the following three
steps.
1. Before apps start requesting spell checker sessions.
2. While apps are owning active spell checker sessions.
3. After all the apps that owned spell checker sessions are
gone.
Made sure that spell checker service is not running when
there is not spell checker bind group.
Bug: 7254002
Change-Id: I92e7aa40dc9ea14f67d355f0bfa15325b775d27b
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
One application can provide two or more custom Quick Settings tiles.
But there is no way to know which tile is long-pressed from application
side because ACTION_QS_TILE_PREFERENCES intent that is sent when
long-pressed doesn't have any additional information. So the component
name and state of the tile should be added to the intent.
Bug: 34832801
Test: manual - long press a custom tile
Change-Id: Iaa884cd944f19a2f007cbde645e8f8b1198bffb7
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
Provides access to persistent VR mode as used by VR viewer when a device
is believed to be inside a viewer.
Bug: 34736524
Test: Built, run using build of vr services that enables mode.
Change-Id: I6ff392f09adb8e4bd522dacbd064777bba836282
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
And move references to the deprecated fields to
NotificationRecord for testability.
Test: runtest systemui-notification
Change-Id: If3910dc78297ad66679b1efa380315127261a018
* Encapsulated application-level auto-fill logic on AutoFillSession.
Currently, Activity.java directly manages the IAutoFillCallback binder
object used to auto-fill its views, but this logic need to be
extended so Views can use it to draw the auto-fill bar.
* Pass auto-fill id and boundaries to requests
So AutoFillUI can display its affordance in the right places.
* Uses a new auto-fill id on View (instead of reusing accessibility's).
That allows moving the logic on whether a new request should be made or
the existing UI moved to the service side.
* Split service methods in 2, for shell cmd and app
And applied the right permission check on both.
* Removed CancelationSignal from onSaveRequest()
Since it's not really needed.
* Etc...
¯\_(ツ)_/¯
BUG: 34637800
BUG: 31001899
Test: CtsAutoFillServiceTestCases passes
Test: manual verification
Change-Id: Ibd0cb2cfff6d0f6bb6b697a423ed5e89df687b82
AutoFillService can now require user authentication, both at
FillResponse and Dataset levels;
- FillResponse authentication is typically used when the user data
need to be unlocked before the first use.
- Dataset authentication is typically used to unlock sensitive data
such as credit card info.
The authentication can be handled by the service itself (for example,
when it uses the credit card CVV to unlock it) or by the Android
system (when the service asks for fingerprint authentication).
Bug: 31001899
Test: manual verification
Test: CtsAutoFillServiceTestCases passes
Change-Id: If62f42f697ab5ef0d14d991ff1077d1c38808e61
- Created an AutoFillManager class, which provides methods to show
the auto-fill bar for views and virtual nodes.
- Automatically launches an auto-fill request when the IME is shown
(and an AutoFillService is set for the given user) on TextViews.
- Updated VirtualNodeListener to use this new API.
BUG: 31001899
BUG: 34171325
Test: CtsAutoFillServiceTestCases passes
Test: manual verification
Change-Id: Id72ce97da70217081b5823cfc7b138412634fcf3
- No one can snooze for an undetermined amount of time
- Only the assistant can unsnooze
- Listeners can retrieve a list of snoozed notifications
Test: runtest systemui-notification, cts verifier
Change-Id: Idfaee6d8bc15a5d41630f86f7e852468b07dc7d0
Add infrastructure and first sets of unit tests for LockSettingsService
Bug: 33126408
Test: runtest frameworks-services -c com.android.server.LockSettingsServiceTests
Change-Id: I4f3b7f6eaef7122f72b06bd11ce49134a093fe35
