Bug: 297019750
Test: m -j; m cts -j; cts-tradefed run commandAndExit cts --skip-system-status-check com.android.compatibility.common.tradefed.targetprep.NetworkConnectivityChecker --skip-device-info -m RenderscriptTest

Change-Id: I112961a279890195aa0387b299844027e483715e

Bug: 307737035
Test: m combined-removed-dex
      # Check before and after to make sure there are no differences
Change-Id: I51e774e6a340d310b96c0291b04f66b4737aebda

This gem of a class doesn't appear to be wired up in any functional way,
so give it a well-deserved retirement into git history.

Note: This was discovered when refining keep rules in system_server
to more accurate reflect services kept by the framework manifest.

Test: m
Bug: 272495195
Change-Id: I9279ee19b3b20871b190aceae586e0828f3b2bd5

* changes:
  Use isCeStorageUnlocked() in StrictMode.java
  Rename methods for creating and destroying user's storage keys
  Rename methods for unlocking, locking, and protecting CE storage

Document more clearly what unlockUserKeyIfUnsecured() actually does.  It
probably should be renamed to something clearer (I'm thinking of just
changing "Key" to "Keys"), but this is a start.

Bug: 306204742
Flag: exempt, comment-only change
Test: presubmit
Change-Id: Ib35a62fb4627db5755fac57609b1fbb3a659492d

isUserKeyUnlocked() is being renamed to isCeStorageUnlocked() to make it
clear what it does (considering that there are many types of user keys).
Change StrictMode.java to use the new name.  No change in behavior.

Bug: 306204742
Flag: exempt, mechanical refactoring
Test: presubmit
Change-Id: I4616b55cc4a088cfd396cc1b4ad60f3ecfed942b

Users have many cryptographic keys, such as:

- Storage (file-based encryption) keys, both CE and DE
- Keystore super keys, both AfterFirstUnlock and UnlockedDeviceRequired
- Keystore client keys
- Synthetic password and the Keystore key that encrypts it

Unfortunately, many StorageManager, vold, and LockSettingsService
methods refer simply to "UserKey".  It isn't clear or consistent which
key(s) they mean.  For example, unlockUserKey unlocks CE storage,
createUserKey creates both the CE and DE keys, and
unlockUserKeyIfUnsecured unlocks CE storage but also does other things.
With the planned fixes to handle Keystore super keys more similarly to
the CE storage key (b/296464083), this confusion will increase further.

This CL is the second part of fixing this.  It renames the following
methods of StorageManager to make it clearer what they do:

   createUserKey => createUserStorageKeys
   destroyUserKey => destroyUserStorageKeys

No change in behavior, except a changed trace tag name and log message.

Bug: 306204742
Flag: exempt, mechanical refactoring
Test: presubmit
Change-Id: I5894beb97823dced5954e405d779fada49c79e8d

Users have many cryptographic keys, such as:

- Storage (file-based encryption) keys, both CE and DE
- Keystore super keys, both AfterFirstUnlock and UnlockedDeviceRequired
- Keystore client keys
- Synthetic password and the Keystore key that encrypts it

Unfortunately, many StorageManager, vold, and LockSettingsService
methods refer simply to "UserKey".  It isn't clear or consistent which
key(s) they mean.  For example, unlockUserKey unlocks CE storage,
createUserKey creates both the CE and DE keys, and
unlockUserKeyIfUnsecured unlocks CE storage but also does other things.
With the planned fixes to handle Keystore super keys more similarly to
the CE storage key (b/296464083), this confusion will increase further.

This CL is the first part of fixing this.  It renames the following
StorageManager methods to make it clear that they deal with CE storage:

   unlockUserKey => unlockCeStorage
   lockUserKey => lockCeStorage
   setUserKeyProtection => setCeStorageProtection

In addition, it starts the renaming of:

   isUserKeyUnlocked => isCeStorageUnlocked

However, isUserKeyUnlocked is used more widely and is also a @TestApi,
so for now it still exists alongside the new name.  Later CLs will
convert the remaining callers of isUserKeyUnlocked to use the new name.

No change in behavior except for some changed log messages.

Bug: 306204742
Flag: exempt, mechanical refactoring
Test: presubmit
Change-Id: I202ebbfd2b4f79fedb3ed120a8ad81500c126894

... until we figure out a way to determine if a device supports a
specific HID usage code. Right now, having a usage code mapping means we
automatically assume the device can report the key code. Assuming a
device can support a stylus keycode makes the device get classified as a
stylus, leading to widespread misclassifications.

Bug: 291529805
Test: atest inputflinger_tests
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:5fb192aaec7a1d4ebb1384d96b3f79d4b2ca2f2c)
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:55930e07d69fbd8ffd27d677a06fd0ba71a30bf8)
Merged-In: I580514bdcbbfbe93df83fa3faa6262077e881243
Change-Id: I580514bdcbbfbe93df83fa3faa6262077e881243

Bug: 304478648
Test: build
Change-Id: I4c102131c9f1639d894b95114c76028808b64c2f

This commit annotates the PackageManager#FEATURE_THREAD_NETWORK API with the
"com.android.net.thread.flags.thread_enabled" flag.

Bug: 303726779
Test: build
Change-Id: I09a27a71b2beab7902bf29b44fb9c36cc3ce2f20

Bug: 290589995
Test: n/a
Change-Id: I7f41eabfd568bae441d1d4fb75f36c4dc58bab60

Fixes: 305938397
Test: NA
Change-Id: I6856844a015d8cdd68efa9f0edee3ce4e339682c

This reverts commit 8140652e.

Reason for revert: Added a fix for the failing code.

Change-Id: I729672340d52a745dd43121e1dbedf9d6d5ec34a

Bug: 305066088
Test: Compiles
Change-Id: If27369575a0f67f227b6ede202280a6cb6a17614

This reverts commit 12058cb9.

Reason for revert: Fails telephony tests

Bug: 303286040
Test: N/A
Change-Id: I07c79f6d07ac8f7394698b8144e9310be2f3f1fe

* changes:
  Recycle the original bitmap after scaling down
  Resize large app icons before adding them in a parcel
  Make AppSnippet parcelable