After upgrading compile sdk and targetSdk to 29, P...
# android
s
After upgrading compile sdk and targetSdk to 29, Parcel.readXXXX and Bundle returns a nullable value. Does anyone know why this change was made?
j
Because they can return null
s
What I mean is, why now? Nullables were introduced in Android years ago.
I am now having to sift through our usages of Bundle and Parcel and fix type issues.
Or maybe we should have always had set the type for values returned from Bundle, Parcel to be Nullable? Either way, it's going to be wonderful experience for me🤣
j
1. Nullability annotations were present in the source but stripped from the stub jar you link against. 2. API 29 was a year ago, so this isn't new. It was the first SDK to ship proper nullability annotations. 3. API 28 contained "recently" nullable annotations which produce warnings for these types, so it's actually been two years: https://android-developers.googleblog.com/2018/08/android-pie-sdk-is-now-more-kotlin.html
❤️ 1
API 30, which is now stable, will transition even more APIs from "recently" annotations to real ones that are enforced
👍 4
And the "why now?" question interpreted when this work started, three years ago, was because Kotlin became a supported language officially and previously with only Java no one cared because no one used tools which enforced nullability.
s
Thank you for the in-depth explanation! We recently got a warning from Google Play Console to upgrade our compilesdk/targetsdk to 29, so that's why I'm asking the question now. It seems like a good practice to regularly keep upgrading to the latest versions.
i
Google Play enforces that you target at least last year's release every year (giving you effectively 1.5 years from the first dev preview of behavior changes to needing to have your app upgraded)
👍 2
s
Totally, it's just one more thing devs need to keep an eye on. Sometimes, when you're just focusing on your product, it can be easy to drop the ball on maintenance type stuff like this. I will communicate this information to my team. Thanks Jake and Ian for your responses.