[jauntywundrkind]

> Almost every Android version imposes new major restrictions when it comes to security requirements, and specifically the Android 10 version update was dramatic for Termux usage, as it disallowed executing downloaded files directly.

> The Termux app avoided that by using a targetSdkVersion of Android 9, declaring that it was not compatible with the Android 10 requirements.

Android level 9 is from Android 2 Gingerbread (2010!!). https://apilevels.com/

For now it's not a huge barrier to Termux running. We can go run Android 2 stuff today, & maybe Android will forever be backwards compatible.

It does mean that Termux can't build a top or use any new Android features. Termux is glued to a truly ancient version of Android, because Android became inhospitable to basic Linux userland use cases. Seems its mostly about being unable to run downloaded code, which feels admittedly like very much "just a technicality", but boy oh boy has that technicality kept Android from expanding outside of its own bespoke userland.

[jraph]

> > The Termux app avoided that by using a targetSdkVersion of Android 9, declaring that it was not compatible with the Android 10 requirements.

> Android level 9 is from Android 2 Gingerbread (2010!!). https://apilevels.com/

Wait, no, Termux is not stuck at Gingerbread, it's stuck at Android 9 (Pie).

Agree with the rest though. Android is a sinking ship, not only the Termux issue, but the increasing number of basic apps and features that are proprietary and not part of AOSP. I hope we'll be able to be caught by Linux Mobile or something like this in time.

[jauntywundrkind]

Apologies! I originally posted Android 9 Pie (2018), but had doubt & switched to the SDK version. My mistake!!

The AI age where the AI needs to be able to peak into all the apps will hopefully create a new API / MCP age, new machine-to-machine work. I'm not sure how much of what Google is doing today is proprietary, adding hooks into all their apps and creating some means for Gemini to access that all, and how much is paved road & available for others. Very curious to know more.

[zozbot234]

Right, Android target levels are so different in how they behave towards applications that they're practically best treated as distinct OS's to begin with. There's really no such thing as a unified Android or iOS, unlike Windows or desktop Linux where even a program from the mid-1990s will run unmodified in the latest version of the OS.

[jraph]

> Android target levels are so different in how they behave towards applications that they're practically best treated as distinct OS's to begin with

You can run applications running different target levels side by side though

> desktop Linux where even a program from the mid-1990s will run unmodified in the latest version of the OS

mhm... I wish but that's not so true for Linux. Your old program will likely be missing some dynamic library or be incompatible with your current libc. Desktop Linux userspace is awfully unstable, compatibility is broken left and right, basically no one cares except the Linux kernel itself. There's a reason people jokingly say that win32, through wine, is the most stable Linux API. If you still have the source code of your program (and the linux ecosystem is full of free software so that's likely), you can always recompile but you'll probably need to edit the code so it's compatible with the current versions of libraries).

I've heard macOS is not great at this neither.

[charcircuit]

>Termux is glued to a truly ancient version of Android, because Android became inhospitable to basic Linux userland use cases.

No, this only a problem with Termux's approach of trying to put all apps into a single app. One Linux app should correspond to one Android app. This also makes it so that permissions you grant to the app is not to all of termux, but to a specific app.

[jraph]

> trying to put all apps into a single app

That's not exactly what it does, it dynamically downloads the programs using apt-get.

I get the security benefits of preventing the execution of data stuff, but building one Android app for each binary is difficult to work with.

[charcircuit]

>it dynamically downloads the programs using apt-get.

And then runs them as the Termux app. I didn't mean to imply that it put all of the apps into itself at build time.

>Android app for each binary is difficult to work with.

You could group multiple binaries that belong to a single conceptual app into a single android app. What do you think would make it difficult to work with? I think most of it could be automated away.

[zozbot234]

The principled way of doing this (while coping with the new post-Pie restrictions) would be to build a new "updated" .apk on-device with a new /usr/bin/ equivalent, then have the user explicitly "install" it and relaunch Termux. It would work no different than any live-CD install, or for that matter any other kind of "immutable" OS.

[jraph]

But then, everything runs under the same Termux user app again, just with extra cumbersome steps. And I'm not sure it's possible to do this safely, you need the APK to be signed, and the only way to do this would be to share the private key. And likely to have a good chunk of the Android SDK bundled with Termux. A version that runs on Android anyway.

Not sure it would fly with Google's Play Store policies.

to your parent:

> And then runs them as the Termux app. I didn't mean to imply that it put all of the apps into itself at build time.

ok, got you

[zozbot234]

Yes but you could just have a custom private key that's generated by a separate "apk builder" app and stored on-device.