Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exception for Async Receivers #6

giech opened this issue Dec 23, 2015 · 2 comments

Exception for Async Receivers #6

giech opened this issue Dec 23, 2015 · 2 comments


Copy link

@giech giech commented Dec 23, 2015

If the receiver implemented for a plugin returns true for the isAsync method, this line throws an Exception:
java.lang.RuntimeException: BroadcastReceiver trying to return result during a non-ordered broadcast

This is because the setResultCode() only works with ordered broadcasts.

Possible workarounds include not calling the method for unordered broadcasts, or catching the exception, but I do not know the surrounding code enough to assess the impact.

Copy link

@ccjernigan ccjernigan commented Jan 30, 2016

Thank you for reporting this!

I believe this should only occur under specific conditions:

  • Plug-in settings that are asynchronous (will not occur with plug-in conditions, nor with synchronous plug-in settings)
  • With hosts not using the plug-in host SDK. Locale 6.0.1 on the Google Play store as of today (Jan 30, 2015) uses a slightly different version of the host SDK, so Locale 6.0.1 should reproduce this issue.

Can you confirm that those two conditions must be met?

Assuming yes, the solution we'd probably implement is: Modify AbstractAsyncReceiver.goAsyncWithCallback(AsyncCallback) to accept an isOrderedBroadcast boolean parameter. This can be passed along to the AsyncHandlerCallback as one of the int arg params. AsyncHandlerCallback can then conditionally call pendingResult.setResultCode only if the broadcast is ordered.

Until that is implemented, the workaround for the time being is to avoid making plug-in settings asynchronous.

ccjernigan added a commit that referenced this issue Jan 30, 2016
Copy link

@giech giech commented Jan 30, 2016

Thank you very much for looking into this, and I apologize for not providing a proof of concept in the original report ( contains code that made the exception fire.)

I can indeed confirm that, at least in my case, the app was only creating async plug-in settings with the client, and not the host SDK.

The commit looks like it fixes the issue, so I am closing it.

Thank you so much for the fix!

@giech giech closed this Jan 30, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants