Stop a patched app from depending on the manager being alive

[JingMatrix]

A manager-backed patch asks the manager for its modules the moment the app starts, and the manager is an ordinary app. On a device that reaps background processes, or after someone force-stops it, that bind goes unanswered: the app then started with no modules, no explanation, and five seconds of its own start-up already spent waiting. Keeping an ordinary app alive is not a fight that can be won, so this work does not try to. It makes the manager's absence survivable, its return automatic, and its uptime something to ask for only after those two hold.

The patched app now keeps its own copy of the module list. After any successful query it records identity alone — which module, which APK, and what the manager said about it — and loads from that copy when the manager does not answer. The code itself is read from the module's installed APK by the same step the served path uses, so a restored module and a served one are the same dex from the same file; only the origin of the list differs. That step became a single shared function, since the embedded, served and restored paths differed in what they passed to it rather than in what they built. Because a miss is no longer fatal, the bind budget falls from five seconds to one and a half. What the copy cannot carry is a change made while the manager was unreachable, which is the price of loading anything at all in that state.

The binding is kept and re-established rather than made once. A manager reaped for memory returns on the binding that still exists; a force-stop breaks that binding for good and is rebound explicitly, with a growing delay. Reconnecting restores everything the previous manager process was holding: the channel it drives a hot reload over, which modules this process is running, and a live service for each module the hook still holds. Each module's service is now an object belonging to the host, forwarding to whichever manager binder is current. It has to be: the framework keeps what it is given for the life of the process and nothing re-delivers it, and it keeps its client only while it can take a binder from that service and watch it die. Everything the interface offers is read-only, which is what makes caching it safe — a cached value is an older read, never a conflicting one.

Presence is handled separately, and modestly. The foreground service that existed only for log collection now carries it generally, and stands down when nothing on the device is patched. A receiver restores it after a reboot and after the manager is updated, those being the two broadcasts a foreground start is permitted from. Where the person has granted Shizuku, a watchdog inside the shell user service starts the manager again when it finds it gone; that process runs as the shell user and is not what a background reaper or a force-stop acts upon, and a start issued from the shell also clears the stopped state a force-stop leaves behind. It is off unless asked for, since reviving a process someone has just force-stopped is the opposite of what they asked the system to do.

What a device does is reported rather than inferred. A patched app that had to start without the manager carries the count to the next bind that reaches it, because the one party able to notice was the one not running. Asking the shell to lift the platform's background limits reports each request as the device answered it, and distinguishes a limit the device does not have from one it has and withheld — four of the five are AOSP, while the auto-start operation belongs to particular vendors, so a phone that has never heard of it has nothing to refuse.