Add support for the android-arm64 architecture

[SamarArey]

This extension does not support the android-arm64 architecture. I tried to install it on a android-arm64 machine, and it failed due to the lack of an available binary. Would you be able to update the extension's build and release process to include the relevant binary? For more details, see https://docs.github.com/en/github-cli/github-cli/creating-github-cli-extensions.

[drogers0]

Plan: Add android-arm64 release binary (Issue #28)

Problem Summary

gh extension install drogers0/gh-image fails on Android (Termux) because the release
does not publish an android-arm64 asset.

gh installs a precompiled extension by downloading the release asset whose name matches
<GOOS>-<GOARCH> of the running gh binary (see
Creating GitHub CLI extensions).
Termux builds gh with GOOS=android, so it looks for an asset literally named
android-arm64. Our .goreleaser.yml builds only darwin/linux/windows, so no such
asset exists and the install aborts.

This is a build/release-matrix gap, not a code gap. Verified locally against the current
tree (go 1.26.1):

GOOS=android GOARCH=arm64 CGO_ENABLED=0 go build .   # succeeds
file gh-image → ELF 64-bit LSB pie executable, ARM aarch64, interpreter /system/bin/linker64

The binary is already PIE and targets the Bionic loader — exactly what Android/Termux
requires to exec it.

Design Decisions

1. Ship android/arm64 only — do not ship android/amd64

Adding android to the existing goos matrix would also request android/amd64, which
cannot be built:

GOOS=android GOARCH=amd64 CGO_ENABLED=0 go build .
→ android/amd64 requires external (cgo) linking, but cgo is not enabled

Supporting it would mean wiring the Android NDK into the release workflow and turning on
CGO for one target — a large, fragile change (NDK download, per-target CC, cgo-enabled
build of kooky) for a platform that is effectively emulator-only. arm64 covers every
real Android device and the reporter's case.

• Chosen: add android to goos and add an ignore entry for android/amd64,
  mirroring the existing windows/arm64 ignore.
• Rejected: switching the build block to an explicit targets: list. It is arguably
  clearer at five targets, but it is a larger diff that reformats an unrelated config and
  abandons the matrix+ignore pattern already established here. Keep the diff minimal.
• Rejected: NDK + CGO for android/amd64. Revisit only if someone actually reports it.

2. Build natively for android, not linux relabelled as android

An alternative is to build linux/arm64 and publish a copy named android-arm64.
Android is Linux-kernel-based, and a static linux/arm64 Go binary usually does run under
Termux.

• Chosen: a real GOOS=android build. Go's android target emits a PIE binary linked
  against /system/bin/linker64 (Bionic), which is what Android's loader expects, and it
  keeps runtime.GOOS honest for any future platform-conditional code.
• Rejected: the relabelled-linux trick. It works by accident, misreports the platform,
  and quietly breaks if we ever add cgo or a _linux.go/_android.go build-tagged file.

3. No source changes — Android auth goes through --token / GH_SESSION_TOKEN

kooky compiles for android/arm64 (verified — the build above links it in). At runtime
on Termux there is no desktop browser cookie store to read, so browser extraction will
simply find nothing and main.go already falls through to its existing error:

no session token found (set --token flag or GH_SESSION_TOKEN env var, or log into GitHub in a supported browser)

That is the correct, already-implemented behaviour. We document GH_SESSION_TOKEN as the
Android path rather than adding Android-specific cookie code (reading the Android Chrome
app's cookie DB is not possible without root, and is out of scope).

4. Guard the target in CI

The android target is not exercised by go test/go build ./... on the ubuntu runner, so
a future dependency bump could silently break it and we would only find out at tag time,
when the release fails. Add a cross-compile-only step to test.yml. We cannot run the
binary on the runner; compiling it is the check that matters, since the failure mode
(a dep that needs cgo on android) is a compile failure.

5. Existing convention flagged, not reproduced

archives.format: binary is deprecated in GoReleaser v2 in favour of formats: [binary].
It still works and is out of scope for this issue — noted here only so it is a deliberate
omission rather than an oversight. Do not change it as part of this PR.

---

Step-by-step Implementation

Step 1 — .goreleaser.yml: add the android target

In the single entry under builds:, add android to goos and ignore android/amd64.

Resulting builds block:

builds:
  - binary: gh-image
    main: .
    env:
      - CGO_ENABLED=0
    ldflags:
      - -s -w -X main.version={{.Version}}
    goos:
      - darwin
      - linux
      - windows
      - android
    goarch:
      - amd64
      - arm64
    ignore:
      - goos: windows
        goarch: arm64
      # android/amd64 requires external (cgo) linking; we build with CGO_ENABLED=0.
      - goos: android
        goarch: amd64

Leave the existing windows/arm64 ignore exactly as-is (do not annotate it — it is a
pre-existing project choice, not part of this change). Add only the android/amd64 entry
and its comment. Do not touch archives. name_template: "{{ .Os }}-{{ .Arch }}" already yields
android-arm64, which is the exact asset name gh looks for.

Net effect: the release gains one asset, android-arm64, and one extra line in
checksums.txt.

Step 2 — .github/workflows/test.yml: cross-compile guard

Add a step after the existing go build ./...:

      - name: Cross-compile android/arm64
        run: GOOS=android GOARCH=arm64 CGO_ENABLED=0 go build -o /dev/null .

Build the main package (.), not ./...: go build -o /dev/null rejects a multi-package
argument, and . is the only package that produces a shipped binary anyway.

Step 3 — README.md: document Android support

Placeholders in shell blocks must be paste-safe: export GH_SESSION_TOKEN=<value> is a
shell redirection and will error if copied. Use a quoted placeholder everywhere.

Two edits:

1. Line ~36, the platform sentence. Replace:

   Pre-built releases ship for macOS (arm64, amd64), Linux (amd64, arm64), and Windows (amd64).

   with:

   Pre-built releases ship for macOS (arm64, amd64), Linux (amd64, arm64), Windows (amd64), and Android/Termux (arm64).

2. Line ~108, the **Supported platforms:** macOS · Linux · Windows line, and the notes
   that follow it. Update to include Android and add a note explaining that browser cookie
   extraction does not apply there:

   **Supported platforms:** macOS · Linux · Windows · Android (Termux)

   Then, alongside the existing macOS Keychain and Windows/Chrome notes, add:

   > **Android (Termux):** there is no desktop browser cookie store to read from, so
   > automatic token extraction does not apply. Supply the session token explicitly —
   > run `gh image extract-token` on a desktop machine where you are logged into GitHub,
   > then on the phone:
   >
   > ```bash
   > export GH_SESSION_TOKEN='paste-token-here'
   > gh image screenshot.png
   > ```
   >
   > Prefer `GH_SESSION_TOKEN` over `--token` on shared systems: flag values are visible
   > in process listings.

   Match the surrounding blockquote/callout style rather than the exact markup above if
   the file's convention differs.

Step 4 — documentation/architecture.md: sync the platform claims

Two stale spots, both of which would otherwise keep asserting a three-platform release:

1. Under Distribution (~line 266), the bullet reading
   GoReleaser builds binaries for macOS (arm64, amd64), Linux (amd64, arm64), and Windows (amd64) on tagged releases
   → append , and Android/Termux (arm64).

2. Under Platform Notes (~lines 291–295), add a bullet after Windows, matching the
   existing style:

   - **Android (Termux):** Binary is built for android/arm64 (PIE, Bionic-linked). There is no
     desktop browser cookie store, so browser extraction finds nothing — use `GH_SESSION_TOKEN`
     (preferred) or `--token`, the same path as CI / headless.

   Note the existing CI / headless environments bullet already describes exactly this
   auth path; the Android bullet should point at it rather than restate the reasoning.

Step 5 — skills/github-image-upload/SKILL.md: one-line Android row

The skill's troubleshooting table (~line 134) already has a CI / headless run row telling
agents to use GH_SESSION_TOKEN because "the browser cookie path won't exist" — which is
the Android situation verbatim. Add a sibling row rather than a new section:

| Android / Termux | No browser cookie store exists — set `GH_SESSION_TOKEN` (extract it on a desktop with `gh image extract-token`). |

This is a markdown table cell, not a shell block, so the placeholder-quoting concern does
not apply here. Note also that this file has pre-existing unquoted <owner>/<repo> and
<pr> placeholders in its Bash examples (~lines 66, 90, 92, 99, 111). Those are illustrative
tokens meant for the reading agent to substitute, not literal copy-paste input, and they are
unrelated to Android support — out of scope for #28. Do not touch them in this PR; if they
are worth hardening, that is a separate cleanup.

Step 6 — gh-image-submission-guide.md: fix the platform claim

Line ~190 ("Why I think it's awesome") says the project "ships prebuilt binaries for
macOS/Linux/Windows". This copy is reused verbatim in outstanding aggregator submissions,
so it must not go stale: change to macOS/Linux/Windows/Android.

Step 7 — release

The asset only appears once a release is cut; the fix is inert until then.

1. Merge to main.
2. Tag and push (git tag v1.2.0 && git push origin v1.2.0) — a minor bump, since this
   adds a platform.
3. Confirm the release contains an android-arm64 asset and that checksums.txt lists it.

Do not push the tag without the maintainer's go-ahead.

---

Testing

There are no new code paths, so there are no new unit tests to write — asserting on the
contents of a YAML config would test the config file against itself. Verification is
build- and release-shaped:

1. Cross-compile (local, required):

   GOOS=android GOARCH=arm64 CGO_ENABLED=0 go build -o /tmp/gh-image-android .
   file /tmp/gh-image-android

   Expect: ELF 64-bit LSB pie executable, ARM aarch64 ... interpreter /system/bin/linker64.
   A non-PIE or EXEC-type result would not run on Android and must block the PR.

2. GoReleaser full matrix (local, required):

   go run github.com/goreleaser/goreleaser/v2@latest build --snapshot --clean
   ls dist/ && rm -rf dist

   Expect a dist/gh-image_android_arm64_v8.0 artifact and no attempted android/amd64
   build. Already run against the proposed config during planning — GoReleaser v2 accepts
   goos: android (it does not reject it against an allowlist) and the ignore entry
   correctly suppresses android/amd64. Re-run after the edit to confirm, and remember to
   delete dist/ (it is gitignored, but do not leave it behind).

3. Existing suite: go vet ./... and go test -race -cover ./... must stay green
   (they should be untouched).

4. Post-release smoke test (best-effort, on a device or Termux emulator):

   gh extension install drogers0/gh-image
   gh image --help
   GH_SESSION_TOKEN='<token>' gh image ./test.png

   Expect: install resolves the android-arm64 asset; upload succeeds; and with no token
   set, the error names --token / GH_SESSION_TOKEN rather than crashing. If no device
   is available, ask the issue reporter (@SamarArey) to confirm on the released build
   before closing Add support for the android-arm64 architecture #28.

---

Files Touched

File	Change
.goreleaser.yml	add android to goos; ignore android/amd64
.github/workflows/test.yml	add android/arm64 cross-compile step
README.md	list Android in supported platforms; document GH_SESSION_TOKEN usage there
documentation/architecture.md	sync Distribution bullet + add Android to Platform Notes
skills/github-image-upload/SKILL.md	one Android row in the troubleshooting table
gh-image-submission-guide.md	fix the "macOS/Linux/Windows" prebuilt-binaries claim

No Go source changes. No new dependencies. No test files added.

Grep guard before declaring done — every remaining hit must be intentional:

grep -rn -i "macOS.*Linux.*Windows\|Linux.*Windows" --include='*.md' . | grep -v _PLAN.md

[drogers0]

@SamarArey — the fix for this is merged and released: v1.2.0 is now up with an android-arm64 release asset, which is exactly the name gh on Termux looks for. So gh extension install drogers0/gh-image should now resolve on your device.

Since you're the one actually on Termux, two things I'd appreciate your eyes on:

1. Did it work? Does gh extension install drogers0/gh-image succeed on your device, and does gh image <file> run?
2. Is the README accurate? I documented that on Termux there's no browser cookie store to read, so you authenticate by setting GH_SESSION_TOKEN — extract it once on a desktop where you're logged into GitHub with gh image extract-token, then export GH_SESSION_TOKEN='<token>' on the phone — rather than relying on automatic browser cookie extraction. Does that match your setup, or does Termux expose a browser cookie store I should be accounting for?

Thanks for the report!