Неудовлетворенная ошибка связи в jar OSGI с зависимостью aar, которая включает в себя собственные библиотеки

Question

Я пытаюсь создать jar OSGI, используя maven, который зависит от aar, который включает в себя нативные библиотеки.

Вместо того, чтобы добавить aar в качестве зависимости, я извлекла classes.jar и добавила его в качестве зависимости, а затем добавила общие библиотеки в каталог libs / в корне jar.

Окончательная структура банки выглядит следующим образом.

/org/MyClasses
/org/LibClasses (from aar)
/libs/armeabi-v7a/allNativeFiles (from aar)
/META-INF/MANIFEST.MF

При вызове метода, предоставляемого LibClasses, он вызывает System.loadLibrary('some_so_file'), чтобы загрузить один из файлов .so, но этот вызов вызывает ошибку неудовлетворительной связи, поскольку он не может найти файл по пути.

Вот исключение:

07-22 06: 31: 30.112: E / art (2537): dlopen ("/ data / data / org.ambientdynamix.core / files / felix / felix-cache / bundle14 / version0.0 / bundle.jar-lib / 0 / libs / armeabi-v7a / liboc_logger.so ", RTLD_LAZY) не удалось: dlopen не удалось: не удалось загрузить библиотеку"libgnustl_shared.so", необходимую для"liboc_logger.so"; вызвано библиотекой "libgnustl_shared.so" не найдено

Android ищет файл.so в.../bundle.jar-lib/0/libs/armeabi-v7a, когда файл находится в.../bundle.jar/libs/armeabi-v7a

Конфигурация плагина из POM:

<plugin>
    <groupId>org.apache.felix</groupId>
    <artifactId>maven-bundle-plugin</artifactId>
    <version>2.3.7</version>
    <extensions>true</extensions>
    <!-- configure plugin to generate MANIFEST.MF -->
    <executions>
        <execution>
            <id>bundle-manifest</id>
            <phase>process-classes</phase>
            <goals>
                <goal>manifest</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <!-- configure plugin to support jar packaging -->
        <supportedProjectTypes>
            <supportedProjectType>jar</supportedProjectType>
        </supportedProjectTypes>
        <instructions>
            <Export-Package>
                org.ambientdynamix.contextplugins.iotivity
            </Export-Package>
            <Bundle-NativeCode>libs/armeabi-v7a/libca-interface.so ;
                libs/armeabi-v7a/libconnectivity_abstraction.so ; libs/armeabi-v7a/libgnustl_shared.so
                ;libs/armeabi-v7a/liboc.so ;libs/armeabi-v7a/liboc_logger.so
                ;libs/armeabi-v7a/libocstack-jni.so ;libs/armeabi-v7a/liboctbstack.so ;
                osname=Linux;
                processor=arm_le
            </Bundle-NativeCode>
            <Import-Package>org.ambientdynamix.api.application,
                org.ambientdynamix.api.contextplugin,
                org.ambientdynamix.api.contextplugin.security
            </Import-Package>
            <Bundle-ClassPath>
                .
            </Bundle-ClassPath>
            <Bundle-Activator/>

            <Include-Resource>native=src/main/resources/libs</Include-Resource>

            <DynamicImport-Package>*</DynamicImport-Package>
            <Bundle-SymbolicName>org.ambientdynamix.contextplugins.iotivity</Bundle-SymbolicName>
        </instructions>
    </configuration>
</plugin>

Любой возможный способ исправить это?

Answer 1

Проблема здесь в том, что у вас есть несколько библиотек, которые имеют взаимозависимости. Как правило, одна библиотека - это код JNI, на который ссылается ваш код Java через вызов System.loadLibrary. Тогда эта библиотека будет ссылаться на другую библиотеку. Проблема в том, что процесс VM не знает, как найти эти другие библиотеки, потому что они находятся в папке (например, /data/data/org.ambientdynamix.core/files/felix/felix-cache/bundle14/version0.0/bundle.jar-lib/0/libs/), о котором процесс виртуальной машины не знает и которого нет в LD_LIBRARY_PATH.

Возможное решение этой проблемы - ваш Java-код вызывает System.loadLibrary на каждой из библиотек, но вы должны делать это в правильном порядке. Сначала вы загружаете библиотеки, которые не зависят от других библиотек, затем библиотеки, которые зависят от уже загруженных библиотек, и, наконец, библиотека JNI. Таким образом, зависимости каждой библиотеки уже загружены в процесс виртуальной машины для связи с текущей загружаемой библиотекой.

Это не очень хорошее решение, так как вам нужно загрузить много библиотек и, надеюсь, в графе зависимостей нет циклов.