The change I58a9c06b7651ebe97cd03447b083cc9887f863b1
introduced a self-apparent bug. We fix it and amend the test case so
that the issue would have been caught.

Bug: 281951190
Test: atest ViewGroupTest
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:c45197fb27ddce3886ae392465c759027f1795cd)
Merged-In: I886a2594a091e5d1870e564b67d46ce5e4901ae5
Change-Id: I886a2594a091e5d1870e564b67d46ce5e4901ae5

It's safer to have this as an opt-in configuration, as not all devices
with multiple internal displays need to have their rotation matched.

Bug: 274416890
Fixes: 303780641

Test: manual
Merged-In: I1f7b2cf45f6e1c865ea51a9947e68c9e1ffa8d13
Change-Id: I1f7b2cf45f6e1c865ea51a9947e68c9e1ffa8d13

* changes:
  LockSettingsService: remove obsolete EventLog logging
  Ensure that LockSettingsService waits for gatekeeperd to be ready
  Make PasswordMetrics#computeForPasswordOrPin() private
  Remove PasswordMetrics#validatePassword()
  Enforce minimum pattern length in PasswordMetrics
  Properly validate credential in setLock(int, byte[], int, byte[])
  DPMS: allow getPasswordMinimumMetrics() to anyone who can set LSKF
  Allow constructing a PIN LockscreenCredential with mInvalidChars
  Make LockSettingsService enforce basic requirements for new credentials
  Add and use PasswordMetrics#validateCredential()
  Make LockscreenCredential remember whether it has invalid chars
  Allow LockscreenCredential to represent any proposed credential
  Convert LockscreenCredentialTest to JUnit4
  Handle incomplete protectors in destroyAllWeakTokenBasedProtectors()
  LockSettingsService: remove redundant calls to verifyChallenge()

Merge "Revert line introduced in previous CL that seems to always pass `false` for `onTrustManagedChanged`" into main

So the android.os.Debug#getBinderProxyObjectCount will include
the binder proxies from both of the Java and native layers.

Bug: 298314844
Test: dumpsys meminfo
Merged-In: Ifb57eeacc0a4b6ee6e164e83f6f843bfe36f2b15
Change-Id: I4fc8f48e0055544c32d9cf597d3573f0a48a13e4

DeviceConfig callbacks often block indef and cause test module timeouts.

Add a test timeout for this class and mark them as flaky to take out of
presubmit.

TODO: 275746222 - don't rely on these callbacks, and instead mock/fake
the config, since it isn't related to what we are testing.

Bug: 287361279
Bug: 303578791

Change-Id: I603ebe0ceac23335248a8cdb299d52829b55536a
Merged-In: I603ebe0ceac23335248a8cdb299d52829b55536a

Test: N/A
Change-Id: I1154d866611a744a34631a9bc129419b1e9f99e6

The name of this source file does not match the test class it contains.
Rename the source file to match the test class.

Flag: TEST_ONLY
Test: atest TrustTests
Change-Id: Ib1b4bbcf980545dd0ee7b08951185d4038954e37
Merged-In: Ib1b4bbcf980545dd0ee7b08951185d4038954e37
(cherry picked from commit 2e98f22c)

This change was introduce in commit fd27baff.
Test: verified manually,
  1. adb shell settings put global systemui/buffer/KeyguardUpdateMonitorLog DEBUG
  2. adb logcat -s "TrustRepositoryLog:*"
  3. Disable Extend Unlock and enable it, see the onTrustManagedChanged being passed with false and then true.
Change-Id: I2a4e3579d945a8c993b1a03eb27b05ceb4c4c792
Merged-In: I2a4e3579d945a8c993b1a03eb27b05ceb4c4c792
(cherry picked from commit b772ef6e)

Bug: 255714762
Test: presubmit
Change-Id: I7e29732e1e77e37cfb491521d14d2f3eb07deb36
Merged-In: I7e29732e1e77e37cfb491521d14d2f3eb07deb36

Making changes to use aidl_interface build system in
KeyAttestationApplicationProvider to support Rust, CPP and Java
backends.
Defined AAID interface and its parcelables using AIDL types.
Removed custom parcelables defined for AAID.

Bug: 267452060
Test: atest android.keystore.cts.KeyAttestationTest
Change-Id: Iec558642867c13e2998d7f69f00b3f1adf4e2b62

