This is safe for O as all updates come from a trusted
source.
Change-Id: Iab8ec1e68f8f9f9e345ebf4d5e44718191cc49e6
Fixes: 37986254
Test: runtest systemui-notification
There is now an IBinder "token" that must be specified when setting
the whitelist duration for an Intent. To have the whitelist supplied,
the caller to send a PendingIntent must pass in the same token. The
PendingIntent and IntentSender classes now internally maintain this token
to pass in when their send() is called.
The big complexity for making this work is we now need to associate this
whitelist token correctly with the actual PendingIntent objects that
applications and other code is getting. To do this, we propagate the
token in the Notification object, and have a new API on Parcel that allows
us to make it available to PendingIntent when it is unmarshalled. And
this allows to deal with PendingIntents appearing in nested bundles, as
we can propagate that information from the original Parcel to the new
Parcel that Bundle keeps to delay unmarshalling.
Test: manual
Change-Id: Idda00490ccfe2be37e4ab21354b9ab7528a52750
Bug: 37778488
Test: In a FBE device, turning on and off work profile quickly.
Observe that no more this exception in the log.
Change-Id: I38d72ff5fbb275cf13936abd56f7f4f7b51eea0a
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
