New app: USBridge Client (io.usbridge.client)

App

USBridge Client (io.usbridge.client) — hybrid remote-access client: BIOS-level KVM control via USBridge-KVM hardware, plus a lightweight software remote desktop over the Moonlight streaming protocol (interoperable with Sunshine and NVIDIA GameStream-compatible hosts).

• Source: https://github.com/USBridge-Technologies/USBridge-Remote
• License: GPL-3.0-only (root-level LICENSE file added)
• This recipe targets the dedicated "market" Gradle flavor, which has the app's self-update path (internal/update) compiled out entirely via a Go build tag (noselfupdate) and does not request REQUEST_INSTALL_PACKAGES.

Build recipe status

The init/build/gradle steps in this recipe have been validated end-to-end against F-Droid's own real buildserver (this MR's own CI: fdroid rewritemeta / fdroid lint / fdroid build / check apk all green).

Along the way this also caught and fixed a couple of real project-level bugs (not F-Droid-specific), now also fixed upstream in the app's own build script:

• gomobile bind -target android (no ABI suffix) silently builds all four Android ABIs; scoped to -target android/arm64 since the app only ships arm64-v8a.
• An untargeted NDK clang defaults to API 21, which gates out libaaudio/libvulkan regardless of -L search paths; the recipe targets API 26 explicitly (matches minSdk).
• unzip (no -o) hangs on an interactive overwrite prompt (no TTY) when a later Builds: entry's steps re-extract into a path an earlier entry's steps already populated in the same job/VM -- hit this while an earlier (since-removed, never-released) 2.1.13 entry was still present; fixed with -o regardless, since it's cheap insurance for whenever a second entry gets added back for a future release.

Required

• The app complies with the inclusion criteria
• The original app author has been notified (and does not oppose the inclusion) — I am the developer/maintainer
• All related fdroiddata and RFP issues have been referenced in this merge request — no RFP was filed beforehand, went straight to this MR
• Builds with fdroid build and all pipelines pass
• There is an issue tracker and contact info of the author so that we can report bugs and contact the author (GitHub Issues: https://github.com/USBridge-Technologies/USBridge-Remote/issues)

Strongly Recommended

• The upstream app source code repo contains the app metadata (summary/description/changelog) in a Fastlane folder structure — added at client/android/fastlane/metadata/android/en-US/ (no screenshots yet)
• Releases are tagged and auto update is enabled — deliberately AutoUpdateMode: None/UpdateCheckMode: None: this app's versionCode is derived from client/VERSION, not the git tag itself (tags bundle all platforms under one release, e.g. v2.1.16), and this recipe's build steps are custom enough (Go/NDK/gomobile/moonlight-common-c from source) that unattended rebuilds aren't realistic anyway — see docs/fdroid/README.md in the source tree for the full reasoning and the manual-update-per-release process this project follows instead.

Suggested

• External repos are added as git submodules instead of srclibs (client/moonlight-common-c, see submodules: true)
• Enable Reproducible Builds — tried and reverted: the buildserver rebuild did not byte-match the officially released APK (classes.dex/baseline-profiles/every Go+cgo-built .so differed). This app cross-compiles Go+cgo+NDK native code, which needs real reproducibility engineering (pinned toolchain, SOURCE_DATE_EPOCH, deterministic linker flags) not done yet -- documented in MaintainerNotes as a known gap, not blocking.
• Multiple apks for native code — single arm64-v8a ABI only, not applicable