I work for an operator, and we preload applications on Android phones.
However, some preloaded applications, once upgraded from Market, crash.
The problem is this:
- the application contains a .so library file
- in order to preload the complete application on a phone, the .so library file has to be placed separately into the lib directory (/system/lib/libXXXXjni.so)
- when the preloaded application is upgraded from Market and run, instead of the .so library file in the new APK being found, the older preloaded .so file is found first - causing a crash, because the two .so fiels have differing contents
Does anyone have a suggested work-around, or knowledge of the library-searching algorthim which may help me solve this?
One possible solution might be to simply rename the library file, but is that enough?
Thanks in advance...
When you preload, try putting the applications library in:
/data/data/com.package.foobar/lib/libXXXXjni.so
Renaming the library would work. Possibly using the app's version number as the name of the .so file. The build becomes more complicated though.
Related
I have a mature app that needs to have an SDK brought in that wraps the camera and makes it do some spiffy processing while it's running. The SDK has come to me in the form of some aar files but my app still lives in Eclipse. Because of my massive, steaming pile of a branding structure and deadlines for this integration the uncertain timeline required to fully migrate to Android Studio will not work (for now) so I'm going for converting the aars and using them in my app via Eclipse.
The problem I'm having is that I need to kick off the activity in the library but even though I fixed up all my build time reference problems, when running the app once I get to the point that is supposed to kick off the activity I get this error.
I've read through and double checked dozens of how-tos explaining how to consume the aar files and I think I've followed every step including:
Unzip the aar files and dress them up as individual library projects, including the file structure with the resources, the manifest, and the .jar
Make the project that needs the libraries add them as such
Add the .jars contained in the library projects to the build path (this step was not listed in most articles, and wasn't necessary for the project to build, but nevertheless it did not help my problem)
Declare the activity in your AndroidManifest.xml that the library brings in and declares in its AndroidManifest.xml
As I've said, everything looks good at build time, so I'm not sure what else to check. Because I'm reading that Gradle and Android Studio mashes manifests together really well, I have a hunch that it's something I'm supposed to regulate between the manifests but I don't know what it could be if that is it. I've wondered if I'm declaring the 3rd party's activity properly, but I'm not sure how to test it because the only way I can think to test it is to provide gibberish for the namespace but even then there are no complaints. I've also tried dissecting the .apk to look at the .dex file but I could not decipher anything useful.
My guess is that the library may not be building properly in eclipse - even before it's being added as a dependency to the application project.
Try looking at out/classes/* and making sure you have a .class file for the activity in question. I think the .class should actually be in the library as well as end up in the application project's out/ dir also.
If there are any native files (x.so) (as I would imagine there might be for spiffy camera stuff), you can look for the x.so files being included in the out/ dirs of both the library and application projects as well as the library.jar file.
Another option to maybe consider for this use case: https://github.com/ksoichiro/gradle-eclipse-aar-plugin
It seems that our app had a bad version of the appcompat-v7 support library. The .jars in it were different sizes than the one that comes with the SDK and several resources were missing. I have no idea how we ended up that way or where this bad version came from. Once I replaced it, things went great.
Later, I did encounter the need to drop in the .so files into the libraries I made that came out of the .aar files as Stad Kurdziel said in his answer, but that was causing a different error (the exception explicitly states that the .so is missing) and I arrived at the solution independently.
I added the audio android-ffmeg library project in my application.
I added a file called libsox.so in the libs folder of the application.
The file is called via a ShellCallback , looking in the file system.
The problem is that it return a "nullPointerException", depending on the mobile phone. On my Samsung it works without problem, but this problem appear on other device.
The problem looks to be in the first line:
fileBinDir = new File(_context.getFilesDir().getParentFile(),"lib");
soxBin = new File(fileBinDir,"libsox.so").getCanonicalPath();
Somebody know why it can't be found on some device ?
Native libraries are handled different to assets. Usually you include one library for each platform (armebi, armebi-v7a and x86). When you install the app the matching library in installed and the other libraries are just ignored.
If you want to load a library use System.loadlibrary("sox") instead. The "lib" and ".so" parts will be automatically added and Android knows where it installed the library.
Alternatively you can use System.mapLibraryName(..) to get the library file name and then use findLibrary(..) of your current classloader for getting the path to the library.
I'm currently trying to find a solution to have an AIR native extension including a C - library for Android that is using JNI.
So far, I tried to pack the .so lib into a jar, which then is packaged into the ane.
As I learned here, I have to unpack the .so from the .jar first in order to access it.
The code found there seems to be working for a regular android project, unfortunatly when doing this for a .jar which is then packaged into an .ane, it seems to lose scope, resulting in a
FileNotFoundException: File path/to/my/lib was not found inside JAR
I already double and triple checked all paths and the contents of my jar. It's all there and spelled correctly.
Q1: How do I get access to the .so from actionscript?
Q2: Is there any other way to package/address the .so besides the regular extension-jar into the ane?
Q3: I really don't know much about the inner working of the .ane mechanism. Is it also possible to skip the .jar-wrapping and use the .so directly from actionscript?
As always, many thanks for any input.
It becomes a bad habit of me to answer my own questions, but anyway...
Sometimes the docs can help. Here in the adobe docs I finally found the solution.
Simply copying the .so to the libs/armeabi-v7a folder in my ane package directory includes the lib into the ane, so I can use the .so from inside the java code of my extension.
Sorry for bothering.
when building .ane files, you should be careful about naming your resources so no two extensions would conflict each other when used in one app. I know that and it's ok.
I have another kind of conflict problem! you see, in one of the extensions I've been building, I used the external .jar file, Google play services and the extension works like charm. everything was fine until the day that I created another extension which was happened to use the external jar file, Google Play Services again!
when building .ane files, I actually merge any needed external .jar files into the one that I have exported myself from eclipse.
now that I have two different extensions both happen to be using Google Play services external .jar file, when I use them in one app, it won't allow me to package my .apk
the error message says:
java.lang.IllegalArgumentException: already added:
com/google/android/gms/appstate/OnStateListLoadedListener;
at
com.android.dx.dex.file.ClassDefsSection.add(ClassDefsSection.java:123)
how can we bypass this kind of confliction?!
Extension's will not allow same method name's even they are in different extensions. i think that is the mistake you did in making extension's. please look at them and changes method names it will work.
I am attempting to add a third-party library to my Android app. It utilizes a .jar file and a .so file. This is a pre-built .so file (i.e. not built specifically for the Android app) - which I know will provide me with plenty of problems down the road. I do NOT have access to the source files for the .jar or .so files!
I am attempting to dynamically load the library via a call to System.loadLibrary("foo");. Currently, when attempting to run the app, it crashes with the UnsatisfiedLinkError: Library foo not found. I have the .so file in both the libs/ and the libs/armeabi file in my project.
Am I chasing after a ghost here? I am trying to determine if what I'm after is even feasible. I have no native code that I'm referencing - all my function calls are to the .jar file that is, as I understand it, backed by the .so file. I have not run the Android.mk file as I'm not compiling anything - the .so file is already provided. I could really use some advice as to what direction to proceed from here.
It's possible that the base name given to System.loadLibrary() is expanding to a file (or path) name different than that of the actual prebuilt library. Logcat should show you exactly what it is trying to load. You could also use System.load() with a full path/file name instead of System.loadLibrary() - though you really should get it working with the later.
While I think it would generate a different error message, it's also possible that the .so is not android compatible - it must not only be for a compatible processor type and abi, but not depend on any dynamic libraries (such as a non-bionic libc) not installed on the device.