Java lang unsatisfiedlinkerror android

[SOLVED] UnsatisfiedLinkError Problem on Some Android Devices

I am currently working on an android application which streams radio. (This is the app). I use native decoder library which is called aacdecoder. Everything was fine till app gets crash error on some android devices. It was really annoying. Because app was perfectly plays radio streams almost all devices but Samsung S6 and S6 Edge.

Crash report says that

As you see that crash is saying that it could not load native library. But why?

First of all I checked my structure, If native library .so files located correctly.

Seems everything was okay except this crazy error. Then after some research, I find out that some of android devices has 64-bit processors. This devices generates and check arm64 folder to load native library. That was the problem. Because my project does not have arm64 folder. Here is the solution;

You need to add this filters(abiFilters) to your app module’s build.gradle files. So when your device try to run your app, it will check gradle file and understands that it should not generate any folder and use existing native library resources. Boom. Almost solved. But still there is one more thing.

Add this line to your gradle.properties to use deprecated Ndk.

Finally my app works on S6 and S6 Edge. I mean It works on every devices which has new 64-bit processors.I hope you guys find this blogpost and don’t go crazy like me.

Источник

java.lang.UnsatisfiedLinkError: on 64 bit devices #305

Comments

sw-tt-niravbhavsar commented Sep 1, 2015

I have created demo and found below error on 64-bit devices,
java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file «/data/app/com.pckgname.live-2/base.apk»],nativeLibraryDirectories=[/data/app/com.pckgname.live-2/lib/arm64, /vendor/lib64, /system/lib64]]] couldn’t find «libvinit.so»
at java.lang.Runtime.loadLibrary(Runtime.java:366)
at java.lang.System.loadLibrary(System.java:988)
at io.vov.vitamio.Vitamio.(Vitamio.java:258)
at io.vov.vitamio.LibsChecker.checkVitamioLibs(LibsChecker.java:40)
at com.pckgname.activity.LoadingActivity.onCreate(LoadingActivity.java:221)
at android.app.Activity.performCreate(Activity.java:6500)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1120)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3072)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3218)
at android.app.ActivityThread.access$1000(ActivityThread.java:198)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1676)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:145)
at android.app.ActivityThread.main(ActivityThread.java:6837)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1404)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1199)

Note: Its working fine on 32 bit devices.

Help will be appreciated.

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

solarknight commented Sep 4, 2015

I meet the same error with my project. But when I run the offical demo, everything goes well. Hopes for solution.

solarknight commented Sep 4, 2015

BTW: When I copy the ‘/data/app/io.vov.vitamio.demo-1/lib/libvinit.so’ to my app’s corresponding folder，the error changes to below messages.
java.lang.UnsatisfiedLinkError: dlopen failed: «/data/app/fresh.qunar.com.qtown-2/lib/arm64/libvinit.so» is 32-bit instead of 64-bit
at java.lang.Runtime.loadLibrary(Runtime.java:371)
at java.lang.System.loadLibrary(System.java:989)
at io.vov.vitamio.Vitamio.(Vitamio.java:258)
at io.vov.vitamio.LibsChecker.checkVitamioLibs(LibsChecker.java:40)
at .

sw-tt-niravbhavsar commented Sep 4, 2015

By Reviewing below link, i just give up with this error and handled this error in try/catch and play video using default android video api. Assuming that 64 bit device will have enough codecs that can play almost videos. So for 32 bit devices app will play videos using Vitamio and for 64 bit have to play using default android player.

Still looking forward for solution for Vitamio Library.

solarknight commented Sep 6, 2015

Hi, I searched on the net these days and finally found the solution!
If you are using Android studio, just edit the gradle.properties in the root folder and add android.useDeprecatedNdk=true . Then edit the build.gradle file in your app’s folder, set abiFilters as below:

sw-tt-niravbhavsar commented Sep 8, 2015

Thanks Very much!!

thduc89 commented Oct 28, 2015

Big thanks to ThanosZhou you saved my day! Your solution works perfectly (y)

sungerk commented Nov 21, 2015

I use ThanosZhou’ solution

my build.gradle is：

apply plugin: ‘com.android.library’

android <
compileSdkVersion 23
buildToolsVersion «23.0.2»

dependencies <
compile fileTree(dir: ‘libs’, include: [‘*.jar’])
testCompile ‘junit:junit:4.12’
>

