Last Week

Set up the public GitHub issues tracker for our testers – the main communication hub for bug reports, discussions, and feature requests. Going forward, I’ll reference private PRs and commits in the public repo so folks can track development progress.

The Windows Migration

Recently switched from Fedora 40 to Windows 11 IoT LTSC due to driver issues with cutting-edge PC components on Linux. The IoT LTSC version is refreshingly minimal – no bloat, just core Windows functionality with the ability to add components as needed.

Everything was working great… until I tried getting Claude Code to work with Android Studio.

What does it mean in English?

Imagine having two different toolboxes in two different rooms. Android Studio’s tools are in the Windows room, while Claude Code lives in a Linux room (WSL). They can see each other’s files, but Claude Code can’t use Android Studio’s tools directly. When I tried giving Claude Code its own identical toolbox, they started fighting over whose instructions to follow.

Nerdy Details

The issue stems from how Android builds work across Windows and WSL:

  1. Android Studio on Windows: Build tools and emulator run natively on Windows
  2. Claude Code on WSL: Runs in a Linux VM, can access Windows files but not Windows executables
  3. The local.properties problem:
    • Android projects use local.properties to point to build tools location
    • Windows version points to Windows paths
    • WSL can’t use Windows build tools directly
    • Installing separate tools in WSL doesn’t help because local.properties overrides environment variables

The Solution: Modified the build script to detect the current environment and conditionally ignore local.properties when building from WSL:

// Detect if running in WSL and handle local.properties accordingly
if (System.getenv("WSL_DISTRO_NAME") != null) {
    // WSL environment - use environment variables instead
    project.ext.set("sdk.dir", System.getenv("ANDROID_HOME"))
}

Hours of debugging, multiple AI assistants consulted, many unkind words directed at the screen – but it’s finally working.

Next Week

With the development environment sorted, time to dive into the tester feedback and start addressing bug reports. Real users, real issues, real progress.