Builder.equals ignores metered flag and search domains, leaving stale VPN interfaces

[kasnder]

Builder.equals (ServiceSinkhole.java:4130-4176, inherited from NetGuard) compares only activeNetwork, networkInfo type, MTU, addresses, routes, DNS and disallowed apps. It ignores:

• metered flag — a meteredness flip on the same Network triggers a reload, but the builders compare equal, so re-establishment is skipped and setMetered never reaches the live interface (apps see the VPN as unmetered over a now-metered network);
• search domains (addSearchDomain);
• ePDG excludeRoutes added per rebuild since API 33.

Also minor: unchecked cast (Builder) obj before the null check, and both-null networkInfo compares unequal, forcing needless interface replacements.

Low impact in TrackerControl today (no per-network allow/deny split), but a genuine stale-interface state. Fix: compare the missing fields or hash the fully built builder.

[kasnder]

Traced this into master. Confirmed, with one part overstated and one sharper case the report misses.

Confirmed. Builder captures only activeNetwork, networkInfo, mtu, listAddress, listRoute, listDns, listDisallowed, so equals structurally cannot see setMetered, addSearchDomain or excludeRoute.

The metered path is real. setMetered(Util.isMeteredNetwork(this)) is called on both establish paths, and NetworkReloadPolicy triggers a reload precisely on a metered flip. Same Network, identical address/route/DNS/disallowed lists → builder.equals(last_builder) is true → we take the "Native restart" branch only, so the new metered value never reaches the live interface. getAllowedRules computes metered but returns the rules unchanged, so nothing else in the comparison differs either. Stale state confirmed.

Sharper case the report misses: excludeRoute. The ePDG VoWiFi exclusions are re-resolved on every rebuild behind a 1.5s timeout. If the first establish timed out and a later rebuild resolves them successfully, equals suppresses the re-establish and VoWiFi stays broken until some unrelated change forces a real replacement. That is a user-visible breakage, and a better motivation for this fix than the metered flag.

Overstated / non-issues.

• Search domains only change with LinkProperties, and that path almost always changes DNS too, which equals does compare — mostly moot.
• The "unchecked cast" complaint is a non-issue: casting null is legal in Java, and only Builder instances are ever compared.
• Both-null networkInfo returning false is real but only causes extra replacements while offline.

Fix sizing and the risk that matters. ~25 lines in one file. The catch is that the fix deliberately produces more interface replacements, which walks straight into the known ParcelFileDescriptor close race — so this should land together with the replacement sequencer, not on its own. It also overlaps ServiceSinkhole.java with the currently-open #752 and #768.

Verdict: fixable-aligned, but sequence it behind the replacement-race work.