Bug: 36481649
Test: CtsAutofillServiceTestCases (now with a test that has an autofill
session over two full screen fragments)
Change-Id: I55f2f6203f3bd5a7082b4ce90500d2c16a260c7d
- 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.
Fixes: 37078783
Fixes: 33197203
Bug: 33802548
Bug: 35956626
Test: CtsAutoFillServiceTestCases pass
Merged-In: I834d34b8af8bf0d781dc7e0ffcd6e600bfa2d183
Change-Id: I834d34b8af8bf0d781dc7e0ffcd6e600bfa2d183
ensure that ResolverRankerServices are from trust sources.
Test: manually shared images in Camera, and in PTP to confirm it works
as expected.
Change-Id: I3549292d424fec949e9115faea7a0c5bdec06e87
(cherry picked from commit 61cf4d145e)
- 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
Currently the virtual display created in VR mode is of fixed size. This
may not work for all the devices. Add APIs to make the resolution and
DPI adjustable from VrCore.
Bug: 37260266
Test: Sample reflection which works - cl/153039188
Test: adb shell set-persistent-vr-mode-enabled true
adb shell vr set-compatibility-display-properties 500 500 500
adb shell dumpsys display
>> DisplayDeviceInfo{"VR 2D Display":
uniqueId="virtual:android,1000,VR 2D Display,0", 500 x 500, modeId
6, defaultModeId 6, supportedModes [{id=6, width=500, height=500,
fps=60.0}], colorMode 0, supportedColorModes [0], HdrCapabilities
null, density 500, 500.0 x 500.0 dpi, appVsyncOff 0, presDeadline
16666666, touch NONE, rotation 0, type VIRTUAL, state ON, owner
android (uid 1000), FLAG_PRIVATE, FLAG_NEVER_BLANK,
FLAG_OWN_CONTENT_ONLY}
Change-Id: Ibb2d03b7f7f8f62fcce97fcc2b373ae3f09cef01
Signed-off-by: Karthik Ravi Shankar <karthikrs@google.com>
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
- 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
Currently, authenticate FillResponses do not support partition and follows
the "Highlander approach" (There can be just only one), which causes the
authentication UI to show on all views.
This CL overloads FillResponse.setAuthentication() so it requires the
AutofillIds of the autofillable fields, although behind the scenes it
calls the old method - once clients use the new method, the old method
will be removed and the underlying implementation changed.
The new behavior will be tested by testFillResponseAuthJustOneField()
on LoginActivityTest, although currently it's testing the old behavior.
Test: LoginActivityTest.testFillResponseAuthJustOneField
Bug: 35707731
Bug: 36855717
Change-Id: I601f3e4776aa8763415a06d8d802901a930728d2
bug: 30982298
Test: manual - shared images in Camera, texts in Messenger, and webpages
in Chrome.
Change-Id: If335c269ca54145839ad8fd4b3f9b93a74b550f8
(cherry picked from commit 35b9e30155)
The new service separates OEM lock management from the implementation.
Currently, a user restriction (DISALLOW_OEM_UNLOCK) and the persistent
data block have been used to implement OEM lock management. In future,
other implemention will be used e.g. a secure element.
The new API also allows for a signature to be passed when changing
whether the device is allowed to be OEM unlocked by the carrier which
can be used for cryptographic protection of the flag.
Bug: 34766843
Test: gts-tradefed run gts -m GtsOemLockServiceTestCases -t com.google.android.oemlock.gts.OemLockServiceTest
Test: cts-tradefed run cts -m CtsPermission2TestCases -t android.permission2.cts.PrivappPermissionsTest
Change-Id: I01660d7605d297f273d43436ca03d64ff611b6cf
