Safety Center expects a response to the broadcast in this case.
The Settings app should respond with explicitely no data to Safety
Center rather than not respond.
Bug: 295143688
Test: atest BiometricsSafetySourceTest
Change-Id: Iea7f7c53919d90bf3d7fd989fb2f320a5c9ee9c6
The screens don't work as expected if they're launched in the work
profile. The reason for this is that Settings handle the user separately
with an extra inside the intent. I assume launching the actual screen in
a separate user is not supported.
Note that I've also:
1. Added a safeguard to make sure that the "active unlock" code path
only occurs in the profile parent — it seems preferrable (see
b/277877289#comment4)
2. Added the user id as an identifier on the intents lauched by the
entries. The reason we do this is to make sure the user id is taken
into account in the PendingIntent#equals implementation. This was
automatically taken care of when launching with the profile context,
but now that we launch everything in the profile parent context we
have to make sure the user id is taken into account
Bug: 278665241
Bug: 277877289
Test: manual
Change-Id: Idcaa31cd56ed64768aa8f069d30d2adeb7269099
We want to show this page as long as active unlock is enabled. The
underlying check of isAvailable checks if the appropriate biometrics are
available and updates the title accordingly.
Test: manual test, confirm combined page appears when active unlock on
Test: atest BiometricsSafetySourceTest
Bug: 264812908
Change-Id: I5da1c20d65b879751bdd615c14c2f8a71cc54d80
Settings uses a system of intent extras to open subsettings pages. When
PendingIntents are created from these Intents, the system does not think
they are unique as extras are not included in this equality check. So
only one of them is likely to work.
A unique request code can be used to distinguish between them.
Bug: 238605613
Test: atest LockScreenSafetySourceTest
Change-Id: Ia59197eeb86e988d9ffbb86caff4bbda7b30f059
