Support androidNative target

[Syrou]

Been trying to setup coroutines against

  fromPreset(presets.androidNativeArm64, 'androidNative')

but it seems not to work with

 implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core-native:$coroutines_version"

but it does not resolve the dependencies, is this not working yet?

[SeekDaSky]

The gradle file for K/N compilation does not have android native in its targets so you can not use it in K/N android projects. But you could maybe try to clone the repo, add the target and see if it compiles, but that is a bit experimental.

Edit: that won't work, AtomicFU does not have the android native target either

[Syrou]

@SeekDaSky Seems like you are correct, there is support for it in kotlin multiplatform but these libraries are still missing it. I'm hoping for it to get added soon.

[elizarov]

What would be your use-case of using coroutines with androidNative target?

[Syrou]

@elizarov In this specific case it would be to standardize a communication bridge with Unity. iOS makes use extern "C" in order for unity to be able to run iOS code. My wish in this specific case would to open up the same possibility for android and reuse the exact same code in Unity for both platforms

but I also see a great possibility to write Native Libraries and hopefully make it more hard for people to reverse them since it would no longer be java code (This is still true with the common base, but it would take it all the way)

[dhakehurst]

+1

[elizarov]

@dhakehurst Can you, please, elaborate a bit on what is your use-case for it?

[dhakehurst]

I would have thought obvious. ?
Kotlin 1.4 provides androidNative as a target.
I want to build androidNative applications?

Maybe something i miss understand about this target.

[LouisCAD]

@dhakehurst Why do you need to run with the NDK and not in ART as most apps do?

[dhakehurst]

Well, I don't "need" to. I want to.
it is a valid kotlin Target, so why not support it?
is it a problem to support it?

[dhakehurst]

there are many articles discussing ART vs NDK.
e.g. https://www.androidauthority.com/java-vs-c-app-performance-689081/

which states
"Google recommends using the NDK for “CPU-intensive applications such as game engines, signal processing, and physics simulations.”"

[elizarov]

Supporting each target adds a considerable burden. We don't even have the infrastructure to test it. We'll have to create it. So that's why we need to understand what's the use-case. Why would you need it? If you use NDK you might be writing a game with Unity or some other game engine. Why would you need Kotlin coroutines there?

[natario1]

I'd like to add my 2 cents here, just as a "Please do it!". Over the last year I've been asked why I use androidNative a few times by the Kotlin team (like here, here, ...) but it won't hurt to say it again.

In this case I think the question "Why would you need Kotlin coroutines there?" is not hitting the right spot, because the androidNative == Unity equation is wrong. Tons of apps use native libraries in mixed projects, and potentially all the non-UI code could be there with many benefits. Historically this does not happen in Android teams, but I think that's because of a language barrier - not only C++ syntax, but also losing all the JVM treats e.g. around memory.

androidNative has a huge potential to fill this gap with a language and environment Android developers are used to. And it is a great choice for many reasons. Performance is getting better, memory model is getting better, shipping binary code is a huge relief (compared to the JVM, where it takes a few hours to decompile and clone your app), and you can interact with native, extremely performant libraries through cinterop. If you ask me, this (not JVM) is the natural companion to iOS targets, when UI is not involved. I can, say, compile my custom build of dlib for both in little time.

Now if there are many diverse reasons to use androidNative, the "I thought it'd be obvious?" by someone above is a legit answer to the coroutine question. We just want the idiomatic solution to threading and concurrency, shared with iOS. I agree that most people will not have an event loop in native, we just have synchronous JNI calls where threading is managed by the JVM layer. Single threaded coroutines are 100% useless here. But still this is just where K/N drove us with its current limitations. Had we had AtomicFUs for example, the whole structure would be different. With ktor, we'd be so much happier. And multi-threaded coroutines, once they're ready, would give a huge performance boost and unleash more possibilities. Just like they do on other platforms.

So... We kind of have all this on one side, and on the other, AtomicFU and Coroutines are missing a few lines in their build file, which gives a second-class citizen feeling (I'm still confused as to why 1.4.0 multiplatform has an ios() target but not androidNative() which is just as useful). I understand your concerns about testing, I even asked what do you need, but I still think the weights are much much stronger on the "do it" side, even if untested. I hope you can allocate some resources to this soon @elizarov

[elizarov]

I understand your pain, but adding androidNative target is really a lot of effort throughout the whole Kotlin toolchain. Currently, we don't even support running androidNative tests in a Gradle Kotlin plugin. We don't have resources to add that in the short-term. If somebody is willing to work on adding and supporting it, then please contact me either via email or DM via Kotlinlang slack.

[dhakehurst]

why does Kotlin provide androidNative as a target, if the libraries will not support it?

[elizarov]

Support of andoirdNative in Kotlin/Native is very experimental and minimally tested. It might be fine to try it out, play with it. That's why it is there, to let the community play with it and gather feedback, but it is not fine for stable libraries like kotlinx.coroutines.

[dhakehurst]

Ok. Community feedback: I like it. I need coroutine library support in order to play with it and better evaluate it. 😉

…

On Fri, 18 Sep 2020 at 11:46, Roman Elizarov ***@***.***> wrote: Support of andoirdNative in Kotlin/Native is very experimental and minimally tested. It might be fine to try it out, play with it. That's why it is there, to let the community play with it and gather feedback, but it is not fine for stable libraries like kotlinx.coroutines. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#812 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABK3WZNOGDASWFEYJ3RSN6DSGMUABANCNFSM4GCSMY3A> .

[Syrou]

In order for this addition to be made, we would need to rely on android emulators to give green light for the tests, or am I wrong @elizarov ?

[elizarov]

Right. To get started, we'll need somebody who works in this domain and knows ins-and-outs of working with Android Native code to contribute build scripts that can automatically run tests for the compiled code under an emulator. It is not our field of expertise, so there's not much we can help with.

[natario1]

If anyone wants to give it a try I'm happy to give advices if needed. In the next months I'll try to work on it myself as well.

[blackstardlb]

A usecase for this is compiling your networking code to androidNative / ios as a shared lib and using the shared library from flutter. This way you don't have to deal with with serializing JVM/IOS classes to pass messages between flutter and the kotlin networking layer.

[LouisCAD]

@elizarov Would it be ok if you enable GitHub Actions on this repo (unless it already is) and on atomicfu as well, and then have someone contribute testing there for the Android NDK?

I don't expect much or any difference compared to linuxX64 support when it comes to the code being compiled. Of course it'd need to be added to atomicfu first.

[elizarov]

@LouisCAD We don't use GitHub actions in Kotlin org.

[LouisCAD]

I know you use TeamCity, but why not start using both for this purpose? These things are not mutually exclusive AFAIK.

Or provide us a little guidance to contribute to the TeamCity configuration?

[Syrou]

I have waited a long time for this 🎉. Thanks!