Glide: java.lang.IllegalArgumentException: register too many Broadcast Receivers

[francescocervone]

Glide Version: 3.6.1

Device/Android Version: Huawei RIO-L01 Android 5.1

Issue details: It seems to be caused by an issue in the Android framework that occurs only on Huawei RIO-L01. Anyway it could be solved catching the exception when DefaultConnectivityMonitor registers the receiver.

Actually I was considering to fix it myself providing a no-op ConnectivityMonitor only for the devices affected by this issue through GlideBuilder#setConnectivityMonitorFactory, but I have seen that this isn't possible in 3.x version.

Stack trace / LogCat:

Fatal Exception: java.lang.RuntimeException: Unable to start activity ComponentInfo{it.subito/it.subito.v2.detail.AdDetailActivity}: java.lang.IllegalArgumentException: regist too many Broadcast Receivers
       at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2450)
       at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2512)
       at android.app.ActivityThread.access$1200(ActivityThread.java:165)
       at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1373)
       at android.os.Handler.dispatchMessage(Handler.java:102)
       at android.os.Looper.loop(Looper.java:135)
       at android.app.ActivityThread.main(ActivityThread.java:5593)
       at java.lang.reflect.Method.invoke(Method.java)
       at java.lang.reflect.Method.invoke(Method.java:372)
       at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:960)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)
Caused by java.lang.IllegalArgumentException: regist too many Broadcast Receivers
       at android.app.ContextImpl.registerReceiverInternal(ContextImpl.java:1836)
       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:39)
       at com.bumptech.glide.manager.DefaultConnectivityMonitor.onStart(SourceFile:61)
       at com.bumptech.glide.manager.ActivityFragmentLifecycle.onStart(SourceFile:50)
       at com.bumptech.glide.manager.SupportRequestManagerFragment.onStart(SourceFile:135)
       at android.support.v4.app.Fragment.performStart(SourceFile:1986)
       at android.support.v4.app.FragmentManagerImpl.moveToState(SourceFile:1102)
       at android.support.v4.app.FragmentManagerImpl.moveToState(SourceFile:1248)
       at android.support.v4.app.FragmentManagerImpl.moveToState(SourceFile:1230)
       at android.support.v4.app.FragmentManagerImpl.dispatchStart(SourceFile:2047)
       at android.support.v4.app.FragmentController.dispatchStart(SourceFile:176)
       at android.support.v4.app.FragmentActivity.onStart(SourceFile:553)
       at com.trello.rxlifecycle.components.support.RxAppCompatActivity.onStart(SourceFile:43)
       at it.subito.v2.activities.BaseActivity.onStart(SourceFile:41)
       at android.app.Instrumentation.callActivityOnStart(Instrumentation.java:1236)
       at android.app.Activity.performStart(Activity.java:6118)
       at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2413)
       at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2512)
       at android.app.ActivityThread.access$1200(ActivityThread.java:165)
       at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1373)
       at android.os.Handler.dispatchMessage(Handler.java:102)
       at android.os.Looper.loop(Looper.java:135)
       at android.app.ActivityThread.main(ActivityThread.java:5593)
       at java.lang.reflect.Method.invoke(Method.java)
       at java.lang.reflect.Method.invoke(Method.java:372)
       at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:960)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)

[TWiStErRob]

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.

[stale[bot]]

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.

[seviu]

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!).

[sjudd]

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.

[sjudd]

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.

[sjudd]

@seviu are you interested in working on this?

[seviu]

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

[llew2011]

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

[sjudd]

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

[MichaelJokAr]

it's Huawei bug. Only crash in huawei

[xxhong]

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

[csbz17027]

it also crash in SM G9650 and one plus A5000.

[xxhong]

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

[llew2011]

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'
}

```java
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

[Longalei]

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

[xxoolltt]

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。

[nileshgrubber]

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.