Android sigsegv segv maperr

Русские Блоги

GSEGV (SEGV_MAPERR) исключение ошибки Android и ее решение

Это лучший способ учиться на ошибках, чтобы понять важные моменты и записать их.

Информация об исключении

SIGSEGV обычно генерируется операционной системой, но пользователи с соответствующими разрешениями могут использовать системный вызов kill или команду kill (программа пользовательского уровня или встроенная команда оболочки) для отправки сигнала процессу, когда это необходимо.

Стек задач ошибки исключения:

причины проблемы

Конфигурация ndk в build.gradle, я добавил только одну архитектуру, поэтому это вызвало исключение

решение:

У всех разные проблемы, поэтому и решения разные, вот только справка

1. Архитектура ЦП = ABI = соответствующая библиотека SO;
2. При загрузке библиотеки SO необходимо загрузить соответствующий тип библиотеки SO;
3. Постарайтесь обеспечить поддержку библиотеки SO для всех типов ЦП платформы;

Библиотека SO в проекте Android

Статья о библиотеке so воспроизведена с https://segmentfault.com/a/1190000005646078

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

Использовать в проекте библиотеку SO очень просто.Загрузите библиотеку SO на SD-картуВ статье также упоминается, что вам нужно скопировать только ту библиотеку SO, которую вам нужно использовать.jniLibs (или библиотеки в проекте Eclipse), А затем вызовите код JAVASystem.loadLibrary(«xxx»)Загрузите соответствующую библиотеку SO, вы можете использовать оператор JNI для вызова собственного метода в библиотеке SO.

Однако некоторые студенты заметили, что файлы библиотеки SO можно переименовывать по желанию, но путь к папке не может быть изменен произвольно. Однако такие имена папок, как «armeabi», «armeabi-v7a» и «x86» имеют строгие требования. Имеет ли имя какое-нибудь значение?

Тип библиотеки SO и тип архитектуры процессора

Причина проста: устройствам с разной архитектурой процессора требуются разные типы SO-библиотек (вы можете догадаться по имени файла ╮ (￣ ▽ ￣ «) ╭).

Помню, когда я еще учился в школе, когда я упомянул процессор ARM, учитель сказал, что в будущем ЦП мобильного устройства в основном будет типа ARM. Учитель никогда меня не обманул: ранняя система Android поддерживала почти только архитектуру ЦП ARM, но теперь она поддерживает как минимум следующие семь различных архитектур ЦП: ARMv5, ARMv7, x86, MIPS, ARMv8, MIPS64 и x86_64. Каждый тип ЦП соответствует ABI (двоичный интерфейс приложения). «Armeabi» перед папкой «armeabi-v7a» относится к типу ABI ARM, а задняя «v7a» относится к ARMv7. Имена папок библиотек SO, соответствующих этим 7 типам ЦП, следующие: armeabi, armeabi-v7a, x86, mips, arm64-v8a, mips64, x86_64.

Когда разные типы мобильных устройств запускают APP, им необходимо загрузить поддерживаемую ими библиотеку SO, иначе это будет GG. ПроходитьBuild.SUPPORTED_ABISМы можем определить ABI, поддерживаемый текущим устройством, но в целом разработчикам не нужно определять ABI самостоятельно. Когда система Android устанавливает APK, она не установит все файлы библиотеки SO в APK, но будет поддерживать его в соответствии с текущим типом процессора. ABI, скопируйте наиболее подходящую библиотеку SO из APK и сохраните ее во внутреннем хранилище приложения.libsНиже. (Общая ситуация здесь из-за того, что есть исключения. Например, когда мы динамически загружаем внешнюю библиотеку SO, нам нужно самостоятельно судить о типе ABI.)

Архитектура ЦП = соответствующий параметр ABI = соответствующий тип библиотеки SO

На этом этапе мы обнаружили, что логика использования библиотеки SO относительно проста, но логика загрузки библиотеки SO в систему Android по-прежнему оставляет нам некоторые проблемы.

Некоторые проблемы, на которые следует обратить внимание при использовании библиотеки SO

1. Не помещайте библиотеку SO в неправильное место.

Библиотека SO фактически загружается, когда приложение работает, то есть приложение знает о существовании файла библиотеки SO только во время его работы, который не может пройти проверку статического кода или проверить, является ли файл библиотеки SO нормальным при компиляции приложения. Следовательно, разработка под Android предъявляет строгие требования к пути хранения библиотеки SO.

При использовании библиотеки SO, помимо имен папок, таких как «armeabi-v7a», которые должны строго соответствовать правилам, библиотека SO должна быть помещена в папку проекта в соответствии с установленной процедурой. Вот краткое изложение:

Проект Android Studio размещенjniLibs/xxxabiВ каталоге (конечно, вы также можете указать его самостоятельно, установив свойство jniLibs.srcDir в файле build.gradle);

Проект Eclipse размещенlibs/xxxabiВ каталоге (это также каталог по умолчанию для создания библиотеки SO с помощью команды ndk-build);

