Hello everyone. I’ve started migrating some demo a...

# kotlin-toolchain

[thunderbiscuit]

Hello everyone. I’ve started migrating some demo apps and libraries to kotlin-toolchain and it’s been great so far! Within the scope of what it does it’s so, so much better to work with than Gradle, and reminds me of cargo a little bit. Thanks for the work. I’m on 0.12.2 right now.

Now that I’ve gotten a taste for it I just want to start migrating more things 😂! So here is my question: when packaging Android apps, I’m wondering if there is a way to restrict the ABIs supported. settings.android exposes no equivalent of AGP’s defaultConfig.ndk.abiFilters or splits.abi . Every ABI present in any dependency .aar is merged into the APK and declared as a targetable ABI in the AAB, and there is no supported way to narrow that set that I nor my trusted friend Claude can find. For apps whose dependencies ship more ABIs than the app actually supports, this means shipping and advertising on Google Play device support that is totally broken. I’m not sure if maybe I’m just not looking in the right places. Thanks!

[joffrey]

I wasn't aware of this feature but at first glance it seems reasonable. @Anton Prokhorov do you know about this?

[Anton Prokhorov]

I’m wondering if there is a way to restrict the ABIs supported. settings.android exposes no equivalent of AGP’s defaultConfig.ndk.abiFilters or splits.abi

No, there is no, and no workaround so far

Could you please share which native libraries do you use?

Is this a problem that effective set of supported platforms is narrower because one of the library just doesn't support all of the abi's of the other? or there is another reason, why you want to limit abi's?

[thunderbiscuit]

The core requirement is for the dev to be able to decide which platforms/ABIs are supported by the app, and not ship for others by default. For us for example we build Android and Swift libraries that have some Rust components in them and so must provide the binaries with them. Those libs do not support all 32-bit architectures, and therefore any user downstream of us cannot either. For the platforms that we do support however, kotlin-toolchain will currently build apps that automatically support and ship for those architectures, even if the devs do not intend this at all.

[thunderbiscuit]

At the moment, anyone declaring the library as a dependency (and building their apps using the kotlin-toolchain) will start shipping (wrongly) apps for all architectures that the library supports, but clearly they should still be in charge of what platforms they want to support, not the library forcing it onto the app.

Here is a concrete example: the bdk-android library supports the x86 architecture (for 32-bit computers that would run emulators I guess??) but that’s definitely not something I want to ship as part of my APK nor by AAB. My current workflow building and packaging with kotlin-toolchain produces an AAB that incorrectly ships support for the x86 platform, when in fact it’s not supported.

[thunderbiscuit]

I can send repos with reproducible examples if ever that’s of interest! I’m basically looking for a way to tell kotlin-toochain “Hey build this app only for arm64-v8a` please. Which reduces my build time, bundle and APK size, and is just overall good practice to be explicit about what I support and ship.

[Anton Prokhorov]

I'm drafting an issue in Youtrack right now, so yeah, if you have project to share, please share, I really appreciate

[thunderbiscuit]

Would you like me to add the links on YouTrack or share with you here?

[Anton Prokhorov]

youtrack.jetbrains.com/issue/KTC-5897/Support-explicit-Android-ABI-filtering-for-application-packaging

[Anton Prokhorov]

feel free to attach the file and add more context that you feel nessesary
thanks for reporting!

[Alexey Barsov]

@thunderbiscuit
ABI filtering fix has landed in the main branch and is available starting from 0.13.0-dev-4425. If you'd have time and give it a try, it would be awesome.

[thunderbiscuit]

Awesome! Wow that was quick.

[thunderbiscuit]

What’s the best way to find the APIs to use? Should I just clone the repo and build the mkdocs website myself (or ask Claude to go through it maybe)? I can’t find the PR that brought this in so not sure where to find the documentation for it

[thunderbiscuit]

Oh got it. Thanks!

[thunderbiscuit]

github.com/JetBrains/kotlin-toolchain/commit/c2ea9284f9e4…

[joffrey]

@thunderbiscuit usually, if we didn't forget to update the docs, you can see the docs of the dev version using the version selector at the top of the documentation website:
kotlin-toolchain.org/dev

[joffrey]

From there, you should be able to use the search bar

[Alexey Barsov]

documentation about abiFilters parameter
github.com/JetBrains/kotlin-toolchain/blob/…/android-app.md#…

[joffrey]

This (👇🏼) is the published version of these (☝🏼) docs on the website:
kotlin-toolchain.org/dev/user-guide/product-types/android-app#…

[thunderbiscuit]

Oh sweeeeet ok I didn’t notice the dropdown that allowed for the latest dev release. Perfect thanks! I had found the commits and so started to test anyway a few minutes ago and yes, this solved our issue completely! Man you guys are on fire, that’s 2 of my prod issues fixed in 2 weeks. Thanks!

[Alexey Barsov]

Thanks to you! Being an earlier adopter of the technology brings its niceties.
Your feedback is very welcome and as you see it might affect the shape of the technology itself, especially if that is around our golden path, so keep posting what prevents you from adoption. I can't promise we will fix everything, we keep focusing on our current plans and road map, what I can promise is that requests will not be left unattended.