Recover native tunnel failures safely

[kasnder]

What changed

• keep the user's protection intent enabled after transient native tunnel exits
• retry native tunnel startup with a bounded 1–16 second exponential backoff
• stop retrying after five attempts and tear down the service cleanly to prevent restart storms
• reset retry capacity after a stable run or an explicit user restart
• pass native errno values to the service and provide a clear file-descriptor exhaustion error
• avoid duplicate exit reports when epoll setup cannot proceed

Why

A transient native tunnel failure previously disabled protection immediately and required user intervention. Repeated failures also lacked a bounded recovery policy. This change automatically repairs short-lived failures while retaining a finite budget for persistent faults.

User impact

Protection now recovers automatically from transient native tunnel failures. Persistent failures still surface an error and stop after a bounded number of attempts instead of creating a restart loop.

Validation

• ./gradlew assembleGithubDebug testGithubDebugUnitTest -x wgbridgeBuild
• native compilation completed for arm64-v8a, armeabi-v7a, x86, and x86_64
• focused unit coverage for backoff, exhaustion, stable-window reset, explicit reset, clock reset, and file-descriptor exhaustion detection

The bridge rebuild task was excluded from the final post-rebase run because it stalled without output; it is unrelated to this change and the existing bridge artifact was used. The same branch passed a complete assembly and unit suite, including that task, before rebasing the single implementation commit onto the current default branch.

[kasnder]

Verdict: Solid recovery design, but one release-only blocker — a stale ProGuard keep rule will strip the renamed JNI callback and crash the exact path this PR hardens.

Blocking

• app/proguard-rules.pro:38 — the keep rule still lists void nativeExit(java.lang.String);, but this PR changes the method to void nativeExit(int, java.lang.String). release has minifyEnabled = true (app/build.gradle:186), so R8 runs; the new 2-arg method has no Java caller (it's invoked by name from JNI, invisible to R8), and line 24's -keepnames only prevents renaming of surviving members, not removal — the explicit -keep block at lines 37–46 is what actually retains these callbacks. Since line 38 no longer matches the new signature, R8 can strip/rename nativeExit(int,String). At runtime jniGetMethodID(env, cls, "nativeExit", "(ILjava/lang/String;)V") (netguard.c:538) then returns NULL and the following CallVoidMethod aborts — i.e. the native-failure path this PR adds crashes in release. The PR's validation only built the debug variant (no minify), so this wasn't exercised. Fix: change line 38 to void nativeExit(int, java.lang.String);.

Should fix

• ServiceSinkhole.java nativeExit(int,String) — showErrorNotification(displayReason) fires on every native exit, before the recovery decision. A transient failure that auto-recovers within ~1s still raises a hard error notification, and for non-FD reasons it surfaces the raw technical reason string to the user. This partly contradicts the "recovers transparently" goal; consider notifying only when the budget is exhausted (NO_RETRY), or using a softer transient message.

Nits

• session.c (epoll_ctl tun setup) — the two earlier setup failures now goto cleanup, but the epoll_ctl tun failure only sets stopping = 1 and relies on fall-through into the while (!stopping) guard. Correct today, but asymmetric and fragile if code is later inserted before the loop; a matching goto cleanup would be consistent.
• ServiceSinkhole.java — tunnelThread was made volatile here, but the recovery runnable also reads vpn (written on the command looper) without volatile/synchronization. Minor visibility gap; consider making it consistent. (unverified impact)
• NativeFailureRecoveryPolicy.onFailure — initialDelayMs << failures is safe for the shipped config (max shift 4) but would overflow / shift past 63 for a large maxRetries; guard or document, since the class is generic.

What's good

• JNI migration is otherwise complete and consistent: all 8 report_exit call sites (session.c ×4, ip.c ×4) updated, plus the declaration (netguard.h) and definition (netguard.c:535); jniCheckException still guards the upcall so a Java-side failure can't crash the VpnService.
• The added goto cleanup genuinely fixes a real duplicate-report bug: previously epoll_create failure fell through and re-reported via epoll_ctl on a negative fd.
• Recovery is properly bounded and battery-safe — 1→16s backoff, 5 attempts, then a clean stop — with a synchronized policy, cancellation on start/stop/onDestroy, and re-validation inside the runnable, so no restart storm.

Automated review by Claude Opus 4.8 (agent-assisted).

[kasnder]

The implementation now looks sound and the earlier release blocker is fixed. One small user-facing correction before merge: msg_native_fd_exhausted promises an automatic restart if capacity remains, but nativeExit displays it only on the terminal NO_RETRY path, and nativeError displays it without initiating recovery. Please make the text truthful for both call sites (or split the messages). Otherwise I found no blocker. Merge after #621, rebase and resolve the ServiceSinkhole overlap, then rerun CI plus a release/minified build because this changes a JNI callback keep rule.

[kasnder]

Implemented in d3195f0: split the shared FD-failure text into a terminal recovery-exhausted message and an immediate native-error message, so neither call site promises a restart it will not perform. Focused recovery-policy tests and a minified assembleGithubRelease pass locally. Non-base locales intentionally fall back to English until the normal translation workflow catches up.