Additionally, don't hide keyguard when it's disabled if the user has locked
down the device.

Manual test steps:
    1. Enable app pinning and disable "Ask for PIN before unpinning" setting
    2. Pin an app (ie: Settings)
    3. Lockdown from the power menu
    4. Observe: user is brought to the keyguard, primary auth is
       required to enter the device.
       => After entering correct credential, the device is still in
          app pinning mode.
       => After entering an incorrect credential, the keyguard remains
          showing and the user can attempt again up to the limit

Bug: 300463732
Bug: 218495634
Test: atest KeyguardViewMediatorTest
Test: manual
Change-Id: I70fdae80f717712b3dfc9df54b9649959b4bb8f0
Merged-In: I70fdae80f717712b3dfc9df54b9649959b4bb8f0

This reverts commit b23c2d5f.

Reason for revert: b/300463732 regression
Bug: 300463732
Bug: 218495634

Change-Id: I31485d0d8caa3060e998636b071dbe03f6b4fc82
Merged-In: Ida8f2ab5e4ac79b38c21ba7bacfe9c374c9cc600
Merged-In: I314e5615b798487d9a965eaa0937905b65aa85fc
Merged-In: I31485d0d8caa3060e998636b071dbe03f6b4fc82

Test: manual testing on device
Change-Id: I68903ebd6d3d85f4bc820b745e3233a448b62273
Bug: b/261709193
(cherry picked from commit b651d295)
Merged-In: I68903ebd6d3d85f4bc820b745e3233a448b62273

Bug: 288110451
Test: manual
Change-Id: Idbde676f871db83825155730e3714f3727e25762
Merged-In: Idbde676f871db83825155730e3714f3727e25762

This CL fixes the issue where, when an app have multiple main
activities, the total number of shortcuts can grow indefinitely if they
were published through addDynamicShortcuts.

Bug: 281061287
Test: manual
Change-Id: Ib3eecefee34517b670c59dd5b8526fe9eb24f463
Merged-In: Ib3eecefee34517b670c59dd5b8526fe9eb24f463

readFileDescriptor doesn't provide ownership of the fds. fdopen
needs ownership of the fds. Fds read from parcel should be duped
in this scenario and readUniqueFileDescriptor dups fds internally.

Test: m incidentd_service_fuzzer && adb sync data && adb shell /data/fuzz/x86_64/incidentd_service_fuzzer/incidentd_service_fuzzer
Test: atest incidentd_test
Bug: 286931110
Bug: 283699145
Merged-In: Ibe03a17dee91ac5bf25d123d4fd9c0bdd3c7d80e
Change-Id: Ibe03a17dee91ac5bf25d123d4fd9c0bdd3c7d80e
(cherry picked from commit ba78ef27)

Bug: 288113797
Test: manual
Merged-In: I392f8e923923bf40827a2b6207c4eaa262694fbc
Change-Id: I392f8e923923bf40827a2b6207c4eaa262694fbc

Similar to ag/24422287, but the same URI verification should be done in
SettingsProvider as well, which can be called by apps via
Settings.System API or ContentProvider APIs without using
RingtoneManager.

BUG: 227201030
Test: manual with a test app. Will add a CTS test.
Change-Id: Ic0ffa1db14b5660d02880b632a7f2ad9e6e5d84b

Even if the corresponding styles themselves were not applied to the Notification.Builder.

Test: atest NotificationManagerServiceTest
Bug: 287640400
Change-Id: I25acab19be7dd486aabede8c91dbad5a1a217abf
Merged-In: I25acab19be7dd486aabede8c91dbad5a1a217abf

Ensure that when the usersetup for the user is not complete, we do not
want to go to lockscreen, even if lockscreen is not disabled.

Bug: 222446076
Test: add Unit test,
Test: Wipe device, auth sim pin in setup, observe that lockscreen is
not there.

Change-Id: I8e33db8eb6e2c917966cab3d6a4f982670473040

AM.backupAgentCreated() should enforce that caller belongs the package called in the API.

Bug: 289549315
Test: atest android.security.cts.ActivityManagerTest#testActivityManager_backupAgentCreated_rejectIfCallerUidNotEqualsPackageUid
Change-Id: I9f3ae5ec0b8f00e020d471cc0eddf8bd8bdbb82d

Bug: 288896339
Test: Manual, verify that the app which can be found on the bug can no longer call
keyguardGoingAway successfully


Require permission to unlock keyguard

