vinit
vinit

Reputation: 131

dlopen() is not working with android-n

dlopen() is working fine at API-23, but For Android-N, when I tried to open any sofile using dlopen it return a soinfo structure type pointer. but when i tried to access any variable of this structure the application get crash.

si = (soinfo*) dlopen("/data/app/com.xxx.xxx.sampleapp.android-1/lib/x86/libtest.so", RTLD_GLOBAL);

if (si == NULL)
    return;

LOGI("value of dlopen [%d]", si->size);

Is there any change in dlopen() functionality with Android-N??

Upvotes: 3

Views: 7807

Answers (4)

Graeme Gill
Graeme Gill

Reputation: 645

On version of Android that return an opaque handle rather than a pointer to soinfo, the function dl_iterate_phdr() is available. This lets you locate the Elf headers of all the .so's, and the Elf headers contain a great deal of the same information as the soinfo structures.

Upvotes: 2

evanchin
evanchin

Reputation: 2048

Here is the change from Google to hide the soinfo to prevent access to linker internal fields.


https://android.googlesource.com/platform/bionic/+/d88e1f350111b3dfd71c6492321f0503cb5540db

linker: hide the pointer to soinfo

Handle no longer is a pointer to soinfo of a corresponding library. This is done to prevent access to linker internal fields.

Upvotes: 0

Roman Khimov
Roman Khimov

Reputation: 4977

dlopen() doesn't return a pointer to some soinfo structure, it returns void*, the standard Linux man page is very specific about this:

The function dlopen() loads the dynamic shared object (shared library) file named by the null-terminated string filename and returns an opaque "handle" for the loaded object. This handle is employed with other functions in the dlopen API, such as dlsym(3), dladdr(3), dlinfo(3), and dlclose().

So the fact that you could interpret returned value in some way was non-standard and now Google is just enforcing that with this change:

commit  ae74e8750b9dae51b24a22fdb4b0e0a2d84f37b9
author  Dimitry Ivanov <[email protected]>
...
linker: hide the pointer to soinfo

Handle no longer is a pointer to soinfo of
a corresponding library. This is done to
prevent access to linker internal fields.

Bug: http://b/25593965
Change-Id: I62bff0d0e5b2dc842e6bf0babb30fcc4c000be24
(cherry picked from commit d88e1f350111b3dfd71c6492321f0503cb5540db)

So unless your application is targeting SDK version 23 or less (see soinfo::to_handle()), you're now getting the handle that could only be converted back to soinfo* with an internal bionic soinfo_from_handle().

Upvotes: 8

Michael
Michael

Reputation: 58427

From the developer documentation (emphasis added):

Starting in Android 7.0, the system prevents apps from dynamically linking against non-NDK libraries, which may cause your app to crash. This change in behavior aims to create a consistent app experience across platform updates and different devices.
...
All apps generate a runtime error when they call an API that is neither public nor temporarily accessible. The result is that System.loadLibrary and dlopen(3) both return NULL, and may cause your app to crash.

Upvotes: 2

Related Questions