Sorry about the delay...

Yes, v4 is ought to have more features than v3... That setter was introduced in #709 so you can either move yourself forward to the v4 snapshot or backport that change if you really want it in 3.0 branch.

This looks like a vendor issue, right? So it's not a widespread problem. Do you really end up with too many Broadcast Receivers or the framework on that device is too touchy? You may be able to reduce the number of receivers if you use the activity context to load with Glide, because it will reduce the number of SupportRequestManagerFragments being registered. You may have to do some manual Glide.clearing though, as a result, if you have a lot of fragment transactions.

This issue has been automatically marked as stale because it has not had activity in the last seven days. It will be closed if no further activity occurs within the next seven days. Thank you for your contributions.

I just happened to get this exception using the latest version of glide (4.4.0)

Attached the stacktrace:

Caused by java.lang.IllegalArgumentException: regist too many Broadcast Receivers at android.app.ContextImpl.registerReceiverInternal(ContextImpl.java:1838) at android.app.ContextImpl.registerReceiver(ContextImpl.java:1794) at android.app.ContextImpl.registerReceiver(ContextImpl.java:1788) at android.content.ContextWrapper.registerReceiver(ContextWrapper.java:489) at com.bumptech.glide.manager.DefaultConnectivityMonitor.register(SourceFile:1062) at com.bumptech.glide.manager.ActivityFragmentLifecycle.onStart(SourceFile:50) at com.bumptech.glide.manager.SupportRequestManagerFragment.onStart(SourceFile:175)

Lines are wrong due to proguard, but the method namess should be correct.
If the fix is as easy as cathing the exception, I can make a pull request. This issue seems happened on a HUAWEI MediaPad T2 10.0 pro. It is easy to search for it since the message has a typo in it (regist!).

I don't object to try/catch since we're already doing that. I'm curious to know though whether this means that there's some other bug causing receivers not to be unregistered (either in Glide or in the application). It's probably unlikely if this only happens on one specific device, but it's a strange exception.

I don't see any instances of this in applications I work on.

A better solution might be to pull the broadcast receiver registration (or even the connectivity monitor) up to the top level Glide singleton. Right now there's one per RequestManager, which means one per Fragment or Activity. If you have a sufficiently large number of Activitys stacked on top of each other or a sufficiently large number of Fragments within a single Activity, you could end up with quite a few programatically registered receivers.

@seviu are you interested in working on this?

@sjudd I have been away for a few days and I could not answer sooner. However I would love to take a look at it.

This is the bug of huawei's mobile phone system. Huawei's mobile phone has a white list mechanism. Only the APP in their white list can avoid this bug. I use reflection to try to solve this bug.
https://github.com/llew2011/HuaWeiVerifier

How to usage

dependencies {
    // add dependencies
    implementation 'com.llew.huawei:verifier:1.0.2'
}

public class SimpleApplication extends Application {

    @Override
    public void onCreate() {
        super.onCreate();
        LoadedApkHuaWei.hookHuaWeiVerifier(getBaseContext());
    }
}

That all

@seviu no problem, let me know if you're planning on sending a pull request.

it's Huawei bug. Only crash in huawei

@llew2011 I used your method, but still reported an error, Chinese users

it also crash in SM G9650 and one plus A5000.

This is the bug of huawei's mobile phone system. Huawei's mobile phone has a white list mechanism. Only the APP in their white list can avoid this bug. I use reflection to try to solve this bug.
https://github.com/llew2011/HuaWeiVerifier

How to usage

dependencies {
    // add dependencies
    implementation 'com.llew.huawei:verifier:1.0.2'
}

public class SimpleApplication extends Application {

    @Override
    public void onCreate() {
        super.onCreate();
        LoadedApkHuaWei.hookHuaWeiVerifier(getBaseContext());
    }
}

That all

I tried. It didn't work

This is the bug of huawei's mobile phone system. Huawei's mobile phone has a white list mechanism. Only the APP in their white list can avoid this bug. I use reflection to try to solve this bug.
https://github.com/llew2011/HuaWeiVerifier

How to usage

dependencies {
    // add dependencies
    implementation 'com.llew.huawei:verifier:1.0.2'
}

public class SimpleApplication extends Application {

    @Override
    public void onCreate() {
        super.onCreate();
        LoadedApkHuaWei.hookHuaWeiVerifier(getBaseContext());
    }
}

That all

I tried. It didn't work

latest version is 1.1.1

@sjudd About the problem. Could we try catch the exception in the class DefaultConnectivityMonitor#register() ?

I find a way that may case this crash 。
Use Glide.with(View) in a fragment ，and in a not be destroyed activity while the fragment destroyed 。（such as HomeActivity)。 Then fragment recreate in the activity and Glide.with(View) recall , and register more and more BroadcastReceiver。
so, use Glide.with(Fragment) in a fragment may fix this。

