SoylentNews is people
SoylentNews
Back in 2012, during the early days of KeepSafe, we sought to implement an encryption scheme for our Android App. Through many iterations and prototypes, we found a sweet spot of sorts by leveraging the power of the JNI (Java Native Interface.) We decided to write our interface into the encryption library we utilized in Java, calling into the library via the JNI solely for the purpose of encryption and decryption. We opted for an on-the-fly solution, minimizing the impact on user experience as much as possible. Once we were happy with our solution, we decided to deploy it into our production app. We rigorously tested our code and were confident that everything would go smoothly; that is, until things beyond our control broke.
As we anxiously refreshed our crash reports following our release, we started to notice a recurring error. Users were running into an “UnsatisfiedLinkError”, which means that either A) the native library we were calling into did not exist or B) the native method we were calling did not exist. Since B) would almost always be caught via compiling and basic testing, we were immediately perplexed at the fact that users’ installations did not have the native libraries we shipped within the APK.
That's the agony and ecstasy of software development right there, pal.
(Score: 2) by Gravis on Monday November 09 2015, @10:14AM
this isn't a problem with loading native libraries, this is a problem with java. the solution is to not use java. the android NDK is free, you know.
(Score: 1, Offtopic) by Pino P on Monday November 09 2015, @03:05PM
leveraging the power of the JNI (Java Native Interface.)
this is a problem with java. the solution is to not use java. the android NDK is free, you know.
The Android NDK uses JNI. Unless you include binaries for all instruction sets in every APK, using the NDK will cause the problem described in the article of exceptions when trying to run sideloaded binaries made for a different instruction set.