esefxdzandClaude Opus 5
4e5c7a02db
Core recovery could never succeed, and every attempt left a live
libxray.so behind.
startCore() calls startTimer(), which builds a CountDownTimer and so a
Handler on the calling thread. handleXrayCoreExit() runs recovery on a
bare Thread, so the constructor threw "Can't create handler inside
thread ... that has not called Looper.prepare()" and took the whole
restart down with it. The catch then deleted the ephemeral config and
returned false without killing the process pb.start() had already
started, so each retry stranded another core.
Measured on an emulator by killing the live core:
before 1 -> 5 -> 6 -> 8 processes over 120 s, never recovers
after "Xray core recovered without dropping TUN" on attempt 1,
exactly 1 process
startTimer now posts to the main looper, re-checking RUNTIME_TOKEN
inside the post so a stop that lands while it is queued cannot leave a
timer running for a dead generation. stopTimer posts too, so the
countDownTimer field is only touched from one thread. The catch clears
xrayProcess before destroying it, so the monitor thread's
`xrayProcess === process` guard fails and recovery is not re-entered
for a core being killed here.
Pre-existing on main; reachable whenever the core exits.
Co-Authored-By: Claude Opus 5 <[email protected]>
flutter_vless_android
The Android implementation of the flutter_vless plugin.
Runtime
Android runtime binaries and geodata are delivered through the Maven Central AAR dependency dev.tfox.fluttervless:xray-android:26.7.11. This keeps the Pub.dev package lightweight while preserving the same packaged Xray files in the final Android app.
Do not add raw android/src/main/jniLibs or geodata files back to this package. Rebuild runtime files in android_runtime/xray_android/src/main, publish the Maven AAR, then publish this wrapper package.
Emulator Support
The current Maven runtime AAR includes armeabi-v7a, arm64-v8a, x86, and x86_64.
This covers both physical Android devices and Android emulators.