[JingMatrix]

attachProcess is answered inside the fork it is about. RequestAppBinder transacts for the framework binder during specialization, synchronously and with no flags, so whatever the daemon does on that path a starting application waits for.

What it did there was build the whole configuration. shouldSkipProcess reaches the readiness latch, and the latch runs performCacheUpdate under rebuildLock: every enabled module's APK parsed, its dexes read and rewritten through the slicer, its scope expanded over every user with a package manager call apiece. The first fork to arrive paid for all of it and every fork behind it waited on the same lock. Each of those processes is one AMS started, and AMS kills a process that has not attached within PROC_START_TIMEOUT, ten seconds — failed to attach, start timeout, reason 7 in dumpsys activity exit-info. #1050 reports fifteen or sixteen of them on every boot, each killed exactly 10.0 s after its Start proc, and none on a boot with the module disabled.

The rebuild moves to the one point where it costs nobody anything: main, after the four core services it needs are up and before sendToBridge publishes the binder an injected process looks us up through. Nothing can attach until that call returns, and once the latch is closed attachProcess never takes the lock again — the fast path is a volatile read. It runs on the main thread, which already blocks there, since sendToBridge waits on activity in a loop of its own, and system_server's own handshake arrives on a binder thread through the proxy name claimed at the very top of main, so that is unaffected either way.

Also here: the latch is set only if a rebuild actually published a state. It used to be set whatever happened, so a rebuild that bailed because the user service had not answered — which it refuses to read as "no module is installed", correctly, and which is likelier now that the first attempt is earlier — left an empty module set marked as the finished one: every process skipped for the life of the daemon while the framework reported itself as up. Both reasons a rebuild bails are reached before any of the expensive work, so retrying costs nothing and the next caller simply does.

Left alone: the lock itself, and the rebuild's cost. Serialising rebuilds is right, and a package install still pays for one; what changes is that no fork is behind it. Also left alone: the processes forked between the zygote starting and sendToBridge returning, which get no injection. That window already existed and this adds the rebuild to it — a few hundred milliseconds of it, on a path where the alternative was a process AMS kills.

Not tested on a device. #1050's measurement is against LSPosed 7912 rather than this daemon, so the numbers there are evidence for the shape and not for the fix.

[JingMatrix]

Low quality AI PR, didn't even check if the issue writer is using Vector at all.