Device Armabi path error
Opened this issue · 12 comments
In some android devices we are getting list of abis as
"armabi" only however the jni files we have belong to armabi-v7a folder. This is causing crash in load at in some files.
Is it possible to expose the LibraryLoader interface? so we can specify the abi folders that our app supports
Caused by com.getkeepsafe.relinker.MissingLibraryException: lib/armeabi/libjingle_peerconnection_so.so
at com.getkeepsafe.relinker.ApkLibraryInstaller.installLibrary(ApkLibraryInstaller.java:85)
at com.getkeepsafe.relinker.ReLinkerInstance.loadLibraryInternal(ReLinkerInstance.java:180)
at com.getkeepsafe.relinker.ReLinkerInstance.loadLibrary(ReLinkerInstance.java:136)
at com.getkeepsafe.relinker.ReLinkerInstance.loadLibrary(ReLinkerInstance.java:92)
This may be a general problem. I have seen crash reports in my application that may have been the same issue, so it would be worth fixing it in ReLinker rather than exposing the classes and forcing each application to solve it on their own.
May I ask how are you planning to use the exposed interface? If the device claims that it supports only "armeabi", how will you recognize that it is wrong and "armeabi-v7a" is really supported? It could be really "armeabi"-only device and loading "armeabi-v7a" library will eventually crash with bad instruction.
ReLinker currently uses Build.SUPPORTED_ABIS, or Build.CPU_ABI and Build.CPU_ABI2 to get the list of supported abis. If this information is not reliable, we could try to figure out where the android system loader gets the correct information.
there are some devices, i think with some new cpu Dual-core 1.5 GHz Krait
anyhow i was going to check if device is 32 bit or 64 bit
then allow to load a jni file from 32 bit folder or 64 bit folder
maybe there can be a function which can supply preferred paths for 32 bit & 64 bit library in case of miss?
This is a real pain point, but I think that the relinker API would be better if we added a way to override ABI detection, like an CurrentABIProvider interface or something.
Exposing LibraryLoader feels like overkill, given that it does a good deal more than just ABI detection.
We are serving the through split apk based on abi on google play store as there are lot of jni libs for us.
So device actually downloads the correct version of apk from app store.
What we did was to look up in the path for which directory was present amongst these
x86, x86_64, armabi-v7a, arm64
and then we loaded the jni file from that directory, seems to work for us. Maybe same approach can be taken here
Does this issue have to do with Split APK? I just released version 1.3.0 and wonder if this is still and issue.
I'm not sure if I completely understand the problem.
yes, the issue still remains. It is related to the jni folder name that android returns back.
My vote remains firmly -1 on exposing internal relinker interfaces.
We can address the issue either by adding an API to override ABI detection, or by adding additional smarts so that relinker tries to do the right thing. Option 1 is easy, but option 2 is hard... but good for users if it can be made to work.
Will like to see some static API to be used for ABI detection in case of failure.
As this library is embedded in realm java too, and we will like to do some custom overloading.
why not try to copy so lib from base apk(the value of ApplicationInfo#sourceDir)?
there exists the original so lib definitely if the android system does the job wrong, we can extract it by our self.
I agree with @benjamin-bader here. Would be nice if the library would do the right thing.
Especially considering that the goal of this is to be a broad use library that makes loading native libs easy.
Does anyone on this thread have the capacity at the moment to dig in and come up with the "doing the right thing" solution? Right now at Keepsafe we don't unfortunately.
Hello guys, just FYI; twilio is using this library and it is causing some problems on apps on production.
Basically we are using bundles, it means Google manages splitting binaries and delivering them to devices.
Devices we seen so far:
- Sony Xperia XZ
- ZTE ZFive C LTE
Both have android 7
Here is logs:
com.getkeepsafe.relinker.ApkLibraryInstaller.installLibrary (ApkLibraryInstaller.java:128) com.getkeepsafe.relinker.ReLinkerInstance.loadLibraryInternal (ReLinkerInstance.java:180) com.getkeepsafe.relinker.ReLinkerInstance.loadLibrary (ReLinkerInstance.java:136) com.getkeepsafe.relinker.ReLinker.loadLibrary (ReLinker.java:70) com.getkeepsafe.relinker.ReLinker.loadLibrary (ReLinker.java:51) com.twilio.video.MediaFactory.instance (MediaFactory.java:44) com.twilio.video.LocalAudioTrack.create (LocalAudioTrack.java:99) com.twilio.video.LocalAudioTrack.create (LocalAudioTrack.java:43)