I recently updated my Android app from using 3.1.0 (I think) to 3.3.1. I only package armeabi-v7a lib, but this has always worked on devices like the Asus Zenfone range (which use libhoudini for translation).
However, now using 3.3.1, I get (on the Asus Zenfone 6 (Android 4.3) and similar on Icona One 7 (Android 4.4)) :
Build fingerprint: 'asus/WW_a600cg/ASUS_T00G:4.3/JSS15Q/WW_user_1.15.40.35_20140715_3795:user/release-keys'
Revision: '0'
pid: 27380, tid: 27410, name: IntentService[F >>> com.mycompany.myapp <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
eax 00000000 ebx 000000c6 ecx 00000000 edx 00000000
esi 00000e59 edi 00000000
xcs 00000073 xds 0000007b xes 0000007b xfs 00000043 xss 0000007b
eip 61d11378 ebp 2200ff0c esp 2200fec4 flags 00210246
backtrace:
#00 pc 00087378 /system/lib/libhoudini.so.3.4.7.44914
#01 pc 00085d0e /system/lib/libhoudini.so.3.4.7.44914
#02 pc 00073328 /system/lib/libhoudini.so.3.4.7.44914
#03 pc 0006f7ff /system/lib/libhoudini.so.3.4.7.44914
#04 pc 0006f3bf /system/lib/libhoudini.so.3.4.7.44914
#05 pc 000b92de /system/lib/libhoudini.so.3.4.7.44914
#06 pc ffffffff <unknown>
#07 pc 001445aa /system/lib/libhoudini.so.3.4.7.44914
Hello @marcardar
Can you try bundling the x86 binaries along with your application to see if that addresses the issue? There should not be any specific architecture changes shipped between those two versions.
Unfortunately, I don’t have access to either of those devices (only seen the reports in Google Play Dev Console). Both crashes came immediately after I published the 3.3.1 update. I’ve since reverted to 3.1.0 about 36 hours ago, and no crash reports yet (but still early days). Still, it’s very likely that there is something different between 3.3.1 and 3.1.0 (maybe the NDK level?). I can’t publish my app with x86 binaries because I have other ARM libs (but no x86 equivalents) and you can’t mix and match in Android, in my experience.
Ideally, someone with access to a Asus Zenfone 6 or Icona One 7, could try out some test apk.
I do not have access to either of those devices, but I do have some x86 devices floating around my Secret Mountain Lair. Is the app that’s crashing available on the Play Store?
Thanks Mark. Well, I’ve already reverted the app to use 3.1.0. Furthermore, I’ve tested the 3.3.1 app on a Zenfone 5 (Lollipop) without any crash, so it’s not a problem for x86 devices in general. I’d be happy to send you an APK if you still think it’s worth testing out on your lair! Just ping me.
Ah, OK. If it’s not a general x86 problem, then the odds aren’t great that I’d be able to reproduce it.
It could be that the problem is on pre-Lollipop x86 devices, so if you have any of those it’s probably worth trying.
I have now permanently switched to 3.3.1-2, but am still seeing these crashes. The latest is on a Zenfone 5 (ASUS_T00J) running Android 4.4.2. Again, I’m using armeabi-v7a libs even though this is an x86 device. This should work thanks to libhoudini.
I haven’t been able to determine exactly what API call triggers the crash (I don’t have access to the device), but FWIW, the crash is consistent and during my app’s initialisation phase.
Everything works fine on a couple of other x86 devices (including a Zenfone 2 running 5.0) I’ve tried.
This supports my suspicion that the problem is for pre-Lollipop x86 devices using the armeabi-v7a libs.
Build fingerprint: 'asus/WW_a501cgS/ASUS_T00J:4.4.2/KVT49L/WW_user_2.22.40.54_20150527_44:user/release-keys'
Revision: '0'
pid: 2841, tid: 2863, name: IntentService[F >>> com.mycompany.myapp <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr dead0000
eax 00000000 ebx 00000001 ecx 61a80114 edx 00000000
esi 00000008 edi 1a100030
xcs 00000073 xds 0000007b xes 0000007b xfs 00000043 xss 0000007b
eip 61879595 ebp 1a111ebc esp 1a111e94 flags 00210246
backtrace:
#00 pc 0018c595 /system/lib/libhoudini.so.4.0.8.45720
#01 pc 0000dea3 [stack:2863]
#02 pc 000b333b /system/lib/libhoudini.so.4.0.8.45720
#03 pc 000ff02f [stack:2874]
#04 pc 000b2263 /system/lib/libhoudini.so.4.0.8.45720
#05 pc 000ff02f [stack:2874]
#06 pc 000aeea7 /system/lib/libhoudini.so.4.0.8.45720
#07 pc 000e6f67 /data/app-lib/com.mycompany.myapp-1/libsqlcipher_android.so
#08 pc 000ae88c /system/lib/libhoudini.so.4.0.8.45720
#09 pc ffffffff <unknown>
#10 pc 000fdb2c /system/lib/libhoudini.so.4.0.8.45720
Hi @marcardar
Are you not including the x86 binaries with your application?
No, I don’t include the x86 binaries (please see earlier comment for explanation). 3.1.0 armeabi-v7a binaries worked fine on those x86 devices. Something in 3.2 or 3.3 (not sure which) broke things.
Hi @developernotes. I have same problem. It crashes on Asus Zenfone 4, 5, 6 models and may be any other. On Asus Zenfone 2 it works ok. Was this problme solved or it is stlll uncatched? Thanks.
My stacktrace here:
dalvikvm: Trying to load lib /data/app-lib/com.idamob.tinkoff.android.qa-1/libstlport_shared.so 0x43a258d0
houdini: [23275] Loading library(version: 4.0.8.45720 RELEASE)… successfully.
Added shared lib /data/app-lib/com.package/libstlport_shared.so 0x43a258d0
dalvikvm: No JNI_OnLoad found in /data/app-lib/com.packege/libstlport_shared.so 0x43a258d0, skipping init
dalvikvm: Trying to load lib /data/app-lib/com.package/libsqlcipher_android.so 0x43a258d0
houdini: [23275] Unsupported feature (ID:0x20e00149).
com.package A/libc: Fatal signal 11 (SIGSEGV) at 0xdead0000 (code=1), thread 23275 (koff.android.qa)
So I used “net.sqlcipher:sqlcipher:3.1.0.1” that does not unclude .so files and I put them manualy in jniLibs folder. It worked ok on AUS but does not work on Philips Xenium W732 and Nexus 5x. I updated lib to “net.zetetic:android-database-sqlcipher:3.3.1-2” version and it crashes on ASUS Zenfone 4,5,6. Now I dublicate .so files. I put them in jniLibs and it solved my problem with ASUSes. Hope problem will be solved and my copied .so files will be removed.
updated : if I put .so files from version 3.1.0.1 it works OK on ASUS but it is not correct putting old .so with new library. Putting .so from 3.3.1-2 version does not work.
Hello @Ilya_Demidov
Are you using the community AAR package? If so, the native .so files are included for supporting armeabi, armeabi-v7a, and x86.
@developernotes do you know why only recent versions of sqlcipher armeabi-v7a libs fail to work on the Zenfone 4,5,6? This never used to be an issue…
Here is the latest crash (Zenfone 5) I received today. It gives an interesting “unsupported feature”:
03-13 14:31:18.116 8646 8666 D dalvikvm: Added shared lib /mnt/asec/com.mycompany.myapp-1/lib/libstlport_shared.so 0x43a28ed0
03-13 14:31:18.116 8646 8666 D dalvikvm: No JNI_OnLoad found in /mnt/asec/com.mycompany.myapp-1/lib/libstlport_shared.so 0x43a28ed0, skipping init
03-13 14:31:18.116 8646 8666 D dalvikvm: Trying to load lib /mnt/asec/com.mycompany.myapp-1/lib/libsqlcipher_android.so 0x43a28ed0
03-13 14:31:18.136 8646 8666 D houdini : [8666] Unsupported feature (ID:0x20e00149).
03-13 14:31:18.136 8646 8666 F libc : Fatal signal 11 (SIGSEGV) at 0xdead0000 (code=1), thread 8666 (IntentService[F)
03-13 14:31:18.186 181 181 I DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-13 14:31:18.186 181 181 I DEBUG : Build fingerprint: 'asus/WW_a501cg/ASUS_T00J:4.4.2/KVT49L/WW_user_2.22.40.54_20151120_16:user/release-keys'
03-13 14:31:18.186 181 181 I DEBUG : Revision: '0'
03-13 14:31:18.186 181 181 I DEBUG : pid: 8646, tid: 8666, name: IntentService[F >>> com.mycompany.myapp <<<
03-13 14:31:18.186 181 181 I DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr dead0000
03-13 14:31:18.216 181 181 I DEBUG : eax 00000000 ebx 00000001 ecx 61a7f114 edx 00000000
03-13 14:31:18.216 181 181 I DEBUG : esi 00000008 edi 1a000030
03-13 14:31:18.216 181 181 I DEBUG : xcs 00000073 xds 0000007b xes 0000007b xfs 00000043 xss 0000007b
03-13 14:31:18.216 181 181 I DEBUG : eip 61878595 ebp 1a011ebc esp 1a011e94 flags 00210246
03-13 14:31:18.216 181 181 I DEBUG :
03-13 14:31:18.216 181 181 I DEBUG : backtrace:
03-13 14:31:18.216 181 181 I DEBUG : #00 pc 0018c595 /system/lib/libhoudini.so.4.0.8.45720
03-13 14:31:18.216 181 181 I DEBUG : #01 pc 0000dea3 [stack:8666]
03-13 14:31:18.216 181 181 I DEBUG : #02 pc 000b333b /system/lib/libhoudini.so.4.0.8.45720
03-13 14:31:18.216 181 181 I DEBUG : #03 pc 0000002f <unknown>
03-13 14:31:18.216 181 181 I DEBUG : #04 pc 000b2263 /system/lib/libhoudini.so.4.0.8.45720
03-13 14:31:18.216 181 181 I DEBUG : #05 pc 0000002f <unknown>
03-13 14:31:18.216 181 181 I DEBUG : #06 pc 000aeea7 /system/lib/libhoudini.so.4.0.8.45720
03-13 14:31:18.216 181 181 I DEBUG : #07 pc 000e6f67 /mnt/asec/com.mycompany.myapp-1/lib/libsqlcipher_android.so
03-13 14:31:18.216 181 181 I DEBUG : #08 pc 000ae88c /system/lib/libhoudini.so.4.0.8.45720
03-13 14:31:18.216 181 181 I DEBUG : #09 pc ffffffff <unknown>
03-13 14:31:18.216 181 181 I DEBUG : #10 pc 000fdb2c /system/lib/libhoudini.so.4.0.8.45720
03-13 14:31:18.216 181 181 I DEBUG :
03-13 14:31:18.216 181 181 I DEBUG : stack:
03-13 14:31:18.216 181 181 I DEBUG : 1a011e54 61935bdc /system/lib/libhoudini.so.4.0.8.45720
03-13 14:31:18.216 181 181 I DEBUG : 1a011e58 00000000
03-13 14:31:18.216 181 181 I DEBUG : 1a011e5c 1a011ebc [stack:8666]
03-13 14:31:18.216 181 181 I DEBUG : 1a011e60 617ab326 /system/lib/libhoudini.so.4.0.8.45720
03-13 14:31:18.216 181 181 I DEBUG : 1a011e64 f9b5100e
03-13 14:31:18.216 181 181 I DEBUG : 1a011e68 00000000
03-13 14:31:18.216 181 181 I DEBUG : 1a011e6c 00000138
03-13 14:31:18.216 181 181 I DEBUG : 1a011e70 00000000
03-13 14:31:18.216 181 181 I DEBUG : 1a011e74 000000fc
03-13 14:31:18.216 181 181 I DEBUG : 1a011e78 fffffd5b
03-13 14:31:18.216 181 181 I DEBUG : 1a011e7c 00000900
03-13 14:31:18.216 181 181 I DEBUG : 1a011e80 00000190
03-13 14:31:18.216 181 181 I DEBUG : 1a011e84 00000008
03-13 14:31:18.216 181 181 I DEBUG : 1a011e88 00000001
03-13 14:31:18.216 181 181 I DEBUG : 1a011e8c 1a011ebc [stack:8666]
03-13 14:31:18.216 181 181 I DEBUG : 1a011e90 61878595 /system/lib/libhoudini.so.4.0.8.45720
03-13 14:31:18.216 181 181 I DEBUG : #00 1a011e94 1a011ea4 [stack:8666]
03-13 14:31:18.216 181 181 I DEBUG : ........ ........
03-13 14:31:18.216 181 181 I DEBUG : ........ ........
03-13 14:31:18.216 181 181 I DEBUG : #02 1a011ec4 1a000030
03-13 14:31:18.216 181 181 I DEBUG : ........ ........
03-13 14:31:18.226 181 181 I DEBUG :
03-13 14:31:18.226 181 181 I DEBUG : memory map around fault addr dead0000:
03-13 14:31:18.226 181 181 I DEBUG : bfa64000-bfa85000 rw- [stack]
03-13 14:31:18.226 181 181 I DEBUG : (no map for address)
03-13 14:31:18.226 181 181 I DEBUG : (no map above)
Hi @marcardar
That is an interesting message from libhoudini. Out of curiosity, what version of Android OS are you running on the Zenfone 5?
Hi @marcardar
I am not familar with the Zenfone devices, however it appears to being using an Intel Atom Z2580 chip which uses the x86 instruction set. Is it correct that you are not shipping the x86 native libraries of SQLCipher for Android and instead relying on libhoudini to perform ARM to x86 translations?
Hi @developernotes - yes, using armeabi-v7a libs on a x86 device. The thing is this worked on earlier versions of sqlcipher and works for other armeabi-v7a libs, so there is something that has changed in recent versions of your armeabi-v7a libs.
Build: ASUS_T00J_WW_user_2.22.40.54_20151120_16 release-keys
Build fingerprint: 'asus/WW_a501cg/ASUS_T00J:4.4.2/KVT49L/WW_user_2.22.40.54_20151120_16:user/release-keys’
Bootloader: unknown
Radio: unknown
Network: DIGITEL
Kernel: Linux version 3.10.20-262979-gaee3d1b (jenkins@android01-RS704D-E6-PS8) (gcc version 4.7 (GCC) ) #1 SMP PREEMPT Fri Nov 20 18:36:59 CST 2015
Hello @marcardar
I realize you may not have the device available to you, however it would be beneficial to know if SQLCipher for Android works properly on the Zenfone devices with the native x86 libraries themselves.