.so does not end up in .apk if project inside workspace

[lattice0]

If you have

android_project
libsomething
libsomething2
Cargo.toml

and Cargo.toml happens to be a workspace for libsomething and libsomething2, then

cargo {
    module  = "../../../libsomething"
    libname = "something"  
    verbose = true
    apiLevel = 21
    profile = 'release'
    targets = ["arm64"]
}

will compile the libs but the libsomething.so does not end up in the rustJniLibs folder, probably because the target folder is not inside libsomething but at the root workspace.

I don't want to compile the entire workspace, just this lib, that's why I point to just it. If I pointed to the workspace, it would probably work, but the workspace contains non android things.

Fully working example: https://github.com/lattice0/flutter_workspace/blob/master/flutter_bug/android/app/build.gradle#L66

What could be done here? I really need this stuff to be in a workspace otherwise rust-analyzer goes completely crazy.

[ncalexan]

Use targetIncludes. I'm going to leave this open because I'm not confident that targetIncludes will work with relative paths, although I expect it will. Please report back if you can't solve this with targetIncludes; we can probably make it handle absolute and relative paths easily enough.

[lattice0]

Unfortunately it doesn't work. I also tried to pass

cargo {
    module  = "../../../"
    libname = "something"  

so it builds the workspace but only uses something, but in this case libsomething2 cannot even be built because it's not for android (it's not even a lib, but a desktop application).

[lattice0]

I think the best option here would be to run cargo run --package=${libname}. Then it would always compile the workspace but just the libname

[ncalexan]

I think the best option here would be to run cargo run --package=${libname}. Then it would always compile the workspace but just the libname

I assume you mean cargo build --package=.... I'd take a patch to do that, or at least I'd get it tested in CI and review it. I will say that historically workspaces plus specific --package=... invocations straight up didn't work, but that was years ago so the situation may be much better. Working code will win out :)

[lattice0]

I was able to make it work by

targetDirectory = '../../../target'

I tried to fix the problem though but gradle is very annoying when using a local plugin for fast changes

[ncalexan]

I was able to make it work by

targetDirectory = '../../../target'

I tried to fix the problem though but gradle is very annoying when using a local plugin for fast changes

Can you say more? The substitution workflow is pretty smooth for me: https://github.com/mozilla/rust-android-gradle/blob/master/README.md#testing-local-changes.

[jmartinesp]

I had similar issues and I can confirm that a mix of:

targetIncludes = ["my_library.so"]
targetDirectory = "../path/to/target/"

Fixed it for me. Thank you both for the workaround!

[ncalexan]

I had similar issues and I can confirm that a mix of:

targetIncludes = ["my_library.so"]
targetDirectory = "../path/to/target/"

Fixed it for me. Thank you both for the workaround!

Glad to hear it. @lattice0, if you want to propose a "first class" fix, I'd entertain it.

[stan-irl]

same problem here. I cant get it to work with any combination of targetIncludes and targetDirectory

[stan-irl]

Ignore my previous comments - I was looking for jniLibs folder when the plugin puts them in rustJniLibs. Also they arent visible in android studio. I had to look in the android//build folder folder