Hi, I just wonder if you have any plans to support...

# kotlin-native

[benny.huo]

Hi, I just wonder if you have any plans to support Android X86 target?

[olonho]

We could, but not sure how important it is. Other native Android didn’t brought much interest, so we need to be convinced, that such target is relevant indeed

[louiscad]

I'd be very interested if there was an example on how to have interop with Kotlin and Kotlin/Native in an Android app, and I'm certain that's what many Android devs are looking for. Also, IMHO, most Android devs are NDK noobs and don't want to deal with unsafe C/C++ and complex JNI stuff. I think you'd need to go hand in hand with Google to bring first class Kotlin/Native to Android with interop with non native Kotlin.

[gildor]

Yes, interop between Kotlin/Native and Kotlin/JVM would be a huge selling point for Android
And x86 not the most common architecture for Android, but for a real production application or library you usually want to provide x86 and x86_64 binaries (for example we do that).
Also, for some more specialised Android markets (like Android Things or Android on Chromebooks) x86 much more common thing

[gildor]

Also, there are some use cases that still solved usually by NDK on Android:
graphics, audio (our case, especially low-latency audio and realtime audio processing) and some additional use cases, like work with big images (see uCrop), out of heap memory (see Fresco) and so on.
And Kotlin/Native still very useful on Android, but JNI is a huge pain

[dsgryazin]

I don't think NDK and K/N have common business.

Code sharing is the major reason to use K/N on mobile. If you use NDK, you possibly use C-libraries ports to solve complex tasks, not to share code between platforms. You can generate .so with K/N though.

I guess it's going to work with multiplatform rather than NDK. People gonna write common modules with actual implementations as wrappers of platform specific libraries.

[dsgryazin]

Using c-libraries for typical tasks on Android is a
doubtful decision, as it is hard to debug and it tends to bring more bugs on total android device fragmentation

[gildor]

What is "typical task"?
For example if you want to work with low latency audio on Android, NDK and OpenSL API is you only choice (or for never Android it's AAudio that also has pure C API)
So it's not a way to share code, it's way to do things.

And biggest pain on Android is interop with NDK.
And K/N can help to solve this, especially if we would have K/N and K/JVM interop
Of course, I don't want to use K/N or NDK where it's possible to do not use it. And just use multiplatform Kotlin for code sharing, but code sharing is not the only case

[gildor]

I would never recommend to use NDK if it's possible to use Android SDK instead

[dsgryazin]

And biggest pain on Android is interop with NDK

Why? JNI is clumsy? Do you mean that you have to communicate with low-level C APIs?

Can't see how KN would help here, as you are tied to C anyway and you have to know it.

[gildor]

Yes, JNI is very clumsy and tedious to write, this is my main point.
Actually there is a couple points:
1. K/N needs x86 support on Android and Kotlin JVM cannot cover all existing cases.
In some cases you must use NDK. So it means that you can choose K/N instead of C/C++, bit in this case you probably want x86 and x86_64 support, not only arm (32 and 64 bits)
2. Kotlin Native actually can help with jvm/native interop. K/N already has internal interop level with C and (probably) with Kotlin Native directly or through C interop. K/N compiler is JVM only, so this is the reason why C interop facilities are there.
So I just said, that if we will have direct interop of Kotlin JVM and Kotlin Native and C it would be really big feature for anyone, who already use Kotlin and have no choice and uses NDK because of any reason, because you don't want to work with JNI

Do you mean that you have to communicate with low-level C APIs?

Not low level, just with your own ndk library.

you are tied to C anyway and you have to know it.

Yes, but use C from K/N is much more pleasant than use it from JVM