Skip to content

Conversation

@Subham-KRLX
Copy link

Closes #14569

Documents how to properly load native libraries in Android plugins with dynamic naming instead of hardcoding System.loadLibrary("app_lib").

Adds guide explaining:

  • Library naming convention from Cargo.toml
  • Portable code pattern using constants
  • Error handling and quick reference

Reference for updating tauri-apps/tauri-docs.

@Subham-KRLX Subham-KRLX requested a review from a team as a code owner November 29, 2025 10:21
@github-project-automation github-project-automation bot moved this to 📬Proposal in Roadmap Nov 29, 2025
@Subham-KRLX
Copy link
Author

Subham-KRLX commented Nov 29, 2025

@IT-ess ,@FabianLars can you please review this.

@cntrvsy
Copy link

cntrvsy commented Nov 29, 2025

@IT-ess ,@cntrvsy can you please review this.
Wish I could, try reaching out on the discord
https://discord.gg/tauri

@IT-ess
Copy link

IT-ess commented Nov 29, 2025

Thanks for the PR !
This is a first step, but this doc will mainly be useful for the users of plugin that do need Rust lib linking. The actual issue is for plugin developers to make the lib linking dynamic, and that part should be documented instead. This kind of knowledge would allow plugin devs to make more flexible plugins while keeping them "plug and play".
I don't know if this requires changes in Tauri's code, or if the solution is already out there but I just don't know how to do it.

@Subham-KRLX
Copy link
Author

Thanks for the feedback @IT-ess!
To clarify the scope: should this PR document how plugin developers can implement automatic library loading (so users don't need to configure anything), or should it stay focused on helping plugin users adopt better practices?
If it's the former, does Tauri already support automatic library name detection, or would that require code changes? Happy to research and expand the PR accordingly.

@IT-ess
Copy link

IT-ess commented Nov 29, 2025

It is the former, and I don't know if that requires modifications in the code. I guess it does need some, otherwise it would probably have been documented either

@Subham-KRLX
Copy link
Author

@IT-ess Found the solution! Plugin devs can auto-generate the library name using Gradle BuildConfig:

In android/build.gradle.kts:

android {
    defaultConfig {
        // Read from Cargo.toml at build time
        val cargoToml = file("../../Cargo.toml")
        val libraryName = cargoToml.readText()
            .lines()
            .find { it.trim().startsWith("name") }
            ?.substringAfter("\"")?.substringBefore("\"")
            ?.replace("-", "_") ?: "unknown"
        
        buildConfigField("String", "LIBRARY_NAME", "\"$libraryName\"")
    }
    buildFeatures { buildConfig = true }
}
In Example.kt:

kotlin
companion object {
    init {
        System.loadLibrary(BuildConfig.LIBRARY_NAME) // Auto-generated!
    }
}

@IT-ess
Copy link

IT-ess commented Nov 30, 2025

I'm not sure but the config should be added to the build.gradle.kts of the plugin user, not the plugin itself ? 🤔
I'll give it a try later, I don't have my computer with me right now

@Subham-KRLX
Copy link
Author

@IT-ess It goes in the plugin's build.gradle.kts not the user's app.

Flow:

  1. Plugin developer (you) adds BuildConfig to your plugin's android/build.gradle.kts once
  2. Plugin users just install your plugin - no config needed ✅

Structure:
tauri-plugin-yourplugin/ └── android/ ├── build.gradle.kts ← BuildConfig HERE (plugin dev sets up once) └── src/.../Example.kt ← Uses BuildConfig.LIBRARY_NAME

user-app/ └── (just imports plugin, no changes needed)

This makes your plugin automatically load the correct library so users don't have to configure anything. Try it out when you get a chance!

@IT-ess
Copy link

IT-ess commented Dec 1, 2025

I just tested that, and it doesn't work at all 🫤

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: 📬Proposal

Development

Successfully merging this pull request may close these issues.

[docs] [android] retrieve the app lib name dynamically in Kotlin

3 participants