1. You can only execute binaries together if they're signed by the same key. 2. Each person has to have a unique signing key. 3. If a user wants to execute a pre-existing software, and something compiled by themselves, both need to be signed by the same key. 4. This means you need to re-package and sign every single program you'd ever want to use together with your own code again, in new packages, and submit it all to Google Play.
This means every Termux user that would want to ever run gcc would have to
(a) submit every single hello world they write to the play store to try it. And every single run requires a full app update, and (b) additionally repackage and submit all linux packages, signed with their own key, to the Play Store.
This means to even compile and run Hello World, you need to submit several hundredthousand packages to the Play Store, wait for approval, and download them all.
Yet at the same time, Google Chrome can use WebAPK and auto-generate APKs on the fly with custom code and install them on the device without going through the Play Store.
The alternative of course is not being able to use a phone as general purpose computing device, but considering Google advertised Android as exactly that, that's getting close to fraud on Google's part, removing functionality after a sale.
As well as programming environments.
I use a couple of them to code on the go.
- ProtoShade
- Pydroid
If you mean a classical shell, I guess something like Another Term might do.
They write in the description:
- Full-featured Terminal Emulator, with a readline support (available in pip).
- Built-in C, C++ and even Fortran compiler designed specially for Pydroid 3. It lets Pydroid 3 build any library from pip, even if it is using native code. You can also build & install dependencies from a command line.
So when SElinux comes to Android this app will be broken, too.
Those apps are affected by the same rules as Termux.
And yes you need to install application extensions via the store, so what?
Writing your own code and executing that is explicitly forbidden. Be it REPLs or compiler suites. That too would have to go through the store. Only interpreters are allowed.
The other issue is obviously that you can’t have an extension developed by person A for an app developed by person B. It’s very common to see mods, plugins, addons whatever you may call them on many other platforms, but Android explicitly forbids this.
Just use Android IPC mechanisms instead of trying to copy UNIX patterns.
I even managed to get .NET core running on my tablet. There's a real possibility to do real work, everything you're suggesting is a toy at best.
For real work there are laptops and desktops.
Why have all this power if all I can do is play Candy Crush?
Also, plenty of musicians, painters, designers, writers do real work on Android, my previous remark about real work was playing devil's advocate.
Yes, plenty of musicians, painters, designers, can do real on Android. We cannot. The unix nonoculture, as you call it, is effectively programmer culture -- even Microsoft has included Linux with Windows now. Supporting a Linux user land on Android would be easy (given it's Linux kernel roots) and instantly give developers a massive library of software to work with.
In 12 years, not a single decent useful developer tool has ever been built natively for Android. With a few small moves, Google could give developers 50 years worth of software to be productive with. Instead they continue to make it more difficult.
Adroid is productive enough for me to have some coding session while having a coffee or a short train trip.
As of the existing solutions being lacking, don't wait for Google, produce it, and sell it on the store.
Business opportunity, as one of my beloved teachers used to say.
Honestly, Apple should have gone with BeOS and I look forward to Fuchsia.
What does that even mean?
> Apparently the 10 years I spent programming across 8 bit and 16 bit platforms
At the time you never touched a command line or a compiler? You keep replying to but you haven't gotten anywhere near a point.
> As of the existing solutions being lacking, don't wait for Google, produce it, and sell it on the store.
You can't even build it -- the store is now restrictive enough that an honest to goodness compiler that produces runnable executables is impossible. That's the whole point.
We can't even make Turbo Pascal for Android.
The funny thing there are plenty of existing solutions that work just fine right now but Google keeps tightening the screws.
Apples huge success with developers on Mac OS definitely resulted from it's Unix abilities. WSL on Windows is Microsoft's direct response to that. You might hate Unix but denying its utility is futile.
And command lines that were 100% unrelated to UNIX, just like some that exist today on Android, written in Java/Kotlin.
A command line doesn't need to be yet another bash clone.
WSL on Windows is Microsoft's marketing to FOSS developers that rather give money to Apple to build their beautiful GNU/Linux apps instead of supporting Linux OEMs, and required to have Docker, the 2020 NoSQL.
Turbo Pascal for Android is called Kotlin.
It's an option but it's pretty terrible. It's basically the state of the art on Android and it gets worse from there.
> A command line doesn't need to be yet another bash clone.
No, but if your platform already runs Linux then it's a pretty good choice. Plus, at this point, it has the largest body of code/scripting available. I don't want a command line that doesn't run anything just like I don't want an OS that doesn't run anything.
> Turbo Pascal for Android is called Kotlin.
Kotlin runs on Android?
Kotlin is the main official language since 2 years now, it shows how much you know Android.
It literally does. It doesn't run GNU/Linux. And the native non-Java API is usable by Android applications so it's not just an implementation detail. In fact, I suspect most games are developed this way. This shows how much you know about Android. Google even calls this the Native Development Kit.
> Kotlin is the main official language since 2 years now
Kotlin doesn't run on Android. You need a "real" computer to run Kotlin. It's not an Android native development tool. Why you bothered to bring it up when it's outside the scope of this conversation, I don't know.
https://developer.android.com/kotlin
So my phone is a real computer.
Here find out the Linux APIs on the NDK.
https://developer.android.com/ndk/guides/stable_apis
ISO C and C++ standard libraries
OpenGL, Vulkan, OpenSL, OpenMax, Khronos standards
Android specific native APIs.
Zero Linux specific APIs.
Any OS can provide them, and most of them are already on Fuchsia.
And what's wrong with it? It may be implementation detail but termux increases utility of the phone. It seems you always have an axe against UNIX / FOSS ecosystem to grind. But every system has its strengths and weaknesses, Unix is just too ubiquitous for what it is worth. Look at fuchsia, while having laudable goals, has already become quite complicated (in typical Google project manner).
UNIX compatibility is also what keeps C alive, actually.
Want a CLI? The Java APIs on Android provide all the required features.
Do you also want me to teach you Android Java or Kotlin?