[Bug 785406] android: gstjniutils.c fails to find application class loader provider on Android 7.0

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=785406

--- Comment #16 from Jeremi Wójcicki <jeremi.wojcicki at gmail.com> ---
OK, so following you intuition about dlopen() and dlsym() calls, I looked into
changes that were introduced since Android 7.0. It seems we've pin-pointed the
issue: for target APIs of 24(Nougat) and higher dynamic linking seems to be
restricted
(https://developer.android.com/about/versions/nougat/android-7.0-changes.html#ndk).

To verify that, I have actually downgraded my compile and target api to 21 and
changed at the same time target to armeabi-v7a (64bit instruction set is
supported api level 24 up). After the changes I could see the class loader and
amc plugin properly registered!

My app begun crashing, tough, when I was touching samples received through
appsink in another thread (which did not occur before). Its possible that I
have some mixed 32 (gstreamer) and 64 (oculus mobile sdk) bit libs and hence
the issue, and it should rather not be related to the main problem.

Now, what makes me wonder is that Android 7.0 changelog says that the NDK
public libraries can still be dynamically linked. AMC and OpenMAX are public,
aren't they? Is gstreamer dynamically linking to itself (gstreamer.so)? Perhaps
somehow modifying this behavior could work as a quickfix to the issue.
Otherwise, I guess, the approach to handling AMC and OMX by gstremer should be
changed (I guess static library loading etc.).

That is all I have learnt about this issue. Anyhow, the workaround using the
downgraded target api and using 32bit build seems to be OK for now. I'll post
more if I find other related problems or solutions.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.