Defines permissions for guarding access to Thread network API.

The permissions are also granted to shell for CTS tests, see the
instructions here: go/ctswrite#write-a-test-to-test-an-api-that-requires-system-permission

Design doc: go/thread-android-api

Bug: 262683651
Merged-In: Ib15d5589bbd304d68840ee52a193676d12110512
Change-Id: Ifc6c1d55cc170a5a200dfb5d531f5e0f86a9507a

Adding a placeholder so that soong build integration can happen in
parallel with the implementation of this flag.

Bug: 297373084
Bug: 306024510
Test: m aapt2
Change-Id: If9df57daaa871c11e146a8a8f8113fceb2fd96c2

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

It handles the case from InputMethodManagerService#reportStartInput
with
Activity <- IME container LastRelativeLayer
 - Base Window
 - Dialog Window <- ImeControlTarget, ImeLayeringTarget

The LastRelativeLayer should update to Dialog window, so IME container
can show above Dialog.

Test: atest ZOrderingTests# \
      testAssignWindowLayers_ForImeOnPopupImeLayeringTarget
Bug: 301134949
Bug: 301261260
Change-Id: I7ab44f7fc4724bcb79cf3f58979de21c143edb34

isUserKeyUnlocked() is being renamed to isCeStorageUnlocked() to make it
clear what it does (considering that there are many types of user keys).
Temporarily, the method exists under both names.  Change
AppDataRollbackHelper to use the new name.  No change in behavior.

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

Add aconfig for VCN feature flags and the flag for VCN
safe mode configurability

Bug: 276358140
Test: verified flags are accessible
Change-Id: I4a54445a4238c81a409604be16c90ef341eed638
Merged-In: I4a54445a4238c81a409604be16c90ef341eed638

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

isUserKeyUnlocked() is being renamed to isCeStorageUnlocked() to make it
clear what it does (considering that there are many types of user keys).
Temporarily, the method exists under both names.  Change the package
manager to use the new name.  No change in behavior.

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

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