Making the scope more accurate that only acquire the lock when trying
to access frame info in FrameInfoVisualizer, then make it irrelevant
to the real draw operation.

Bug: 317995179
Test: 1.going to developer options
      2. swapping the "profile hwui" option from "none" to "bars"
          and back a couple times, no crash

Change-Id: I069a28a7e847c0c3fca94fd9c43e95382f501b80
Merged-In: I069a28a7e847c0c3fca94fd9c43e95382f501b80

Merge "Merge "Revert "Making adapter child views in RemoteCollectionItemsAdapter size-aware"" into android14-tests-dev am: 679d9285" into main

Merge "Revert "Making adapter child views in RemoteCollectionItemsAdapter size-aware"" into android14-tests-dev am: 679d9285

Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/2915243



Change-Id: I2e82b39f5d5295e491a0d63a2259b08e2034968c
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>

Merge "Revert "Making adapter child views in RemoteCollectionItemsAdapter size-aware"" into android14-tests-dev

This reverts commit 225bfb76.

Reason for revert: We are possibly losing tombstones

Change-Id: I8372ae3b7b5db63bc48155eca63eb3cae41239c8

* changes:
  RemoteInputConnectionImpl should not call on IMM#isActive()
  Simplify RemoteInputConnectionImpl#finishComposingText*()
  Remove RemoteInputConnectionImpl#mLock, which is redudant

Historically RemoteInputConnectionImpl has been calling on

  InputMethodManager#isActive()

to see if the InputConnection is considered to be active or inactive
when actually handling each incoming InputConnection operation.

However, InputMethodManager#isActive() is also known to be tricky
because it internally calls InputMethodManager#checkFocus(), which can
have non-trivial side effects.

With this CL, RemoteInputConnectionImpl keeps maintains its own
boolean state on whether #deactivate() is already called or not so
that it does not need to rely on IMM#isActive() any more.

For 99% cases there must be no observable behavior change, and for the
remaining 1% cases the new behavior should be more easily
understandable.

Bug: 291826769
Test: atest CtsInputMethodTestCases:InputConnectionHandlerTest#testInputConnectionSideEffect
Merged-In: I2fb9c549da19ff01e7cc3fd8bfc1f9c19aa0f0a8
Change-Id: I2fb9c549da19ff01e7cc3fd8bfc1f9c19aa0f0a8

With my previous CLs [1][2], we can generally assume the following
things.

 - InputConnection#closeConnection() always gets called when it
   becomes invalidated, including the case when the IME has switched
   to another IME client.

 - Each implementation of InputConnection#closeConnection() is
   expected to do appropriate clean up including finishing composing
   text. {Base,Editable}InputConnection actually do this correctly.

With that it should be safe for #finishComposingText*() to follow the
same pattern about isActive().

 [1]: I234309c5880c9fe0b299b8bd0f8862796d4dda0d
      9f9afe52
 [2]: If2a03bc84d318775fd4a197fa43acde086eda442
      aaa38c9f

Bug: 35301295
Bug: 291826769
Test: presubmit
Merged-In: If913701bf8555f5d76fceb272e38a99f5e243bbe
Change-Id: If913701bf8555f5d76fceb272e38a99f5e243bbe

It is guaranteed that the following two boolean expressions have
always the same value observed outside from
RemoteInputConnectionImpl#mLock.

  A. RemoteInputConnectionImpl#mFinished
  B. RemoteInputConnectionImpl#mInputConnection != null

With that we should be able to simply merge them into an atomic
reference object

  AtomicReference<InputConnection>

without requiring RemoteInputConnectionImpl#mLock as a lock object.

This CL does so as a preparation to clean up RemoteInputConnectionImpl
for Bug 291826769.

There should be no observable behavior change, except for the fact
that

  RemoteInputConnectionImpl#dumpDebug()

no longer blocks other operations that required mLock, which is kind
of out of our original intention.

Bug: 291826769
Test: presubmit
Merged-In: I69fa2c81670f84be3dd4a808262758a803f69dfc
Change-Id: I69fa2c81670f84be3dd4a808262758a803f69dfc

ed0743da

Bug:b/289203818
Test: m nothing

Change-Id: Id156c0fd4b7b783c5b9f1488914f5650e30ffed5
Merged-In: If6789fee9a908231babd7624280b40515d377dfe

This reverts commit 28dcae49.

Reason for revert: Revert framework changes on test platform, will follow up with a CL that makes the CTS test permissive

Change-Id: I825b4978270720c3693e718f007040c033ccf58f

