GitHug Android

Native Android adaptation of the Ruby Githug learning game, built with Kotlin + Jetpack Compose. The product goal is a shippable mobile implementation that preserves GitHug's CLI-first learning style while making repository state easier to inspect on a phone.

Implementation Strategy

The app is organized around GitHug parity rather than simplified command quizzes:

• The level catalog follows the upstream Ruby Githug order from Githug::Level::LEVELS.
• Each exercise lives in its own Kotlin source file under app/src/main/java/solutions/tretter/githugandroid/levels/.
• Each level file documents the intended repository setup, evaluation strategy, hints, command suggestions, and embedded solution scenarios.
• Validators prefer repository state and Git objects over raw command text. Direct command-answer validation is reserved for upstream answer-style levels such as identifying a hash, filename, remote URL, author, or count.
• Shared tests execute the embedded solution scenarios for every level and assert that the Android catalog still matches the upstream level order.
• The runtime prepares an isolated sandbox per level. When a bundled native Git binary is present, Git commands run against real repository directories; otherwise the Kotlin fallback engine keeps development and tests deterministic.

The UI supports a terminal-centered workflow with optional inspection panes:

• CLI ONLY: hide visualization and play with terminal-style input.
• HYBRID: command line with optional repository panels.
• VISUAL: repository panels visible by default, still backed by the same command engine.

Development Workflow

Development tasks should be run through the project tooling script. It provisions the local toolchain, keeps paths project-relative, and runs Gradle with the project configuration expected by this repository.

Android project tooling

This repo includes a root-level tooling script:

bash ./AndroidProjectTooling.sh

It is designed to be idempotent and uses project-relative paths to:

• install a project-local JDK into ./jdk
• install Android command-line tools into ./android-sdk
• restore gradle/wrapper/gradle-wrapper.jar if missing
• install required Android SDK packages
• write local.properties

To run the JVM unit test suite after ensuring the local toolchain is ready:

bash ./AndroidProjectTooling.sh --test

To build the debug APK:

bash ./AndroidProjectTooling.sh --build

The script avoids depending on the system Java version by provisioning a project-local JDK 17, which is required by current Android SDK command-line tools.

To avoid repeated expensive SDK verification, the script writes a small state file named:

./.android-project-tooling.state

If all required components were verified successfully, the script will skip SDK verification/reinstallation for the next 24 hours unless required directories are missing.

When --build is used, the script also:

• increments versionCode by 1
• increments the patch component of versionName, for example 0.1.0 to 0.1.1
• renames the debug APK to githug-android-debug.apk
• attempts to create a git commit after a successful build if there are source changes

Runtime Architecture

The command engine has two execution paths behind one app-facing runtime:

• Native Git path: if the packaged executable is present for the device ABI, Git commands execute in a real per-level repository sandbox in app-private storage.
• Kotlin fallback path: the in-memory sandbox engine mirrors the same observable repository facts for development, JVM tests, and environments without a bundled native Git binary.

Both paths expose the same RepoState surface to validators. In addition to files, commits, branches, tags, remotes, and config, the model tracks learning-relevant effects such as stashes, fetched remote refs, pushed branches/tags, submodules, and repository maintenance actions.

Helper shell-like commands (ls, pwd, cat, touch, mkdir, rm, echo, cd) remain implemented in Kotlin so the mobile terminal behaves consistently across devices.

Level Authoring

When adding or changing a level:

• Keep one source file per exercise.
• Keep allGithugLevels() in upstream Ruby Githug order.
• Document the setup and validation intent in the level file.
• Prefer validators that inspect RepoState over validators that match command strings.
• Add multiple LevelTestCase scenarios when more than one solution path should be accepted.
• Run bash ./AndroidProjectTooling.sh --test before building.

Production Focus

Current work is focused on:

• improving parity with upstream Ruby Githug setup and validation semantics
• expanding native-Git-backed behavior across complex repository workflows
• preserving robust fallback tests for every level
• improving onboarding, accessibility, UI polish, icons, and Play Store readiness