We are also facing same Issue of glide.

Glide Version : 4.11
Device : LENOVO Lenovo TB-X605FC

Description : We are using BaseActivity to load image and using base activity context. here is code snippet...

 Glide.with(mActivity)
                        .load(url_gc_logo)
                        .thumbnail(0.25f)
                        .apply(RequestOptions.overrideOf(UIHelper.getDeviceWidthInPercentage(20), 0))
                        .apply(RequestOptions.diskCacheStrategyOf(DiskCacheStrategy.AUTOMATIC))
                        .into(imageView);

Stack Trace Log Cat:

java.lang.RuntimeException: Unable to start activity ComponentInfo{com.xyz/com.xyz.NormalItemDetailsActivity}: java.lang.IllegalStateException: Too many receivers, total of 1000, registered for pid: 21747, callerPackage: com.xyz
	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3280)
	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3419)
	at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:83)
	at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
	at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2020)
	at android.os.Handler.dispatchMessage(Handler.java:107)
	at android.os.Looper.loop(Looper.java:214)
	at android.app.ActivityThread.main(ActivityThread.java:7406)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:944)
Caused by: java.lang.IllegalStateException: Too many receivers, total of 1000, registered for pid: 21747, callerPackage: com.xyz
	at android.os.Parcel.createException(Parcel.java:2079)
	at android.os.Parcel.readException(Parcel.java:2039)
	at android.os.Parcel.readException(Parcel.java:1987)
	at android.app.IActivityManager$Stub$Proxy.registerReceiver(IActivityManager.java:4824)
	at android.app.ContextImpl.registerReceiverInternal(ContextImpl.java:1527)
	at android.app.ContextImpl.registerReceiver(ContextImpl.java:1488)
	at android.app.ContextImpl.registerReceiver(ContextImpl.java:1476)
	at android.content.ContextWrapper.registerReceiver(ContextWrapper.java:627)
	at com.bumptech.glide.manager.DefaultConnectivityMonitor.register(DefaultConnectivityMonitor.java:60)
	at com.bumptech.glide.manager.DefaultConnectivityMonitor.onStart(DefaultConnectivityMonitor.java:106)
	at com.bumptech.glide.manager.ActivityFragmentLifecycle.addListener(ActivityFragmentLifecycle.java:37)
	at com.bumptech.glide.RequestManager.<init>(RequestManager.java:144)
	at com.bumptech.glide.RequestManager.<init>(RequestManager.java:106)
	at com.xyz.utils.GlideRequests.<init>(GlideRequests.java:32)
	at com.bumptech.glide.GeneratedRequestManagerFactory.build(GeneratedRequestManagerFactory.java:18)
	at com.bumptech.glide.manager.RequestManagerRetriever.supportFragmentGet(RequestManagerRetriever.java:438)
	at com.bumptech.glide.manager.RequestManagerRetriever.get(RequestManagerRetriever.java:130)
	at com.bumptech.glide.Glide.with(Glide.java:801)
	at com.xyz.service.MyBaseActivity.DisplayBranchLogo(MyBaseActivity.java:294)
	at com.xyz.NormalItemDetailsActivity.setDetails(NormalItemDetailsActivity.java:195)
	at com.xyz.NormalItemDetailsActivity.onCreate(NormalItemDetailsActivity.java:166)
	at android.app.Activity.performCreate(Activity.java:7878)
	at android.app.Activity.performCreate(Activity.java:7867)
	at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1307)
	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3255)
	... 11 more
Caused by: android.os.RemoteException: Remote stack trace:
	at com.android.server.am.ActivityManagerService.registerReceiver(ActivityManagerService.java:14695)
	at android.app.IActivityManager$Stub.onTransact(IActivityManager.java:1906)
	at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:2846)
	at android.os.Binder.execTransactInternal(Binder.java:1021)
	at android.os.Binder.execTransact(Binder.java:994)

Is there any device specific issue? Please help us to solve this issue.

i am facing the same issue, any update on this? @sjudd @seviu

İ was facing this issue a couple weeks in crashlytics. After a lot of researching i found a solution like this;

@Override
    protected void onStop() {
        super.onStop();
        Glide.with(this).onStop();
    }

After adding onStop() method into which i'm used context of Fragment/Activity, i never faced with this issue yet.
İ hope this helps until a new release.

I have an S23 and get the same error when trying to download too many files at once.

It happens when I attempt to use NativeAdapter from dio, which uses cronet.

No luck so far figuring this one out. But if I do NOT use cronet and instead just use http, no errors. HOWEVER, downloads are not as fast as cronet.