- Check UID to make sure one service cannot read FillSelections of other
services
- Add id to Dataset to allow to tag the datasets. This id is then found
in the FillSelection.Event
- Add clientState to FillSelection to allow service to store more data
Fixes: 36871500
Test: CtsAutoFillServiceTestCases
Change-Id: Ice894245508227265294a1c59ea97842175e5aec
Because listeners can see notifications on managed profiles.
Test: runtest systemui-notification and testing with a sample app
(reading and updating channels and getting change
callbacks on a managed profile)
Change-Id: I5d7af3c417e3a3d18f992cc9ad01fbd7959de398
Fixes: 36783632
An service can option to finish the session once all views that it
declared as important. Views that are important are all autofillable
views of any partition and the saveable fields of the last partition.
Test: CtsAutoFillServiceTestCases
Fixes: 35708237
Change-Id: I0ccade8ebb427e5d8928697ef0007c75d3f83df0
Now it's possible to listen to changes on wallpaper colors by
registering a listener on WallpaperManager. It's also possible
to get the current wallpaper text color hints.
Bug: 36856508
Test: compilation
Change-Id: I5102cb7be9a4af60b85fc8913154a79dfe5c21a0
When saving data filled by the user the platform provides to
an autofill provider the state of the UI allowing the provider
to interpret this state and store relevant information.
A limitation of the current design is that the fill provider
needs to interpret the screen content twice, once handling a
fill request and once handling a save request. To address this
we are introducing a id for each fill request allowing the
autofill provider to associate arbitrary state with each fill
request and store it in the client data bundle later passed
to save.
Another limitation of the current design is that if the screen
changes dynamically while the user interacts with the app the
UI state passed on save represents a static snapshot, therefore
it is not possible to the autofill provider to determine the
context in which the data in the UI was filled. We could
keep the views and have deltas for views being removed/added
/moved/changed but this is not enough as the fill provider
needs to know not only what changed but what changed for every
fill request and in one session there could be multiple fill
requests. To address this we provide a list of fill contexts
on save each of which has the id of the corresponding fill
request. This allows the fill provider to know the exact context
in which the data was popuplated and also use its custom client
state for this fill request if desired.
This change deprecates the old APIs and the new ones delegate
to the old ones. Once the clients migrate to the new APIs we
will remove the old ones.
Test: all autofill CTS tests pass
Change-Id: Idcebcc671aa3c078a305d8c358e225274fccc588
We now have a software feature for autofill which can be used
by partners to disable it on low-end devices or form factors
for which autofill doesn't make sense.
bug:35956220
Test: manual (requires a custom build)
Change-Id: I6c06462ed9ca3ae93331700dce38a8c08dfd0722
-Implement EuiccManager#startResolutionActivity. This is just a
pass-through to start the LUI dispatcher.
-Add and implement EuiccManager#continueOperation. The LUI calls this
method upon completion of a resolution action to continue the original
operation.
-Remove the "consentGranted" bit from DownloadableSubscription. This
was originally to be used by the LUI to communicate user consent, but
it is impossible to allow the LUI to modify the given
DownloadableSubscription while also preventing it from tampering by
the untrusted app. It's also unclear what kind of "consent"
was granted - it could be to disable the physical SIM, or to
grant an unprivileged app permissions to switch. Instead, this bit is
passed by the LUI to continueOperation() as an extra and propagated
down as an explicit parameter to the LPA.
Bug: 33075886
Test: Manual verification using test LPA
Change-Id: I17d8028e0ecea365ca5a2cc17424fc9645f5a489
- Callbacks when channels and groups are modified
- Allow them to read and update channels and groups
Test: runtest systemui-notification
Change-Id: Ie4d02bd4583f71f9faf27603bcc59a1ec0eeaf46
Also:
- Give the session an integer ID as the activityToken is not stable over
restarts of the activity
- Verify that session is only accessed by one UID
- stabilize AccessibilityViewIds over activity lifecycle at least for
the IDs we can do that. This required to split the ID namespace in
"per-app" and "per-activity" views. Only the later ones can be
restored.
- Do not end session when app is killed (as it can be restarted)
Bug: 35484143
Fixes: 36392498
Test: cts-tradefed run cts-dev -m CtsAutoFillServiceTestCases --test=android.autofillservice.cts.SessionLifecycleTest
cts-tradefed run cts-dev -m CtsAutoFillServiceTestCases
Change-Id: I229acc1b3ce35fb57262da7d7466b5d4328b49d4