Удаленная двоичная общая библиотека nativeLibrary не извлекается

Поэтому я предоставляю двоичные файлы в виде удаленной зависимости, упакованной как aar. Библиотека Android имеет файлы libMyLibrary.so в каталоге src/main/jniLibs/<abi>/, поэтому при сборке и развертывании они находятся в каталоге jni aar. Единственное, что есть в библиотеке, это файл манифеста, не содержащий ничего, кроме имени пакета package.name.A.

импорт package.name.A в качестве зависимости от другого проекта, different.package.B, приводит к тому, что все правильно упаковано в сборку, а общие библиотеки содержатся в lib/<abi>/libMyLibrary.so apk для отладки/релиза. Однако при установке они не извлекаются в собственный каталог приложения.

Фактически установленный apk показывает, что файлы .so находятся в apk ZipFile(context.applicationInfo.sourceDir).getEntry("lib/${Build.SUPPORTED_ABIS[0]}/libMyLibrary.so"), и я могу извлечь его таким образом (только не в nativeDir приложения, исключение безопасности). И System.mapLibraryName("MyLibrary") возвращает libMyLibrary.so...

Они были извлечены до того, как я предоставил их как удаленную зависимость, и содержались в каталоге src/main/jniLibs/<abi>/ приложения. Теперь единственный способ получить его для извлечения при предоставлении их в качестве удаленной зависимости через aar — это включить в манифест android:extractNativeLibs="true".

Как я могу заставить вещи правильно извлекаться без необходимости объявлять это в моем манифесте?

Есть ли что-то, что мне нужно объявить в манифесте удаленной библиотеки, чтобы после слияния Android знал об общей нативной библиотеке и правильно извлекал? Нужен ли мне файл Android.mk?

Руководство/помощь будут очень признательны!


android android-native-library
person 05nelsonm    schedule 09.07.2020    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Этот ответ содержит довольно подробное описание использования функции extractNativeLibs и того, как вам нужно изменить процесс упаковки/развертывания, чтобы оставить для него значение false: https://stackoverflow.com/a/44704840/13924538. Вкратце: ваш APK будет больше по размеру, но загружается быстрее и занимает меньше места на телефоне, потому что его не нужно распаковывать.

Документация для extractNativeLibs находится здесь, которая также дает некоторое представление: https://developer.android.com/guide/topics/manifest/application-element#extractNativeLibs

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

Вот документация по инструменту zipalign, который можно запустить вручную или включить в сценарий оболочки в процесс развертывания (предварительной подписи): https://developer.android.com/studio/command-line/zipalign

zipalign [-f] [-v] 4 infile.apk outfile.apk # f overwrites outfile.apk, v for verbose, 4 byte is the only allowed value that does anything for alignment

или, в gradle, до шага (ов) подписания:

task zipAlign {
   workingDir "<my apk output dir>"
   commandLine "zipalign -f -v 4 infile.apk outfile.apk"
}
person lmgtfy    schedule 13.07.2020
comment
Хотя эта ссылка может ответить на вопрос, лучше включить сюда основные части ответа и предоставить ссылку для справки. Ответы, содержащие только ссылки, могут стать недействительными, если связанная страница изменится. – Из обзора - person Boken; 14.07.2020
comment
Итак, после дальнейшего изучения, aar создается со сжатыми файлами .so. Есть ли способ не сжимать собственные библиотеки, чтобы при их импорте different.package.B они были необработанными, несжатыми файлами? - person 05nelsonm; 17.07.2020

arrow_upward
0
arrow_downward

Добавление в different.package.B блок build.gradle android

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
}

решил мою проблему. Файлы *.so, предоставленные через aar, теперь извлекаются в собственный каталог приложения.

см.: https://github.com/05nelsonm/TOPL-Android-TorBinary

person 05nelsonm    schedule 19.07.2020