permissions, manganis::ffi, full Info.plist/AndroidManifest.xml customization

[wheregmis]

This PR introduces a comprehensive linker-based permission management for automatic update of manifest files and android native plugin building foundation for Dioxus. The implementation is inspired by Manganis's linker-based asset collection approach.

Build on top of #4932 so diff is huge for now

Two main motivation for this PR

1. To automatically handle the manifest file and info.plist file instead of invoking, ejecting or providing custom file.
2. Able to pass in the java file path through linker, copy and bundle them (Opening doors for android native apis development)

Currently packages/geolocation and geolocation example resides within this PR, its just for the ease of testing, and will not be upstreamed

Here is a breakdown of how things are working for now.

Android (Kotlin / Gradle)

Source layout

• Kotlin sources + Gradle wrapper live under packages/geolocation/android/
• The module builds a release .aar: android/build/outputs/aar/geolocation-plugin-release.aar

build.rs responsibilities

packages/geolocation/build.rs builds the Gradle module whenever the target triple contains
android:

1. Respects the toolchain env exported by the CLI (DX_ANDROID_JAVA_HOME, DX_ANDROID_SDK_ROOT,
   DX_ANDROID_NDK_HOME, DX_ANDROID_ARTIFACT_DIR). If those are absent (non-dx builds) it falls
   back to ANDROID_* or JAVA_HOME.
2. Runs ./gradlew assembleRelease inside packages/geolocation/android.
3. Copies the resulting .aar into the CLI-provided artifact staging dir
   ($DX_ANDROID_ARTIFACT_DIR/geolocation-plugin-release.aar or
   $OUT_DIR/android-artifacts/... as a fallback).
4. Emits cargo:rustc-env=DIOXUS_ANDROID_ARTIFACT=<absolute path> so the Rust macro can reference
   the built artifact.

Metadata embedded in the Rust binary

In packages/geolocation/src/lib.rs we declare the Android artifact like this:

#[cfg(all(feature = "metadata", target_os = "android"))]
dioxus_platform_bridge::android_plugin!(
    plugin = "geolocation",
    aar = { env = "DIOXUS_ANDROID_ARTIFACT" },
    deps = ["implementation(\"com.google.android.gms:play-services-location:21.3.0\")"]
);

The aar block only needs a stable way to refer to the file that build.rs produced. Emitting a
cargo:rustc-env=... from the build script is the idiomatic Rust approach for passing data from
build.rs to the crate being compiled, which is why each plugin publishes its own environment
variable. Nothing prevents you from using unique names—DIOXUS_GEO_ANDROID_ARTIFACT,
DIOXUS_CAMERA_ANDROID_ARTIFACT, etc.—as long as your macro invocation references the same key that
your build script sets. Automatically inferring the path from the plugin name is brittle because the
artifact location lives in target/ (or another $OUT_DIR) that only build.rs knows about after
running Gradle, so the build script remains the single source of truth.

The macro serializes:

• plugin name
• Absolute aar path (resolved via the env var emitted by build.rs)
• Any Gradle dependency lines listed in deps

The metadata is wrapped in SymbolData::AndroidArtifact and stored under the shared
__ASSETS__* symbol prefix (the same one used for assets and permissions). Nothing runs at runtime—
the symbols are just scanned later by the CLI.

What the CLI does (dx serve --android)

1. After building the Rust binary, dx walks every __ASSETS__* symbol once. When it encounters a
   SymbolData::AndroidArtifact, it adds it to the manifest alongside assets and permissions.
2. install_android_artifacts() (in packages/cli/src/build/request.rs) copies each .aar into
   target/dx/.../app/libs/ in the generated Gradle project.
3. For every artifact it ensures the Gradle dependency file contains both:
   • implementation(files("libs/<artifact>.aar"))
   • Any additional strings from deps (e.g. the Play Services location runtime)
4. When Gradle runs for the host app, those libraries are already on disk and referenced in
   app/build.gradle.kts, so they get packaged automatically.

Note: because the .aar is built inside the Rust crate, plugin authors do not touch the app’s
Gradle project. Everything happens by copying artifacts + editing app/build.gradle.kts inside the
generated dx workspace.

---

iOS / macOS (Swift Package)

