Status Update
Comments
jo...@google.com <jo...@google.com>
tn...@google.com <tn...@google.com> #2
What lint is telling you is that the if
-check will always evaluate to true, so you can replace the entire thing and get rid of the else block. It's unnecessary code.
This is just a warning, not an error, in lint. I see that it's showing up as an error in your copy pasted output, so I'm assuming somewhere in your builds you're telling lint to report all warnings as errors?
Note that we've assigned this check a separate issue id, so if you don't want these warnings you can disable ObsoleteSdkInt
. But it's often helpful to people since they may raise the minSdkVersion of their app and not realize that they're still carrying around a lot of compatibility handling that is no longer necessary.
tn...@google.com <tn...@google.com> #3
(I'm going to close this as working as intended, unless I misunderstood something?)
rv...@mozilla.com <rv...@mozilla.com> #4
Yes, we have ObsoleteSdkInt
set as an error in our configs. I'm just wondering what changed in 8.8 to cause this to start failing now when earlier releases don't.
rv...@mozilla.com <rv...@mozilla.com> #5
For Context.kt, maybe this is an interaction between the @TargetApi
annotation at the top of the function and the SDK_INT
check later on? But on-device, the code is valid as-written as we still support running on devices <N (21 is our minimum).
For PictureInPictureFeature.kt, it seems like SDK_INT >= Build.VERSION_CODES.N
is a bit excessive as the only valid case there is when SDK_INT
is exactly N
, but again, I don't see a reason this code isn't valid since all of
tn...@google.com <tn...@google.com> #6
This is getting flagged now because in the new version, we made the SDK_INT check smarter! See
I didn't look carefully at the second case you linked to before:
63 fun enterPipModeCompat() = when {
64 !hasSystemFeature -> false
65 SDK_INT >= Build.VERSION_CODES.O -> enterPipModeForO()
66 SDK_INT >= Build.VERSION_CODES.N -> enterPipModeForN()
67 else -> false
68 }
And I think that is actually a bug!
Lint is trying to be smart -- it sees that the first switch case references hasSystemFeature
, which is defined as
private val hasSystemFeature = SDK_INT >= Build.VERSION_CODES.N &&
activity.packageManager.hasSystemFeature(PackageManager.FEATURE_PICTURE_IN_PICTURE)
If the switch case had been hasSystemFeature -> false
, then we could conclude that AFTER the switch case, SDK_INT must surely be < N. But here the switch case is inverted. And it is incorrect for lint to negate the version constraint here -- that's the bug -- it now believes that by line 65, we know SDK_INT >= N. And that's why by line 66 when it sees an SDK_INT >= N comparison, it flags it as redundant.
rv...@mozilla.com <rv...@mozilla.com> #8
Thanks for the quick fix! I'll verify it when alpha07 is released.
Regarding Context.kt, I did more digging into where the function gets called in our codebase and am confident now that the improved detection in 8.8 is doing the right thing in this case. I can confirm that lint still passes if I remove the @TargetApi annotation entirely as the function is only ever called when running on <Q.
tn...@google.com <tn...@google.com> #9
Great, thank you! (P.S. I think alpha07 was released yesterday so this will be in alpha08.)
an...@google.com <an...@google.com> #10
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Studio Ladybug Feature Drop | 2024.2.2 Canary 8
- Android Gradle Plugin 8.8.0-alpha08
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
rv...@mozilla.com <rv...@mozilla.com> #11
Verified fixed in alpha08!
Description
With the AGP 8.8.0 alpha builds, we're seeing new ObsoleteSdkInt warnings that seem spurious. Our project is built with minSdkVersion = 21, targetSdkVersion = 34, and compileSdkVersion = 35.
I'm not sure if it's the TargetApi annotation that's tripping things up, but my understanding is there's nothing preventing this code from running on older API levels and the code is valid as-written.