New app: Horus

Horus puts an Alpine Linux ARM64 workspace on an Android phone (no root, no Termux) and runs coding agents (Claude Code, Codex, OpenCode) or a plain zsh shell in it. It ships its own PRoot build, a native PTY and a native terminal renderer. An optional, off-by-default feature gives a paired computer an SSH shell over USB (adb forward only; nothing listens on the network).

• Source: https://github.com/scarif-labs/horus (MIT)
• Fastlane metadata: https://github.com/scarif-labs/horus/tree/HEAD/fastlane/metadata/android/en-US

Notes on the recipe:

• srclib hermes: the React Native build normally uses the prebuilt hermesc from node_modules. The recipe deletes it and builds hermesc from the Hermes source at the tag matching the pinned hermes-compiler version instead. It is a srclib rather than a submodule because it is only a build tool for the JS bundle, not app source; happy to change that if you prefer a submodule.
• Node.js: nodejs and npm are installed from Debian forky (the build tools come from trixie first), for npm ci and the Metro bundler.
• Native code (PRoot, talloc, libandroid-shmem) is built from source in the repo with the NDK; the PRoot patches are in native/patches.
• Anti-features: NonFreeNet because the app downloads Alpine, its packages and the agents from their upstream servers, and Claude Code and Codex need provider accounts. NonFreeAdd because it offers to install Claude Code and Codex, which are proprietary.
• Reproducible builds: not used; Horus will be signed by F-Droid (final).
• ABI split: not needed, the app is arm64-v8a only (about 12 MB).

Checklist

Policy

• The app complies with the inclusion criteria.
• The original app author has been notified (and does not oppose the inclusion). If you are not the author, please paste the link of the reply from the author. (I am the author.)
• The upstream app source code repo contains the app metadata in a Fastlane or Triple-T folder structure. The summary and description must be included and images, icon, and changelog should also be provided for better user experience. The en-US locale must be included.

Docs

• Please read the guide first if this is your first contribution.
• Please make sure your metadata follows the best practice in our templates.
• Please read the Build Metadata Reference and make sure your metadata is valid.
• Please read the Quick Start Guide.

Merge Request Setup

• The title of this merge request should follow "New app: app name" format.
• Please make sure your fdroiddata fork is public and your branch is not protected. See https://docs.gitlab.com/user/project/repository/branches/protected/.
• Please read our Git guide if you don't know how to rebase your branch. Don't rebase your branch if there is no conflict.
• All related fdroiddata and RFP issues have been referenced in this merge request (none).
• Please only submit one app in one MR.

Metadata

• Metadata must be put in metadata/<applicationId>.yml.
• Metadata must be a valid YAML file.
• Metadata must use LF as line ending.
• Don't add summary/description/changelog/images or anything that should be provided in upstream repo. Please check the Changes tab to make sure there is no other unrelated files added in the MR.
• Releases are tagged and auto update is enabled unless there is a special reason.
• There is an issue tracker and contact info of the author so that we can report bugs and contact the author.
• An AuthorName must be added. It doesn't need to be the real name.
• External repos are added as git submodules instead of srclibs. (Hermes is a srclib, see the note above.)
• Enable Reproducible Builds. (Not used, F-Droid signing, see above.)
• Setup abi split if the APK is large and the splitted ones can be much smaller.
• Only the latest versions should be kept in the metadata before it's merged. If you update the metadata, please replace the old versions with the new ones.
• Don't add any disabled versions in the metadata.
• The commit field should be the full hash. Please don't use tag or branch in commit.

Pipeline

• All pipelines should pass.
• All warnings and errors in the Reports tab should be fixed or explained.
• F-Droid CI runners are under GitLab's FOSS program, so there's no need for you to pay for any CI time. If Gitlab starts asking for phone numbers or credit cards don't submit anything, just leave a note in the MR so we know we need to trigger the CI.