use native lib dir instead of assets to pack rclone executables

[davsinghm]

android Q includes the following security change.

Removed execute permission for app home directory
Untrusted apps that target Android Q can no longer invoke exec() on files within the app's home directory. This execution of files from the writable app home directory is a W^X violation. Apps should load only the binary code that's embedded within an app's APK file.

In addition, apps that target Android Q cannot in-memory modify executable code from files which have been dlopen()ed. This includes any shared object (.so) files with text relocations.

more info:
https://developer.android.com/preview/behavior-changes-all#execute-permission
https://www.reddit.com/r/androiddev/comments/b2inbu/psa_android_q_blocks_executing_binaries_in_your/

this is to avoid running malicious code by apps which download native code from internet, which is direct violation of play store policy.
even though this app doesn't download native code from other sources and ships executables within apk, this commit updates the method used. binaries are moved to native library directory and extraction is done by android during app installation, making the process a lot cleaner. this doesn't affect any behavior on older android versions and also makes the app initialization process faster.

[x0b]

The cited reddit thread also links to https://stackoverflow.com/questions/16179062/using-exec-with-ndk, hinting at the possibility of exec beeing removed completely at some point - this would require refactoring rclone as a proper jni library, correct?

[davsinghm]

The cited reddit thread also links to https://stackoverflow.com/questions/16179062/using-exec-with-ndk, hinting at the possibility of exec beeing removed completely at some point - this would require refactoring rclone as a proper jni library, correct?

i doubt that will ever happen. it will break a lot apps. the whole point of this change is security. i.e. to avoid running code which is not shipped with the APK (downloading unchecked code etc.), not to prevent shipping any executable at all.

[x0b]

I agree, but there seems to be quite a panic around this, e.g. in this reddit thread.

At least for rclone, this is not the catastrophe like it is for termux and creating a jni frontend would actually be feasible.