Android unsatisfiedlinkerror dlopen failed

dlopen failed: cannot locate symbol (java.lang.UnsatisfiedLinkError) #1185

Comments

Gibson85 commented Feb 8, 2020 •

Hi, have problems linking multiple shared libs (with circular dependencies) against my native android app/lib.

My CMake looks like this:

I also checked the shared lib. The «missing» symbol is still existing. If I open the shared lib per dlopen on Linux.

. I don’t get a error message. So why android can’t link these libs? Any ideas what I could check to find the reason?

The text was updated successfully, but these errors were encountered:

alexcohn commented Feb 9, 2020 •

Try to load the library that you doubt about in Android directly from Java, i.e.

The diagnostic may help you understand what went wrong.

Gibson85 commented Feb 9, 2020

Thanks for your quick response. I did so using the «hello-libs» NDK example, but it gives me the same error:

Anything else I could try?

Gibson85 commented Feb 9, 2020

Is there a way I could extract the libs packed into the apk file to see if the symbol was maybe stripped away later? There is an apk inspector but there seems not to be an export option. Or maybe it could be a name mangling issue? The symbol that was not found is a class member function. I checked the existing of the function symbol with (readelf -Ws libMyLibB.so).

Gibson85 commented Feb 9, 2020 •

Ah maybe I found the reason.
The libMyLibB.so in the «build/intermediates/stripped_native_libs» directory contains the function symbol but it is declared as «NOTYPE» .

. while the function symbol of the original lib looks like this:

Could this be an error caused by the stripping?

alexcohn commented Feb 10, 2020

The libraries can be extracted from an APK with simple unzip .

But I am afraid I don’t understand what you found about libMyLibB.so. Please try to load this library alone, because now your findings may be obscured by the other libraries involved.

And I hope the missing symbol has some meaningful characters where you show dots.

Gibson85 commented Feb 10, 2020 •

It’s getting crazier and crazier.
Today I compiled everything again and suddently without having changed anything all linking problems are gone. I also unzipped the generated apk file’s libs and the missing symbol was existing (now). After that I run my app once, but sadly still the log message in my «ANativeActivity_onCreate» function did not appear in logcat (I am not using android_native_app_glue). Then I did a second run and suddently the message appeared! But after the third and forth run not again.

So my guess was that at the end the code was executed well all the time, but maybe the log message was not logged properly by Android Studio. After having run my app for about 100 times now I can say that the log messages appeared for only about 3 times. But you can imagine that this is completely unacceptable. Even break points are not getting hit then at all. There’s something completely strange in that very early program startup phase. All my app is doing for now is printing the following log message:

One other thing I recognized was that when having copied my latest compiled libs to the android app directory even after a build or «Refresh linked C++ Projects» the apk was not updated at all. So at least now I now I always have to do a complete rebuild.

So what I would like to know:

1.) Is there a way to ensure that the log message gets logged? Is there maybe a flush function for that purpose? I guess «__android_log_print» will buffer the messages on first step.

2.) If I set the «android:hasCode=false» property in my manifest file I see a.

. message in my logcat with an obvious empty path. What does that mean?

3.) Sometimes I see the following log messages in my locat also:

But it’s luck if it is logged or not. Maybe there are timing issues in this early program phase?

Gibson85 commented Feb 10, 2020

Here’s a full thread dump after startup. Can you see something unusual here?

enh-google commented Feb 11, 2020

Regarding breakpoints at this very early stage – they aren’t reliable. We put a loop with sleep that polls some global variable before the first breakpoint that we set. Then we start the app, suspend it when it finally gets connected to debugger, change the global variable to false , and resume the execution.

