`slint android init` for a persistent Android project (Tauri-style workflow)

[krishna-kush]

slint android init (persistent Android project)

I would like Slint to support a command like:

slint android init

The goal is to create a persistent android/ project in the repo (Gradle + Kotlin/Java + Manifest + resources), while still using Rust/Slint for app logic and UI.

Why I need this

The current x run / x build flow is great for quick Rust-first builds, but in real Android apps I often need native Android code and full control of Android files.

Common examples:

• Runtime permissions and lifecycle callbacks (onRequestPermissionsResult, activity result handling)
• Android 12+ splash setup (installSplashScreen() timing in Activity)
• Deep links, intents, share targets
• Services, notifications, receivers
• Billing and other Android SDK integrations
• Custom Activity / Application behavior and Manifest edits

For this, I need a stable, source-controlled Android folder that I can edit directly in Android Studio.

Why xbuild alone is not enough for this workflow

xbuild is useful for packaging/building, but it does not feel equivalent to a first-class, persistent Android project workflow like Tauri's tauri android init.

I know custom Kotlin can be kept in a project kotlin/ folder and copied during build. That helps.

But core generated Android files are still written by the tool during build (not owned as normal app source), including:

• top-level Gradle files
• app build.gradle
• generated AndroidManifest.xml

So direct edits in generated Gradle output are fragile, especially for advanced Android setup (plugins, signing configs, flavors, multi-module config, custom Gradle structure).

Even if generated files are moved out of target/, this is still not the same as a stable, source-controlled android/ project I can treat as part of my app.

Suggested output

slint android init could generate a project like:

• android/settings.gradle(.kts)
• android/build.gradle(.kts)
• android/app/build.gradle(.kts)
• android/app/src/main/AndroidManifest.xml
• android/app/src/main/java/.../MainActivity.kt
• android/app/src/main/res/...

It should also wire Rust correctly (android_main, library naming/linking, and runnable from Android Studio).

CLI direction suggestion

I would prefer Slint to move away from exposing xbuild directly in the user-facing workflow.

Possible directions:

• Replace x commands with first-party commands like slint android run and slint android build
• If needed, keep xbuild only as an internal backend detail
• Or fully remove xbuild dependency from the recommended workflow and use a persistent Android-project-first approach

If everything I described is already possible in a clean and maintainable way with current xbuild workflow, please share that path before closing this request. It would be a big help, since I am new to both xbuild and Slint and I am trying to migrate my app from Tauri to Slint.

[NYBACHOK]

I don't think xbuild is focused on Slint, but persistent Android project is way that I would like to see too. This would even simplify setting of insets for Activity.

It also would be great to have some simple way of communication with Kotlin side using something like unix socket or grpc? to omit complexity of direct JNI calls.

[krishna-kush]

I wanted this issue to open in slint repo and not here but by mistake I did it here. So I'm closing it.