Hi guys, here is another issue we’ve encountered w...

# kotlin-toolchain

[thunderbiscuit]

Hi guys, here is another issue we’ve encountered while attempting the migration to kotlin-toolchain this week. I tried searching the YouTrack but I’m not sure I’m correctly using the tool. Let me know if you are already tracking this one.

When a dependency’s metadata requests the aar artifact of a transitive dependency via the POM’s aar, the toolchain ignores that and resolves the default jar artifact instead. For libraries that publish Android native code only in their aar, the app builds successfully and then fails at runtime.

This comes up if any of your dependencies leverages the JNA. The POM declares:

<dependency>
  <groupId>net.java.dev.jna</groupId>
  <artifactId>jna</artifactId>
  <version>5.14.0</version>
  <type>aar</type>
  <scope>runtime</scope>
</dependency>

But kotlin-toolchain resolves the jar instead of the aar, and the artifacts are not interchangeable, because the JNA lib ships its Android native libraries only in the aar. The app compiles fine but crashes at runtime because the appropriate lib/<abi>/libjnidispatch.so are not there.

[alexey.barsov]

hi @thunderbiscuit, it should has been fixed in 0.13.0-dev build

[alexey.barsov]

let me look for an issue

[thunderbiscuit]

Awesome!! Is that a nightly I can get easily? Or should I just wait for 13 to come out?

[alexey.barsov]

what Kotlin Toolchain version do you use now?

[thunderbiscuit]

0.12.2 at the moment.

[alexey.barsov]

> kotlin-toolchain resolves the jar instead of the aar
This should have been fixed in youtrack.jetbrains.com/issue/KTC-5270 (0.12.0-dev-4265). It was included in release versions 0.12.x

First I need to confirm the issue (I am not sure could it be caused by some other reason, Like AAR is resolved, but lib/<abi>/* of the library is not taken into account at runtime by some reason).

Could you please share you module.yaml file that references jna library transitively?

[alexey.barsov]

I have found one more issue about custom maven dependencies youtrack.jetbrains.com/issue/KTC-5779 that was fixed in version 0.13.0-dev-4328

You could try it on your project by updating the kotlin wrapper to a dev version.

> ./kotlin update --dev

[alexey.barsov]

I tried it locally with the latest dev version and see that in runtime aar file is resolved

jna-5.14.0.aar

I used io.gorules:zen-engine-kotlin-android:2.0.2 that have exactly the same dependency in its pom.xml

[alexey.barsov]

so if you can share your module.yaml with those dependencies or provide a minimalistic reproducer project that will be great.

[thunderbiscuit]

I was able to try it locally, and worked flawlessly! Thanks a bunch.

[thunderbiscuit]

Quick question: what do the 4 numbers in the suffix mean on the dev version of the toolchain? The version I just installed is 0.13.0-dev-4413 . It’s not part of the commit hash so I’m curious

[alexey.barsov]

4413 is just our internal build number

[thunderbiscuit]

Awesome thanks!

[thunderbiscuit]

One more thing I want to point out; this fix is a good example of why the ABI split I brought up yesterday (my previous thread) is important for prod.

If an app supports only a subset of what the JNA library supports (in my case I want to support arm64-v8a only), it cannot restrict its support and will automatically bundle all supported architectures that JNA provides. This is a lot of binaries that will never be run and are not meant to be in the APK. In the case of JNA, they support 7 arch (arm64-v8a, x86_64, armeabi-v7a, x86, mips, mips64, and armeabi). There are 2 core issues with this:

1. Your APK is super bloated and you can’t choose what goes in it, so it just ships with everything included.
2. In the case of an AAB, the users’ download size will be correct and not include the binaries not required for their platform, but Google Play will wrongfully advertise that all these platforms are supported, when they are absolutely not! This is maybe the bigger issue for production applications I suspect.

[thunderbiscuit]

In any case, thanks for the super quick response guys! This tool is an absolute pleasure to work with, and I’m looking forward to continue migrating more of our projects to the toolchain. Cheers!