If a dataset needs to be authenticated the fill service
may not have the values but needs to tell the system for
which fields to show the fill UI. We now allow passing
a null value to mean the view is a part of the dataset
semantically but its value should remain unchanged.
If a dataset has no values, i.e. the related autofill ids
are mapped to null, we cannot properly filter. In this case
we always match such items regardless what the user typed.
While at this improved accessibility support for filtering
to announce when the number of items being filtered changes.
Also while at this allowed a dataset authentication to return
a response which replaces the current response and refreshes
the UI. Matching datasets with null values to any text plus
allowing a response to be returned from a dataset auth enables
the use case where there is always "Import" item at the
end of the list which when clicked can show arbitrarily more
data entries associated to other apps.
Another change is that we now provide the client state
bundle on both request and dataset auth.
Finally, this change gets rid of dataset waiting auth and
response waiting auth concepts since the reference to the
response and the dataset is piped with the auth request.
Fixed a bug where the width of the autofill UI was not
properly measured by going over all items in the adapter.
Now we measure enough height to fit the first three and the
width id the width of the widest item in the adapter.
Test: Added LoginActivityTest#testDatasetAuthTwoFieldsReplaceResponse
Added LoginActivityTest#testDatasetAuthTwoFieldsNoValues
Added LiginActivityTest#filterTextNullValuesAlwaysMatched
All autofill CTS tests pass
bug:37724701
bug:37424539
Change-Id: Ic19e5d7cbdbb7d110c9e7da0ad60b540cbf1aecf
This changelist enforces that activities targeting O and beyond
can only specify an orientation if they are fullscreen. The
change ignores the orientation on the server side and throws an
exception when the client has an orientation set in onCreate or
invokes Activity#setRequestedOrientation.
Fixes: 33483680
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test CtsServicesHostTestCases android.server.cts.ActivityManagerAppConfigurationTests#testNonFullscreenActivityProhibited
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test CtsServicesHostTestCases android.server.cts.ActivityManagerAppConfigurationTests#testLegacyNonFullscreenActivityPermitted
Change-Id: I4f7f79744918fad6465a537633dfadec8d05c6df
From the WTF log we know Args.run() sometimes gets called multiple
times.
Remove the Runnable interface from the Args class to make it
impossible to cast it to Runnable.
If the WTF still happens with this change, that'd be *very* interesting.
Test: Build and boot
Bug: 37809561
Change-Id: Id4bd9bd8d4098086649235fddfc2136527805838
KeyguardUpdateMonitor onFingerprintAuthenticated currently doesn't
immediately update the trust state. TrustManager.isDeviceLocked()
should return "unlocked" after FP is authenticated.
Fixes: 37963501
Test: Two tests as follows
1) use custom app that polls isDeviceLocked(), make sure
it returns "unlocked" after FP is authenticated but keyguard is showing.
To get that state, slide keyguard up slightly and touch FP sensor
without letting go of the other finger.
2) with at least 2 accounts, run the app on both accounts.
when switching users, the app should show that the "inactive/underneath"
user is locked. the app should report that the current user is locked
before touching fp, and unlocked after touching fp
Change-Id: I2a11411deebf369d85dee62cffdcd631bd99649f
we have a link to the client which is enough to find the views.
Also there was some cases where the windowToken was not updated
properly. This is moot now.
Also: Read a array of views from the client to speed up the
client<->AutofillManager communication.
Fixes: 38070352
Test: CtsAutoFillServiceTestCases
1 Started autofill, saw fill UI
2 Home button
3 Kill activity in background
4 Recents -> back to activity
5 Saw fill UI restored
Change-Id: I7c2c9411204fa5d65867efae9b7296399121c3a2