android7.0是哪个ndk,由于sqlcipher库和NDK限制,Android 7.0本机崩溃

我在Android 7.0三星S8上收到以下崩溃信息,以及许多其他此类本机崩溃信息：

backtrace:

#00 pc 000000000005da7c /system/lib64/libbinder.so (_ZN7android6Parcel14freeDataNoInitEv+16)

#01 pc 00000000000f8538 /system/lib64/libandroid_runtime.so

#02 pc 0000000002a4fa24 /system/framework/arm64/boot-framework.oat (android.os.Parcel.nativeDestroy+128)

#03 pc 0000000002a4ee10 /system/framework/arm64/boot-framework.oat (android.os.Parcel.destroy+76)

#04 pc 0000000002a5396c /system/framework/arm64/boot-framework.oat (android.os.Parcel.finalize+40)

#05 pc 000000000068a6e0 /system/framework/arm64/boot-core-libart.oat (java.lang.Daemons$FinalizerDaemon.doFinalize+140)

#06 pc 000000000068a9bc /system/framework/arm64/boot-core-libart.oat (java.lang.Daemons$FinalizerDaemon.runInternal+520)

#07 pc 000000000068a054 /system/framework/arm64/boot-core-libart.oat (java.lang.Daemons$Daemon.run+96)

#08 pc 000000000065fda0 /system/framework/arm64/boot.oat (java.lang.Thread.run+60)

#09 pc 00000000000d25b4 /system/lib64/libart.so (art_quick_invoke_stub+580)

#10 pc 00000000000df6e4 /system/lib64/libart.so (_Z N3art9ArtMethod6InvokeEPNS_6ThreadEPjjPNS_6JValueEPKc+212)

#11 pc 0000000000475fc4 /system/lib64/libart.so (_ZN3artL18InvokeWithArgArrayERKNS_33ScopedObjectAccessAlreadyRunnableEPNS_9ArtMethodEPNS_8ArgArrayEPNS_6JValueEPKc+108)

#12 pc 0000000000477598 /system/lib64/libart.so (_ZN3art35InvokeVirtualOrInterfaceWithJValuesERKNS_33ScopedObjectAccessAlreadyRunnableEP8_jobjectP10_jmethodIDP6jvalue+372)

#13 pc 00000000004988a8 /system/lib64/libart.so (_ZN3art6Thread14CreateCallbackEPv+1104)

#14 pc 00000000000770f4 /system/lib64/libc.so (_ZL15__pthread_startPv+204)

#15 pc 000000000001e7d0 /system/lib64/libc.so (__start_thread+16)

此崩溃已在Play商店中记录.对于我们在Play商店中提供的每个版本更新,它都会不断重复.

我的应用程序中使用了以下库,这是唯一使用NDK中的jni代码的库.

compile 'net.zetetic:android-database-sqlcipher:3.5.9@aar'

compile 'org.greenrobot:greendao:3.0.1'

请帮助解决此崩溃问题.对于我的应用程序来说,它每天都在增加.

见下图：

解决方法:

请确认您没有在共享存储首选项或本地sqlite db之类的持久存储中存储任何可打包对象.

包裹不是通用的序列化机制.此类(以及用于将任意对象放入Parcel的相应的Parcelable API)被设计为高性能IPC传输.因此,将任何Parcel数据放置到持久性存储中是不合适的：对Parcel中任何数据的基础实现的更改可能会使较旧的数据变得不可读.