As per go/asa-remove-safetynet-fix-requirement, EventLog statements that
were added for SafetyNet are deprecated and can be removed.

Test: presubmit
Change-Id: Idc5ff9171d3f40676183c2f5460886adff288f09
Merged-In: Idc5ff9171d3f40676183c2f5460886adff288f09
(cherry picked from commit 18346d8f)

gatekeeperd is started asynchronously.  Thus, there is no hard guarantee
that it will be ready when LockSettingsService first tries to use it.
Therefore, use waitForService() to wait for it to be ready.  To avoid
introducing any unnecessary delay, stop calling getGateKeeperService()
from LockSettingsService#systemReady(), where GK isn't yet needed.

This is motivated by a bug that caused gatekeeperd to wait 5 seconds
during start-up, fixed by https://r.android.com/2623413.  Apparently,
that was enough of a delay to sometimes cause gatekeeperd to not be
ready by LockSettingsService#loadEscrowData().

Bug: 283055837
Test: Boot and 'atest com.android.server.locksettings'
Change-Id: I815151cc6024c447bf3eff194a911ecdaab22d10
Merged-In: I815151cc6024c447bf3eff194a911ecdaab22d10
(cherry picked from commit cdd03b77)

PasswordMetrics#computeForPasswordOrPin() has unnecessarily broad
visibility and was being misused by the clockwork settings app (fixed by
http://ag/23923392).  Now it is only used by PasswordMetrics itself and
unit tests, but the unit tests can just use computeForCredential()
instead.  Do that, and make computeForPasswordOrPin() a private method.

Test: atest PasswordMetricsTest com.android.server.devicepolicy.DevicePolicyManagerTest
Change-Id: I1028e946ac97bd51c489e630d2de6df7685d454f
Merged-In: I1028e946ac97bd51c489e630d2de6df7685d454f
(cherry picked from commit 3226b81b)

PasswordMetrics#validatePassword() is no longer used since all its
callers were to converted to use PasswordMetrics#validateCredential()
instead.  So, remove it.

Bug: 219511761
Bug: 232900169
Bug: 243881358
Test: build
Change-Id: Ica7adff4f7171b24518cd916f1d4f6d4707851d6
Merged-In: Ica7adff4f7171b24518cd916f1d4f6d4707851d6
(cherry picked from commit 25053e20)

For patterns, currently PasswordMetrics#validateCredential() does
nothing except validate that the pattern credential type is allowed.
Pattern length is supposed to be >= MIN_LOCK_PATTERN_SIZE, but that is
hardcoded into the ChooseLockPattern activity in Settings.

Since there are other places that can set a pattern lockscreen
credential, such as LockSettingsShellCommand, let's add the pattern
length validation to PasswordMetrics#validatePasswordMetrics() so that
it gets done in the same place as PIN and password validation.

Note that this required starting to populate the length field of
PasswordMetrics created for patterns.

Bug: 219511761
Bug: 232900169
Bug: 243881358
Test: atest PasswordMetricsTest
Change-Id: I9f33f86045ea5f674b8ab79f9fda62c988436c53
Merged-In: I9f33f86045ea5f674b8ab79f9fda62c988436c53
(cherry picked from commit e4c9d2de)

In KeyguardManager, one of the two overloads of setLock() properly
validates the new credential using the logic in PasswordMetrics, while
the other doesn't.  This appears to be an oversight, and it was allowing
a test to set a PIN containing invalid characters.  Fix this by always
calling PasswordMetrics#validateCredential() on the new credential.

Bug: 219511761
Bug: 232900169
Bug: 243881358
Test: atest android.app.KeyguardManagerTest
Test: atest android.app.cts.KeyguardManagerTest
Test: atest CtsSensorPrivacyTestCases # since it calls setLock()
Change-Id: I46d8bf920526a00d6e6d2145d06c8e39f8047ea8
Merged-In: I46d8bf920526a00d6e6d2145d06c8e39f8047ea8
(cherry picked from commit 0e4385e2)

Everyone who sets a new LSKF is supposed to first validate it against
the minimum password metrics.  Yet, the
SET_AND_VERIFY_LOCKSCREEN_CREDENTIALS or ACCESS_KEYGUARD_SECURE_STORAGE
permission is sufficient to set a new LSKF but isn't necessarily
sufficient to get the minimum password metrics.  This is preventing
'KeyguardManager#setLock(int, byte[], int, byte[])' from being fixed to
properly validate the new LSKF.

To fix this, make DevicePolicyManagerService#getPasswordMinimumMetrics()
accept these permissions.

Bug: 219511761
Bug: 232900169
Bug: 243881358
Test: see I46d8bf920526a00d6e6d2145d06c8e39f8047ea8
Change-Id: Ic69fd01dadf95ab49b025295711fa020180690ff
Merged-In: Ic69fd01dadf95ab49b025295711fa020180690ff
(cherry picked from commit 62dbf253)

KeyguardManager#setLock() (both overloads) and LockSettingsShellCommand
can try to set a PIN containing arbitrary characters.  The check for
digits-only happens in PasswordMetrics#validatePasswordMetrics().
However, due to one of my recent changes, before getting to that point,
constructing the LockscreenCredential throws IllegalArgumentException if
the PIN contains any chars outside ASCII 32–127.  This is because I had
thought this case would only be possible for PASSWORD.

As it's needed for PIN too, allow this case.

Bug: 219511761
Bug: 232900169
Bug: 243881358
Bug: 288904180
Test: atest LockscreenCredentialTest
Change-Id: Icd101f2dbb0c700a0cc5442a81c0c9ac345737b3
Merged-In: Icd101f2dbb0c700a0cc5442a81c0c9ac345737b3
(cherry picked from commit a775edfa)

Currently all LSKF requirements are enforced by
PasswordMetrics#validateCredential().  The standard minimum length of 4
is also checked again in LockPatternUtils#setLockCredential().

These are both at the caller's option, though.  These requirements could
be circumvented by calling ILockSettings#setLockCredential() directly.

Therefore, to provide higher assurance that at least the standard
requirements are met, this CL moves the standard length check into
LockSettingsService and also adds the invalid chars check alongside it.

Bug: 219511761
Bug: 232900169
Bug: 243881358
Test: atest LockscreenCredentialTest
Test: atest com.android.server.locksettings
Change-Id: Icc48a0d6caac0884bf3e3a9181828e8dfffff7e4
Merged-In: Icc48a0d6caac0884bf3e3a9181828e8dfffff7e4
(cherry picked from commit fe59a023)

Add a method PasswordMetrics#validateCredential() which takes a
LockscreenCredential argument and honors the "invalid chars" flag in it.
This should be used instead of PasswordMetrics#validatePassword() which
does not honor the "invalid chars" flag (which it does not have access
to) and only works for PASSWORD and PIN, not PATTERN and NONE.

Convert all callers of validatePassword() in frameworks/base to use
validateCredential().  After this, two callers remain: one in
packages/apps/Settings which I'll convert right away too, and several in
packages/apps/Car/Settings which will take a bit longer to get rid of.

Bug: 219511761
Bug: 232900169
Bug: 243881358
Test: atest PasswordMetricsTest
Test: Verified that 'locksettings set-password' no longer accepts
      a non-ASCII char that was accepted before
Test: see I5f1822a34688473cb103eb64dca56e4c19d4dd08
Change-Id: Ib8f43aef5b5aa5bb059780707582d0419f9ddf9a
Merged-In: Ib8f43aef5b5aa5bb059780707582d0419f9ddf9a
(cherry picked from commit 813f32c9)

http://ag/6283443 ("Refactor passwords/pins/patterns to byte[]" in
packages/apps/Settings), which went into Android 10, introduced a bug
where the chars of the lockscreen password are truncated to bytes before
the password is validated to contain only ASCII 32–127.  This causes
characters outside the intended range to be accepted.  Specifically, any
character U-XXXX where XXXX mod 256 is in 32–127 is accepted and is
treated as equivalent to some ASCII character.

