Agree with that; probably this would mean a library rewrite, right?

a library rewrite

Not really, if you take a look at the initialize part of the library, you'll notice that we'll only need a valid zip file to be unzip to the hardcoded destination, despite of where the zip file comes: downloaded from somewhere or extracted from apk (appContext.applicationInfo.nativeLibraryDir)

Yess. Well seen

Where this zips would be hosted?

Where this zips would be hosted?

Similarly, we can host these binaries in the release section of a separate GitHub repository

Where this zips would be hosted?

Similarly, we can host these binaries in the release section of a separate GitHub repository

It's a good idea.

Here is some additional input if anyone is interested in this: the executable files themselves (libpython.so, and libffmpeg.so), need to be packaged and shipped along with apks. And the files which can be downloaded, unzipped and loaded are the dependencies of the executables (libpython.zip.so, and libffmpeg.zip.so)

This change is introduced in Android 10: https://developer.android.com/about/versions/10/behavior-changes-10#execute-permission

To ensure that dependencies are downloaded and loaded after the first cold start, we need to design a reliable process that includes exception handling, downloading progress tracking, and the ability to detect and apply updates online. We should also consider which parts of this process should be implemented in the library itself and which parts should be left to the library's users (app developers).

Additionally, we should maintain the original method of loading dependencies from the APK or external files, since network connections are not always reliable or simply for compatibility.

Here is some additional input if anyone is interested in this: the executable files themselves (libpython.so, and libffmpeg.so), need to be packaged and shipped along with apks. And the files which can be downloaded, unzipped and loaded are the dependencies of the executables (libpython.zip.so, and libffmpeg.zip.so)

This change is introduced in Android 10: developer.android.com/about/versions/10/behavior-changes-10#execute-permission

Exactly what I thought. We can leave packaged in the library those two first and the ones left, downloaded from a hosting service or even GitHub Releases.

To ensure that dependencies are downloaded and loaded after the first cold start, we need to design a reliable process that includes exception handling, downloading progress tracking, and the ability to detect and apply updates online. We should also consider which parts of this process should be implemented in the library itself and which parts should be left to the library's users (app developers).

Additionally, we should maintain the original method of loading dependencies from the APK or external files, since network connections are not always reliable or simply for compatibility.

We could use Ktor Client or maybe OkHttp for the downloading process, downloading the files in the tmp folder of the app data directory, and after that, unzip it and move the dir to the executable's directory

Hi, I'm back with some news. I've made a branch where I will try to achieve this; the ability to download the packages in-app and not to make them be present at the build time increasing the app size. By the moment I have just created the files downloader with Ktor Client. Any other progress will be told here.