but is still has bug
Process: sunger.org.demo, PID: 23186
java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file «/data/app/sunger.org.demo-1/base.apk»],nativeLibraryDirectories=[/data/app/sunger.org.demo-1/lib/arm64, /vendor/lib64, /system/lib64]]] couldn’t find «libvinit.so»

solarknight commented Nov 23, 2015

Maybe you should use it in your application module, like this

If it still doesn’t work, I have no idea.

ghost commented Nov 23, 2015

this problem Caused by the fresco

I didn’t find a solution

Hanqing commented Dec 5, 2015

Thanks, ThanosZhou. Worked for me.

liuxu0703 commented Dec 7, 2015

i spend a whole day to solve the problem. i browsed this answer before the end of the day.
works for me! can not thank you more.

Источник

Unsatisfied Link Error Class

Definition

Some information relates to prerelease product that may be substantially modified before it’s released. Microsoft makes no warranties, express or implied, with respect to the information provided here.

Thrown if the Java Virtual Machine cannot find an appropriate native-language definition of a method declared native .

Remarks

Portions of this page are modifications based on work created and shared by the Android Open Source Project and used according to terms described in the Creative Commons 2.5 Attribution License.

Constructors

Constructs an UnsatisfiedLinkError with no detail message.

A constructor used when creating managed representations of JNI objects; called by the runtime.

Constructs an UnsatisfiedLinkError with no detail message.

Fields

Properties

Returns the cause of this throwable or null if the cause is nonexistent or unknown.

(Inherited from Throwable) Class (Inherited from Throwable) Handle

The handle to the underlying Android instance.

(Inherited from Throwable) JniIdentityHashCode (Inherited from Throwable) JniPeerMembers LocalizedMessage

Creates a localized description of this throwable.

(Inherited from Throwable) Message

Returns the detail message string of this throwable.

(Inherited from Throwable) PeerReference (Inherited from Throwable) StackTrace (Inherited from Throwable) ThresholdClass

This API supports the Mono for Android infrastructure and is not intended to be used directly from your code.

This API supports the Mono for Android infrastructure and is not intended to be used directly from your code.

Methods

Appends the specified exception to the exceptions that were suppressed in order to deliver this exception.

(Inherited from Throwable) Dispose() (Inherited from Throwable) Dispose(Boolean) (Inherited from Throwable) FillInStackTrace()

Fills in the execution stack trace.

(Inherited from Throwable) GetStackTrace()

Provides programmatic access to the stack trace information printed by #printStackTrace() .

(Inherited from Throwable) GetSuppressed()

Returns an array containing all of the exceptions that were suppressed, typically by the try -with-resources statement, in order to deliver this exception.

(Inherited from Throwable) InitCause(Throwable)

Initializes the cause of this throwable to the specified value.

(Inherited from Throwable) PrintStackTrace()

Prints this throwable and its backtrace to the standard error stream.

(Inherited from Throwable) PrintStackTrace(PrintStream)

Prints this throwable and its backtrace to the standard error stream.

(Inherited from Throwable) PrintStackTrace(PrintWriter)

Prints this throwable and its backtrace to the standard error stream.

(Inherited from Throwable) SetHandle(IntPtr, JniHandleOwnership)

Sets the Handle property.

(Inherited from Throwable) SetStackTrace(StackTraceElement[])

Sets the stack trace elements that will be returned by #getStackTrace() and printed by #printStackTrace() and related methods.

(Inherited from Throwable) ToString() (Inherited from Throwable) UnregisterFromRuntime() (Inherited from Throwable)

Explicit Interface Implementations

IJavaPeerable.Disposed()	(Inherited from Throwable)
IJavaPeerable.DisposeUnlessReferenced()	(Inherited from Throwable)
IJavaPeerable.Finalized()	(Inherited from Throwable)
IJavaPeerable.JniManagedPeerState	(Inherited from Throwable)
IJavaPeerable.SetJniIdentityHashCode(Int32)	(Inherited from Throwable)
IJavaPeerable.SetJniManagedPeerState(JniManagedPeerStates)	(Inherited from Throwable)
IJavaPeerable.SetPeerReference(JniObjectReference)	(Inherited from Throwable)

Extension Methods

Performs an Android runtime-checked type conversion.

Источник

Почему некоторые Android-телефоны заставляют наше приложение бросать java.lang.UnsatisfiedLinkError?

Мы испытываем java.lang.UnsatisfiedLinkError на некоторых телефонах Android, которые используют наше приложение на рынке.

Описание проблемы:

Сбой приложения в строках System.loadLibrary() с помощью java.lang.UnsatisfiedLinkError . java.lang.UnsatisfiedLinkError: Couldn’t load stlport_shared from loader dalvik.system.PathClassLoader[dexPath=/data/app/app_id-2.apk,libraryPath=/data/app-lib/app_id-2]: findLibrary returned null

Решение

На всех наших установках мы запустили специальную диагностику, чтобы проверить, не распакована ли каждая /data/data/app_id/lib папке /data/data/app_id/lib .

На каждом тестовом телефоне у нас есть numberOfLibFiles == 3 и subFilesLarger0 == true . Мы хотели проверить, все ли библиотеки распакованы правильно и они больше, чем 0 байт. Кроме того, мы смотрим на freeSpace чтобы узнать, сколько места на диске доступно. freeSpace соответствует объему памяти, который вы можете найти в настройках -> Приложения в нижней части экрана. Мысль за этим подходом заключалась в том, что, когда на диске недостаточно свободного места, у установщика могут возникнуть проблемы с распаковкой APK.

Сценарий реального мира

Глядя на диагностику, некоторые из устройств там НЕ имеют всех 3 libs в папке /data/data/app_id/lib но имеют много свободного места. Мне интересно, почему сообщение об ошибке ищет /data/app-lib/app_id-2 . Все наши телефоны хранят свои библиотеки в /data/data/app_id/lib . Также System.loadLibrary() должен использовать согласованный путь для установки и загрузки libs? Как я могу узнать, где ОС ищет библиотеки?

Вопрос

Кто-нибудь испытывает проблемы с установкой родных libs? Какая работа прошла успешно? Какой-либо опыт загрузки загружаемых файлов через Интернет, если они не существуют и хранятся вручную? Что может вызвать проблему в первую очередь?

РЕДАКТИРОВАТЬ

У меня теперь также есть пользователь, который сталкивается с этой проблемой после обновления приложения. Предыдущая версия отлично работала на его телефоне, после обновления, по-видимому, отсутствуют собственные библиотеки. Копирование файлов вручную вручную также вызывает проблемы. Он находится на android 4.x с неуправляемым телефоном без специального ПЗУ.

EDIT 2 – Решение

После 2 лет тратить время на эту проблему. Мы придумали решение, которое теперь хорошо работает для нас. Мы открываем его: https://github.com/KeepSafe/ReLinker

У меня такая же проблема, и UnsatisfiedLinkErrors поставляется на всех версиях Android – за последние 6 месяцев для приложения, которое в настоящее время имеет более 90000 активных установок, у меня было:

И пользователи сообщают, что это обычно происходит сразу после обновления приложения. Это приложение, которое получает около 200 – 500 новых пользователей в день.

Думаю, я придумал более простой подход . Я могу узнать, где оригинальный apk моего приложения с помощью этого простого вызова:

Это возвращает что-то вроде «/data/app/com.example.pkgname-3.apk», точное имя файла APK моего приложения. Этот файл является обычным ZIP-файлом, и он читается без использования root. Поэтому, если я поймаю java.lang.UnsatisfiedLinkError, я могу извлечь и скопировать мою собственную библиотеку из папки .apk (zip) lib / armeabi-v7a (или любой другой архитектуры, в которой я включен), в любой каталог, где Я могу читать / писать / выполнять и загружать его с помощью System.load (full_path).

Изменить: похоже, работает

Обновление 1 июля 2014 года с момента выпуска версии моего продукта с кодом, аналогичным приведенному ниже, 23 июня 2014 года, не имело ошибок, которые не удалось устранить из моей родной библиотеки.

Вот код, который я использовал:

К сожалению, если плохое обновление приложения оставляет старую версию родной библиотеки или как-то поврежденную копию, которую мы загрузили с помощью System.loadLibrary («MyNativeLibName»), нет возможности ее выгрузить. Узнав о такой оставшейся не существующей библиотеке, задерживающейся в обычной папке lib, например, вызывая один из наших собственных методов и выясняя, что ее нет (UnsatisfiedLinkError снова), мы могли бы сохранить предпочтение, чтобы избежать вызова стандартной System.loadLibrary ( ) В целом и опираясь на наш собственный код извлечения и загрузки при следующих запусках приложений.

Для полноты, вот класс UnzipUtil, который я скопировал и модифицировал из этой статьи CodeJava UnzipUtility :

EDIT: Поскольку вчера я получил еще один отчет о сбоях в одном из моих приложений, я углубился в этот вопрос и нашел третье очень вероятное объяснение этой проблемы:

Частичное обновление APK от Google Play идет не так

Честно говоря, я не знал об этой функции. Суффикс имени файла APK «-2.apk» сделал меня подозрительным. Он упоминается в сообщении об аварии этого вопроса здесь, и я также могу найти этот суффикс в отчете о сбоях моего клиента.

Я считаю, что «-2.apk» намекает на частичное обновление, которое, вероятно, обеспечивает меньшую дельта для Android-устройств. Эта дельта, по-видимому, не содержит родные библиотеки, когда они не менялись со времени предыдущей версии.

По какой-либо причине функция System.loadLibrary пытается найти собственную библиотеку из частичного обновления (там, где она не существует). Это и недостаток в Android, и в Google Play.

Вот очень актуальный отчет об ошибках с интересным обсуждением подобных наблюдений: https://code.google.com/p/android/issues/detail?id=35962

Похоже, что Jelly Bean может быть испорчен с точки зрения установки и загрузки собственной библиотеки (оба отчета о сбоях, которые приходили, были устройствами Jelly Bean).

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

EDIT (12/19/13): Идея изменить исходный код библиотеки для каждой сборки, к сожалению, не работает. Я попробовал это с одним из моих приложений и получил сообщение о сбое «неудовлетворенной ссылки» от клиента, который все равно обновил.

Неполная установка APK

Это, к сожалению, просто из моей памяти, и я больше не могу найти ссылку. В прошлом году я прочитал статью в блоге об этой неудовлетворенной проблеме ссылок. Автор сказал, что это ошибка в процедуре установки APK.

Когда копирование родных библиотек в их целевой каталог сбой по какой-либо причине (у устройства закончилось место для хранения, возможно, также испорчено разрешение на запись в каталог …), установщик по-прежнему возвращает «успех», как если бы родные библиотеки были просто «дополнительными расширениями» для приложение.

В этом случае единственным обходным решением будет переустановка APK, при этом убедитесь, что для приложения достаточно места для хранения.

Тем не менее, я больше не могу найти ни одного бита Android-бонуса, ни оригинальную статью в блоге, и я искал его совсем немного. Таким образом, это объяснение может быть в сферах мифов и легенд.

Каталог «armeabi-v7a» имеет приоритет над каталогом «armeabi»

В этом обсуждении с ошибкой намекает на «проблему параллелизма» с установленными родными библиотеками, см. Биг-код Android # 9089 .

Если есть каталог «armeabi-v7a», содержащий только одну родную библиотеку, весь каталог для этой архитектуры имеет приоритет над каталогом «armeabi».

Если вы попытаетесь загрузить библиотеку, которая присутствует только в «armeabi», вы получите UnsatisfiedLinkException. Кстати, эта ошибка отмечена как «работает по назначению».

Возможное обходное решение

В любом случае: я нашел интересный ответ на аналогичный вопрос здесь, на SO. Все сводится к упаковыванию всех родных библиотек в качестве исходных ресурсов для вашего APK, и копирование на первом приложении запускает правильные для текущей архитектуры процессора (приватную) файловую систему. Используйте System.load с полными файловыми путями для загрузки этих библиотек.

Однако это обходное решение имеет недостаток: поскольку родные библиотеки будут находиться в качестве ресурсов в APK, Google Play не сможет их найти и создать фильтры устройств для обязательных архитектур процессоров. Его можно было бы обойти, поместив «манекены» родных библиотек в папку lib для всех целевых архитектур.

В целом я считаю, что эта проблема должна быть надлежащим образом передана Google. Кажется, что оба Jelly Bean и Google Play испорчены.

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

Android начал упаковывать свои библиотеки в / data / app-lib // когда-то вокруг Ice Cream Sandwich или Jellybean, я не помню, какой.

Вы строите и распространяете как «руку», так и «armv7a»? Мое лучшее предположение, что вы строились только для одной из архитектур, и вы тестируете другую.

После того, как я сам это сделал и немного изучил (ака-роуглинг), я смог решить проблему, настроив более низкий SDK.

У меня был compileSdkVersion установлен на 20 (который работал в 4.4)

MinSdkVersion 20 targetSdkVersion 20

Как только я изменил их на 18 (я был в состоянии сделать это без каких-либо больших последствий), я смог запустить приложение без проблем на Lollipop.

Надеюсь, что это поможет – это заставляло меня остывать в течение нескольких дней.

Источник