Bug: 288896339
Test: Manual, verify that the app which can be found on the bug can no longer call
keyguardGoingAway successfully
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:bd2aa5d309c5bf8e73161975bd5aba7945b25e84)
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:ef1345d278bd2a8944c6362bf65cff7305ca6fc5)
Merged-In: I7ba7e56f954c8e6f1f734311f735215918975bc6
Change-Id: I7ba7e56f954c8e6f1f734311f735215918975bc6

Bug: 291299076
Test: Build and flash the device and check if it throws exception for
non UsbInterface object
Test: atest CtsUsbManagerTestCases
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:85d7e6712a9eeeed3bdd68ea3c3862c7e88bfe70)
Merged-In: I2917c8331b6d56caaa9a6479bcd9a2d089f5f503
Change-Id: I2917c8331b6d56caaa9a6479bcd9a2d089f5f503

When RescueParty detects that a system process is crashing frequently,
it tries to recover in various ways, such as by resetting all settings.
Unfortunately, this included resetting the secure_frp_mode setting,
which is the means by which the system keeps track of whether the
Factory Reset Protection (FRP) challenge has been passed yet.  With this
setting reset, some FRP restrictions went away and it became possible to
bypass FRP by setting a new lockscreen credential.

Fix this by excluding secure_frp_mode from resets.

Note: currently this bug isn't reproducible on 'main' due to ag/23727749
disabling much of RescueParty, but that is a temporary change.

Bug: 253043065
Test: With ag/23727749 reverted and with my fix to prevent
      com.android.settings from crashing *not* applied, tried repeatedly
      setting lockscreen credential while in FRP mode, using the
      smartlock setup activity launched by intent via adb.  Verified
      that although RescueParty is still triggered after 5 attempts,
      secure_frp_mode is no longer reset (its value remains "1").
Test: Verified that secure_frp_mode still gets changed from 1 to 0 when
      FRP is passed legitimately.
Test: atest com.android.providers.settings.SettingsProviderTest
Test: atest android.provider.SettingsProviderTest
Change-Id: Id95ed43b9cc2208090064392bcd5dc012710af93
(cherry picked from commit 9890dd7f)
(changed Global.SECURE_FRP_MODE to Secure.SECURE_FRP_MODE,
 needed because this setting was moved in U)
(removed static keyword from shouldExcludeSettingFromReset(),
 needed for compatibility with Java 15 and earlier)
(resolved conflict in resetSettingsLocked())
Merged-In: Id95ed43b9cc2208090064392bcd5dc012710af93

Test: manual with the steps from the bug
Test: manual with a normal icon
Test: atest CanUseIconPredicate
Test: atest ControlViewHolderTest
Bug: 272025416
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:ffa97f42dd9496bb404e01727c923292d05a4466)
Merged-In: I39b7bc62d82e20b5ba8747be13a2aa7bf21a59a2
Merged-In: I60896a6f53307f0e97a9223b599a2891c6c0c08d
Merged-In: Ib0e677f7ccbed6299ea07939519c7dcf6d371bec
Merged-In: Ibe4fb69a90904787b9f97a7cd90d318a047d1e11
Merged-In: Iba846f19098c71c0519470cd7b8c1fd60d47e70b
Change-Id: I354469a53611c094c7bb695b1c2017c6786dd396

Which may be abused by malicious app to create a non-visible PiP
window that bypasses the background restriction.

Bug: 270368476
Test: Manually, using the POC app
Change-Id: Ifc0e4ffe8b7a9754053246069cb480aa6a59a7e1

pushedEventThread references class members after detaching. Making
pushedEventThread as class member and joining in statsService
destructor. Adding a method to stop readLogs thread.

Ignore-AOSP-First: Bug is in still security triage and fuzzer is
crashing on startup.
Test: atest statsd_test
Test: m statsd_service_fuzzer && adb sync data && adb shell
/data/fuzz/arm64/statsd_service_fuzzer/statsd_service_fuzzer -runs=10000
Bug: 285645039

Change-Id: I1e886f9ccb7203714216da061c35e793b2a63d8a

Bug: 278246904
Test: manually, with the PoC app attached to the bug
Merged-In: Idbd4081bf464e2b3420d4c3fd22ca37867d26bc0
Merged-In: Ib3f5b8b6b9ce644fdf1173548d9078e4d969ae2e
Change-Id: Iecfc1fb962de611cbe3c51a44ba4fded53925a7d