What about development on-the-device?

- 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

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.

Having bytecodes doesn't mean being interpreted.

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].

[0]: https://issuetracker.google.com/issues/128554619

[1]: https://www.youtube.com/watch?v=HUEvRyemKSg

> > 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.

Keeping those APKs updated and rebuilt is work.

How would binaries compiled on the device differ from those downloaded from the internet?

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.

You can run binaries you compiled either. On device dev is essentially pointless.

You can run interpreters, but possibly in a restricted context in the future.

s/can/can't

Are there any SELinux + Android experts there? Do you know if there is a way to alter the policy to undo this change with root privileges without disabling SELinux enforcement entirely? It fundamentally seems like it should be possible; I just don't know how. It would get around the issue very nicely if someone can figure out how, since I imagine many people with Termux also have root.