Without this patch, you end up with the following build failure.
Failed to transform artifact 'core.aar (androidx.core:core:1.6.0-alpha03)' to match attributes {artifactType=android-dex, dexing-enable-desugaring=false, dexing-is-debuggable=true, dexing-min-sdk=21, org.gradle.usage=java-runtime}.
Execution failed for DexingNoClasspathTransform: /Users/paulproteus/.gradle/caches/transforms-2/files-2.1/06fa1a1e81ab0310f823a5246519dd3a/core-1.6.0-alpha03-runtime.jar.
Error while dexing.
After this patch, the build failure goes away.
I tested by creating a new app with briefcase new, then modifying the template = ... line to use this patched template. With the patch reverted, the build fails.
Root (?) cause
A new version of androidx.core was released yesterday and it appears to be named in this error. I presume then that something in our Gradle configuration is willing to auto-update to higher and higher versions of androidx.core, presumably this:
implementation "androidx.core:core-ktx:+"
I'm pretty sure I added that as part of some generic recommendation from Google, or maybe from some template for automatically generating Android apps' Gradle files, or maybe automation from Android Studio.
I recommend we not try hard to pin this. If this fails again for us in some way that we care about, we can try pinning. Personally I think we're probably well-served not to pin things yet and try to fix things as they arise.
It relates to our use of Kotlin, which I would also like to see us retain until we get more/other/bigger problems. We use Kotlin because android/Helpers.kt within the template is written in Kotlin. We could also port that to Java and/or turn it into a Maven dependency.
Without this patch, you end up with the following build failure.
After this patch, the build failure goes away.
I tested by creating a new app with
briefcase new
, then modifying thetemplate = ...
line to use this patched template. With the patch reverted, the build fails.Root (?) cause
A new version of androidx.core was released yesterday and it appears to be named in this error. I presume then that something in our Gradle configuration is willing to auto-update to higher and higher versions of androidx.core, presumably this:
I'm pretty sure I added that as part of some generic recommendation from Google, or maybe from some template for automatically generating Android apps' Gradle files, or maybe automation from Android Studio.
I recommend we not try hard to pin this. If this fails again for us in some way that we care about, we can try pinning. Personally I think we're probably well-served not to pin things yet and try to fix things as they arise.
It relates to our use of Kotlin, which I would also like to see us retain until we get more/other/bigger problems. We use Kotlin because
android/Helpers.kt
within the template is written in Kotlin. We could also port that to Java and/or turn it into a Maven dependency.PR Checklist: