Arguing from first principles, the first step in detecting a problem is to know your device's baseline operation. This means knowing the bevvy of processes that are running, the resources they use, and the messages they send and to which hosts. With this baseline, you can now see if something is going wrong - a process you don't recognize, connecting to hosts you don't recognize, and so on.
Of course, this is also the step where almost everyone, including devs, fail. How many devs know their phone to this degree? Even for our laptops, we tend to give way too much leeway to 3rd party binaries, and allow the environment to get so noisy that any kind of signal is impossible to detect. It's a depressing trade-off we (almost) all make for convenience, using the (almost) good enough assumption that we're safe in the herd. It's actually a very, very dumb assumption and I feel like it's something of a hacker golden age because of it, and as long as they don't get too greedy and spook the herd, the gravy train is here to stay.
On argument against doing even this is that a hacker can take steps to hide their process. This has happened on PCs, with rootkits that hide certain processes. This may happen for phone malware, if only to make it harder to automate detection and removal, if not to guard against watchful users (of which there are precious few).
In terms of capability, I speculate that the best an attacker can achieve is a sticky, privileged process that accepts arbitrary commands at runtime, which can be used to read the disk, analyze other running processes, install and exfil sensor data, etc. From the attacker's POV for high value targets, it probably feels like ssh'ing into a mystery box, and "see what you can do" - and they probably have a (growing) library of scripts to check for easy, juicy things. (I would guess that they would hate to see bespoke applications that have to be understood and reversed to get value out of.)