- It seems C compiled with clang on the device wouldn't be executable? (If it was, that would be a way around the restriction: distribute packages as source, like the good old days)
This seems a promising solution: compile from source, create an apk, install - your custom distribution! For popular collections of packages, a pre-built apk.
- Java might be explicitly blocked, being a system language for android, even though its byecode is interpeted and not exec()ed.
- Other interpreted languages should be OK e.g. python
DEX bytecode is compiled to native code since Android 5, Android 7 introduced a multi-layer where it is intepreted only to get the first execution profile for the JIT, then the JIT gathers PGO data while executing, which will be used by AOT compiler when the device is idle, afterwards only the pure machine code binary executes until the next update, or loading code that wasn't touched by the JIT.
As of Android 10, PGO data files are uploaded into the store and shared across similar devices so that the AOT compilation with PGO can be done right away on installation.
Unfortunately not. The underlying mechanism they're using to enforce this is essentially: if your app can write to a directory, it can't execute from that directory.
Apparently this is plugs a vulnerability known as W^X. See their explanation in the issue here[0]. Personally I would love to know how many real-world exploits they can blame on this specific vulnerability, stacked up against the number of truly useful apps like Termux that have now been hamstrung.
Also, this leaves the state of running native executables on Android as something of a joke. Any executable you want to run has to be named `lib<exe_name>.so`, and included in your jniLib directory at build time.
It's clear what side GOOG has picked in the war on general-purpose computing[1].
> > offer users the option of generating an apk wrapping their native code in a usable way.
> This seems a promising solution: compile from source, create an apk, install - your custom distribution! For popular collections of packages, a pre-built apk.
FPM could probably generate APKs in addition to the source archive and package types that it already supports.
The conda-forge package CI flow is excellent. There's a bot that sends a Pull Request to update the version number in the conda package feedstock meta.yml when it detects that e.g. there's a new version of the source package on e.g. PyPI. When a PR is merged, conda-forge builds on Win/Mac/Lin and publishes the package to the conda-forge package channel (`conda install -y -c conda-forge jupyterlab pandas`)
The Fedora GitOps package workflow is great too, but bugzilla isn't Markdown by default.
Yeah, I think you're right: you could download instead of compile, it's just the assembling into an apk on the device that has the advantage of customizing exactly what you want.
- It seems C compiled with clang on the device wouldn't be executable? (If it was, that would be a way around the restriction: distribute packages as source, like the good old days)
> offer users the option of generating an apk wrapping their native code in a usable way. https://github.com/termux/termux-app/issues/1072#issuecommen...
This seems a promising solution: compile from source, create an apk, install - your custom distribution! For popular collections of packages, a pre-built apk.
- Java might be explicitly blocked, being a system language for android, even though its byecode is interpeted and not exec()ed.
- Other interpreted languages should be OK e.g. python