ANTIGRAVITY LABJP
Articles/App Development
App Development/2026-05-15Intermediate

Library Added via Antigravity Crashes Only on Older Android Devices: The coreLibraryDesugaring Blind Spot

When a library added through Antigravity starts crashing only on Android 6/7 devices, the culprit is often missing coreLibraryDesugaring config. Learn how to diagnose and fix it from a real-world case.

android28troubleshooting108coreLibraryDesugaringgradle2crash2

Right after releasing v2.0.0 of Beautiful HD Wallpapers (iOS/Android, 50M+ cumulative downloads), a flood of unfamiliar crash reports started coming in through Google Play Console. Over 28 days, more than 50 users hit the same crash — and every single one was on an Android 6.0.1 or 7.x device.

The crash was completely unreproducible on modern devices. The stack trace pointed to code that seemed totally unrelated. When I pasted it into Antigravity, it suggested reviewing the Glide configuration — technically in the right direction, but missing the actual root cause.

As an indie developer managing multiple apps simultaneously, this kind of hard-to-reproduce, device-specific crash is particularly draining. The root cause turned out to be a missing Java 8 desugaring configuration — something Antigravity didn't add when it upgraded the library dependency.

This article covers how to diagnose the problem, apply the fix, and prevent it from recurring.

What the error log looks like

You'll see something like this in Play Console or Crashlytics:

java.lang.NoClassDefFoundError: Failed resolution of: Ljava/util/function/Supplier;
    at com.bumptech.glide.load.engine.cache.DiskCacheAdapter.<init>(DiskCacheAdapter.java:14)
    at com.bumptech.glide.load.engine.cache.InternalCacheDiskCacheFactory.build(...)

java.util.function.Supplier is part of the Java 8 standard library. Android 6.x and 7.x don't natively include many Java 8 APIs, so when a library tries to use one at runtime, it crashes with NoClassDefFoundError.

Why Antigravity doesn't add the fix automatically

Antigravity reads your build.gradle and correctly suggests adding Glide 5.0.5. What it may not account for is that if your minSdkVersion is 23 (Android 6.0), you need an explicit compatibility bridge to safely use Java 8 APIs.

Glide 5.x shifted its internals significantly compared to Glide 4.x — it now relies heavily on Java 8 Functional Interfaces. Even with AGP 9.x, this compatibility shim (called desugaring) has to be explicitly enabled.

In my case, I asked Antigravity to upgrade Glide to version 5. It updated the dependency correctly but didn't touch the compileOptions block. Updating a library and maintaining minSdkVersion compatibility are treated as separate concerns by the AI.

Beyond Glide, several other popular libraries have the same Java 8 dependency:

  • OkHttp 4.x+: uses java.net.InetAddress changes
  • Retrofit 2.8.x+: uses java.util.function.Function
  • Kotlin Coroutines (certain versions): depends on java.util.concurrent.Flow
  • Room 2.5.x+: uses java.util.Optional

If you're maintaining minSdkVersion below 26 — which is still reasonable for maximizing reach on the Google Play Store — this is a pattern worth knowing about.

Diagnosing the problem

Check your crash log for any of these class name patterns:

NoClassDefFoundError: Ljava/util/function/
NoClassDefFoundError: Ljava/util/stream/
NoClassDefFoundError: Ljava/time/

These are all Java 8 API classes. If you're seeing any of them, and the crashes are exclusive to devices below API level 26, you're almost certainly dealing with a missing desugaring configuration.

In Play Console, go to Android Vitals → Crashes and ANRs, then filter by Android version. A crash distribution heavily skewed toward Android 6.x and 7.x, with no crashes on Android 8+ devices, is the clearest signal.

The fix: enable coreLibraryDesugaring

Add the following to your app/build.gradle:

