`package_name` routing misidentifies apps that share UID (e.g. Termux + addons)

Operating system

Android

System version

A10

Installation type

sing-box for Android Graphical Client

If you are using a graphical client, please provide the version of the client.

1.12.16

Version

Description

Environment:

• sing-box core: 1.12.16
• Client: Android GUI app
• OS: Android 10
• Inbound: TUN (router rules using package_name)

---

Description

When multiple apps share the same Android UID, package_name route rules do not work correctly. sing-box appears to resolve the UID to a single package name (the first one it finds) and uses only that for matching, making all other packages with the same UID effectively unmatchable.

Example: Termux and its addon com.termux.styling share the same UID. All connections originating from Termux are seen and matched as com.termux.styling by sing-box, so rules targeting com.termux never match.

---

Expected behavior

• sing-box should correctly distinguish and match the actual originating package when multiple packages share the same UID, or at least provide a deterministic and configurable way to target each package.
• Traffic from Termux should match rules for com.termux, not be attributed to another package sharing the UID.

---

Actual behavior

• sing-box looks up package names for the UID, takes the first one, and uses it for matching.
• All traffic from apps sharing that UID is treated as coming from that single package.
• In the Termux example, all Termux-related connections are seen as com.termux.styling, making rules for com.termux unusable.

---

Additional notes

• This likely affects any setup where system apps or other apps share a UID (e.g. via android:sharedUserId), not just Termux.
• A more robust approach might be to:
  • Use more precise process/package resolution when available, or
  • Expose UID-based matching directly and document the limitation, or
  • Provide a way to list and select which package name to associate with a given UID.

Reproduction

1. On Android 10, install:
   • com.termux
   • com.termux.styling (or any addon sharing Termux’s UID)
2. Configure sing-box Android client (1.12.16) with a TUN inbound.
3. Add route rules using package_name, for example:
   • One rule matching com.termux
   • Another rule matching com.termux.styling
4. Generate network traffic from Termux (not from the styling addon).
5. Observe which package_name sing-box reports and which rule is matched.

Logs

Supporter

• I am a sponsor

Integrity requirements

• I confirm that I have read the documentation, understand the meaning of all the configuration items I wrote, and did not pile up seemingly useful options or default values.
• I confirm that I have provided the server and client configuration files and process that can be reproduced locally, instead of a complicated client configuration file that has been stripped of sensitive data.
• I confirm that I have provided the simplest configuration that can be used to reproduce the error I reported, instead of depending on remote servers, TUN, graphical interface clients, or other closed-source software.
• I confirm that I have provided the complete configuration files and logs, rather than just providing parts I think are useful out of confidence in my own intelligence.

Reproduce the issue on Android 10 with sing-box 1.12.16, Termux, and com.termux.styling using TUN routing and package_name rules. Trace the Android package_name resolution for a shared UID and determine whether the originating package can be distinguished. Done means traffic from Termux and its addon is matched consistently, or the supported UID-based limitation is explicitly defined and documented.