Because `system.img` is a dependency of `fontchain_lint`, and
`system.img` is currently not generated inside `Soong`, it is not
possible to directly convert `fontchain_lint` to `Android.bp`.
Move it to build/core/task first.

Bug: 319050958
Test: m fontchain_lint
Change-Id: Iad483117a609786ecfb885b13015f18dda113155

Change-Id: Iacacba4e4cf03b1c9fd02ffef39ca99e4c597160

Add this permission for Thread user restrictions control.

See go/ae-v-thread-admin-control

Bug: 319198393
Merged-In: Ie8393cf876435a3ffb77a4b27bcf419b529fd785
Change-Id: Ie8393cf876435a3ffb77a4b27bcf419b529fd785

Merge "Fix crash issue when gallery app with Ultra HDR photo is moved to the virtual display." into main

Bug: 298052174

Change-Id: I369affbb103cbf860a2fabfc1b85f0c44750ed82

Previously, the `core/api/current.txt` erroneously and unnecessarily
listed `drawMesh(...)` as the only method in the
`android.graphics.RecordingCanvas` class. That was because there was an
bug in Metalava that meant it ignored a super method if that method
came from a hidden/inaccessible class. The accompanying change in this
topic fixes the bug and so it can be removed.

Listing `drawMesh(...)` method in `RecordingCanvas` was unnecessary
because `RecordingCanvas` extends `Canvas` which defines and provides a
concrete implement of `drawMesh(...)`. The `RecordingCanvas` does not
add any new methods, it simply overrides the methods from `Canvas` and
records their parameters.

Bug: 319826204
Test: m checkapi
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:cf7ff527cf5fa7deb086cb61c5ec3400d45838db)
Merged-In: I7e23b93659a87f13606ca2d6c4c3ceebee23901f
Change-Id: I7e23b93659a87f13606ca2d6c4c3ceebee23901f

This gives more context when a subsequent fallback call to
setDataSource(String, Map<String, String>, List<HttpCookie>) fails
(which is often expected, especially for content:// URIs). These logs
should help to see more detail of the unexpected failure from
ContentResolver in this case.

Bug: 313263440
Test: Presubmit
Change-Id: I77df208d796c92596a5c28d845aaaf71546173b5

This needs to be used in a cts test and so it is good to have it
annotated as such.

Test: Manually verify that its stubs are generated in the correct txt.

Bug: 304347838

Merged-In: I5a6f30cdb76a37f5ff412339a0d78e98991fe86e
Change-Id: I5a6f30cdb76a37f5ff412339a0d78e98991fe86e

We'd like to limit the usage of libvintf because of its
performance/memory impact. By removing VintfObject and VintfRuntimeInfo
classes from preloaded-classes list, we can avoid loading libvintf from
libandroid_runtime. A new JNI library (libvintf_jni) is loaded only when
it's actually used.

Bug: 270169217
Test: atest VintfObjectTest
Change-Id: I469f368ee04863374988359c28bcd1a5fb4ead9e

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

Bug:319498513

When gallery app opens Ultra HDR photo on default display, ViewRootImpl#updateColorModeIfNeeded is executed and mHdrSdrRatioChangedListener is not null. At this point, we move the gallery app to the virtual display, ViewRootImpl#updateInternalDisplay is executed and mDisplay is updated as the virtual display. The virtual display is ready to register hdr/sdr ratio listener due to non-null mHdrSdrRatioChangedListener and mDisplay. However, the virtual display is not available for hdr/sdr ratio, the gallery app in the virtual display will crash.

Change-Id: I34f03dfe5a00841131784dc3abbe1c11fd07d4b2
Merged-In: Ic69b633d6042145a537c7d39e713f804faff6600
Signed-off-by: linkai <linkai@xiaomi.com>

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