search

mozilla / rust-android-gradle

Apache License 2.0
1.03k stars 67 forks source link

Support and add a sample/test showing how to include a Rust binary like `$name` instead of a library like `lib$name.so` #30

Open Mygod opened 4 years ago

Mygod commented 4 years ago

gradle.plugin.org.mozilla.rust-android-gradle:plugin:0.8.3. Android gradle plugin 4.0.0-beta01.

thomcc commented 4 years ago

Can you elaborate here? We should be outputting lib$name.so currently.

Mygod commented 4 years ago

According to my test, it didn't work until we used some patch like https://github.com/shadowsocks/shadowsocks-android/commit/5ea3e3559adfb7b779ba6f3f633a02b3bcf50145.

thomcc commented 4 years ago

Can you elaborate on "didn't work"? Sorry, just trying to understand what the issue is.

Mygod commented 4 years ago

Yeah as said in title, the output binary is named $name instead of lib$name.so, so it does not get bundled into apk.

Mygod commented 4 years ago

I understand that the code I changed in #31 is supposed to do exactly that but somehow that did not work.

Mygod commented 4 years ago

Okay I guess the issue is that we are compiling a binary instead of libraries like most Android apps do. I wonder what's the easiest way to do this with this plugin then. Currently we are using a convoluted workaround: https://github.com/shadowsocks/shadowsocks-android/commit/833b35e7b792cf13709e4e5f1f87c591bffcf062

ncalexan commented 3 years ago

Should somebody see this, I think we can support this without a workaround right now using targetIncludes. I'll leave this ticket to include a sample project that does exactly this.

Mygod commented 2 years ago

I am not sure how this relates to compiling a binary?

ncalexan commented 2 years ago

I am not sure how this relates to compiling a binary?

If I understand correctly, the issue is that cargo build debug will produce binary, but the plugin won't package it into jniLibs (which is where executables must go, last I checked). I think you can use targetIncludes to package it, but I haven't verified. Hence, let's have a sample project/test showing how to do it and making sure we don't regress the functionality. Is that clear?

Mygod commented 2 years ago

I think last time I checked, the binary is not extracted from apk if the filename does not match lib$name.so. I could check again sometime.

ncalexan commented 2 years ago

OK, I took a look at this. The way I'd like to support binaries is as follows:

  1. Make libname optional and add binname and/or binnames.
  2. Make binnames add --bin ... to the command line as appropriate
  3. Follow https://developer.android.com/ndk/guides/wrap-script#packaging_wrapsh and put the executable file into the Java resources. (I could be convinced that renaming to binname.so is enough here.)
  4. Verify that the APK does get the binary in the correct libs/$arch/... location in the APK.
  5. Verify that we can actually execute the binary on device and emulator.