This reduces the entropy of the password, but also it can make it
impossible for the user to unlock the device after rebooting.  This
happens if the chosen password uses a character that can only be entered
on a third-party keyboard (IME) that is not direct boot aware or was
uninstalled later.  (The potential dependence on a third-party keyboard
is one of the reasons that non-ASCII characters were never intended to
be allowed in lockscreen passwords in the first place.)

Unfortunately, it's likely that some users managed to set a password
containing non-ASCII character(s) and are happily using it.  To allow
fixing this bug without locking out such users, this CL updates
LockscreenCredential to keep track of whether it was instantiated using
any invalid characters or not, while still keeping the truncation bug in
place.  Later CLs will use this "invalid chars" flag to reject new
passwords that contain any invalid characters.

Bug: 219511761
Bug: 232900169
Bug: 243881358
Test: atest LockscreenCredentialTest
Test: atest com.android.server.locksettings
Change-Id: I5c3c55367c3a294578cd0f97ac0e315a11ed517e
Merged-In: I5c3c55367c3a294578cd0f97ac0e315a11ed517e
(cherry picked from commit d984e5fd)

Currently the ChooseLockPassword activity in Settings creates a
LockscreenCredential object for the text the user has entered, every
time a character is added or deleted to/from the text view.  It then
uses this LockscreenCredential to validate that requirements such as
minimum length have been met.  Thus, LockscreenCredential is expected to
be able to represent any proposed credential, even an invalid one.

