refactor(lsposed): hook ConnectivityService getters instead of writeToParcel

[okhsunrog]

Background

The current LSPosed hooks live on Parcelable.writeToParcel() of NetworkCapabilities, NetworkInfo, and LinkProperties (HookEntry.kt:209-211). Inside each hook we look up the caller via Binder.getCallingUid() and, if the caller is in the target list, write a sanitised copy into the parcel instead.

This works for the common case (a target app calls ConnectivityManager.getActiveNetworkInfo() over Binder; the response is serialised in system_server in the same Binder context; getCallingUid() returns the right UID). It is, however, architecturally fragile.

Problem

writeToParcel() is called in many contexts where the current Binder calling UID is not the eventual recipient of the parcel:

• Sticky broadcasts — ConnectivityService posts CONNECTIVITY_ACTION (and friends) with EXTRA_NETWORK_INFO. Serialisation happens on ConnectivityService's handler thread; whether getCallingUid() returns the original requester, SYSTEM_UID, or stale state from the last incoming transaction depends on Android version and timing.
• NetworkCallback fan-out — one NetworkCapabilities object is sent to N subscribers. Modifying it once based on "some" caller's UID is semantically wrong.
• Internal persistence / dump / cache fill — same risk.
• IpcDataCache (Android 11+) — ConnectivityManager caches results client-side. Server-side writeToParcel modification interacts oddly with the cache invalidation protocol.

In addition, the writeToParcel hook fires for every serialisation of these objects across the system, even when the caller is not in our target list; for non-targets we exit early after a Set.contains(), but the dispatch itself plus reflection access in the entry block (getLongField etc. for the bail-fast check on NC) is still per-call overhead.

Symptoms reported

#16 — multiple users on Magisk Kitsune report apps hanging on infinite loading (Ozon, Home Assistant, unofficial 4pda client, slow Chrome cold start) even when the affected app is excluded from the VPN Hide target list, or never added. I am not yet 100% sure this refactor fixes that specific report — it might be unrelated Magisk Kitsune zygisk overhead — but the underlying architecture is brittle regardless and worth fixing on its own.

Proposal

Move filtering to server-side getters in com.android.server.ConnectivityService — specifically:

• getActiveNetworkInfo, getActiveNetworkInfoForUid, getNetworkInfo, getNetworkInfoForUid, getAllNetworkInfo
• getActiveNetwork, getActiveNetworkForUid, getAllNetworks
• getNetworkCapabilities, getLinkProperties, getActiveLinkProperties
• getDefaultNetworkCapabilitiesForUser

Each of these runs strictly inside the incoming Binder transaction from the requesting app, so Binder.getCallingUid() is the real caller without ambiguity. We replace the result via param.result = ... in afterHookedMethod. AOSP version differences in method signatures are handled by hooking by name and walking declaredMethods.

Open questions / TODO

• NetworkCallback path — the writeToParcel approach was the only thing covering callbacks. For target apps that subscribe to NetworkCallback, callback delivery sends NetworkCapabilities / LinkProperties to the app's process. Need to figure out the right hook for that. Options:
  • Hook IConnectivityManager#registerNetworkCallback and wrap the messenger
  • Hook in zygisk on the client side
  • Keep writeToParcel as a fallback only for the messenger fan-out path
• Network handle hiding — getActiveNetwork() / getAllNetworks() return opaque Network handles. Hiding a VPN here means returning null / filtering the array, which requires a cross-call lookup of which Network is the VPN. Skeleton has a TODO.
• IpcDataCache invalidation — when our list of targets changes, we likely need to nudge ConnectivityManager to drop its cache for the affected app(s).
• Wire up ConnectivityServiceHooks.install(...) from HookEntry with the actual sanitising lambdas (currently those lambdas live as private helpers in HookEntry and need to be extracted / made callable).
• Decide rollout — feature flag, or just replace?
• Test on Android 11 / 12 / 13 / 14 / 15 — method signatures vary; need to confirm declaredMethods walking finds everything we expect on each.

What this PR actually contains right now

A skeleton file ConnectivityServiceHooks.kt with the hook installation scaffolding, the list of methods to cover, and the dispatch table for sanitising results by type. It is not wired into HookEntry yet, so there is no behaviour change. The skeleton is intentionally compile-only so this PR can be merged (or kept as draft) without risk while we work through the open questions above.