Termux is amazing. I have coded up Python and Go basic web services to test it out. Then opened localhost and they work. Heck I did it with Emacs and a bluetooth keyboard.
You can fit 5 fairly large-font lines or 4 huge-font lines with the phone sideways (for the big keyboard).
I like hackin' on it with a bluetooth keyboard so the whole phone display is my terminal -- if I could just find my ideal folding keyboard, or perhaps one of those recent sliding-keyboard revival phones
I like the iClever Wireless Folding Keyboard - mini version. It's tiny and easy to carry with a phone. You need to be a little more careful with where some keys are.
Not applicable for general Android programming, but I had lots of fun with LÖVE for Android. It's a port of 2D gaming library for Lua language. The API is really well designed and simple to remember.
The app can can open and interpret source files (and fonts, sprites, sounds...) from internal memory. You could build everything from scratch on the phone without PC. Text editing is a pain, so I used it mainly to tweak constants and fix bugs.
I've briefly been without a usable computer (but with several usable phones) a couple times recently, and attempted to use Android or iOS for development. The result was that I learned to do everything on the command line, and I learned to use vim. Thankfully I have a working computer again, but I doubt if I ever would have put in the effort to learn things the hard (but better) way otherwise.
Enjoy it while it lasts, folks. Google policies forbid running of binaries that did not come from the original app APK or a Google Play download, and these are enforced with SELinux policies. I think recent Termux releases get around this with ptrace-based chicanery, but Google can and probably will plug that hole in a later release.
> Enjoy it while it lasts, folks... I think recent Termux releases get around this with ptrace-based chicanery, but Google can and probably will plug that hole in a later release.
FTR, Termux team announced the end of Android 5.x/6.x support on 2020-01-01.[0]
I fail to find any specific references to these policies forbidding use of executables not embedded in the apk. Not saying it's wrong, it's just news to me. Does it apply only to apps published via Google Play?
"An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism. Likewise, an app may not download executable code (e.g. dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine and has limited access to Android APIs (such as JavaScript in a webview or browser)."
It will always be possible to run outside code in a sandboxed VM, since this is needed for JIT in web browsers and the like. So as soon as the WASM w/ WASI interface becomes good enough to run interesting development apps, Termux will be able to use that. Running a whole-system VM ala QEMU based on, e.g. RISC-V code (easier to interpret or emulate than other archs and becoming supported by many Linux distributions now) is another feasible approach.
Honestly that doesn't sound like a terrible idea. It sucks for the tiny minority of people doing development on their phones but let's face it, most apps running binaries from the Internet really shouldn't. The only reason a "normal" app would do this is to work around the AV scanning that Google does.
I don't think Google should add permissions or warnings for this either as that doesn't help because people are clicking through warnings already.
Too bad termux will fall victim to this. Hopefully some of the Magisk / Xposed folk will find a workaround that will allow specific apps to execute binaries again so that Termux will work for those that rely on it.
> I don't think Google should add permissions or warnings for this either as that doesn't help because people are clicking through warnings already.
There's nothing preventing them to add a developer mode enabled by typing a few lines of code in a terminal (hard for unknowledgeable users), that sounds like an excuse to remove user rights.
If they do that, people will put those lines in guides on "how to get [pirated app name] working 2019 confirmed working" and people will disable their security regardless.
There's a trick to bypass any certificate warning errors in Chrome: it involved typing "badidea" into the error screen. Google had to update the code word because large vendors started putting the phrase into their documentation instead of fixing their buggy applications. It's only a matter of time until the code phrase changes again. This proves to me that secret phrases and magic developer toggles will just be made invalid by guides aimed at less technical folk which tell people to ignore warnings.
For it to work it needs to be something dynamic the user has to do involving multiple steps, like reading into a file and using the content somewhere else, all in a terminal with unix commands. Or something else dynamic and difficult if you're not used to terminals.
And I don't think a few users getting abused with this trick is sufficient enough to remove the feature altogether, that's their device after all. The alternative of removing everything seems much worse.
That could work for security if it's only possible to do so from an authenticated environment (such as ADB) and if the OS will flag the danger any time an app is opened that uses this feature. However, I think such a system is a complete maintenance horror for a problem very few people have.
There are 2.5 billion Android devices out there and only 5 million people have ever installed Termux, let alone compiled and run their own binaries. Would you, as a developer, implement a workaround for disabling an OS security mechanism for _at most_ 0.2% of your user base, most of which will probably work around it themselves by flashing an Magisk module anyway? What about the need to validate and maintain the workaround so that malicious apps can't find a vulnerability to disable the feature themselves? It doesn't make business sense to me. Android is already full of backwards compatibility hacks to make sure apps don't break too quickly, especially when they're doing stuff that you wouldn't expect.
App developers can still provide modules to the Play Store (grouped packages can access each other's data as far as I know) so the most valid use case I can think of aside from compiling your own code (optional video codecs) would already be covered. Python interpreters and Java runtimes would work just fine as well, so programmers whipping up a quick program on their tablets are still able to do so.
The only victim are people who compile their own binaries on their phones. I don't think their use case is worth risking disabling a very valid security mechanism.
> Would you, as a developer, implement a workaround for disabling an OS security mechanism for _at most_ 0.2% of your user base, most of which will probably work around it themselves by flashing an Magisk module anyway?
I wouldn't write the code to disable the functionality of the device.
Obviously, that means I wouldn't end up on the team to begin with. So it goes.
> only 5 million people have ever installed Termux
Only?
Granted, it's Google, who makes that kind of evaluation (see also: killing products that could be a whole company because they "Google scale"), but it still seems like throwing away that many users is eventually going to come back to bite them.
Keep in mind that download numbers are severely inflated. I have downloaded termux at least 5 to 10 times over the years and I've only really used it once or twice.
Just because someone installs an app doesn't mean they use it every day. Reading the reviews, most people seem to just use it as a basic terminal emulator, like there are so many on the play store.
Those people aren't going to notice anything about no longer being able to compile executables.
If you package the compiler with termux and output the APK to a shared location, nothing about this article will change after Google's future modification.
> I don't think Google should add permissions or warnings for this either
When I buy a phone, it's my phone. Not Google's, not Apple's, not anyone else's: it's mine. And I have a fundamental human right to run any software on my property that I wish.
It's one thing for Google to impose limitations on what apps available from the Play Store may do: I may always sideload anything I wish. But to impose limitations on what sideloaded apps may do is unconscionable.
To paraphrase another hackernews: Freedom is nice, but it comes with tradeoffs that for whatever reason buyers aren't willing to make right now.
A restricted platform provides security guarantees that total freedom cannot provide, No matter what kind of magic incantation the OS vendor hides the "I know what I'm doing, let me run what I want on my own device" mode behind, some normie end-user schlub is going to find it on the internet as part of a malware author's instructions to download pirated video or games and get infected. Multiply that by a few thousand or million and that's a big black eye for Android the platform. That's a chunk of total Android devices infected with malware that iOS just doesn't have. Why? Because Apple did the smart thing and locked everything down from the beginning.
So yes, for Android the openness genie is going back into the bottle. Get used to it. In the current environment of billions of always-on, always-networked devices, we can't afford to let them all run arbitrary code. You are free to purchase a phone whose vendor respects your freedom, but those are niche items and likely to get rarer.
That's fine. It's your phone, so you decide if you want Google's software or not. You can pick if you want to enable selinux, inject WireGuard kernel modules or render all fonts upside down for what I care.
If you want to do that, you're going to have to run your own software though. If what you want isn't in line with what Google wants, you're going to have to make your own Android configuration or modify an existing one. There is no law saying you can't disable security features, but there's no law to prevent Google from implementing features you don't like either.
By the way, sideloaded apps have always been limited, as some permissions are only available to APKs signed with the same key as the OS.
If you want to run apps that can do everything they want, you're going to have to put in work to disable some of the security layers that have been stacked on top of Android over the years.
But doesn't this project fix that problem? If you package your locally-built binary into an APK and install it, then the binary did come from the original APK.
The point is that you can build the app and package it into a (local) APK file, and then just install that APK file the same way as any other APK you download. It's as legitimate as installing an APK from any other source.
Wired: Distribute on F-Droid
Enlightened: make && make install