Yet, currently the constructor of LockscreenCredential throws an
exception if the length is 0 and the credential type is not NONE.  For
the empty text case, ChooseLockPassword currently works around this by
constructing a LockscreenCredential of type NONE and then actually
treating it as a PIN or PASSWORD when validating it.

To make it possible to fix the bug where invalid characters are being
allowed in passwords, I'm adding a new validation method that operates
on LockscreenCredential.  For ChooseLockPassword to be converted to
this, though, it needs to start constructing a LockscreenCredential with
the correct type for the proposed credential.  Therefore, this CL allows
non-none LockscreenCredential objects to be constructed with length 0.

Bug: 219511761
Bug: 232900169
Bug: 243881358
Test: atest LockscreenCredentialTest
Test: atest com.android.server.locksettings
Change-Id: I6b951759aa7fabacc46c20bbfd31d3a0dafa4c1c
Merged-In: I6b951759aa7fabacc46c20bbfd31d3a0dafa4c1c
(cherry picked from commit 8066a758)

Convert LockscreenCredentialTest from the JUnit3-based AndroidTestCase,
which is deprecated, to JUnit4.

Bug: 219511761
Bug: 232900169
Bug: 243881358
Test: atest LockscreenCredentialTest
Change-Id: Id8da1606b1f758ff91f67c25d37a36f36a72c2bf
Merged-In: Id8da1606b1f758ff91f67c25d37a36f36a72c2bf
(cherry picked from commit b63430f2)

A partner reported a NullPointerException in
SyntheticPasswordManager#destroyAllWeakTokenBasedProtectors() because
loadState(SP_BLOB_NAME, ...) returned null.  I think the only way this
could happen is if an incomplete protector exists on-disk due to a
crash, containing the secdiscardable file but not the spblob file.

It does seem theoretically possible, though, so make
destroyAllWeakTokenBasedProtectors() handle this case by filtering the
protectors by the existence of the spblob file.

Bug: 285241930
Change-Id: Ia148234aa332ca716dcb208a814ae2d3b3c9f6b7
Merged-In: Ia148234aa332ca716dcb208a814ae2d3b3c9f6b7
(cherry picked from commit 937dae7f)

Both unlockLskfBasedProtector() and unlockTokenBasedProtector() do a
Gatekeeper verification immediately after decrypting the SP.  Therefore,
it's redundant for doVerifyCredential() to do it again.

Similarly, the same thing is redundant in
setLockCredentialWithSpLocked() too, since either
unlockLskfBasedProtector() or unlockTokenBasedProtector() was just
called to get the SP in the first place.

Remove these redundant calls to verifyChallenge() to simplify the code
and improve performance.

Bug: 269394345
Test: atest AuthBoundKeyTest
Test: atest com.android.server.locksettings
Change-Id: Ib73b4a082793458cedb7d06d3f81b77abb427426
Merged-In: Ib73b4a082793458cedb7d06d3f81b77abb427426
(cherry picked from commit e9d7d483)

Bug: 298295554
Merged-In: Id9763fb487e94440df2e61fbb7910902baa12fa8
Change-Id: Ib873cb09386abdacfc3693605a6e6b45f11e3f37

Revert submission 2759049-framework-pdf

Reason for revert: it blocks us from enabling prebuilts in next target in main (go/stale-mainline-prebuilts for more info)

Reverted changes: /q/submissionid:2759049-framework-pdf

Change-Id: I53b3216ec43471789a6c23c6b620c8a153953cc9