i asked the Studio folks about this, and it’s news to them. (they also couldn’t reproduce with a trivial example.) if you have repro steps, file a bug with them (https://developer.android.com/studio/report-bugs). if you let me know the bug id i’ll make sure the right folks get to see it.

alexcohn commented Feb 11, 2020

@enh-google I don’t have a working example of unreliable breakpoints at hand, I am no longer working for that company. And quite possibly, this happened only on some devices, and not with the latest versions of AS and SDK.

My comment was not a form of bug report. My point was that if AS doesn’t show something in logcat window or stop at some breakpoint, it does not necessarily mean that this code is not executed.

alexcohn commented Feb 11, 2020

Here’s a full thread dump after startup. Can you see something unusual here?

why should there be anything unusual?

Gibson85 commented Feb 11, 2020 •

@enh-google
I am fighting with these annoying problems since weeks now.
So do me a favour. Take your android studio folks and kick them into their ass from me.
I can’t believe what a saw now.

I thought the debugger would be broken completely, because the lines (e.g. at NativeActivity.java) I had put the breakpoints on, had been greyed out because there would be no executable code. «Luckily» I only found these greyed out lines. Now I did a new try and there are really lines you can put a «working» breakpoint on. By the way there are IDEs that will move the breakpoint to the next line that can be executed. But thats not the problem at all. I placed now three breakpoints that not had been greyed out and started debugging. All these three breakpoints have a checkmark also. But the first breakpoint.

NativeActivity.java line 160:

. never gets hit at all.
Ok, but there are two other chances left. So lets hope the best.
The second breakpoint at line 167.

. really gets hit.
Originally I was interested in line 170 and the return value, but as said before the breakpoint was greyed out. So finally the third breakpoint at line 176 was hit also and showed that the «mNativeHandle» was zero. Ok, that was unexpected to me. Then on next line 177 the «UnsatisfiedLinkError» exception was thrown claiming it couldn’t find my app’s shared lib. Fun part. This exception never was logged in logcat and even crazier although an exception was thrown the next line 180

was executed nevertheless.

And that’s not all.

I have to control myself very much now.
In this fuc. logcat window now all these log messages I wanted to see since weeks appeared. Most probably because your shitty Android is completely broken with maybe heavy multithreading or other timing problems. If I step through the code with the debugger all these messages appear now but not by running it!

BUT THATS STILL NOT ALL!

Before I started these debugger sessions I commented out this fuc. «ANativeActivity_onCreate» function and even veryfied by readelf that there is not a single «ANativeActivity_onCreate» symbol at any lib I was linking to. I also verified that I had activated the linker flags that no missing symbols are allowed. In addition I did a project cleanup, refreshed linked C++ projects and did a complete rebuild not only once I did it twice.

BUT STILL I WAS GETTING THESE LOG MESSAGES IN THE ANDROID STUDIOS LOCAT WINDOW FROM A FUNCTION NOT BEING EXISTEND ANYMORE.

Finally I removed all android build files manually and believe it or not now I got what I would have expected before:

But again. The above log message only appears when stepping through the code with the debugger. If you «Run» the code there is nothing!

THERE IS NOTHING!

I hope this is trivial enough for you and your android folks to find out the bugs.
And I hope this will be fixed soon. And by the way. If that behavior gets proven by you folks,
I think the least you could do to me is paying a monthly salary as compensation :D.

I wish I would not have get confused by the greyed out breakpoints respectively by breakpoints not getting hit at all. That could have saved me a lot of time because I was completely blind on «debugging».

To be honest. Please fix these annoying problems. Please!

Источник

Сбой Android M java.lang.UnsatisfiedLinkError: сбой dlopen:

Мое приложение для Android дает сбой и выдает следующее сообщение об ошибке:

java.lang.UnsatisfiedLinkError: ошибка dlopen: не удается найти

7 ответов

Это связано с переходом Android 6.0 (Marshmallow) с OpenSSL на BoringSSL.

Ваше исключение возникает в коде указанной библиотеки. Обратитесь к поставщику за исправлением или вручную включите библиотеки OpenSSL, чтобы избежать проблемы.

Вылет происходит из-за следующего факта, который был изменен в Android M

«В предыдущих версиях Android, если ваше приложение запрашивало у системы загрузку общей библиотеки с перемещением текста, система отображала предупреждение, но все же позволяла загрузку библиотеки. Начиная с этого выпуска, система отклоняет эту библиотеку, если цель вашего приложения Версия SDK — 23 или выше. Чтобы помочь вам определить, не удалось ли загрузить библиотеку, ваше приложение должно регистрировать сбой dlopen (3) и включать текст описания проблемы, возвращаемый вызовом dlerror (3). Чтобы узнать больше об обработке текста переезд, см. это руководство «

Для получения дополнительных сведений перейдите по этой ссылке

Прежде всего я должен сказать, что я не понимаю всей специфики этой темы, но я постараюсь провести вас по пути, который мне помог.

Я видел, что эта проблема возникает только при использовании целевой версии как 23. Прочитав другие сообщения, было легко определить, что это произошло с библиотеками, скомпилированными с помощью старых инструментов ndk (ndk-build, если быть более конкретным, но я не знаю точно, этот инструмент появился позже для удовлетворения новых потребностей).

Это случилось со мной, когда я использовал libiconv, зависимость от проекта ZBar. Я подумал, что перекомпиляция поможет, и это помогло. Я использовал инструмент ndk-build для перекомпиляции библиотек zbar и iconv.

Надеюсь, этого хватит.

В качестве простого ответа вам просто нужно настроить таргетинг на android 22 sdk вместо android 23 в конфигурации сборки. Например, с использованием gradle:

Попробуйте изменить targetSdkVersion в build.gradle на 22 и APP_PLATFORM := android-22 в application.mk . Это сработало в моей среде.

Не уверен, поможет ли это кому-то или нет, но у меня была аналогичная ошибка, и вот как она была исправлена ​​для меня. Моя проблема заключалась в том, что у меня был библиотечный модуль, в котором я использовал файлы sqlchiper .so, эти файлы .so были в моем модуле приложения, но зависимость от реализации этого sqlitechiper была в модуле библиотеки build.gradle.

Но мы решили преобразовать модуль библиотеки как файл .aar и добавить его в модуль приложения в качестве зависимости, и именно тогда у меня произошел сбой java.lang.UnsatisfiedLinkError: dlopen failed: . И я использовал sqlitechiper.jar на уровне приложения, поэтому у меня также не было ошибок времени компиляции.

Добавление зависимости на уровне приложения и удаление зависимости файла sqlitechiper.jar от уровня приложения устранило проблему.

После прочтения нескольких ответов stackoverflow я понял, что зависимости, которые добавляются в файлы .aar, не включаются транзитивно в уровень приложения, если ur добавляет файл .aar напрямую, если ur добавляет его как зависимость с помощью compile / api / implementation, тогда они будут добавлены переходно.

Я мог бы заставить его работать в более поздних версиях SdkVersions, добавив следующую строку в NDK в скрипте gradle

Источник

java.lang.UnsatisfiedLinkError: dlopen failed: library «libavutil.so.54» not found #92

Comments

vxhviet commented Mar 30, 2016

Please @wseemann could you elaborate how to get FFmpegMediaMetadataRetriever:1.0.5 working with Android Studio 1.5.1?

What I’ve tried so far:
1.
Add the following maven dependency to your project’s build.gradle file:

result in:
java.lang.UnsatisfiedLinkError: dlopen failed: library «libavutil.so.54» not found

when calling:
FFmpegMediaMetadataRetriever retriever = new FFmpegMediaMetadataRetriever();

Add the following maven dependency to your project’s build.gradle file:

Add all-fmmr.aar to project’s libs folder and change:

result in:
Warning:Project app: Only Jar-type local dependencies are supported. Cannot handle: . \app\libs\all-fmmr.aar

Same stuffs as above but instead rename all-fmmr.aar to all-fmmr.jar and revert include: [‘*.aar’] back to include: [‘*.jar’] result in:
Error:duplicate files during packaging of APK . \app\build\outputs\apk\app-debug-unaligned.apk Path in archive: AndroidManifest.xml

Same stuff as above but add this to the build.gradle :

and getting java.lang.UnsatisfiedLinkError: dlopen failed: library «libavutil.so.54» not found again.

I guess Android Studio still haven’t recognize the libs so I try File>New>New Module. >Import .JAR/.AAR Package>all-fmmr.aar and then add all-fmmr module as module dependency to app module and get:
Error:Execution failed for task ‘:app:transformClassesWithDexForDebug’. com.android.build.api.transform.TransformException: com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process ‘command ‘C:\Program Files\Java\jdk1.7.0_79\bin\java.exe» finished with non-zero exit value 2

So I tried this solution and get:
Error:Execution failed for task ‘:app:transformClassesWithJarMergingForDebug’. com.android.build.api.transform.TransformException: java.util.zip.ZipException: duplicate entry: wseemann/media/BuildConfig.class

I actually did tried ./gradlew clean after that but I guess you all must be so bored with this stuff until now so I won’t bother writing it down.

Long story short, is there a clearer instruction to get this lib working in Android Studio?

The text was updated successfully, but these errors were encountered:

Источник