How Claude Code Helped Me Kill a Glide 5.0.5 Java 8 Crash with One Line

After Beautiful HD Wallpapers v2.0.0 shipped, every Android 6.0.1 user crashed within 3 seconds. The fix turned out to be a single missing line in build.gradle.kts — and Claude Code is what got me there.

android⁹ glide desugar claude-code¹²⁹ debugging⁸

✦ Premium Article

Seven days after shipping Beautiful HD Wallpapers v2.0.0, Firebase Crashlytics lit up a red issue tagged "Early Crash." The cause was NoClassDefFoundError: java.util.function.Supplier, and once I filtered by OS version, every affected device was Android 6.0.1 (API 23). Twelve events in seven days, four distinct users — but those four users were crashing 100% of the time, within three seconds of cold start.

Beautiful HD Wallpapers has accumulated roughly 50 million downloads across the years I've run it as an indie developer. API 23 is the slow tail you keep alive out of stubbornness rather than ROI, but watching a fresh release wipe out an entire OS bucket was not acceptable. Here's the path I walked with Claude Code — from Crashlytics issue to a single-line fix — in case you're staring at the same stack trace.

What the crash actually was — a Java 8 API missing on API 23

The stack trace I first looked at was three lines long:

Fatal Exception: java.lang.NoClassDefFoundError:
  Failed resolution of: Ljava/util/function/Supplier;
  at com.bumptech.glide.GlideBuilder.<init>(GlideBuilder.java:64)

java.util.function.Supplier is a Java 8 functional interface. Android only ships those in the runtime starting at API 24 (Nougat). API 23 is late Marshmallow, and that's where Glide 5.x began reaching for something the platform doesn't expose.

Glide's documentation says minSdk = 21, but the moment they started touching Java 8 functional types directly happened around the 5.x line. Combined with bumping Android Gradle Plugin to 9.x, the static linkage through Supplier became real instead of hypothetical.

What rescues you here is Core Library Desugaring — R8's mechanism for back-porting newer Java APIs to older Android runtimes. I had declared the dependency. I had not turned on the flag.

Why declaring the dependency was not enough

Adding coreLibraryDesugaring("com.android.tools:desugar_jdk_libs:2.1.5") to dependencies is one half of the contract. R8 will not actually invoke desugaring until you flip isCoreLibraryDesugaringEnabled = true inside compileOptions. AGP keeps these decoupled on purpose: declaring the artifact and asking the toolchain to use it are different statements.

Up through v2.0.0 my project lived on Glide 4.x, which did not lean on Java 8 APIs in the surface area I was hitting. The exact version bump that exposed it was AGP 8.11.1 → 9.0.0 and Glide 4.16.0 → 5.0.5, landed in the same release. Twelve years of indie Android work have taught me that this is the canonical shape of "silent breakage on a major library bump."

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦Reproduce the exact path that recovered Crash-free users from 99.3% to 99.78% on Beautiful HD Wallpapers v2.1.0, with all Android 6.0.1 startup crashes (12 events / 4 users in 7 days) eliminated by a single line

✦Understand why declaring desugar_jdk_libs in dependencies is not enough — and what the compileOptions flag actually tells R8 to do under AGP 9.x

✦Apply the 4-step Claude Code workflow (Crashlytics issue → hypothesis triplet → minimal patch → CI guard) to your own Android project before the next major library bump

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

The smallest prompt I gave Claude Code

I gave Claude Code the Crashlytics issue body, my build.gradle.kts, and the diff of the library update PR — nothing more. I deliberately left the diagnostic path open so the model would explore instead of jumping to a memorized fix.

Here is the template I keep around for Crashlytics-driven debugging with Claude Code:

## Context
- App: Beautiful HD Wallpapers (Android, minSdk 23, targetSdk 36)
- AGP: 9.0.0, Kotlin: 2.1.21, Java: 17
- Crashlytics Issue (7d): NoClassDefFoundError on java.util.function.Supplier
- Affected devices: all Android 6.0.1 (API 23) users (4 / 4)
- Reproduces in: 3 seconds of cold start on an API 23 emulator
 
## Recent change (suspect)
- Glide: 4.16.0 -> 5.0.5
- AGP: 8.11.1 -> 9.0.0
 
