I have a thread from a thread pool in a service that does quite a lot of things. In the end it inserts some data into a provider and sends a broadcast to notify GUI about the new data.
Quite often 1-3 broadcasts are sent and received, then no more broadcasts are received. When I look at the threads stacktrace all of them are sitting in the system methods in sendBroadcast.
Stacktrace from never returning threads:
BinderProxy.transact(int, Parcel, Parcel, int) line: not available [native method]
ActivityManagerProxy.getProviderMimeType(Uri) line: 3296
ContextImpl$ApplicationContentResolver(ContentResolver).getType(Uri) line: 231
Intent.resolveType(ContentResolver) line: 3754
Intent.resolveTypeIfNeeded(ContentResolver) line: 3776
ContextImpl.sendBroadcast(Intent) line: 969
Application(ContextWrapper).sendBroadcast(Intent) line: 301
Reciver registration:
<receiver android:name=".gui.MeasurementReceiver">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<data android:scheme="content" android:host="compy.product.providers.measurement"/>
</intent-filter>
</receiver>
Broadcast sending:
context.sendBroadcast(new Intent(android.content.Intent.ACTION_VIEW).
setData(Uri.withAppendedPath(compy.content.Intent.URI_channel, ""+id )));
Now for the real fun part, the above works without any problems on a Galaxy Nexus with ICS and on Galaxy Note pre ICS. But fails in the described way on Galaxy Note, Galaxy SII and Galaxy SIII with ICS.
On a perhaps related note on Galaxy Nexus the provider is started once or perhaps twice. On the problematic phones it’s get started for all queries. We haven’t found any reason for this behaviour either.
Any ideas?
Okay this turns out to be really simple….
We had double registered the ContentProvider in the Mainfest file…
So if you have crazy errors check your manifest. I have no idea why that broke the broadcast.
Some more information (edit):
A tell tail for this problem is “Loading Provider ‘your class name'” in the LogCat most of the times you try to do a operation on the Provider. This seems to be a quite rare message otherwise. We only found a couple of references to it on the net.
So the related note in the end was the most important….