FR: loading the native library specified by the filename argument

[artyomd]

There should be an API interface for System.load, which will take the library path and try to load it with System.load. If loading fails, it will try to load dependencies and try again.

[philippb]

@artyomd thanks for submitting your PR in references to this feature request.
Can you please elaborate why you think ReLinked needs this functionality?

[artyomd]

@philippb Thanks for your response. So there are 2 ways of loading native libraries, the first one is with System.loadLibrary providing a library name, and the second one with System.load providing a file path. ReLinker supports loading libraries by name but does not support loading from a path, yet. And there are many reasons to download native libraries at app runtime and load them with System.load instead of shipping the app with them. So I thought why not to implement that functionality? I don't think that there is a reason why ReLinker must not have this functionality. @philippb What you think about this?

[benjamin-bader]

Android Q is going to specifically disallow downloading and executing native code, JFYI.

[artyomd]

@benjamin-bader What do you mean by saying disallow? I don't think that android will remove or deprecate System.load method. Btw, ReLinker currently relies on System.load. In the other side, there will be always a way to get a native library from somewhere at runtime. So as far as I know only google play store bans apps that download and execute native code. So the os itself cannot restrict an app from doing that. And there are apps that are not being published in play store. So the functionality to load an external native lib is there, why not use that? Anyway, you are just a library project maintainers, why not to support that functionality for the ones who want to do that kind of things?

[benjamin-bader]

I don't mean that System.load is going away, but it turns out I'm wrong in a different way.

What's changed in Q is that you may not exec() a downloaded native binary; you can still load a .so that was downloaded and made executable. That, which is the use case you are referring to, is likely going to be banned in R.

See the following thread: https://www.reddit.com/r/androiddev/comments/b2inbu/psa_android_q_blocks_executing_binaries_in_your/

[artyomd]

@benjamin-bader Thanks for your response. It will be banned in the future or not, currently does not matter, but it is a common use case and ReLinker can address that.