add xray-core tun mode

[dfliaoyue]

It is completed with github copilot agent, with several tests and changes. It seems to work well on my phone.
As I'm an amateur, although I have found some reference sources and provided to copilot, I cannot check whether the codes by AI are clean and efficient enough.

1. Add a toggle in setting screen to choose hev tun or xray tun.
2. Add xray tun support. To use xray tun, tun outbound must be included in the config. It is architecture for xray tun mode (generated by copilot) below:
   Kotlin: nativeSpawnXray(xrayPath, filesDir.path, vpnFd)
   │
   │ JNI 调用 → libxray-exec.so (xray_exec.c)
   ▼
   C 代码内部:
   pipe(stdin_pipe) # 用于传 config JSON
   pipe(stdout_pipe) # 用于读日志
   fork()
   │
   ├─ 父进程 → 返回 {pid, stdout_read_fd, stdin_write_fd} 给 Kotlin
   │
   └─ 子进程（独立进程！）
   dup2(stdin_pipe[0], STDIN)
   dup2(stdout_pipe[1], STDOUT/STDERR)
   dup2(vpn_fd, 4) ← 关键！绕过 FD_CLOEXEC
   close_extra_fds(keep=4)
   execve(xray_path, ...) # Xray core 仍是独立子进程
3. Fix connectivity check and app/geosite/geoip update for xray tun mode, as in xray mode socks inbound should not be configurated. After trying different ways, only the chosen way is somewhat avaliable and secure: restart xray core with additional socks inbound (random local address, port, user and password), complete the task, and if new task is required, use the same socks inbound, and after all tasks complete, restart xray core with no additional inbounds.

[maxtom25]

HandlerService API seems like a bad idea (security hole / backdoor). API port randomization and 127.x.x.x address is valid protection for "harmless" StatsService, but not for HandlerService.
HandlerService is used to create temporary SOCKS inbound for connection test only. If connection test from the App is required it is much easier to create (add in user config) a dedicated SOCKS inbound routed to a specific test address for example.

[dfliaoyue]

HandlerService API seems like a bad idea (security hole / backdoor). API port randomization and 127.x.x.x address is valid protection for "harmless" StatsService, but not for HandlerService.
HandlerService is used to create temporary SOCKS inbound for connection test only. If connection test from the App is required it is much easier to create (add in user config) a dedicated SOCKS inbound routed to a specific test address for example.

I don't think a persistent socks inbound is secured either, which exposes socks proxy and port. May you find a cleaner and better way? Or maybe just disable the connectivity check in xray tun mode?

[dfliaoyue]

HandlerService API seems like a bad idea (security hole / backdoor). API port randomization and 127.x.x.x address is valid protection for "harmless" StatsService, but not for HandlerService.
HandlerService is used to create temporary SOCKS inbound for connection test only. If connection test from the App is required it is much easier to create (add in user config) a dedicated SOCKS inbound routed to a specific test address for example.

I found dat download and update check are broken because of the same reason. Sing-box android can download new version and rule-set files, its method may be applied here.

[maxtom25]

I don't think a persistent socks inbound is secured either, which exposes socks proxy and port.
Sing-box android can download new version and rule-set files, its method may be applied here.

Mihomo and probably sing-box include themself into addAllowedApplication and use protected sockets to communicate outside. With a native xray-core running there is a very limited control and almost no way to implement it this way.
But, same 127.x.x.x:rand trick can be used for a special SOCKS inbound with connections limited to a specific set of domains / ports / etc. SOCKS listening on 127.x.x.x:rand with almost all connections routed to direct is way less of a hole or a fingerprint in comparison to Xray API "hidden" the same.
As far as I can see SimpleXray concept is: it is up to me to configure, no hidden / inserted sub configs, etc. and HandlerService is a very different way to go.

"inbounds": [ { "tag": "con_test", "listen": "127.1.2.3", "port": 12345, "protocol": "socks", "settings": {"auth": "noauth"} } ]
"routing": { "domainStrategy": "AsIs", "rules": [
{ "type": "field", "inboundTag": ["con_test"], "domain": ["full:www.gstatic.com"], "outboundTag": "proxy" },
{ "type": "field", "inboundTag": ["con_test"], "outboundTag": "direct" } ] }

[dfliaoyue]

I don't think a persistent socks inbound is secured either, which exposes socks proxy and port.
Sing-box android can download new version and rule-set files, its method may be applied here.

Mihomo and probably sing-box include themself into addAllowedApplication and use protected sockets to communicate outside. With a native xray-core running there is a very limited control and almost no way to implement it this way. But, same 127.x.x.x:rand trick can be used for a special SOCKS inbound with connections limited to a specific set of domains / ports / etc. SOCKS listening on 127.x.x.x:rand with almost all connections routed to direct is way less of a hole or a fingerprint in comparison to Xray API "hidden" the same. As far as I can see SimpleXray concept is: it is up to me to configure, no hidden / inserted sub configs, etc. and HandlerService is a very different way to go.

"inbounds": [ { "tag": "con_test", "listen": "127.1.2.3", "port": 12345, "protocol": "socks", "settings": {"auth": "noauth"} } ] "routing": { "domainStrategy": "AsIs", "rules": [ { "type": "field", "inboundTag": ["con_test"], "domain": ["full:www.gstatic.com"], "outboundTag": "proxy" }, { "type": "field", "inboundTag": ["con_test"], "outboundTag": "direct" } ] }

I shall abandon the handleAPI method, but still cannot accept a persistent socks even with random local address, port and credentials. I prefer using temporary socks to perform those tasks by restart xray core with temorarily changed config, which may cause some problems only when the tasks are running.

[maxtom25]

I shall abandon the handleAPI method, but still cannot accept a persistent socks even with random local address, port and credentials. I prefer using temporary socks to perform those tasks by restart xray core with temorarily changed config, which may cause some problems only when the tasks are running.

May I suggest: check for user defined (in prefs? or may be in config with predefined name), if none restart with temp inbound? TCP only inbound with just a few domains allowed seems harmless to me, but other might prefer short lived temp inbound.

[dfliaoyue]

I shall abandon the handleAPI method, but still cannot accept a persistent socks even with random local address, port and credentials. I prefer using temporary socks to perform those tasks by restart xray core with temorarily changed config, which may cause some problems only when the tasks are running.

May I suggest: check for user defined (in prefs? or may be in config with predefined name), if none restart with temp inbound? TCP only inbound with just a few domains allowed seems harmless to me, but other might prefer short lived temp inbound.

I have considered it but abandoned the thought. Because user-defined inbound may be attached to complex route rules. Well too many methods may increase the complexity, I will make current way available now.

[maxtom25]

I have considered it but abandoned the thought. Because user-defined inbound may be attached to complex route rules. Well too many methods may increase the complexity, I will make current way available now.

App compiled from your repository fails to start Xray (in any mode) on my devices (Android 13 and 11, unrooted). Seems like exception in xray-exec (tricky to catch as it is native code). Releases in your repository are based on week old source (no TUN, etc.), thus cannot check precompiled (just in case it is build issue somehow).

[dfliaoyue]

I have considered it but abandoned the thought. Because user-defined inbound may be attached to complex route rules. Well too many methods may increase the complexity, I will make current way available now.

App compiled from your repository fails to start Xray (in any mode) on my devices (Android 13 and 11, unrooted). Seems like exception in xray-exec (tricky to catch as it is native code). Releases in your repository are based on week old source (no TUN, etc.), thus cannot check precompiled (just in case it is build issue somehow).

Well I may misunderstand the release build process...Try build #89 or #93 in action in my fork. Maybe some codes don't support older android? Lhear has set java to 21, is the recent build by lhear (only hev tun) works?

[dfliaoyue]

I have considered it but abandoned the thought. Because user-defined inbound may be attached to complex route rules. Well too many methods may increase the complexity, I will make current way available now.

App compiled from your repository fails to start Xray (in any mode) on my devices (Android 13 and 11, unrooted). Seems like exception in xray-exec (tricky to catch as it is native code). Releases in your repository are based on week old source (no TUN, etc.), thus cannot check precompiled (just in case it is build issue somehow).

Try build #97 in my fork too. #89 and #93 should be the same, and #95 has some changes (All work on my phone android 16). Tell me whether #95 works, and if not, please describe the bug and present log if possible. If #97 works and you are using per app proxy (allowed app mode, rather than disallowed mode), perhaps it's because a change causes conflict, which was intended to fix connectivity check problem using socket method (failed) but became unnecessary for current temp socks method.

[maxtom25]

Try build #97 in my fork too. #89 and #93 should be the same, and #95 has some changes (All work on my phone android 16). Tell me whether #95 works, and if not, please describe the bug and present log if possible. If #97 works and you are using per app proxy (allowed app mode, rather than disallowed mode), perhaps it's because a change causes conflict, which was intended to fix connectivity check problem using socket method (failed) but became unnecessary for current temp socks method.

Synced up to commit 58a5492 (fix in xray_exec), starts fine in both modes. Running in TUN mode without any issues so far.

[dfliaoyue]

Try build #97 in my fork too. #89 and #93 should be the same, and #95 has some changes (All work on my phone android 16). Tell me whether #95 works, and if not, please describe the bug and present log if possible. If #97 works and you are using per app proxy (allowed app mode, rather than disallowed mode), perhaps it's because a change causes conflict, which was intended to fix connectivity check problem using socket method (failed) but became unnecessary for current temp socks method.

Synced up to commit 58a5492 (fix in xray_exec), starts fine in both modes. Running in TUN mode without any issues so far.

Actually there is a cleaner way: unix domain socket for API, and http proxy on unix domain socket for delay test and asset download.