This is an incredibly, incredibly weird so I'll need pointers from the team.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/android-ndk/f3b1db5a-2827-40ea-acfb-dad4d32e5e44n%40googlegroups.com.
--
you could read the file '/proc/self/maps' and see if the libraries you expect to be there are there... it's possible that different libraries get loaded before your library when debug is enabled, that aren't loaded when debug is disabled.If your library requires another library in the lib folder, dlopen has previously not wanted to load those, and I had to manually load the dependencies first. And unfortunately while it is possible to get the error about the required library, if it's loaded after the fact, and the original library attempted again, the library continues to return its original error message.
Is this a new project? Or are you just updating something existing?--On Tue, Dec 17, 2024 at 2:02 PM Lanre Olokoba <olokob...@gmail.com> wrote:I'm facing an incredibly weird issue. I am building an Android app where I embed shared libraries into the APK, and try to load them into the process at runtime using `dlopen`. Some observations:
- Testing on Android 14 (Galaxy S21), NDK 26.3.11579264 and 26.3.11579264.
- I have confirmed that the output APK always contains my library in the ABI-specific `libs` folder:
- I renamed the shared library file, so it differs from the SONAME of the library. I always call `dlopen("filename.so").
- As I mentioned above, I've been able to isolate calls to `dlopen` failing to setting `android:debuggable="false"` when building my app. When this happens, here is the output of `dlerror`:
```dlopen failed: library "24138ad4b81d96ebb12fcbaf9bf5d2610993506ed7689d12fd4f64c74b640a49.so" not found```--
- I assumed that this might have something to do with apps having to declare their native libraries with `<uses-native-library>`, but:
- Declaring the library in the `AndroidManifest.xml` fails with the same error above.
- Compiling with target SDK version 30 also fails, same error.
- I can't enable logging in the linker because...`android:debuggable="false"`
This is an incredibly, incredibly weird so I'll need pointers from the team.
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/android-ndk/f3b1db5a-2827-40ea-acfb-dad4d32e5e44n%40googlegroups.com.
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/android-ndk/CAA2GJqXm7H-h7Fcicq675vf%3DaYUz-d_bPfX_NE2H38JFnQie%3Dg%40mail.gmail.com.
Oh, and here are the verbose logs of the successful call to `dlopen` when `android:debuggable="true"`:
To view this discussion visit https://groups.google.com/d/msgid/android-ndk/3413ae60-35d0-4635-be59-05762ca5813an%40googlegroups.com.
I MyApp: Custom load hnd: 0x0 err: dlopen failed: library "/data/app/~~VmvIk2_XHMBwf1KdpnKAgg==/app.videokit.videokit-ANvF2125nH5TjSnqIJnkcA==/base.apk!/lib/arm64-v8a/libSomeLibrary.so" not found
```
I also made an observation that might or might not be relevant: when the APK is bundled, native libraries for the `arm64-v8a` ABI are bundled in `lib/arm64-v8a`. But at runtime, when you get the path of the current library using `dladdr`, the relative path is `lib/arm64`. I wonder why.I think I found the cause. I reproduced my initial setup, and once the call to `dlopen` failed, checked the contents of `lib/arm64` using the `ls` command in `adb shell`. The library was missing, which sort of vindicates the linker.Adding a `lib` prefix before the name of the library fixes the issue. I confirmed that once I added the `lib` prefix, the library was present in the `lib/arm64` folder as expected, and the call to `dlopen` succeeded.
To view this discussion visit https://groups.google.com/d/msgid/android-ndk/4090ea4e-253f-4388-848c-d3ae58dff40dn%40googlegroups.com.
Looking at the linker source code, there isn't any obvious branching that would cause this to occur when debuggable is set to false.
From tracing control flow, my guess is that the call to `open_library_on_paths` in the `open_library` function is what fails. If this hypothesis is correct, then `ns->get_default_library_paths()` differs depending on the value of `android:debuggable`.Is there any documentation about the internal differences caused by `android:debuggable`, especially as it relates to the linker or linker configuration for the whole application?
To view this discussion visit https://groups.google.com/d/msgid/android-ndk/b1fe5675-6785-42cc-a0a7-35a7fb3e72a5n%40googlegroups.com.