Skip to content

Add xraycore-compatible probing and policy-group warm-start#201

Open
eliotcougar wants to merge 1 commit into
2dust:mainfrom
eliotcougar:fix/android-network-switch-state-upstream-core
Open

Add xraycore-compatible probing and policy-group warm-start#201
eliotcougar wants to merge 1 commit into
2dust:mainfrom
eliotcougar:fix/android-network-switch-state-upstream-core

Conversation

@eliotcougar

Copy link
Copy Markdown

Summary

This PR adds Android network-switch recovery, policy-group warm starts, and low-overhead bulk outbound probing without requiring any new xray-core functionality.

It is a more limited alternative implementation of #200 that doesn't require changes to xray-core. It uses the existing xray-core lifecycle, router override, BurstObservatory.Check, GetObservation, and balancer principle-target APIs. Scheduled Observatory behavior remains unchanged.

Network-switch recovery

  • Recreates the running Xray instance after Android changes the VPN underlay.
  • Keeps the Android-owned TUN file descriptor and VPN service active.
  • Sequentially closes the old instance before creating the replacement, avoiding overlapping instances and process-global state corruption.
  • Closes network-bound TCP, UDP, mux, and transport-pool state so new connections use the current Wi-Fi or cellular network.
  • Retries the original configuration if replacement startup fails and reports both errors if recovery also fails.

Policy-group warm start

A known previously successful policy-group outbound can be applied as a router override while the replacement Observatory gathers fresh measurements.

The warm-to-observed transition is an acknowledged handoff:

  1. Observatory produces a viable fresh strategy target.
  2. OnBalancerTargetChanged reports it to the embedder.
  3. The embedder acknowledges it by returning zero.
  4. Only then is the warm override removed.

A nonzero callback result retains the warm route and retries the notification. Override inspection or release failures are also retried.

If Observatory is slow or never produces a viable target, the known warm route remains active instead of leaving the balancer without a usable outbound.

Progressive bulk probing

The single-use OutboundProbeController is intended for a short-lived dedicated process and supports:

  • Validating source configurations before combining a batch.
  • Probing many outbounds through one Xray instance.
  • Bounded configuration-level concurrency.
  • Grouping all candidates belonging to one UI/profile configuration.
  • Concurrent candidate checks inside an active policy group.
  • A serialized progressive callback after each candidate finishes.
  • Partial results on cancellation.
  • Final balancer principle targets for least-ping and least-load policy groups.

ProbeOutbounds remains available as the flat compatibility API. ProbeOutboundGroups preserves higher-level configuration boundaries, allowing v2rayNG’s True delay concurrency setting to retain its original per-profile meaning.

Why this belongs in AndroidLib

The current v2rayN method of bulk probing, apparently vilolates the intended workflow where only one xray core should be run in a single process. Running temporary xray cores in the same process as the main core can corrupt the main core.

Running one temporary native core per outbound is expensive for Android and other constrained embedders. This adapter provides finite, reliable bulk probing through one disposable process while depending only on xray-core’s existing public behavior.

Verification

  • go test .
  • go test -race . with the workspace MinGW-w64 race toolchain
  • Four-ABI gomobile AAR build
  • Warm-route callback ordering and acknowledgement tests
  • Stalled-Observatory warm-route retention test
  • Progressive policy-group result test
  • Configuration-group concurrency-boundary test
  • Cancellation and partial-result tests

Recreate Xray safely across Android underlay changes, preserve policy routes through an acknowledged warm handoff, and provide progressive grouped outbound probes using only the existing upstream observatory and router APIs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant