Note that there are 297 hidden items in that issue so you have to click "Load more..." ceil(297/60) times to read all of the comments about how APK packaging is soon necessary for latest Android devices so the termux package manager can't just dump executable binaries wherever.

FWIU:

- Android Q+ disallows exec() on anything in $HOME, which is where termux installed binaries that may have been writeable by the executing user.

- Binaries installed from APKs can be exec()'d, so termux must keep APK repacks rebuilt and uploaded to a play store.

- Termux shouldn't be installed from Google Play anymore: you should install termux from the F-Droid APK package repos, and it will install APKs instead of what it was doing.

- Compiling to WASM with e.g. emscripten or WASI was one considered alternative. "Emscripten & WASI & POSIX" https://github.com/emscripten-core/emscripten/issues/9479

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.

Sadly, since January 1st, 2020 Termux team dropped[0] support for Android 5.x/6.x, so actually in F-Droidrepo it now requires minimum Android 7.x:

> Support for Android 5.x.x - 6.x.x is dropped forever. Time to upgrade your devices or learn how to backport git changes.[1]

And this part from Termux devs reply is especially cynical:

> ... Time to upgrade your devices...[1]

It looks like they has a contract with devices manufacturers...

... No, I no need such type of "app improvements in new version" which require me to buy a new device.

FTR, In F-Droid Archive[2] repo there is still Termux v0.75 for Android 5.x/6.x (which I'm using on Ido device), but it is horrible because Termux packages repo for Android 5.x/6.x are now disabled[3] too.

[0] https://github.com/termux/termux-app/issues/1516

[1] https://github.com/termux/termux-app/issues/1407#issuecommen...

[2] https://apt.izzysoft.de/fdroid/index/apk/com.termux?repo=arc...

[3] https://github.com/termux/termux-packages/issues/4467

It is not Termux devs fault that many phone manufacturers fail to handle OS upgrades.

They are not obligated to support them, feel free to support all Android versions at once in your project.

Precisely. If you want long-term support, don't use Android in the first place.

Or at least buy phones where at least some support is promised.

> It is not Termux devs fault

This reply to Termux user is Termux devs fault:

> ... Time to upgrade your devices...[0]

[0] https://github.com/termux/termux-app/issues/1407#issuecommen...

If someone is stuck on Android 6 due to failure to deliver OS updates then it is still fault of whoever manufactured such device.

And a bit of failure to buy something where there are updates.

Why would you expect them to continue supporting a 5 year old OS version?

Because most devices can't be updated? Supporting version 4+ gives you a much larger audience than limiting to version 7+.

I think this was a very logical thing for them to do.

Supporting platforms that old comes with a massive amount of headaches. It is hard enough for big teams of applications with high MRR to do, and is near impossible for a FOSS application to do in perpetuity.

Because 5 year old isn't really that old. My Android 5 powered phone (which is my only phone) works perfectly fine, the only annoyance i have with it is that it has become sluggish - but that is the fault of software developers bloating their code (the software pretty much does the same stuff as it did when i got the phone years ago), not of the phone itself.

Note that i do not expect someone to do free work for me, i just do not consider a 5 year old device "old" enough to be weird for it to be supported - especially when it works just fine.

I know some people do this for iOS, so I would have expected it to almost be the norm on Android where many devices frequently fall behind on updates.

> I know some people do this for iOS

Apple devs has a smart trick how to declare you to buy new iPhone {n+1} just next day after it out: Apple devs just may decrease performance of your previous iPhone {n} fully remotely without any prompts to you and without your permission.[0]

And such remoted control over users costs only $500M single pay - not too much as for Apple at all.[1]

[0] https://news.ycombinator.com/item?id=15965119

[1] https://news.ycombinator.com/item?id=22465829

Because its community driven FLOSS project.

And it would "OK" if there would no releases with new features... but bug fix releases which is worse.

Instead, team (owner & core members) just dropped & disabled everything, leaving Android 5.x/6.x device owners in frozen state.

Even more, team not proposed itself & ignored any proposition from others to at least support Termux for Android 5.x/6.x in LTS-way.

I think 5 years of support is reasonable.

No.

Beside Android 5.x/6.x devices, I has Symbian 9.x (Nokia N82) smartphone which works perfectly. And there are a lot of new apps for it:

- https://old.reddit.com/r/symbian/new

P.S. My 10+ year-old laptop perfectly works with latest MX Linux distribution (based on Debian 10 buster) and all modern FLOSS desktop apps (GIMP, FreeCAD, Inkscape, etc.) works like a charm on it.

So, software devs should NOT declare users to buy/upgrade hardware.

Phone manufacturers certainly ought to offer 5+ years of OS updates. Apple does, after all. So I agree with you to that extent.

But if users want third parties volunteers to support devices whose vendors have already dropped support? If there are no volunteers wanting to do the work, the work doesn't get done.

The bad guys here are the phone vendors, not the Termux developers IMHO.

> The bad guys here are the phone vendors, not the Termux developers IMHO.

Here is Termux devs reply to Termux user:

> ... Time to upgrade your devices...[0]

Who is bad guy here according this quote?

P.S. It would not be so bad if devs just says "we don't support such devices", but instead devs declared to upgrade device in reply to user...

[0] https://github.com/termux/termux-app/issues/1407#issuecommen...

I'm not seeing a problem there?

I mean, I'll admit its tone is quite direct - I guess they could have copy-pasted some corporate-speak about what a difficult decision it was and how very sorry they were about having to make it, instead of being so direct and unambiguous. But that's pretty trivial IMHO.

Now that just comes off as being written by someone who feels very entitled to the hard work of others.

If you feel so strongly about it, why don't you fork the project and continue integrating upstream features and fixes for those on pre 7.x devices? Or would that take too much of your own time to do?

If you're committed to sticking with a really old phone and want to use Termux, you should switch to a custom ROM based on more modern Android. Android 5 and 6 are ancient at this point.

So regardless the amount of work it involves and how few people use them, e.g. 6-year old devices should always be supported?

With PC the compatibility is quite a success story, but hardly the standard.

It's an open source project. Feel free to pitch in, sponsor, or shut the fuck up .

> Feel free

And I feel free to tell my personal POV on this situation, as you and everyone else.

While i do not agree with the expectation that others should do work for free, 5 year support is really short when the devices work perfectly fine. Why contribute to e-waste and force people spend money they may not have when that isn't necessary?

5 years is okay for a phone, but once you subtract the time it takes for Android releases to get into new phones it can be a problem. Hopefully the manufacturer releases OS updates! Hopefully.

For an open source project, yes. There aren't enough people to really work and maintain this thing.

But in general, hell fucking no. 5 years is terribly short sighted. Look at how much e-waste is piling up. We can't really recycle phones. They get shipped to Asian and African countries where people melt down the plastic without adequate ventilation and extract out all the metals they can in OSHA free environments.

We should be designing things to be as useful as possible for as long as possible.