Kindness mode has a habit of quietly not being on anymore. This traces the three ways that happens and closes each of them.

The stopped proxy that keeps running (#1183). enableProxy() takes its lock, then does the real work in a coroutine that has no lock at all. A stopProxy() that lands before that coroutine runs sees proxy == null, does nothing, and the coroutine then starts a proxy nothing owns. The service stops and restarts the proxy on every network callback, so this window gets hit in normal use, and an orphaned proxy is a plausible source of the CPU drain reported there. Starts now carry a generation number: if a stop or a newer start won while the ports were being mapped, the late start closes its own mappings and never calls start().

There is a second copy of the same race one layer down. IPtProxy's Start() flips its isRunning flag inside a goroutine it spawns, and its Stop() is a no-op until that flag is set, so a fast stop is silently ignored and the proxy comes up anyway:

go func() {
    sp.isRunning = true
    err := sp.proxy.Start()
    ...
}()

func (sp *SnowflakeProxy) Stop() {
    if sp.isRunning {
        ...

That matches cohosh's shutdown race hypothesis in the issue. The app cannot fix the library, but it can stop dropping its reference too early: after stop(), the wrapper watches the instance for two seconds and stops it again if it came up late. The remainder, if any, is upstream in IPtProxy.

The service that stays dead (#1799, #1783). START_STICKY is the only thing that brought the service back, and sticky restarts get throttled, abandoned after repeated kills, and never delivered at all on some builds. The only re-arm paths were opening the app or toggling the switch, which is why people find the proxy off hours later. The pref is already the user's standing intent, so it gets honored now: OnBootReceiver starts the service after a reboot when kindness mode is on, and a 15 minute WorkManager watchdog (the dependency was already in the app) restarts it when it is wanted, allowed in this region, and not running. The watchdog cancels itself when the user turns kindness mode off. A background start denial on 31+ is caught and left for the next boot or app open. This will not resurrect the service inside a stopped GrapheneOS work profile, nothing can, but within a running profile the watchdog covers the kill-and-forget case.

The port mappings that outlive the process (#1795). Mapped UPnP ports lived in one in-memory list, so any abnormal termination left them open on the router until the lease expired, with nothing on the next launch knowing they existed. The mapping is written to prefs before the proxy starts, cleared on clean release, and releaseStalePorts() closes whatever a dead run left behind on the next service start.

Fixes #1183, fixes #1799, fixes #1795. Helps #1783 within what the platform allows.

Compatible with #1805: this deliberately stays out of initNetworkCallbacks(), so both apply cleanly in either order.

Verified with the unit suite (eleven new tests: the start-commit and watchdog decision tables, and the port record parsing) and assembleFullpermDebug, both clean. I do not have a device farm, so the multi-hour soak that #1799 describes is exactly the test this needs from someone who does. Happy to adjust anything.

One thing I noticed but left alone, since it is outside these issues: the preference listener in SnowflakeProxyService.onCreate returns early unless a key equals two different constants at once, so the region kill switch and the camo refresh there look unreachable. Can file separately if useful.