[Hedda]

FYI, not sure if this behavioral changes regarding dynamically linking in Android "N" (7.0?) will directly affect Kodi as is, but as it could so please read;

http://android-developers.blogspot.se/20...te-cc.html

and

https://developer.android.com/preview/be...s.html#ndk

NDK Apps Linking to Platform Libraries

Starting in Android N, 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. Even though your code might not be linking against private libraries, it's possible that a third-party static library in your app could be doing so. Therefore, all developers should check to make sure that their apps do not crash on devices running Android N. If your app uses native code, you should only be using public NDK APIs.

...

[Koying]

Shouldn't be an issue.
Only the stagefright codec ever linked to private android libs, IIRC.

[MrMC]

Non-issue, only effects apps that dyload android private libs to access android private APIs.

Correction, this would effect amlcodec as it dyloads the aml private libs. But AMLCodec is in the process of being nuked for Android under v17. So also maybe effecting SPMC but not MrMC fork.

[Martijn]

Well it's just one button away

[fritsch]

Funny - what a lot of hate we got from all the users around for motivating pure mediacodec / audiotrack API for v17 ... now the beloved OS will kill all those non standard conform stuff itself. Yeah, if it wants to get serious, it needs to stop supporting old ringtone apis and make a step forward. I am already happy about v24 audio api changes, good move. Killing vendor hacks was a sane step to happen.

[stefansaraev]

Non-issue, only effects apps that dyload android private libs to access android private APIs.

Correction, this would effect amlcodec as it dyloads the aml private libs. But AMLCodec is in the process of being nuked for Android under v17. So also maybe effecting SPMC but not MrMC fork.

kodi ships the lib itself, so I think it's a non issue.

[MrMC]

ahh, not for android libamplayer.so/libamcodec.so is built by the firmware provider for aml boxes.

[stefansaraev]

ouch. thats right, just looked at android v16 apk. I always thought we ship that .so

but on android, we also dont build static or bundle openssl, sqlite dlls and what not. so do we have a problem now (at least, boringssl vs openssl) ?

[MrMC]

For example, MrMC builds and includes the following inside the app.

OBJS = libcurl.so
OBJS+= libcpluff.so
OBJS+= libass.so
OBJS+= libxbogg.so libxbvorbis.so libxbvorbisfile.so
OBJS+= libmpeg2.so libmpeg2convert.so
OBJS+= libnfs.so
OBJS+= libdsm.so
OBJS+= libsmbclient.so
OBJS+= libdvdnav.so
OBJS+= libbluray.so
OBJS+= libplist.so
OBJS+= libshairplay.so

There might be collisions with existing system libs, I'd have to check how our loader for android works again and which one is picked first and the rules regarding providing a full path to the xx.so. Even if there are collisions, that is solved by a simple prefix (like libxbcurl.so). Android build did that at one time, or I might be confusing with work I did under Pivos.

[Koying]

Correction, this would effect amlcodec as it dyloads the aml private libs.

Hehe... We'll have to wait for an aml sdk with android N to be sure.
Let's see when the M comes out first