bumptech/glide · error · IllegalArgumentException

You cannot start a load for a destroyed activity

Error message

You cannot start a load for a destroyed activity

What it means

IllegalArgumentException thrown by RequestManagerRetriever.assertNotDestroyed() when the Activity passed to Glide.with(activity) reports isDestroyed()==true (API 17+). Loading into a destroyed activity would leak the request and crash on UI updates, so Glide rejects it up front.

Source

Thrown at library/src/main/java/com/bumptech/glide/manager/RequestManagerRetriever.java:237

    tempViewToSupportFragment.clear();
    return result;
  }

  @Nullable
  private static Activity findActivity(@NonNull Context context) {
    if (context instanceof Activity) {
      return (Activity) context;
    } else if (context instanceof ContextWrapper) {
      return findActivity(((ContextWrapper) context).getBaseContext());
    } else {
      return null;
    }
  }

  @TargetApi(Build.VERSION_CODES.JELLY_BEAN_MR1)
  private static void assertNotDestroyed(@NonNull Activity activity) {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR1 && activity.isDestroyed()) {
      throw new IllegalArgumentException("You cannot start a load for a destroyed activity");
    }
  }

  /**
   * @deprecated This is equivalent to calling {@link #get(Context)} with the application context.
   *     Use androidx fragments instead: {@link Fragment}.
   */
  @Deprecated
  @NonNull
  @TargetApi(Build.VERSION_CODES.JELLY_BEAN_MR1)
  public RequestManager get(@NonNull android.app.Fragment fragment) {
    if (fragment.getActivity() == null) {
      throw new IllegalArgumentException(
          "You cannot start a load on a fragment before it is attached");
    }
    return get(fragment.getActivity().getApplicationContext());
  }

View on GitHub (pinned to eb14a895d8)

Solutions

1. Check !isDestroyed() && !isFinishing() before issuing the load in callbacks.
2. Cancel pending loads in onDestroy() (Glide.with(this).clear(target)).
3. Use lifecycle-scoped coroutines/LiveData so callbacks don't fire after destroy.
4. For background-thread fetches, use Glide.with(applicationContext) so the request outlives the activity safely.

Example fix

// before
api.fetchImage(url, new Callback() {
  public void onSuccess(Bitmap b) {
    Glide.with(activity).load(url).into(img);
  }
});
// after
api.fetchImage(url, new Callback() {
  public void onSuccess(Bitmap b) {
    if (activity.isDestroyed() || activity.isFinishing()) return;
    Glide.with(activity).load(url).into(img);
  }
});

// Guard async callbacks against a destroyed/finishing activity.
Activity activity = weakActivity.get();
if (activity == null || activity.isDestroyed() || activity.isFinishing()) {
  return; // skip the load
}
Glide.with(activity).load(url).into(img);

When it happens

Trigger: Calling Glide.with((FragmentActivity) activity) or Glide.with((Activity) activity) after Activity.isDestroyed() returns true. Happens in async callbacks (Handler posts, Retrofit responses, coroutines) that fire after the user navigated away.

Common situations: Network callbacks completing after the activity is finished. RecyclerView adapters loading images in onViewRecycled paths racing with activity destruction. Post-delayed runnables that outlive the activity.

Related errors

• You cannot start a load on a null Context
• Cannot register already registered manager
• Cannot unregister not yet registered manager
• BufferedInputStream is closed
• Stream is closed

AI-assisted analysis of bumptech/glide@eb14a895d8 (2026-08-14). Data as JSON: /api/errors/e4f319bf9d84d3df. Report an issue: GitHub.