Fix Termux/Android compatibility issues (DNS, locking, Android target support)

[wallentx]

Codex CLI currently fails on native Termux/Android due to DNS resolution and unsupported lock semantics in this environment. This PR adds compatibility adjustments that allow:

• Authentication and request execution to succeed on Termux/Android.
• Lock-based session persistence to work without runtime errors.
• Reproducible Android build artifacts in CI for easier validation and testing.

The changes preserve existing behavior on non-Android platforms.

---

Changes

DNS/Resolver fixes

• Apply Android/Termux-specific resolver fallback path while preserving normal resolver behavior elsewhere.
• Fallback chain for resolver config:
  1. system config,
  2. $PREFIX/etc/resolv.conf,
  3. a deterministic fallback.
• Register both UDP and TCP entries for nameservers.
• Add tests covering parsing, protocol registration, and environment detection.

---

Graceful handling of unsupported locks

• Detect and handle std::io::ErrorKind::Unsupported from try_lock() without failing.
• Allow session preference flows (e.g., “press p” to auto-accept) to proceed when locks are unavailable.
• Adjust affected unit tests to consider environments without file-locking support.

---

Android build target support in CI

To produce and validate builds targeting Android (e.g. native Termux):

• Add aarch64-linux-android target in GitHub Actions.
• Install and configure Android NDK in CI workflow.
• Configure Cargo linker, CC, and AR for the Android target.
• Enable vendored OpenSSL for Android builds.
• Adjust keyring target dependencies for Android.

This enables CI to build Android artifacts that include the compatibility adjustments above, which aids testing and validation.

---

Validation

• just fmt
• cargo test
• Verified on a real native Termux/Android device (no proot/chroot):
  • Authentication succeeds.
  • Interactive requests complete.
  • Session preference persistence works.
  • No regressions observed on existing targets.

[robertkirkman]

Hi, do you know if this will continue to work with, and maybe improve, https://github.com/termux-user-repository/tur/blob/cf26feef42820d03b7061866ee5f456324657a7a/tur/codex/build.sh ?

[wallentx]

Hi, do you know if this will continue to work with, and maybe improve, https://github.com/termux-user-repository/tur/blob/cf26feef42820d03b7061866ee5f456324657a7a/tur/codex/build.sh ?

The current TUR provided codex is impacted by the issue that my PR resolves, so if I get an invite to PR upstream, this should fix at least the locking issues.
I'll need to fork TUR and point it here to see what the build produces.

I had some code change logic to handle the absence of /etc/resolve.conf on android, but found that simply adding an aarch64-linux-android target made all of that unnecessary.. but if this never gets merged upstream, I could provide a patch with that original conditional logic so that this can be fully solved via patches in the TUR. Are you a maintainer, @robertkirkman ?

[robertkirkman]

I had some code change logic to handle the absence of /etc/resolve.conf on android, but found that simply adding an aarch64-linux-android target made all of that unnecessary.. but if this never gets merged upstream, I could provide a patch with that original conditional logic so that this can be fully solved via patches in the TUR. Are you a maintainer, @robertkirkman ?

Yes, I have merge permission for TUR. If you want users of Codex on TUR to get this fix, you could also submit this to https://github.com/termux-user-repository/tur/pulls and I would be able to approve it there, and then whenever this version gets merged the patch could be removed from the TUR version when it gets updated.

[wallentx]

Upstream, they have made a prerelease for rusty-v8 that they are using to test artifacts against their release binaries https://github.com/openai/codex/releases/tag/rusty-v8-v147.4.0
I am going to see if I can bring in that workflow to mirror their pre-release, and put the logic that builds the android artifacts on top of that that I have from https://github.com/wallentx/rusty_v8/releases/tag/v146.9.0

Then I can mirror their upstream prerelease for rust-v8-v147.4.0 which will also include my android artifacts, and this PR might actually be suitable for upstream merging.