Source layout

• Swift sources + Package.swift live under packages/geolocation/ios/
• The Swift Package exports a single product: GeolocationPlugin

build.rs responsibilities

For Apple targets, build.rs:

1. Detects the desired triple (aarch64-apple-ios, aarch64-apple-ios-sim, x86_64-apple-ios) and
   finds the matching SDK via xcrun --show-sdk-path.
2. Runs xcrun swift build --package-path ios --configuration <debug|release> --triple <...> --sdk <...> --product GeolocationPlugin.
3. Locates the resulting static library (libGeolocationPlugin.a) and emits:
   • cargo:rustc-link-search for both the Swift build output and the Xcode toolchain Swift libs
   • cargo:rustc-link-lib=static=GeolocationPlugin
   • cargo:rustc-link-lib=swiftCompatibility* + -force_load flags so the ObjC runtime sees the
     plugin class
   • cargo:rustc-link-lib=framework=CoreLocation / Foundation

At this point the Swift code is already linked into the Mach-O produced by Rust; no additional build
steps are required later.

Metadata embedded in the Rust binary

In packages/geolocation/src/lib.rs we declare the Swift package via:

#[cfg(all(feature = "metadata", any(target_os = "ios", target_os = "macos")))]
dioxus_platform_bridge::ios_plugin!(
    plugin = "geolocation",
    spm = { path = "ios", product = "GeolocationPlugin" }
);

This writes an entry into the shared __ASSETS__* stream as SymbolData::SwiftPackage. Again,
nothing is executed at runtime; it is just discoverable metadata alongside assets and permissions.

What the CLI does (dx serve --ios / --macos)

1. The CLI sees the SymbolData::SwiftPackage entries while it’s already processing the asset
   stream.
2. When at least one Swift package is present, embed_swift_stdlibs() runs (see
   packages/cli/src/build/request.rs). This invokes xcrun swift-stdlib-tool --scan-executable on
   the final app binary and copies the required Swift runtime libraries into the bundle’s
   Frameworks/ folder (iOS) or Contents/Frameworks/ (macOS).

Because the Swift package was linked during the Rust build, the CLI’s only job is to make sure the
Swift runtime ships alongside the executable.

---

Summary table

Platform	Native sources live	Compiled by	Metadata stored	CLI responsibilities
Android	packages/geolocation/android (Gradle lib)	build.rs running gradlew assembleRelease	SymbolData::AndroidArtifact (plugin, path, deps)	Copy .aar into app/libs, append Gradle dependencies
iOS/macOS	packages/geolocation/ios (SwiftPM)	build.rs running xcrun swift build	SymbolData::SwiftPackage (plugin, package path, product)	Embed Swift stdlibs when Swift metadata is present

This setup keeps each plugin self-contained:

• All native code + build tooling stays inside the crate.
• build.rs produces platform artifacts and emits env vars for linker metadata.
• The Dioxus CLI only needs the linker symbols to know what to copy/embed when bundling user apps.

New crates: (Please suggest the names as i am bad at naming stuff)

• permissions: Public API that re-exports permissions-core and permissions-macro for easy integration.
• permissions-core: Types for permission declaration and platform identifiers (Android, IOS, MacOS) (We can extend the identifiers as needed or requested)
• permissions-macro: Procedural Macros (static_permission!) for declaring permissions via linker symbol (So cli can extract the symbols and update the manifest files automatically)
• dx-macro-helpers: Common helpers for linker based stuff, shared by manganis and permission
• platform-bridge: Bareminimal Cross-platform FFI utilities and plugin metadata for Android (JNI) and Darwin (objc2)
• platform-bridge-macro: android_plugin! macro for embedding Java source file paths in binaries via linker symbols

[wheregmis]

Yey, Android Permission Dialog is working.

[nicoburns]

I'm not seeing the purpose of the typed API for permissions (the enum of all permissions). Or the permissions mapping in Dioxus.toml. Wouldn't it better to treat everything as "custom" permissions (specified as strings)?

That way there would be much less code to maintain, it should work for all permissions not just ones we define, and the code to write permissions in Dioxus would be 1:1 with what is documented in the platform docs, so there's no additional DSL/mapping for users to learn.