IssueTracker

Thanks for reporting your issue!

It appears that the new API additions have introduced these additional checks using reflection. The APIs on Parcel are:

readList(java.util.List, ClassLoader, Class<T>);
readParcelable(ClassLoader, Class<T>);
readParcelableCreator(ClassLoader, Class<T>);

In your case it is the readParcelable call that is triggering this new path.

There are two ways you can workaround the issue:

1. Rewrite the code to avoid using the new APIs listed above.
2. Amend you keep rules to ensure the expected inner/outer relation that is being reflected on is kept.

For workaround 2. you can use these which are the minimal rules that should retain the required info:

# Parcel reading may lookup/validate the parcel and creator via their
# inner-class relationship. Ensure the attributes are kept and the
# inner/outer relationship is soft pinned. The 'allowshrinking' option
# allows the classes to be removed if unused, but otherwise their attributes
# are retained.
-keepattributes EnclosingClass,InnerClasses
-keep,allowshrinking,allowobfuscation class * implements android.os.Parcelable {}
-keep,allowshrinking,allowobfuscation class * implements android.os.Parcelable$Creator {}

In your case, the -keepattributes are already kept by existing rules, but I included it here for completeness. Closing this as intended behavior, but let us know if the above workarounds don't work and we will reopen it.

Thank you. Workaround 2 works and only increases the apk by 5KB. For workaround 1, the alternative APIs are marked as deprecated in framework. Should this be addressed in r8/framework somewhere though instead of closing this as intended behavior?

Good to hear!

I've filed an internal issue to discuss potential resolutions of this (b/274434235).

Likely we will need to distribute the rules in #comment2 as part of the default set of rules in studio going forward.

After more discussion it looks like the best way to resolve this issue is to use the androidx compat layer. They have implemented a fix to avoid calling the API on T devices in androidx.core:1.10.0-alpha01.

Could you try updating the use of android.os.Parcel.readParcelable in your utils class to instead use androidx.core.os.ParcelCompat.readParcelable and ensure you have a dependency on a recent androidx.core (eg., 1.10.0-rc1). With that you should be able to remove the keep rules again.

I see that this API is already fixed on Android U. Thanks!

Yes, the underlying issue is fixed in U, but it will remain an issue for T devices. So if your app is targeting devices that could include T then the compat lib is the best fix.

Unfortunately workaround 2 did not fix the NPE for some reason. (It did kept the enclosing class relationship though looking at decompiled apk.) I guess I will try workaround 1 next.

I am experiencing a similar issue when using Intent::getParcelableExtra in some custom ActivityResultContracts. Does IntentCompat.getParcelableExtra also prevent this issue from happening?

The compat indirections should workaround the issue for you. Let us know if it does not work.

Can you please also add this Android U+ change to BundleCompat.getParcelable?

As far as I can tell the implementation of BundleCompat.getParcelable has the correct check for API 34 to avoid the incorrect implementation shipped in 33. Are you seeing this issue when using BundleCompat.getParcelable?

I was looking at an old version, seems to be fixed, yes (sorry for the inconvenience)