Build process wrongly copies a Linux .so native lib instead of the Android one to the final APK.

[busec0]

Android application type

.NET Android (net7.0-android, net8.0-android, etc.)

Affected platform version

.NET 7.0.313

Description

This is .NET Only!

Summary: .NET Android build process copies the wrong .so into the generated APK. Having an arm64 device, and a NuGet with native libs for both arm64-v8a and linux-arm64, it'll copy the Linux ARM64 slice instead of the Android ARM64.

Having the NuGet with the native libs structure:

runtimes
├── android
│   ├── ditto.aar
│   │   └── jni
│   │   │  └── arm64-v8a
│   │   │  │  └── libdittoffi.so
│   │   │  └── armeabi-v7a
│   │   │  │  └── libdittoffi.so
│   │   │  └── x86_64
│   │   │  │  └── libdittoffi.so
│   ├── Metadata.xml
├──  linux-arm64
|   └── libdittoffi.so
├── linux-x64
    └── libdittoffi.so

And a client application referencing the NuGet.

The output .apk will include a libs folder, with an appropriate arm64-v8a folder and the libdittoffi.so file. However, the .so file is the linux slice from libs/linux/linux-aarch64, not the Android one 🙃

During the build proccess, it identifies properly the .so files, this is from the logs:

      NativeLibraries: 
        obj/Debug/net7.0-android/lp/89/jl/jni/armeabi-v7a/libdittoffi.so
        obj/Debug/net7.0-android/lp/89/jl/jni/arm64-v8a/libdittoffi.so
        obj/Debug/net7.0-android/lp/89/jl/jni/x86_64/libdittoffi.so

And I manually checked each to be correct. So in the obj folder, we're good, but when the apk is built, the linux slice weirdly ends up there.

Note: If you simply remove the Linux slices from the NuGet's runtimes folder and rebuild, it copies the right Android lib.

rm -rf ~/.nuget/packages/ditto/4.6.0-rc.1/runtimes/linux-arm64/ 

Steps to Reproduce

1. Clone https://github.com/getditto/template-app-maui-tasks-app/tree/ditto-4.6 (make sure the branch is ditto-4.6)
2. Try to build & run on an ARM64 emulator / real device. Notice the DllNotFoundException:

3. Inspect the output apk. Notice the libdittoffi.so file is there, but it's the wrong one:

Did you find any workaround?

No. Just by removing the linux slice from the NuGet, but this is not exactly a workaround.

rm -rf ~/.nuget/packages/ditto/4.6.0-rc.1/runtimes/linux-arm64/ 

Relevant log output

No response

[busec0]

Slightly similar: #8466, but that is during the build of the NuGet. This is consuming the NuGet.

I assume there's a similar target that copies the wrong thing - or the first thing it finds "appropriate"

[jonathanpeppers]

I think the problem is mixing/matching different ways to redistribute the .so.

Can you do this instead?

runtimes
├── android
│   ├── ditto.aar
│   │   └── only java code in here, if any
├──  android-arm
|   └── libdittoffi.so
├──  android-arm64
|   └── libdittoffi.so
├──  android-x64
|   └── libdittoffi.so
├──  linux-arm64
|   └── libdittoffi.so
├── linux-x64
    └── libdittoffi.so

[busec0]

Thanks for the idea! That may work, given this is how it was before.

I wanted to make use of the .so files bundled in with the .aar "automatically" for Android, definitely not expecting the linux slice to leak into the apk.

[jonathanpeppers]

I think the problem is RID inheritance goes like linux-arm64 -> linux-bionic-arm64 -> android-arm64. So if you don't use the Android one, it will pick the "best" one that "might" work.

I don't think we can fix it here, we'd have to ask the .NET team if it can even be fixed.