Связывание разделяемой библиотеки libGLES_mali.so вызывает сбой dlopen: библиотека «android.hardware ... @ 1.0.so» не найдена в Android> = 7.0 - PullRequest
0 голосов
/ 30 января 2019

Начиная с Android 7.0, больше невозможно связываться с общей библиотекой, отличной от ndk (см. Приложения NDK, связанные с библиотеками платформы ).

Один из возможных обходных путей заключается во включении библиотеки в apk (см. Обновление приложения ).

Библиотека, с которой вы пытаетесь связать, может зависеть от других не-ndk библиотек.В этом случае вы должны также включить эти библиотеки.

В моем случае я разрабатывал приложение, которое использует OpenCL.На устройствах ARM библиотека с правильными символами - libGLES_mali.so.Приложение отлично работает на устройствах с Android <7.0, но вылетает на устройствах с Android> = 7.0.Ошибка, которую я могу прочитать в logcat:

java.lang.UnsatisfiedLinkError: dlopen failed: library "android.hardware.graphics.common@1.0.so" not found

Используя команду

readelf -d libGLES_mali.so | grep NEEDED

Я могу прочитать названия библиотек, от которых зависит libGLES_mali.so и, как и ожидалось, android.hardware.graphics.common@1.0.so среди них:

0x0000000000000001 (NEEDED)             Shared library: [android.hardware.graphics.common@1.0.so]
 0x0000000000000001 (NEEDED)             Shared library: [liblog.so]
 0x0000000000000001 (NEEDED)             Shared library: [libnativewindow.so]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc++.so]
 0x0000000000000001 (NEEDED)             Shared library: [libutils.so]
 0x0000000000000001 (NEEDED)             Shared library: [libcutils.so]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so]

Я пытался включить вышеупомянутую библиотеку в apk, но я получаю ту же ошибку.Странно то, что библиотека является частью VNDK-SP (см. SP-HAL ), и поэтому я понимаю, что частные библиотеки могут зависеть от нее свободно.

Есть предложения?

РЕДАКТИРОВАТЬ 31/01/2019: все протестированные устройства на Android> = 7.0 были Huawei.Может ли это быть проблема, связанная с продавцом?

1 Ответ

0 голосов
/ 01 февраля 2019

Комментарий Алекса Кона был верным.Чтобы решить проблему, я сделал следующее:

1) Переименован в android.hardware.graphics.common@1.0.so в libfoo.so

2) Добавлен libfoo.so в CMakeLists.txt, как это:

add_library( foo
         SHARED
         IMPORTED )
set_target_properties( foo
         PROPERTIES IMPORTED_LOCATION
         ${PROJECT_SOURCE_DIR}/src/main/jniLibs/${ANDROID_ABI}/libfoo.so )

3) MyLibrary с привязкой к цели, который содержит вызовы OpenCL, против libfoo.so (и, конечно, libGLES_mali.so)

target_link_libraries (MyLibrary GLES_mali foo)

4) Загрузил libfoo.so как можно скорее.Для этого я создал статический метод в своей функции MainActivity, который я вызываю, как только приложение входит в onCreate ().

private static void loadLibrary() {
    System.loadLibrary("foo");
}

@Override
protected void onCreate(Bundle savedInstanceState) {
    loadLibrary();
    ...
}  

В этот момент приложение вылетает, жалуясь на то, что не может найти некоторые библиотеки.Используя команду readelf:

./readelf -d /Users/rodolforocco/AndroidProjects/OvermindClient/app/libs/arm64-v8a/android-27/libfoo.so | grep NEEDED

Я смог увидеть, что это действительно были библиотеки, от которых зависел libfoo.so.Эти библиотеки также зависели от других библиотек, которые не могли быть найдены.Я скопировал их все из папки / system / lib64 / на моем устройстве в папку $ {PROJECT_SOURCE_DIR} / src / main / jniLibs / $ {ANDROID_ABI} /, где находился libfoo.so.

5) Наконец, как и прежде, я загрузил MyLibrary, когда мне это было нужно.

Приложение больше не падает и работает как задумано.Большое спасибо!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...