Glide.get fails if PackageManager IPC fails

[joshzana]

PackageManager has a failure mode where it throws a RuntimeException with "Package manager has died" when IPC calls fail. We see this in the Dropbox app quite frequently. In our internal calls to PackageManager we are careful to catch this RuntimeException and handle it in cases where we can.

Unfortunately, adding Glide to our dependency list has started showing crashes with this stack:

Caused by: java.lang.RuntimeException: Package manager has died
    at android.app.ApplicationPackageManager.getApplicationInfo(ApplicationPackageManager.java:250)
    at com.bumptech.glide.module.ManifestParser.parse(panda.py:25)
    at com.bumptech.glide.Glide.get(panda.py:147)
    at com.dropbox.android.taskqueue.AnimatedGifDownloader.<init>(panda.py:139)
    at com.dropbox.android.DropboxApplication$AppState.initializeMainProcess(panda.py:899)
    at com.dropbox.android.DropboxApplication$AppState.<init>(panda.py:681)
    at com.dropbox.android.DropboxApplication.onCreate(panda.py:207)

For some reason not quite clear to me, we don't see this on anything above 4.4.4.

The request here would be to have a reasonable fallback when PackageManager is unavailable, or a way for apps to opt out of manifest scanning to pick up custom modules, since we don't use any.

[sjudd]

The right long term solution is to switch to using an annotation processor (at compile time), rather than trying to pull entries from the manifest. Unfortunately that won't happen in 3.6, though I may try to take a look at it in 4.0 (pull requests always welcome).

I could add a try/catch for Glide 3, but then sometimes Glide will behave differently than users expect. It would be fine if no modules were registered, as in your case, but the only way we can tell whether or not modules are present is using the manifest.

We could also add a method that would disable the manifest parser for apps that don't use modules, but that would largely defeat the purpose of lazily loading Glide (you'd need to call it in your Application object probably, and even then concurrency makes it hard to guarantee).

Any thoughts?

[TWiStErRob]

@sjudd I agree with a simple patch for 3.x if they want that. Something like a static Glide.disableModules(), if it's static it won't defeat the lazy load... except it seems that they are already initializing Glide on app startup: see the bottom of the stack.

According to the javadoc of Application.onCreate() there shouldn't be worries about concurrency issues.

[sjudd]

@TWiStErRob There can be if you have a ContentProvider that uses Glide. It's still probably better than nothing...

[joshzana]

Yep - I'd prefer a short term solution of disabling modules, and an annotation processor in the long term.

[joshzana]

Hello again - we are still seeing this crash in production several thousand times a day. Any chance I can get a Glide.disableModules() call added?

[TWiStErRob]

Feel free to put up a small PR, it would be very welcome.

Quick question though to rule out a false negative: you do initialize Glide after super.onCreate(), right? Not even sure if that would work, but want to rule it out.

Also see #1742!

[joshzana]

Yes, in our Application subclass we first call super.onCreate() and then initialize things, including calling Glide.get(). It works almost every time!

RE: #1742 - Cool! I hadn't seen that. Not sure I want to wait for v4 though. I'll see about putting up a PR later this week if I have time!