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
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