Consider downgrading dependencies so that `minCompileSdk` is `30` instead of `31`
erikhuizinga opened this issue · comments
This line transitively sets the minCompileSdk
to 31
for all users of this library.
joda-time-android/library/build.gradle
Line 31 in caca377
This breaks the build for projects that still have the compileSdk
set to 30
or lower. An example failure build log:
> A failure occurred while executing com.android.build.gradle.internal.tasks.CheckAarMetadataWorkAction
> One or more issues found when checking AAR metadata values:
The minCompileSdk (30) specified in a
dependency's AAR metadata (META-INF/com/android/build/gradle/aar-metadata.properties)
is greater than this module's compileSdkVersion (android-29).
Dependency: androidx.startup:startup-runtime:1.1.0.
AAR metadata file: ...
In this example, the project doesn't depend directly on androidx.startup:startup-runtime:1.1.0
, but it does on net.danlew:android.joda:2.10.12.2
which depends on the former. The minCompileSdk
leaks from that dep into the client's project.
Because Google Play requires targetSdk
30, it might not be uncommon that compileSdk
still is 30
in various Android projects, including consumers of joda-time-android.
If this change is acceptable or intentional, then this issue can be closed. Otherwise, consider downgrading the dependency version (and checking if other dependencies are also transitively imposing minCompileSdk
greater than 30
).
I could be convinced to lower compileSdkVersion
but I'm skeptical. Typically you should always be compiling to the latest SDK version - what's blocking you from upgrading?
(Keep in mind, targetSdk
is a different beast; you can compile to a higher SDK than you target.)
I agree, but it's not the point. The point is that a library that seems to not depend on the compile SDK suddenly imposes a compile SDK version bump. That decreases the developer experience of this library for everybody that hasn't eagerly kept the compile SDK version up to date. It's a side effect, seemingly.
Note that this is a 'problem' in general: any lib implementing (or api
-ing?) an AndroidX lib that requires compile SDK 31 will have its users' builds break... I guess that this issue is on AndroidX, because they chose to add this requirement recently for many (if not all) of their libs. And it's undocumented, AFAIK.
The fix on the user end should be trivial, so probably not worth fixing by you. Besides, if you'd stick with compatibility for the previous compile SDK version, then your lib will likely not be able to upgrade AndroidX dependencies for a year, always lagging behind the latest and greatest possibilities (in theory).
Makes you wonder what the use is of the compile SDK version, if AndroidX forces you to use the latest stable by default... 🤔
Feel free to close this issue.
I'm not really sure I understand the exact ask here - is it that joda-time-android stops depending on androidx.startup?
Concretely, I ask to stop depending on libraries that set minCompileSdk
to greater than 30
. E.g. if you'd downgrade AndroidX Startup, the previous version likely doesn't require that.
But I now remember the support library, which I think always has had the implicit requirement that your compile SDK version is at least the support lib's major version. Since AndroidX, that major version isn't in the version names any more, so I guess that's partially where the issue lies (like I wrote before): AndroidX fails to communicate / document the minimum required compile SDK:
- Here it says compile SDK 28: https://developer.android.com/jetpack/androidx
- Here it says nothing about a minimum compile SDK: https://developer.android.com/jetpack/androidx/releases/startup
And actually the minimum compile SDK is 31. This, while the Play Store accepts apps (or app updates) with target SDK 30 and therefore it is safe to assume that some of those apps will also use compile SDK 30. That leads to the problem described in this issue: breaking builds. However, like discussed it's not a problem to upgrade the compile SDK version, so I'm closing this.