The MGF1 Digest setter should not accept a null vararg. It should not
take in null at all.

Bug: 302280420
Test: m
Change-Id: I9db395d09e2fd0e609cd9019f3d3aedbb3244ef3

Merge "Implementing support for NFC observe mode, polling loop fingerprints and field strength along with their associated APIs." into main

Revert submission 2789412-cherrypicker-L65800000963076834:N61100001405784943

Reason for revert: Leading to merge conflict
Bug: b/311082270

Reverted changes: /q/submissionid:2789412-cherrypicker-L65800000963076834:N61100001405784943

Change-Id: Ic80afd7a8e09cf2e0cf6e453cbe004db0c9fcbd7
Merged-In: I5c65d85d50b214926f5473908694070b4e896201

Change-Id: I0cc337fecc8115ce4ebbb4803bd96141fd7297cd

This flag is also needed inside the mainline module.
Currently, there is no safe way to use aconfig flag in the module.
Thus, revert this check and use sdk level instead.

Test: atest FrameworksServicesTests:NetworkManagementServiceTest
Bug: 297836825
Change-Id: Ieec0a15cbe6cf3c65f765b18c66b45e4ec93670d

and field strength along with their associated APIs.

Bug: 294217286
Bug: 294435374
Bug: 296057223
Test: tested with CTS and manually
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:81080d559182483d9582dc8dc9ed75de3307c572)
Merged-In: I884527f9271a93997fa47b3764f9fa711cddb6f2

Change-Id: I884527f9271a93997fa47b3764f9fa711cddb6f2

These exceptions are also thrown for FAILED_TRANSACTION.
See frameworks/base/core/jni/android_util_Binder.cpp
signalExceptionForError.

Fixes: 304353893
Test: N/A
Change-Id: Ia832aa88059feaf619e2050eb70887fe7cf77903

The CONTEXTHUB_SERVICE may not be published if the
FEATURE_CONTEXT_HUB feature is not present. So getting the ContextHub
serivce with "context.getSystemService(ContextHubManager.class)"
will throw ServiceNotFoundException.

This commit fixes this issue by checking the CONTEXTHUB_SERVICE
before creating the ContextHubManager instance.

Test: verified with cuttlefish that it won't throw from NearbyService
Bug: 299388818
Change-Id: Icd51a0f88c10259f4a912f5dd82bad49b70562e3

FeatureFlagsFilter looks for `android:featureFlag` attributes in the XML
and removes elements according to the given flag values.

Bug: 297373084
Test: atest aapt2_tests
Change-Id: Icf97de2152c0c53b0b4518ae837e0d198873d1c5

* changes:
  Add PermissionAnnotationDetector
  Ignore superMethods from non-Stub parents

This reverts commit c83ec716.

Reason for revert: b/309999062 | testSmsShortCodeDestination failing

Change-Id: I98b18677f6330e6d1fb52bc3cdfec7c4a4418b57

Bug: 310547345
Change-Id: I64cc5ff6659dfa6875baa225227951d1d5f86eb4
Test: N/A

The security improvements to Keystore's UnlockedDeviceRequired key
protection in Android 12 regressed its behavior by making it no longer
work for unsecured users, e.g. users with a Swipe lock screen.  One of
the things that broke it is that Keystore started superencrypting
UnlockedDeviceRequired keys, yet Keystore unnecessarily ties
superencryption to the existence of the user's LSKF.  That is, Keystore
creates a user's super keys only when an LSKF is set, and Keystore
deletes all super keys and superencrypted keys when the LSKF is removed.

To fix this, we're first making each user's Keystore super keys have the
same lifetime as the user's synthetic password (and always be encrypted
by it), which is very similar to how the CE storage key works starting
in Android 14.  Second, when a user's LSKF is removed, we're making
Keystore delete *only* the user's auth-bound keys.

This change implements the LockSettingsService side of the fix.  This
includes the following parts:

- When initializing a user's synthetic password, LockSettingsService now
  initializes the user's Keystore super keys.

- When upgrading to a build including this fix, LockSettingsService now
  does a one-time migration where it initializes the super keys for
  unsecured users.  This is necessary to handle existing users.

- When removing a user's LSKF, LockSettingsService now calls the new
  onUserLskfRemoved method of Keystore to delete auth-bound keys only.

- Finally, when an unsecured user's CE storage is unlocked,
  LockSettingsService now unlocks the user's Keystore super keys too.

Due to trunk-stable, these changes are actually behind a flag for now.

Bug: 296464083
Test: see If12824369fbad4a90e5cd0427e792655fd233b96
Change-Id: Ib92a439c2c27cef54c28189dfb5beef68756528e

* changes:
  Remove the SDK level checks.
  Remove findIPv4DefaultRoute
  Remove LegacyVpnRunner

Test: N/A
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:e715b9927adc1b5de39e081b9a76cec0713130da)
Merged-In: Ieca72562b291839efe14a03e987da1b13fb6acdc
Change-Id: Ieca72562b291839efe14a03e987da1b13fb6acdc

There are several cases where inner classes of @SystemApi-annotated
classes should be kept, but aren't. Add a conditional rule to ensure
this. This is probably overly conservative, but for now should avoid
issues with optimization.

A follow-up change will refactor this to reuse the rules in
system-api.pro, but that requires a bit of build file surgery first.

Bug: 300514883
Change-Id: Ibd561a9098881db1c7e78346d60f4c91d9c75894
Test: m + check services.jar dex diff