Status Update
Comments
ni...@google.com <ni...@google.com>
br...@google.com <br...@google.com> #2
If this is the same issue as before (CREATOR
with non-enclosing class), we can't pull this into a QPR since it'll create device fragmentation (had a chat with @narayan). Can you document this properly in Intent
, Bundle
& Parcel
, Hani?
ha...@google.com <ha...@google.com>
ge...@tapptitude.com <ge...@tapptitude.com> #3
tb...@google.com <tb...@google.com> #4
st...@gmail.com <st...@gmail.com> #5
What's the guidance right now? Just avoid usage of the new function altogether and continue to use the deprecated version on all API levels?
tk...@google.com <tk...@google.com>
ha...@google.com <ha...@google.com> #6
Hey folks, a quick update here:
-
As above, the new getXXX(key, class) APIs are buggy in T, and throw a NPE if you are retrieving a parcelable where the Parcelable.CREATOR is not defined as an nested inner class of the Parcelable. The issue is fixed for the next major Android release, but unfortunately can't be backported to Android 13 as we don't want to fragment API behaviour across devices.
-
This means if you are impacted, the way forward for now is to continue using the older APIs for Android 13 and below. They are marked as @Deprecated, but still work as intended. If you have simple parcels where the CREATOR /is/ a nested inner class, you can continue using the new methods without impact. I've updated the documentation to call this out, and should be rolling out to the API reference docs with the next doc update.
-
We're also planning to introduce new compatibility methods in Jetpack to help out, and hide away this complexity. Developers should be able to safely call the compat version in all android releases, and jetpack will work out which API to delegate to. The work for that's currently in progress, and will be tracked in
b/242048899
ju...@gmail.com <ju...@gmail.com> #7
Would you know if the parcelize plugin generates Parcelables implementations that falls under this bug case? How it be a mitigation option to make the plugin generate code that avoids the issue?
sc...@gmail.com <sc...@gmail.com> #8
Does this shortcoming of Android T only affect the Intent.getXXX(String, Class)
family of methods, or is the same true for Parcel.readXXX(ClassLoader, Class)
and we should avoid using them until U?
ge...@tapptitude.com <ge...@tapptitude.com> #9
ge...@tapptitude.com <ge...@tapptitude.com> #10
I suppose this is basically the same for:
Intent.getXXX(String, Class)
, Bundle.getXXX(String, Class)
, Parcel.getXXX(String, Class)
- Is this correct?
When will the compatibility functions be introduced so that we can safely remove the deprecated code
tb...@google.com <tb...@google.com> #11
lo...@gmail.com <lo...@gmail.com> #12
What's the quarterly release you're referring? 🤔
ve...@google.com <ve...@google.com> #13
tb...@google.com <tb...@google.com> #14
Hi - it should be released through AndroidX APIs.
One thing I wanted to note is internally there as been a lot of conversation around best practices which is resulting in a little bit of delay. I'll keep an eye on this and update when I see progress on our side.
pa...@gmail.com <pa...@gmail.com> #15
Please make up your mind whether it's on the hotlist or not ;)
ki...@gmail.com <ki...@gmail.com> #16
ge...@tapptitude.com <ge...@tapptitude.com> #17
Hey, any updates regarding this? :)
bo...@gmail.com <bo...@gmail.com> #18
bo...@gmail.com <bo...@gmail.com> #19
st...@hedvig.com <st...@hedvig.com> #20
st...@gmail.com <st...@gmail.com> #21
This issue
ja...@google.com <ja...@google.com> #22
ca...@digitalchargingsolutions.com <ca...@digitalchargingsolutions.com> #23
Is this issue related to the one I am facing here? If not, I will create a new issue:
I am using a reified method. Devices: Poco F5 running Android 13/T/33, and Pixel 6 running Android 14 Beta.
@Suppress("DEPRECATION")
inline fun <reified T : Parcelable> Intent.getParcelableArrayList(key: String): ArrayList<T>? {
return if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
this.getParcelableArrayListExtra(key, T::class.java)
} else {
this.getParcelableArrayListExtra(key)
}
}
The error message is "This function has a reified type parameter and thus can only be inlined at compilation time, not called directly." which does not make sense to me.
ca...@digitalchargingsolutions.com <ca...@digitalchargingsolutions.com> #24
Sorry, my previous comment is not related. I had used putExtra
to pass the data to the intent. I should have used putParcelableArrayListExtra
. The method is working.
yo...@gmail.com <yo...@gmail.com> #25
A separate ticket for BundleCompat.getSerializable
Description
Yes
TPB4.220624.005
N/A, new API
Pixel 4
Use the new
Intent.getParcelableExtra(String,Class)
API. In our case the Class we are passing in is a parcelized data class with an internal constructor.We have a compat function that gracefully handles this change across platforms
Framework
It should function without failure.
This throws an NPE deep in framework code that I cannot diagnose due to lack of available sources.