HARP

Appearance

Android app (experimental) ​

A FOSS Android frontend to the same HARP core, living in the repo's android/ directory. The app embeds src/harp directly via Chaquopy (MIT), so app and CLI can never drift apart.

Everything runs offline: the catalogues, the ephemerides and the astronomical core are all on the phone. No account, no network, no telemetry.

The five tabs ​

  • Home — the landing dashboard, laid out as a mini solar system: tonight's darkness window and Moon state on the Sun, and the other tabs as planets carrying their own status (site name, target count, current alignment error). Tap a planet to jump there.

  • Horizon — the reason the app exists. Live true-north azimuth/altitude from the fused rotation-vector sensor, magnetic declination applied on-device (built-in World Magnetic Model — no NOAA lookup), compass-calibration status, tap-to-record skyline vertices, polar preview, and .hrz export via the share sheet — ready for N.I.N.A. and harp plan.

  • Plan — the full planner on-device: the same ranking the CLI produces, with client-side filter chips by target class and emission type. Results are computed from the selected saved site and its captured horizon. Each row also carries a log action and shows how much integration that target already has (▣ 8h 20m), writing to the same observations.yaml the harp log CLI reads. A when action ranks the coming nights for that target — the app's harp when.

    The "when" sweep is slow on a phone

    It plans one night per day in the window, and Chaquopy runs several times slower than desktop Python: a fortnight that takes ~1.5 s on a laptop is plausibly ~10 s on a phone. So it defaults to 14 nights rather than the CLI's 30, shows a progress indicator, and never starts on its own — you tap when, and 7/14/30-day chips let you extend once you have seen the cost.

  • Align — polar alignment in two stages: a live compass rose for finding the pole by eye, then an assistant that reads the phone's attitude while it is fixed to the mount and gives azimuth/altitude bolt corrections with a bullseye. Built for twilight, before Polaris is visible; see Polar alignment for the workflow and its honest accuracy limits.

  • Settings — rig (focal length, sensor), planning thresholds, catalogue selection, Sharpless options, a comets toggle (online — fetches MPC orbital elements, with an apparent-magnitude limit), refraction pressure/temperature, link provider, and appearance.

Saved sites and the observation log ​

Sites live in the app's private storage in exactly the CLI's layout — sites.yaml plus one .hrz per site — so the whole directory can be copied to a desktop ~/.config/harp/ and used with harp --site. Capturing a horizon in the wizard saves it straight into the selected site, together with the site's optional sky quality — a Bortle class (1–9) or a measured SQM (mag/arcsec²), the same bortle / sqm keys the CLI reads. Declaring it turns on the light-pollution contrast term in the app's plan exactly as it does for harp plan; SQM wins over Bortle when both are given, and declaring neither leaves the ranking untouched.

The observation log sits beside them as observations.yaml, in the same format harp log uses: log a session on the phone at the telescope, copy the file to your desktop, and harp log list totals it. Totals appear on plan rows purely as information — they never influence the ranking, because "already shot" is not the same as "done".

Export your log

Sessions are the one thing in the app you cannot regenerate. Settings → Export observation log shares the file out through the share sheet; a copy of it is what protects your history if the phone is lost or reset.

Appearance ​

Seven indoor themes (Tokyo Night, Catppuccin Mocha, Nord, One Dark, Dracula, Gruvbox Dark, Solarized Dark) plus a red night-vision mode that collapses the whole scheme to red on black for use at the telescope. The night-vision toggle sits in the top bar, reachable from every tab without going into Settings.

Getting the app ​

There is no store listing yet: build a debug APK yourself, one of two ways.

Path A — GitHub CI (zero setup) ​

Every push touching android/** or src/** builds a debug APK in the Android workflow; download the harp-debug-apk artifact from the Actions run and sideload it. Convenient, but each iteration costs a CI round-trip.

Path B — local build (fast iteration) ​

A one-time headless toolchain (JDK 21, Android SDK 35 command-line tools, Gradle 8.13 — no Android Studio required), then:

bash
gradle -p android :app:assembleDebug
# -> android/app/build/outputs/apk/debug/app-debug.apk

After editing the shared src/ Python, add --rerun-tasks

bash
gradle -p android :app:assembleDebug --rerun-tasks

The app embeds src/harp via Chaquopy from outside the Gradle module, so a plain assembleDebug can report the Python merge UP-TO-DATE and bundle the previous bytecode — the APK then runs stale planner/catalog code. Kotlin-only changes do not need it. Full explanation and a verify-the-bundle one-liner are in android/README.md.

First build is slow (Chaquopy fetches the Android wheels of the astro stack); later builds take seconds to a minute. The full setup commands, phone-transfer options (HTTP serve or wireless adb), and the on-device debugging tip (adb logcat -s python.stderr) are in android/README.md, together with the first-device test checklist.