Instead of allowing the user to click the entry, make the entry
non-clickable and mention that it's blocked by IT admin.
Bug: 297965563
Test: atest LockScreenSafetySourceTest
Change-Id: I821d661dd924358a5e7b033118b63e104ade9eaf
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: 295845686
Test: atest LockScreenSafetySourceTest
Change-Id: Ibaa134b1f93304731f37444ab222b3dc628bae02
Settings already sends a SafetySourceIssue to Safety Center when the
user has not set a screen lock. This CL specifies the corresponding
notification for Safety Center to post for that issue.
Also specified the actionability of this issue as manual (although
this is the default so no functional change here, just for clarity).
Fix: 265799125
Bug: 260574754
Test: Manually
Change-Id: I9d579cdb8061d247e89031a5bc360f8fd5848277
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
- use correct severity enum for issues
- update biomterics on lockscreen change
- clean up some nearby tests to use eq matcher instead of captor
Test: SettingsUnitTests
Test: Manually tested
Bug: 223170514
Bug: 222338885
Change-Id: I4e28a418473cbe7cd5d75daf0d62776654fa7917