Starting in Android 12, unlocking the device with a class 1
("convenience") biometric, class 2 ("weak") biometric, or a trust agent
unexpectedly doesn't allow the use of UnlockedDeviceRequired keys.  The
cause of this bug is that the cryptographic protection that Keystore now
applies to UnlockedDeviceRequired keys incorrectly assumes that the
device can only be unlocked using LSKF or via a biometric that
participates in Keystore (has a SID and uses HardwareAuthTokens).
Actually, Keyguard also allows the device to be unlocked using weaker
biometrics that do not particiate in Keystore, if they are enrolled.
Similarly, there are also cases where a trust agent can actively unlock
the device, e.g. unlocking a phone using a paired watch.

In combination with the Keystore changes in
I1b0d9ec4f9e31dc91642e865045766bd17e34cad, this CL fixes the bug by
making Keystore retain the UnlockedDeviceRequired super keys in memory
if a weak unlock method is enabled at device lock time.  This does mean
that UnlockedDeviceRequired is enforced only logically when a weak
unlock method is enabled, but this is the best we can do in this case.

Note: a future CL will take into account the progressive expiration of
unlock methods while the device is locked and upgrade the security of
UnlockedDeviceRequired accordingly.  The present CL focuses just on
choosing the correct protection at lock time, fixing a user-visible bug.

Test: Ran the following automated tests with and without the
      fix_unlocked_device_required_keys_v2 flag enabled:
          atest com.android.server.locksettings \
          && atest TrustManagerServiceTest \
          && atest TrustTests \
          && atest -p --include-subdirs system/security/keystore2 \
          && atest CtsKeystoreTestCases

Test: Manually tested each combination of biometric setup: none,
      fingerprint, face, and fingerprint+face.  Locked the device, then
      verified via logcat that Keystore protected the
      UnlockedDeviceRequired keys in the expected way, then verified
      that UnlockedDeviceRequired keys cannot be used (even in the case
      where the super keys were not protected).  Unlocked device using
      weakest method available, then verified that
      UnlockedDeviceRequired keys can be used.  To check whether
      UnlockedDeviceRequired keys can be used or not, used the CTS
      method mentioned in the Test of https://r.android.com/2878769.

      Also, enabled Extend Unlock with a bluetooth device, and verified
      that it's not counted as an unlock method.

      Also, verified that if Lockdown mode is triggered, the
      UnlockedDeviceRequired keys are fully protected.

Bug: 296464083
Change-Id: I34dc49f1338e94755e96c1cf84de0638dc70d311

Bug: 290312729
Test: N/A
Change-Id: I65e7ce4b7113639523aec1e08682a334056cbb69

This will help minimize merge conflicts down the line

Bug: 289097671
Change-Id: I005714dcf7be28d64e9d131b46d86c857ee4231d
Merged-in: I005714dcf7be28d64e9d131b46d86c857ee4231d

* changes:
  Pass in a new instance supplier for creating RingBuffer.
  Update RingBuffer to take Supplier<T> for creating new instances.

Bug: 312324146
Test: Add android-test-mock-current.txt to the Android.bp
Merged-In: I228744137f82e14bec936b11b96cb6876a392487
Change-Id: Ie895b25a6e0b70e558807d094304ea2e84425a3d

Bug: 312324146
Test: Add android-test-base-current.txt to the Android.bp
Change-Id: I4fe3565be918d7212334f4d36a8d80aa2adf4460

Bug: 289097671
Test: atest android.media.misc.cts.ResourceManagerTest
      atest android.media.misc.cts.ResourceManagerMultiTest
Merged-In: I750ef5a7585b7bba94f0dfb7bb8e70ec12bf70f5
Change-Id: I750ef5a7585b7bba94f0dfb7bb8e70ec12bf70f5

Merge "Merge "Making adapter child views in RemoteCollectionItemsAdapter size-aware" into android14-tests-dev am: 83b74c07" into main

Merge "Making adapter child views in RemoteCollectionItemsAdapter size-aware" into android14-tests-dev am: 83b74c07

Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/2912083



Change-Id: I93142f62b45124a1d25ea839b90927796c67c797
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>

Merge "Making adapter child views in RemoteCollectionItemsAdapter size-aware" into android14-tests-dev

This helps fix issues with improper layouts of
adapter child views in case
RemoteCollecionItemsAdapter is used.

Test: Manual
Bug: 245950570
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:dc464d6e522eebec5221a934ec3ff5f52a4fb90e)
Merged-In: I0eedf4574975bfae88801e0153816135fc1c8181
Change-Id: I0eedf4574975bfae88801e0153816135fc1c8181

This adds profcollect trigger for dex2oat invocations. This helps
improving profile coverage for dex2oat.

Bug: 319377405
Test: manual
Change-Id: I6fa6f2b0538a87d4fbab7f220052e5be621159bb