0

There are some questions like mine.

why I need put *.so files in both armeabi-v7a and armeabi folders?

Why armeabi-v7a conflicts with armeabi of another module?

Why use armeabi-v7a code over armeabi code?

But I am not clear yet. I have many .so files for armeabi and armeabi-v7a.

// binaries

armeabi/libarmeabi-v7a-module1.so
armeabi/libarmeabi-v7a-module2.so

// Application.mk file

APP_ABI := armeabi
APP_PLATFORM := android-19
APP_STL := gnustl_shared

// Android.mk file

include $(CLEAR_VARS)
LOCAL_MODULE := module1
LOCAL_SRC_FILES := $(LOCAL_PATH)/armeabi/libarmeabi-v7a-module1.so
include $(PREBUILT_SHARED_LIBRARY)

include $(CLEAR_VARS)
LOCAL_MODULE := module2
LOCAL_SRC_FILES := $(LOCAL_PATH)/armeabi/libarmeabi-v7a-module2.so
include $(PREBUILT_SHARED_LIBRARY)

This settings work fine on armeabi-v7a devices. But my app crashes when I set armeabi-v7a abi in Application.mk file. Crash message is below:

A/libc: /Volumes/Android/buildbot/src/android/ndk-release-r16/external/libcxx/../../external/libcxxabi/src/abort_message.cpp:73: abort_message: assertion "Pure virtual function called!" failed

zakjma
  • 2,030
  • 12
  • 40
  • 81

2 Answers2

0

armeabi is armv5. It's no longer supported. You can just pretend it doesn't exist.

armeabi-v7a is armv7. This (along with at least arm64-v8a) is what you should be building for.

The fact that your app is crashing is a different problem, and the error message tells you what's happening: there's a pure virtual function that's being called. Some child class isn't implementing a virtual function that it needs to implement.

There's also a third problem. Your APP_STL is gnustl_shared, but the error message indicates that one of your libraries was built with libc++. These two are incompatible. You must use the same STL for the entire app (and since you use more than one shared library, it must be the shared variant).

Dan Albert
  • 10,079
  • 2
  • 36
  • 79
  • You are right, I don't understand how I can fix the error message. Because it works for armeabi setting on my armeabi-v7a phone. – zakjma Jul 17 '19 at 07:17
  • Sorry, Arm's naming conventions are the worst. Corrected to be version numbers rather than core numbers. – Dan Albert Jul 18 '19 at 21:34
0

armeabi is for up to ARM architecture version V6, while armeabi-v7a specifies architecture version version 7, with the suffix A for application processors such as Cortex-A15.

V7 has quite different pipleline behavior plus handful of nice and compiler friendly instructions compare to V6, such as ubfx.

e.g.:

a = (b>>5) & 0x3ff;

// armv6:
lsl a, b, #17
lsr a, a, #22

// armv7:
ubfx a, b, #5, #10 // unsigned bit-field extract from bit 5, ten bits long

As you can see above, you need two instructions with dependency on V6, while V7 only requires one single instruction which is remarkable considering how compiler friendly these new instructions are unlike the DSP-like ones new on V6 which mostly never got utilized by compilers.

And since the compiler has to decide which instructions to use and how to schedule them, the generated machine codes are different, so are the .so files, so are the folders.

I'd exclude armeabi altogether by abiFilters since there are virtually no Android phone with less than V7.

Jake 'Alquimista' LEE
  • 6,197
  • 2
  • 17
  • 25