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)
On ViewState: split value into mCurrentValue and mAutofilledValue.
On Session: replacing mAutofilledDataset by mDatasetWaitingAuth and
ViewState.getAutofilledValue() (mAutofilledDataset is still needed,
but will be removed in the first partitioning CL).
Also fixed a missed 'return' on TimePicker.autofill()
Bug: 35707731
Test: CtsAutoFillServiceTestCases pass
Change-Id: Icc32701ae3e499a77d99e6ae1daa7d070a3df631
Explicitly send broadcasts to systemui, because thats where they are
going.
Test: cts
Change-Id: I2fdc74f2cf874e818ef52f37a58adf7cd38ca455
Fixes: 35704517
(cherry picked from commit c7f7111095)
Use VrManager as a proxy to pass the controller data file descriptor
from VrCore to VrWindowManager, since the latter is a purely native
service with no Java visibility.
This is intended to be replaced by moving the relevant parts of
VrWindowManager into VrCore (b/36506799).
Bug: 35619424
Test: manual on device
Change-Id: I9545349893ed9b23de4ba8d3cb61c7d403ad0b97
This reverts commit 2abf1c60cc.
We need the ability to register remote callbacks for persistent vr mode,
so vr flinger can register for persistent vr mode events.
Bug: 35885165
Test: Manually confirmed vr flinger can register and receive persistent
vr mode events.
Change-Id: I7713c4c8acae9a369fd0c06695ef712fddd12be8
We need the ability to register remote callbacks for persistent vr mode,
so vr flinger can register for persistent vr mode events.
Bug: 35885165
Test: Manually confirmed vr flinger can register and receive persistent
vr mode events.
Change-Id: I28ee7f4e103fc53ae3e5d8e692cb2f6fa7bdbc82
There is some flakiness in View#onConfigurationChanged callback -
if ViewRootImpl receives config update earlier than ActivityThread,
it may not detect the configuration change and skip inner updates.
Also now ViewRootImpl assumes that it receives the global config as
a param, but instead it gets merged config from WM. This means that
ViewRootImpl#sConfigCallbacks was sending incorrect values to the
recipients.
This CL switches to sending global and override configuration to the
client separately. Also in case if there is a corresponding activity,
it first updates it and waits for update callback to ViewRootImpl.
This way global config and override config for activity will always
be set first and resources will be updated before inner state of
ViewRootImpl is updated.
Bug: 35870157
Bug: 34164473
Test: android.server.cts.ActivityManagerDisplayTests
Test: testOnMovedToDisplayCallback
Change-Id: Ic9e7541cf25ecfac6ec90e48f7efb0ece91f657e
- 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 FillResponse was automatically adding the AutofillId of all Datasets to
the SaveInfo object, but that would cause problems when the AutofillService
is not able to save some data (for example, if it comes from a read-only
backend).
Bug: 36076444
Test: OptionalSaveActivityTest pass
Test: m update-api
Change-Id: I1d5faaddf29e1be0f357438c8485e07caf975293
Add an API to get the compatibility display ID from CompatibilityDisplay
in the framework.
Testing Done: Compiled, built and used this API from ActivityManager and
it works.
Bug: 36071574
Change-Id: Ie4d1eb6a6befa7dbc3413519de20e2762529079d
Signed-off-by: Karthik Ravi Shankar <karthikrs@google.com>
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
1. Added a new API for a connected auto-fill service to
disable itself
2. Added a new shell command to destroy all pending sessions
which is used in CTS tests
3. Fixed a bug where the unbind timeout was in minutes
instead of seconds
Test: wrote CTS tests, all auto-fill tests pass
bug:35848030
Change-Id: I681605aa0b8c004a0f14e30b57117c291d89a894
