For completeness, here is how ActivityManagerCompat from support library works:

public static boolean isLowRamDevice(@NonNull ActivityManager am) {
    if (Build.VERSION.SDK_INT >= 19) {
        return ActivityManagerCompatKitKat.isLowRamDevice(am);
    }
    return false;
}

class ActivityManagerCompatKitKat {
    public static boolean isLowRamDevice(ActivityManager am) {
        return am.isLowRamDevice();
    }
}

vs how Glide does it:

@TargetApi(Build.VERSION_CODES.KITKAT)
private static boolean isLowMemoryDevice(ActivityManager activityManager) {
  final int sdkInt = Build.VERSION.SDK_INT;
  return sdkInt < Build.VERSION_CODES.HONEYCOMB
      || (sdkInt >= Build.VERSION_CODES.KITKAT && activityManager.isLowRamDevice());
}

Thanks for the report, it makes me scratch my head: reading the code makes nothing pop out. I have two theories about Android JVMs (and maybe desktop ones too):

1. They throw when they enter a method which references and unexistent method.
   This is definitely true for logging, but not throwing as this would imply a lot of errors from Glide.with on older devices which is not reported.
2. They throw for unexistent methods per statement, which means shortcutting with || and && doesn't work with compatibility, it has to be a normal if-else.
   This looks more plausible, however weird, maybe there's a reason for those extra *Compat<Version> classes in support other than good code structuring practice.

The problem is that these are both just theories, I don't have any evidence pro or contra. Hopefully @sjudd will have some insight, but it may worth asking a SO question, hopefully some Android JVM expert picks it up (just make sure you tag it correctly with android/jvm/dalvik/art).

Huh yeah I don't have any insight here, but it's pretty easy to change if @TWiStErRob's second theory is correct. I can try and push up a change and maybe @joshzana you can try the snapshot?

Sure. I'll give it a shot. I don't have a repro though, so it will have to wait for our next release to get enough coverage and see if the fix takes

You know that it's weird, and probably trumps both of my theories, that you get the crashes on the systems where this method must exist, and not on old ones.

What is your min/target SDK?

15/21. Compile SDK 22.

This is for Dropbox Android, so we have a pretty huge sample size.

I would check in the crash report that the value of Build.VERSION.SDK_INT is correct.
Maybe it is a custom ROM with a bogus value.
Still it is improbable.
It would help to have the logcat lines just preceding the crash as it could contain additional
info to identify the exact cause. Sometimes these errors are the consequence of an earlier Dalvik error at loading classes.

Out of curiosity did you ever figure out a work around for this?

I get this bug too, I found this bug occurred because of some custom rom modify the "Api Level", for example "Android 4.3,level 19".