aar находится в пакете зависимостейjni/ABIВ каталоге (библиотека SO будет автоматически включена в эталонный сжатый пакет AAR в APK);

В окончательно созданном APK-файле инвентарь SO находится вlib/xxxabiВ каталоге (то есть, независимо от того, какой метод вы используете для сборки, если путь к библиотеке SO в пакете APK правильный, проблем нет);

После установки через PackageManager в системах меньше, чем Android 5.0, библиотека SO находится в приложенииnativeLibraryPathВ каталоге; в системах выше или равных Android 5.0 библиотека SO находится в приложенииnativeLibraryRootDir/CPU_ARCHВ каталоге;

Теперь, когда он здесь, кстати, когда я использовал Android Studio 1.5 для создания APK, я обнаружил, что плагин Gradle по умолчанию будет упаковывать только файлы библиотеки SO в jniLibs модуля типа приложения, но не библиотеку SO зависимого пакета aar. Следовательно, файлы библиотеки SO в окончательном APK-файле будут отсутствовать. Временное решение — поместить все библиотеки SO в модуль приложения (это, очевидно, не очень хорошее решение), я не знаю, является ли это ОШИБКА Studio, решение моего коллеги — увеличить зависимость от aar путем изменения плагина Gradle. Поддержка пакетов библиотеки SO (GitHub имеет проект внешнего модуля Gradle с открытым исходным кодом, разработанный на языках Java и Groovy).

2. Предоставьте лучшую библиотеку SO, поддерживаемую ЦП, насколько это возможно.

Когда приложение установлено на устройстве, будет установлена ​​только библиотека SO, соответствующая архитектуре ЦП, поддерживаемой устройством. Однако иногда устройство поддерживает более одного типа библиотеки SO. Например, большинство устройств X86 не только поддерживают библиотеку SO типа X86, но также совместимы с библиотекой SO типа ARM (в настоящее время большинство приложений на рынке приложений адаптируются только к типу ARM. Если устройство типа X86 несовместимо с библиотекой SO типа ARM, оно, вероятно, отрыгнет).

Таким образом, если ваш APK адаптируется только к библиотеке SO типа ARM, он все равно может работать на устройствах типа X86 (например, планшетах ASUS) в совместимом режиме, но это не означает, что вам не нужно адаптироваться к SO типа X86. Библиотека, потому что процессор X86 использует режим совместимости для запуска библиотеки SO типа ARM, она будет аномально зависать (попробуйте вспомнить ощущение использования эмулятора AVD на ПК, когда вы начали изучать разработку Android несколько лет назад).

3. Обратите внимание на скомпилированную версию библиотеки SO

Помимо использования библиотеки SO правильного типа процессора, следует также обратить внимание на вопрос о скомпилированной версии библиотеки SO. Хотя текущая Android Studio поддерживает прямую компиляцию библиотеки SO в проекте, чаще мы предпочитаем использовать предварительно скомпилированную библиотеку SO. В настоящее время мы должны обращать внимание. При компиляции APK мы всегда надеемся использовать последнюю версию. Инструменты сборки для компиляции, потому что последняя версия Android SDK поможет нам добиться максимальной обратной совместимости.

Но это другое дело для компиляции библиотек SO, потому что платформа NDK совместима не снизу, а снизу вверх. Образец NDK версии, соответствующей minSdkVersion приложения, следует использовать для компиляции файла библиотеки SO. Если используется слишком высокая версия NDK, это может привести к снижению производительности приложения или возникновению некоторых связанных с библиотекой SO исключений времени выполнения, таких как «UnsatisfiedLinkError», dlopen: failed «и другие типы сбоев.

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

4. По возможности предоставьте соответствующую библиотеку SO для каждого типа процессора.

Например, иногда из-за бизнес-потребностей нашему приложению не требуется поддерживать устройства AMR64, но это не означает, что нам не нужно компилировать библиотеку SO, соответствующую ARM64. Например, наше приложение поддерживает только архитектуры armeabi-v7a и x86, а затем наше приложение использует стороннюю библиотеку, и эта библиотека обеспечивает поддержку большего количества типов архитектур ЦП, таких как AMR64. При создании APK эти ARM64 Библиотека SO по-прежнему будет упакована в APK, а это означает, что в нашей собственной библиотеке SO нет соответствующей библиотеки SO ARM64, а в сторонней библиотеке есть. В настоящее время, когда некоторые устройства ARM64 устанавливают APK, они обнаруживают, что наш APK содержит библиотеку ARM64 SO, которая будет ошибочно думать, что наше приложение уже выполнило работу по адаптации AMR64, поэтому мы выберем установку только типа ARM64 в APK. Это приведет к неправильной установке библиотеки SO нашего собственного проекта (хотя библиотеки SO типа armeabi-v7a и x86 существуют в пакете APK).

В настоящее время правильный подход — предоставить поддержку AMR64 для нашей собственной библиотеки SO или не упаковывать библиотеку ARM64 SO стороннего проекта библиотеки. При использовании второго решения вы можете удалить папки ABI в APK, которые не нуждаются в поддержке, а затем переупаковать их. В Android Studio вы можете указать требуемый тип библиотеки SO с помощью следующих методов построения.

