changing the field names is much harder due to it going via AIDL

Test: TreeHugger
Bug: 292404319
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I4101caf3b0d2abfadbabf3f389155c29a4d64e0f

Change-Id: Ida2015af70fc6c00ff3cf4d0cd1aa13aadf2b571

Change-Id: I8a72988f2fb3560565f81deb5f9cd40d1e55e295

Change-Id: I54b07b44c23f7a8cb7e2aba9d731c5e7c431247c

Change-Id: I5d0646411d53a7390dca746cba79ae69bd0ec2f5

Change-Id: Id1ff659b4a5ae7809804bacda0a77ccf1815480c

Change-Id: I427112e2986377f37b85d9dfe21620ddd6bb198f

Change-Id: I6836ef908a8482352d5368e4ba2538dc7de0946d

A previous CL added the auto-generated aconfig Flags.FLAG sources to
metalava's input when generating core/api/current.txt, so metalava would
expand the Flags.FLAG to their values.

Do the same for the build targets for the other (system, module-lib,
test) API signature files in core/api.

Also update the API signature files accordingly.

(cherry picked from commit 162ae2a1)

Bug: 301859633
Test: m checkapi
Merged-In: Id06d77e897ecfddeaa42f75cba4d6d37bee9d1b1
Change-Id: Id06d77e897ecfddeaa42f75cba4d6d37bee9d1b1

The target list of enforce_permission_counter can be reconstructed
based on the dependencies of the "services" module. Add the ability to
soong_lint_fix to collect and parse module_bp_java_deps.json which
contains the dependency list.

SoongLintFix is split into 2 classes: SoongWrapper and SoongLintFix. The
former is used as a general wrapper to invoke Soong and parse the module
files. The latter, a subclass of SoongWrapper, contains the calls to the
different steps.

The building and loading of module-info.json and
module_bp_java_deps.json is now done dynamically whenever required.

Bug: 298285238
Test: enforce_permission_counter
Test: lint_fix --no-fix --check AnnotatedAidlCounter --lint-module AndroidUtilsLintChecker services.autofill
Change-Id: I781e9cdf80feb4c4d480673e044d526c528f8412

* changes:
  Guard the death recipient behavior behind a build flag
  binder: fix death recipient leak for apps targeting >= V

Bug: 284266229
Change-Id: Ic0453611147ca1a327a150f0ffc92b9cd60b86b1

Rename some methods to avoid confusion.  No change in behavior.

Test: presubmit
Change-Id: Id765f7fa587e2a333ba3e0e649f3d5ab69961e5c

* changes:
  Add api_surface prop to non-updatable droidstubs
  Replace api_files prop to api_contributions
  Remove non-updatable contribution from android_test_stubs_current_contributions

These will be part of the platform (not part of NFC module) and will be
used by NFC stack to parse platform resource files to form these
structs.

Bug: 263563565
Test: Compiles
(cherry picked from https://android-review.googlesource.com/q/commit:51c5d5ede5c85823fdd127fddc67d56da0defed0)
Merged-In: Ib1f22395567386a6e802d78b6fe359f92c3847d7

Change-Id: Ib1f22395567386a6e802d78b6fe359f92c3847d7

The death recipient behavior introduced with Ibb371f4de45530670d5f783f8ead8404c39381b4
is guarded with a build flag
RELEASE_BINDER_DEATH_RECIPIENT_WEAK_FROM_JNI.

Bug: 298374304
Test: build
Change-Id: Ie604ee723385676cf3c83f0d9b2a46ceb322903a

Before this change, when a death recipient is set on a binder proxy via
linkToDeath, a JNI global ref to the recipient object was created. That
global ref is cleared only when unlinkToDeath is explicitly called or
binderDied is notified.

In addition, since binderDied didn't give the IBinder which has died,
people has kept a strong reference to IBinder in the death recipient
object. Ex:

class FooHolder implements Binder.DeathRecipient {
    private IFoo mFoo;
    public FooHolder(IFoo foo) {
        mFoo = foo; // this!!!
        mFoo.linkToDeath(this, 0);
    }
    @Override
    public void binderDied() {
        // know that IFoo has died
    }
}

Unfortunately, this is prone to leak. Even if there's no reference to
FooHolder in your program, it is kept in memory due to the JNI global
ref as mentioned above. It means that you keep IFoo as well, and that
in turn keeps the binder service in the remote side. As a result,
binderDied will never be called (well, except when the server process
crashes).

The only way to release this object is calling unlinkToDeath explicitly
when you drop references to FooHolder. However, it's error prone and
keeping that practice is hard to be enforced.

Recently, the need for this pattern has become weaker as we introduced
binderDied(IBinder who). However, the API is quite new and its use is
not mandated. There still are many cases where this pattern is used.

This change is an attempt to fix the issue without having to touch the
existing uses. The idea is to change the way that death recipient
objects are strongly referenced - depending on whether you are targeting
Android V+ or not.

If targeting Android V+, the death recipient object is "weakly"
referenced from JNI. Instead, it is "strongly" referenced from the
BinderProxy object it is registered at. This means that if you drop
a BinderProxy object, you are dropping its death recipients as well,
unless you keep references to the recipients separately.

For apps targeting pre-V versions, we keep the JNI strong reference.

An important implication of this is that you won't get binderDied if you
drop BinderProxy object before the binder actually dies. This actually
is the documented behavior and has been the actual behavior "if you
don't use the FooHolder pattern mentioned above". I'd argue that this CL
fixes the undocumented incorrect behavior. However, we should be
conservative when making any behavioral change, thus we are hiding this
change behind the target SDK level.

Bug: 298374304
Test: atest BinderLeakTest BinderLeakTest_legacy

Change-Id: Ibb371f4de45530670d5f783f8ead8404c39381b4

Bug: 282058146
Test: Treehugger
Merged-In: Idd66455b28cc61e53c68f559244ad2d022cf65d3
Change-Id: Iaa956dec6c64220bcd3a83390b4a9811c42e518e

Add a separate setter for the digests used by the MGF1 mask generation
function (for RSA OAEP operations).

Previously the MGF1 digests were specified according to the primary
digests specification, which is not accurate enough.

With the new setter:
* If the user does not explicitly specify MGF1 digests, then the
  default (SHA-1) will be specified in the tag passed to Keystore.
* If the user does explicitly specify MGF1 digests, only those
  digests will be specified in the tag passed to Keystore.
  The SHA-1 digest will not be added.

Bug: 284140060
Test: atest android.security.keystore.KeyGenParameterSpecTest android.security.ParcelableKeyGenParameterSpecTest
Test: atest CtsKeystoreTestCases:android.keystore.cts.CipherTest#testKatBasicWithDifferentProviders
Change-Id: I1521e9b4399ece33c2d17b79133543d490d3b377

Create a genrule, which creates an entry in Android.mk.

Bug: 151360309
Test: m platform-bootclasspath.srcjar
Change-Id: I23e62e72d369059a41ddd566c378b9a8bf0ad6ec