You need an "app" for everything, they can hardly interact with each other, they can get killed at any time, and without rooting (which is subverting how the system is meant to be used) all sorts of things are crippled (from filesystem access, to using a firewall, to freaking setting a different volume for every app).
And the limitations increase with every Android release
They have a proper, standard, high-level way of interacting with each other, literally the whole OS is built around than. Read up on android services, intents, etc. It is eons better than dbus-ing and writing to random files all over my home dir is that linux desktops do.
Killing stuff from time to time is literally an advantage for a system - look at the battery life of a linux desktop or a pinephone. You have to make apps ready for a possible suspension, otherwise they just keep on draining the battery. Besides, services can be called from an active activity, or binded by one and then they will not be killed under normal circumstances.
I don’t want a random app to read my browser caches/ssh keys, etc, but if you like any random repo you download having access to your personal files, you do you.
Intents are only standardized for a few categories, they're slow (you routinely have to wait for the app chooser to load and scroll to the app you want) and not scriptable.
And the calling app can very well be killed by the loading of the called one.
> Killing stuff from time to time is literally an advantage for a system
Killing stuff that I want to have running is literally maddening. Ever wanted to have music in the background, and to not have the player killed at random times?
Or, to have files moved in the background (with the painfully slow SAF) without them getting randomly corrupted?
Or any other thing you'd need to go on while you check out something else?
> You have to make apps ready for a possible suspension
After 15 years the apps that do that reliably, whatever they're doing, are still exceedingly rare; not surprisingly, since software has never been developed in that way, doing it would require constant writing to the persistent storage, and even Android itself provides few facilities to make it more feasible.
And even when that's done correctly, getting back to the saved state often takes time.
> I don’t want a random app to read my browser caches/ssh keys
I want a specific app to read my browser cache/ssh keys or any other file if I need it to.
And yes, I'd like to limit an app's access to what it needs, but on Android it's either all (shared storage) or nothing.
File providers? Yeah, except that it requires the app that has the file to offer them, and very few do.
And one app I'd like to allow access to everything is a backup app; but no, to protect me Google requires me to upload everything to its servers (for what it even allows to be backup up).
And thankfully I can't use SD cards in any meaningful way, to protect me from myself.
For Android security means protecting the apps from the phone's owner, rather than the other way around
How are intents not scriptable? I have an app that can literally call any other intent, but I can even write a bash/python script and run it from Termux to execute whatever I want. Look up the `am` executable.
Re the “killing stuff” paragraph sounds like a memory size issue - frankly, in that case killing something is a better option than desktop linux’s tendency to just freeze the hell up. Just for reference, on a modern low-end samsung I had no such experience.
After 15 years: android’s activity life cycle doesn’t make them constantly save stuff — there is a pause and stop lifecycle events that are appropriate places for saves to happen. Android will attempt to gracefully stop applications, unlike desktop linux’s oom killers. And this model works exceedingly well, you just don’t even notice it, only when it occasionally couldn’t clear enough memory and has to resort to killing.
I haven’t tried doing backups recently, I believe that it is not as streamlined as it should.
That's ONE intent, and not even between two apps...
Have you ever had to pipe more than two applications to operate on something (image, video, whatever)? Or actually, more than one, since in your solution one app is am, or your intent-calling app?
> Re the “killing stuff” paragraph sounds like a memory size issue
Whatever it is, how about asking what to do, instead of assuming that users only care about the foreground app? (I risk smashing my monitor every time I read that in the documentation)
> And this model works exceedingly well, you just don’t even notice it
Nope, I notice it all the time, since apps are more likely to get killed than let to gracefully stop, in my experience.
I heard that the latest Samsung One UI versions behave better, though
> look at the battery life of a linux desktop or a pinephone
Desktops generally don't have a battery. My laptops have perfectly good battery running assorted Linux distros. The pinephone sucks but mostly for hardware reasons; I suspect you would find Android on that hardware to also suck.
> I don’t want a random app to read my browser caches/ssh keys, etc, but if you like any random repo you download having access to your personal files, you do you.
If you must download random untrusted code and execute it, then you should run it inside bubblewrap/firejail/docker.
> I suspect you would find Android on that hardware to also suck
Not at all, android is smooth as butter on even significantly worse hardware.
> if you must download random untrusted code and execute it, then you should run it inside bubblewrap/firejail/docker
There is no if, this is the case for everyone, and thus the default should be sandboxed. Plus, a sandbox should have appropriate channels to communicate with other sandboxes, otherwise you are not ahead even a bit. Just think about a memory unsafe program like a PDF reader opening an untrusted file. It is already ripe for executing arbitrary code, no need for compiling stuff.