android {
    compileOptions {
        // Enables Java 8 API backporting for older Android devices
        coreLibraryDesugaringEnabled true
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
}
 
dependencies {
    // Desugaring library (recommended version for AGP 9.x)
    coreLibraryDesugaring 'com.android.tools:desugar_jdk_libs:2.1.4'
}

Or in Kotlin DSL (build.gradle.kts):

android {
    compileOptions {
        isCoreLibraryDesugaringEnabled = true
        sourceCompatibility = JavaVersion.VERSION_1_8
        targetCompatibility = JavaVersion.VERSION_1_8
    }
}
 
dependencies {
    coreLibraryDesugaring("com.android.tools:desugar_jdk_libs:2.1.4")
}

After shipping this in v2.1.0, the crashes that had been accumulating for 28 days disappeared completely. Every Android 6.0.1 user's crash was resolved with one line of configuration.

Telling Antigravity about this constraint upfront

To prevent the same issue from recurring, add something like this to your GEMINI.md (or Antigravity's custom instructions):

## Android project constraints
 
- Keep minSdkVersion at 23 (Android 6.0)
- When adding or upgrading any library that uses Java 8 APIs
  (java.util.function.*, java.util.stream.*, java.time.*),
  always verify and add coreLibraryDesugaring configuration
- Glide 5.x, OkHttp 4.x+, and modern Kotlin Coroutines versions
  all depend on Java 8 APIs — desugaring is required

With this in place, Antigravity factors in the coreLibraryDesugaring requirement whenever it suggests library updates. This approach — documenting project-specific constraints in GEMINI.md — applies broadly. Any time you discover a hard-won lesson about your project's constraints, encoding it in the context file means the AI carries that knowledge forward.

Before/After

Before (crashes on Android 6.x):

android {
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
        // Missing: coreLibraryDesugaringEnabled true
    }
}
 
dependencies {
    implementation 'com.github.bumptech.glide:glide:5.0.5'
    // Missing: coreLibraryDesugaring dependency
}

After (works on Android 6.x):

android {
    compileOptions {
        coreLibraryDesugaringEnabled true   // add this
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
}
 
dependencies {
    implementation 'com.github.bumptech.glide:glide:5.0.5'
    coreLibraryDesugaring 'com.android.tools:desugar_jdk_libs:2.1.4'  // add this
}

AGP version compatibility

The desugar_jdk_libs version needs to match your AGP version. For AGP 9.x, use the 2.x.x series. The 1.x.x series lacks some Java 11 APIs and may still produce errors in edge cases.

# Check your current AGP version
grep "com.android.tools.build:gradle" build.gradle.kts

The latest compatible versions are listed on the google/desugar_jdk_libs GitHub Releases page.

Setting up a testing baseline for old devices

The most reliable prevention is testing on API level 23–25 before every release. Android Studio's AVD Manager lets you create an Android 6.0 (Marshmallow) emulator. Running a basic smoke test on this emulator after any library upgrade catches the problem before it ships.

If you prefer automated coverage, Google Play Console's Pre-launch Report uses Firebase Test Lab to run your APK against a set of real devices automatically. Crashes from old-API-level devices show up there before they reach your users.

The pattern I follow now: before asking Antigravity to upgrade any library, I check whether minSdkVersion is below 26 and explicitly mention the desugaring requirement in my prompt. After adding this to my GEMINI.md, I haven't hit this class of crash again across any of my apps.

Single-line configuration gaps are easy to miss and surprisingly hard to diagnose. I hope this saves you the same 28 days of confusion.

Share

Thank You for Reading

Antigravity 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.

  • Copy-paste ready implementation code
  • New advanced guides published daily
  • $5/mo or $10 for lifetime access
View Membership →

If you found this article helpful, a small tip ($1.50) would mean a lot to us. Your support helps keep this site ad-free and covers server and hosting costs.

Related Articles

App Dev2026-06-27
Before AI Studio's Gradle and AGP Versions Quietly Break Your Existing App
When you drop an AI Studio-generated Kotlin/Compose screen into an existing Android app, the AGP, Kotlin, and library versions drift and the build breaks silently. Here is how to pin a single source of truth with a version catalog and add a gate that inspects the generated declarations at the import boundary, with measurements and code.
App Dev2026-05-17
When Antigravity Fixes a RecyclerView Crash but Breaks Something Else — The Defensive Copy Solution
If RecyclerView IndexOutOfBoundsExceptions keep coming back after Antigravity's fix, shared list reference is likely the cause. Here's how to prompt Antigravity for the right fix and encode the pattern in AGENTS.md.
App Dev2026-05-16
RecyclerView IndexOutOfBoundsException: The Defensive Copy Fix Antigravity Initially Missed
After 50+ RecyclerView crashes appeared in 28 days post-release, here's how I used Antigravity to debug the issue — and why the first suggestion missed the real cause.
📚RECOMMENDED BOOKS
Build a Large Language Model (From Scratch)
Sebastian Raschka
LLM Dev
Prompt Engineering for LLMs
Berryman & Ziegler
Prompting
AI Engineering
Chip Huyen
AI Eng
* Contains affiliate links
See all →