Следует отметить, что если наш проект является проектом SDK, нам лучше обеспечить полную поддержку библиотеки SO типов платформы, потому что количество типов ЦП устройств, которые может поддерживать приложение, — это минимальное количество типов ЦП, поддерживаемых всеми библиотеками SO в проекте ( Тип ЦП, поддерживаемый приложением с помощью нашего SDK, может быть меньше или равен типу, поддерживаемому нашим SDK).

5. Не уменьшайте размер APK, «уменьшая библиотеки SO, поддерживаемые другими типами ЦП».

Действительно, все устройства x86 / x86_64 / armeabi-v7a / arm64-v8a поддерживают библиотеку SO архитектуры armeabi, поэтому кажется, что удаление библиотеки SO из других ABI — хороший способ уменьшить размер APK. Но на самом деле это не так: это влияет не только на производительность и совместимость библиотеки.

Устройства X86 могут хорошо запускать библиотеки функций типа ARM, но нет никакой гарантии, что 100% сбоев не произойдет, особенно для старых устройств, совместимость — всего лишь гарантийное решение. 64-битные устройства (arm64-v8a, x86_64, mips64) могут запускать 32-битные библиотеки функций, но работать в 32-битном режиме. Если вы запустите 32-битные версии компонентов ART и Android на 64-битных платформах, вы потеряете оптимизированные 64-битные Производительность (АРТ, веб-просмотр, СМИ и т. Д.).

Уменьшать размер APK за счет уменьшения библиотеки SO, поддерживаемой другими типами ЦП, не очень разумно.Если действительно необходимо уменьшить размер библиотеки SO, чтобы сделать APK тонким, у нас есть и другие способы.

Правильная поза для уменьшения объема библиотеки SO

1. Создайте APK с поддержкой определенного ABI.

Мы можем создать APK, который поддерживает все типы процессоров. Но, наоборот, мы можем создать отдельный APK для каждого типа ЦП, а затем установить соответствующий APK для устройств с разными типами ЦП. Конечно, предполагается, что рынок приложений должен обеспечивать поддержку типов ЦП пользовательских устройств. На данный момент , По крайней мере, рынок PLAY это поддерживает.

Gradle может генерировать APK, поддерживаемые различными ABI, с помощью следующей конфигурации (цитируется из других статей, на самом деле не используется):

2. Загрузите библиотеку SO, поддерживаемую текущим устройством, из сети.

Сказав это, наконец, вернемся к теме динамической загрузки. ⊙﹏⊙

Используя технологию динамической загрузки Android, можно загружать внешние библиотеки SO, поэтому мы можем загружать файлы библиотеки SO из Интернета и загружать их. Мы можем загрузить все типы файлов библиотеки SO, а затем загрузить соответствующий тип библиотеки SO, или вы можете загрузить соответствующий тип библиотеки SO, а затем загрузить, но независимо от того, каким образом, нам лучше проверить файл библиотеки SO перед загрузкой библиотеки SO Сделайте суждение о типе.

Мой личный план состоит в том, что библиотека SO, хранящаяся на сервере, по-прежнему упакована в метод сжатия пакета APK, то есть библиотека SO помещается в пакет APK.libs/xxxabiПо пути, после загрузки пакета APK с библиотекой SO, мы можем просмотреть все библиотеки SO по пути libs и выбрать загрузку библиотеки SO соответствующего типа.

Конкретный код реализации выглядит так:

подводить итоги

Архитектура ЦП = ABI = соответствующая библиотека SO;

При загрузке библиотеки SO необходимо загрузить соответствующий тип библиотеки SO;

Постарайтесь обеспечить поддержку библиотеки SO для всех типов ЦП;

В качестве отступления скажу, что использование самой библиотеки SO — это чистейшая технология динамической загрузки. Сама библиотека SO не участвует в процессе компиляции APK. Метод использования JNI для вызова Native метода в библиотеке SO выглядит как своего рода «жесткое программирование» Метод Native ничем не отличается от обычного статического метода Java, но его конкретная реализация может быть динамически заменена в любое время (отлично замените библиотеку SO), которую также можно использовать для реализации решения горячего ремонта, и метод Java после загрузки Его нельзя будет снова заменить после ввода в память. Нативный метод можно заменить по желанию без перезапуска приложения.

По соображениям безопасности и экологического контроля рынок Google Play не позволяет приложениям загружать внешние исполняемые файлы. После того, как ваш APK проверяется на наличие дополнительных исполняемых файлов, это не весело, поэтому теперь многие приложения тайно Замените суффикс исполняемого файла, используемого для динамической загрузки, на «.so», чтобы снизить вероятность обнаружения, потому что загрузка библиотеки SO выглядит как официальная легальная версия динамической загрузки (иначе как работает библиотека SO), Хотя это кажется немного лукавым.

Источник