j4rs: Android calls JvmBuilder::new() with an error.
I have created a new project:
cargo new test --lib
cd test
File src/lib.rs:
use android_activity::AndroidApp;
use j4rs::jni_sys::{JavaVM, jint, jobject};
use j4rs::JvmBuilder;
#[no_mangle]
fn android_main(app: AndroidApp) {
let jvm = JvmBuilder::new().build().unwrap();
println!("{:?}", app);
}
const JNI_VERSION_1_6: jint = 0x00010006;
#[allow(non_snake_case)]
#[no_mangle]
pub extern fn jni_onload(env: *mut JavaVM, _reserved: jobject) -> jint {
j4rs::set_java_vm(env);
JNI_VERSION_1_6
}
File cargo.toml:
[package]
name = "test"
version = "0.1.0"
edition = "2021"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[lib]
name = "test"
crate-type = ["cdylib"]
[dependencies]
[dependencies.android-activity]
features = ["native-activity"]
version = "0.5.2"
[dependencies.j4rs]
version = "0.18.0"
Then use cargo-apk to build:
cargo apk run
Output:
...
04-27 21:17:40.671 20603 20677 I RustStdoutStderr: thread '<unnamed>' panicked at src\lib.rs:7:41:
04-27 21:17:40.672 20603 20677 I RustStdoutStderr: called `Result::unwrap()` on an `Err` value: GeneralError("Error { kind: PermissionDenied, message: \"Permission denied (os error 13)\" }")
04-27 21:17:40.672 20603 20677 I RustStdoutStderr: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
04-27 21:17:40.673 20603 20678 E RustPanic: called `Result::unwrap()` on an `Err` value: GeneralError("Error { kind: PermissionDenied, message: \"Permission denied (os error 13)\" }")
...
May I ask if I missed anything?
About this issue
- Original URL
- State: open
- Created 2 months ago
- Comments: 21 (8 by maintainers)
That tends to happen, the default visibility for new repositories is “private” and I hadn’t noticed when uploading late at night. Should be fixed now.
Unfortunately the Rust Android ecosystem is plagued heavily by NIH syndrome, there are far too many crates and tools attempting to do the same thing, all failing or lacking in certain areas rather than bundling their strength in one coherent system/crate/tool/approach.
However,
cargo-mobile2
is a completely different beast that serves a completely different purpose.cargo-apk
andxbuild
allow you to build applications natively (with the help of a varying number of system tools, and even leveraginggradle
when enabling AAB support inxbuild
).cargo-mobile(2)
generates agradle
Android Studio project to continue your development from, rather than being able to build from an almost-bare-bonesCargo.toml
project.