Develop Reference

Native application crashes on Android L

I have a native application that always worked on Android KitKat with both Dalivik and ART runtimes, but it now crashes on Android L with the following trace:
E/art(12810): dlopen("/data/app-lib/com.mylib.example", RTLD_LAZY) failed: dlopen failed: cannot locate symbol "issetugid" referenced by "mylib.so"...
D/AndroidRuntime(12810): Shutting down VM
E/AndroidRuntime(12810): FATAL EXCEPTION: main
E/AndroidRuntime(12810): Process: com.mylib.example, PID: 12810
E/AndroidRuntime(12810): java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "issetugid" referenced by "mylib.so"...
E/AndroidRuntime(12810): at java.lang.Runtime.loadLibrary(Runtime.java:364)
E/AndroidRuntime(12810): at java.lang.System.loadLibrary(System.java:610)
Is ART runtime in Android L different from KitKat? There is no new NDK available yet, therefore, how to avoid this crash, because it seems that the function issetugid is no longer supported.

The issue has been fixed in the final Android 5.0 release. There is no need to re-compile existing binaries.
However, if the native lib is compiled with target android-21, it fails on previous Android versions (< 5.0)

I think i may have the answer, please correct me if iam wrong.I had faced similar issue and now its fixed (or i have found a workaround rather)
while registering native method to JNI, there are two ways of doing it.
1) Implement JNI_OnLoad() method in your .cpp file and register your native methods with the
appropriate classes.
Check- http://developer.android.com/training/articles/perf-jni.html#native_libraries
example - https://android.googlesource.com/platform/development/+/master/samples/SimpleJNI/jni/native.cpp
2) there is a particular naming convention to follow for the native methods, where the class path (including package) have to be added.
Check - http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp615
Here we need not implement any method. The JVM discovers the native method from the symbol names it self from the binary.
The first method doesn't seem to work in Android ART runtime (ART is Optional in kitkat and it will be the only runtime in Lolipop).I am not not sure why it doesnt work. but i think the reason is because the way ART performs.(The bytecodes are converted and cached during install time itself instead of runtime, so that app runs faster). So since the native libs are not loaded (on_load is not called) the conversion to machine code fails at some point
Use the second method to register natives. it should work.
Only disadvantage is now your function names will be and long and will look horrible (i bet none of the function will fit in 100char limit).bye bye function name readability.
Hope this helps
Cheers,
Shrish

Android NDK can't open any file

I'm trying to open files from C in my Android app/library. This did work at some point but stopped working after changing several things that seem completely irrelevant, and don't run until after this error occurs.
I am using the following function in C: *ppFile = fopen(fullUncFilePathAndName, "r+b"); and then again with permissions "w+b"
After each of these calls, errno = 13 (Permission Denied).
The file path is /data/data/{appFolder}/files/{filename} (got from Context.getFilesDir().getAbsolutePath(), and the working directory according to the C functions is "/". This is on internal storage, but I added the permission WRITE_EXTERNAL_STORAGE just because I had nothing else to do.
Can anyone think why reading or writing to existing and non-existent files in internal storage from an NDK library would fail with permission errors?

This problem solved itself in the best worst way possible. I deleted my app's data folder in the file browser, and then at the next build the app created its files without a hitch.

You could also clean the project and recompile from scratch.

Unsatisfied link error for native library

I developed applications which use native code. All of a sudden those are not working, giving error "Unsatisfied link error: Couldn't load native library from loader dalvik.System.pathClassLoader, findLibrary returned null. I restarted adt twice. Still getting the same error. Applications which are not using native code, are working fine.

The error implies that the program is not able to find the shared libraries that you would have created.
Which devices did you try it on ?
You can check once if they are available in libs directory of your app . [/data/data/app_id/lib ]. Also check if armv7 support is required and if the directory is there in the libs , is .so present there.

Now it's working. I deleted all my virtual devices and then created a new one. However it's showing "skipped 264 frames. application may be doing too much work on main thread" many times and whenever we press a button, displaying this message in log "error loading /system/media/audio/ui/Effect_Tick.ogg"
thanks.

jni problems when system load the .so file

I have already created .so file and put it in proper path.
However,when I try to run the android program the problem came by.
the problem is:
`5-16 15:34:16.704: E/AndroidRuntime(9968): Caused by: java.lang.UnsatisfiedLinkError:
Cannot load library: reloc_library[1311]: 1584 cannot locate '_Z13raptor_decodePKhtPKtPhjPK15RaptorParam_tag'...
raptor_decode is a function which included by the jni_function.`
what should i do to correct this problem? Thanks.

I think here is your problem:
1584 cannot locate '_Z13raptor_decodePKhtPKtPhjPK15RaptorParam_tag'
if raptor_decode is the method you want to call, read up here: http://java.sun.com/docs/books/jni/html/design.html (and read up 11.3)

dlsym returning symbol not found in android after succesful return of dlopen

I am loading one shared library from another. Lets say foo2.so from foo1.so
I am using dlopen followed by dlsym
dlopen succeed with proper handle but dlsym returns with "symbol not found" error .I have used dlerror to print the error.
These are the things i tried. In foo2.so .mk file I added
LOCAL_LDFLAGS += -Wl,--export-dynamic.
I checked the symbol in foo2.so using nm and it is there.
Both the modules are in C except one wrapper file in foo1.so which is in C++, Calling file is in C.
Can any one suggest whether i missed any thing . I am running this on android emulator on froyo.

I would be tempted to poke around at the implementation level and verify things. Look in /proc/PID#/maps and make sure both libraries are loaded.
objdump both caller and callee and make sure that C++ bit didn't mangle the name.
Are you using a suitable RTLD_ flag, and is dlsym getting a valid handle returned by dlopen ?
Can you build (a simplified version of) the two libraries and test executable for a desktop linux or cygwin in order to make sure what you want to do is generally workable - ie, that the problem is android-specific?