## Ask
- Give me three hypotheses for the root cause
- For each, include the exact command or grep to verify
- The final fix should be expressed as a build.gradle.kts diff

The "three hypotheses" line matters. Without it, Claude Code often grabs the most likely cause and runs. Forcing three forces it to widen the search.

The one-line patch that fixed it

What Claude Code converged on, after walking through the three hypotheses, was a single added line in build.gradle.kts:

android {
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_17
        targetCompatibility = JavaVersion.VERSION_17
        // Added: tell R8 to back-port Java 8 APIs onto older runtimes
        isCoreLibraryDesugaringEnabled = true
    }
}
 
dependencies {
    coreLibraryDesugaring("com.android.tools:desugar_jdk_libs:2.1.5")
    implementation("com.github.bumptech.glide:glide:5.0.5")
}

That isCoreLibraryDesugaringEnabled = true line is the bridge between the dependency and the toolchain. If you use Groovy DSL, the equivalent is coreLibraryDesugaringEnabled true.

I confirmed locally on an API 23 emulator (three cold starts, navigate to category, open a wallpaper, back out, repeat). Then I started phased rollout at 5%.

Watching "fixed" land in Crashlytics

What I actually rely on, as an indie developer, is Crash-free users — not issue close states. A single issue going to zero doesn't mean the OS bucket isn't shedding users for a related reason.

I pinned this Crashlytics filter to the dashboard:

fatal_issue_id == "<issue id>"
AND app_version == "2.1.0"
AND os.display_version starts_with "6.0"

After 48 hours: zero events in this bucket. Crash-free users moved from 99.3% on v2.0.0 to 99.78% on v2.1.0. ANR stayed under 0.20%. AdMob rewarded fill rate was unaffected, so I rolled forward to 25%, 50%, and finally 100% over the next four days.

Here is something the docs don't mention: looking at the global Crash-free users number after a major library bump is too coarse. What I recommend is a saved filter that isolates Crash-free users for the lowest supported OS — in my case Android 6.0.x. That bucket is where Java 8 desugaring problems show up first and loudest.

A small CI guard to prevent the same trap

The shape of this bug is structural: declaring desugar in dependencies and forgetting the compileOptions flag is easy to do during a major library bump. I asked Claude Code to draft a tiny CI check, and now it lives in my CI pipeline:

#!/usr/bin/env bash
set -euo pipefail
 
GRADLE_FILE="app/build.gradle.kts"
 
if grep -q "coreLibraryDesugaring(" "$GRADLE_FILE"; then
  if ! grep -q "isCoreLibraryDesugaringEnabled\s*=\s*true" "$GRADLE_FILE"; then
    echo "❌ desugar_jdk_libs is declared but compileOptions has it disabled"
    exit 1
  fi
fi
echo "✅ desugar config consistent"

Glide, Coil, OkHttp, kotlinx-datetime — any major library version that begins touching newer Java APIs internally can quietly reintroduce this problem. A single CI guard like the one above will catch nearly every case before it ships.

A note from 12 years of indie Android work

My grandfathers were both shrine carpenters in Japan, and I grew up watching them spend the most care on joints no visitor would ever see. Android's build.gradle.kts is the same kind of surface — the parts hidden inside compileOptions and coreLibraryDesugaring are what make an app keep running for a decade.

I started building software in 1997, at sixteen, on dial-up. Forty-eight hours a year of unglamorous configuration auditing — sitting with Claude Code, reading Glide / AGP changelogs against my own build.gradle.kts — has done more for my retention numbers than any feature rewrite. I do it in the calm two weeks after each release rather than the panicked days before, and I'd recommend the same cadence to anyone shipping on Android with a long tail of legacy devices.

What to try next

If you're shipping Android with minSdk under 24 and have moved to Glide 5.x or Coil 2.x recently, the most useful 60 seconds you can spend today is opening app/build.gradle.kts and confirming that isCoreLibraryDesugaringEnabled = true is present inside compileOptions. If it's missing, add the line, run a cold start on an API 23 emulator three times, and you'll most likely be done. Thanks for reading — I hope this saves someone else a panicked Tuesday morning.

Thank You for Reading

Claude Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.