Anyone interested in using Rust with Kotlin Multip...

# feed

[Chanjung Kim]

Anyone interested in using Rust with Kotlin Multiplatform? 🦀*+*K
Hi, we've just released Gobley 0.2.0! Gobley provides Gradle build integration between KMP and Cargo for Android, iOS, and JVM.
You can also use Gobley with the Kotlin/JVM plugin or the Kotlin Android plugin, so even if you're not using Kotlin Multiplatform but interested in Rust, you're still welcome.
Kotlin/JS and Kotlin/WASM support is planned, so stay tuned!

We also have some documentation for newcomers:
• Hands-on tutorial: https://gobley.dev/docs/tutorial
• Cross-compilation tips to integrate Kotlin, Rust, and C++: https://gobley.dev/docs/cross-compilation-tips
• Cross-platform example app (Android, iOS, Windows API, & Linux GTK): https://github.com/gobley/gobley/tree/main/examples/app/src
• GitHub discussions: https://github.com/gobley/gobley/discussions
Feel free to ask if you have any questions or have trouble setting up your project!

[Sergey Y.]

Awesome project! I’ve been looking for something like this for a long time. I’ve been working with Rust on Android and had to do many things manually. If this can auto-generate things, that’s just great!

I have a follow-up question.
Does it help with debugging Rust code from Android Studio?
How do you usually perform debugging in such cases?
I haven’t found an answer to this in the documentation so far.

[Sergey Y.]

my experience debugging Rust on Android was purely through the command line using LLDB for Rust. I had to manually copy the LLDB server to the Android device, attach to it from my Rust LLDB client, and perform debugging via the command line.

I also tried connecting directly from Android Studio’s LLDB, but it doesn’t work well with Rust debug symbols.

[Chanjung Kim]

@Sergey Y. First of all, thanks for your attention to this! And unfortunately, we don't have features dedicated for debugging yet. It is possible to debug the Rust code as you did, but manually.
But I don't have any idea why you had to copy the LLDB server to the devices, you can configure Gradle not to strip the debug symbols like the following.

android {
    buildTypes {
        debug {
            packaging {
                jniLibs {
                    keepDebugSymbols += "**/*.so"
                }
            }
        }
    }
}

Then, in the Run configuration, as you'd have done, set the debug type to Java + Native. Launch the app, attach the debugger, pause LLDB, and set breakpoints where you want. At least we would be able to shorten this manual breakpoint-setting process by making an IntelliJ plugin, but we don't have one yet.
I have plans to make an IntelliJ plugin for this, and I'll definitely post that news here when we got a basic debugger support.

As of now, the most practical way is to use unit tests. When you use androidTarget() inside the project, Gobley will build the Rust library for the host machine's platform for local unit tests (You can turn this off). So you can share the unit test code between local unit tests and instrumented unit tests, as you'd do with Java or Kotlin.

[Sergey Y.]

Regarding copying the LLDB server to the Android device, this is something Android Studio handles automatically behind the scenes when you attach the debugger to an app process and step into NDK code. But when working with CLI-based debugging, we have to do it manually.

[Sergey Y.]

You’re describing exactly what I’m doing right now. Inside Android Studio, I specify the directory containing the debug symbols. Then, manually via the command line, after the Android Studio debugger attaches to the Android process, I set a breakpoint using LLDB and step into my code.

[Chanjung Kim]

I thought the LLDB server copying process you mentioned is like something that uses adb, configuring port forwarding, making the lldb server listening on the device, and launch lldb on the host machine that connects to the port.
If I understand it correctly, then at least the process specifying the debug symbol directory and controlling lldb from the terminal, that can be omitted. The screenshot I uploaded is made without doing the process in an external terminal. The only thing that should be manually done is setting breakpoints.

[Sergey Y.]

basically the same steps as described here https://github.com/threeve/swift-android-sdk/wiki/Remote-Debugging-with-LLDB#command-line-remote-debugging

[Sergey Y.]

I’m curious can your plugin help streamline some of these manual steps?

[Chanjung Kim]

Oh I got it, and as I mentioned, the process in the first screenshot is inevitable without an IntelliJ plugin AFAIK (because the IDE doesn't allow setting breakpoints in .rs files). I'm saying that the process in the second screenshot is not necessary. I'm sure that you don't have to manually set the debug directory if you put the above Gradle DSL in your project settings. (If this doesn't work then maybe strip-symbols are enabled in the Cargo profile settings in the workspace manifest).

Screen Recording 2025-04-06 at 7.25.09 PM.mov

[Sergey Y.]

Thank you for explaining, I didn’t know it could work without setting the debug symbols directory.

[Chanjung Kim]

I'm investigating an IDE option to set breakpoints in the Rust source code, but I don't know why, I'm not able to set breakpoints in Kotlin source code right now 😂

[Sergey Y.]

Correct me if I’m wrong: from your video, when you’re setting a debug breakpoint in the add function in your Rust code. Does UniFFI export disable name mangling for the function symbol, or is it still mangled? And if I want to set a breakpoint on a specific function name, I do need to know the exact mangled symbol name, correct?

[Chanjung Kim]

Yes, you need know the exact mangled symbol name (as you'd know, you can find with image lookup). UniFFI doesn't prevent name mangling, but it generates #[no_mangle] extern "C" functions. In the above example, it would be something like uniffi_ffi_app_add (I'm not sure).

[Chanjung Kim]

Used nm -g, it's uniffi_app_fn_func_add.

[Sergey Y.]

Got it.

[Sal]

🎉 Let's go!

[benkuly]

Really cool to see this project, that I started a few years ago getting so much love from awesome new maintainers 💛

[Sal]

Thank you for your work getting this going!