WAI
Status Update
Comments
om...@gmail.com <om...@gmail.com> #2
Update:
I checked on a rooted Nexus One, it looks like the installer doesn't extract the armeabi library in this scenario, so it's not present in the $APP/lib/ folder.
I checked on a rooted Nexus One, it looks like the installer doesn't extract the armeabi library in this scenario, so it's not present in the $APP/lib/ folder.
[Deleted User] <[Deleted User]> #3
Filed internally as 2771143.
[Deleted User] <[Deleted User]> #4
This is, apparently, the intended behavior in the current release. Mixed binaries complicate other stuff (builds scripts, native debugging, etc).
Future changes are planned to address the size issue.
Future changes are planned to address the size issue.
om...@gmail.com <om...@gmail.com> #5
I still didn't understand if that's a known issue or is it really supposed to be that way.
To me it seems like a bug - the NDK docs never mention that the extraction policy is global - you assume that you can have your ARMv7 and ARMv5 libraries without any conflict.
In my case, the workaround got pretty ugly - to overcome the size issue, I put my ARMv5 library in the raw resources, renamed it with the .WAV extension so it won't get compressed and exceed the 1MB size limit (so far pretty ugly), then extract it manually by copying it (using IO streams) to the <package>/files/ folder, then loading it with the absolute path using System.load() (as opposed to System.loadLibrary()).
I doubt that's what you intended - but maybe you're aware of a better workaround than this.
To me it seems like a bug - the NDK docs never mention that the extraction policy is global - you assume that you can have your ARMv7 and ARMv5 libraries without any conflict.
In my case, the workaround got pretty ugly - to overcome the size issue, I put my ARMv5 library in the raw resources, renamed it with the .WAV extension so it won't get compressed and exceed the 1MB size limit (so far pretty ugly), then extract it manually by copying it (using IO streams) to the <package>/files/ folder, then loading it with the absolute path using System.load() (as opposed to System.loadLibrary()).
I doubt that's what you intended - but maybe you're aware of a better workaround than this.
wa...@gmail.com <wa...@gmail.com> #6
A note about this in the Docs would be really helpful. This is an unexpected behavior that I'm still encountering on Nexus 5's.
Description
- Steps to reproduce the problem (including sample code if appropriate).
- What happened.
- What you think the correct behavior should be.
Steps to reproduce:
(happens on Nexus One, doesn't happen on Droid)
In an Android project, create folders for both armeabi and armeabi-v7a.
Put one library in armeabi-v7a, and other libraries only in armeabi.
The scenario is that you have one "fat loaded" library that you compiled for both instruction sets, and other libraries that you compiled only for armeabi.
Then, use System.loadLibrary() to load a library from armeabi that you didn't compile for armeabi-v7a.
What happens:
When you try to load a library that is present only in armeabi, you get UnsatisfiedLinkError - it won't load it.
If you remove the one library in armeabi-v7a, it will load.
Correct behavior:
For EACH library, check if it exists in armeabi-v7a. If it does, load it. If not, check if it exists in armeabi. If it does, load it. If not, throw UnsatisfiedLinkError.
In any way, the existance of one particular library in armeabi-v7a shouldn't affect other libraries that have nothing to do with it.
Workaround:
Put ALL your libraries both in armeabi and armeabi-v7a. This could take a lot of space. In my case, the .APK has to grow from 3MB to 4.5MB because of the duplicate library.
Stack trace:
06-15 12:16:18.024: ERROR/app(2509): Caused by: java.lang.UnsatisfiedLinkError: Library some-library not found
06-15 12:16:18.024: ERROR/app(2509): at java.lang.Runtime.loadLibrary(Runtime.java:489)
06-15 12:16:18.024: ERROR/app(2509): at java.lang.System.loadLibrary(System.java:557)
06-15 12:16:18.024: ERROR/app(2509): at com.app.SomeClass.<clinit>(SomeClass.java:62)
06-15 12:16:18.024: ERROR/app(2509): ... 28 more