SendBroadcast阻止来自ThreadPool的线程调用线程

我有一个服务线程池中的线程，它执行了很多操作。最后它将一些数据插入提供程序，并发送广播以通知GUI有关新数据。SendBroadcast阻止来自ThreadPool的线程调用线程

经常发送和接收1-3个广播，则不会收到更多广播。当我看着线程堆栈跟踪时，他们都坐在sendBroadcast的系统方法中。

堆栈跟踪从从未返回线程：

BinderProxy.transact（INT，包裹，包裹，INT）行：不可用[本机方法]
ActivityManagerProxy.getProviderMimeType（URI）线：3296
ContextImpl $ ApplicationContentResolver（ContentResolver的）.getType（URI）线：231
Intent.resolveType（ContentResolver的）线：3754
Intent.resolveTypeIfNeeded（ContentResolver的）线：3776
ContextImpl.sendBroadcast（意向）线：969
应用（ContextWrapper）.sendBroadcast（意向）线：301

Reciver登记：

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

广播发送：

context.sendBroadcast(new Intent(android.content.Intent.ACTION_VIEW). 
         setData(Uri.withAppendedPath(compy.content.Intent.URI_channel, ""+id)));

现在到了真正有趣的部分，上述工作在没有任何问题的Galaxy Nexus上使用ICS和Galaxy Note pre ICS。但在Galaxy Note，Galaxy SII和Galaxy SIII上以ICS描述的方式失败。

关于Galaxy Nexus的一个可能相关说明，提供程序启动一次或两次。在有问题的手机上，所有查询都会开始。我们还没有发现这种行为的任何理由。

任何想法？

来源

2012-06-25 larlin

好吧，这原来是很简单....

我们曾双注册的ContentProvider在Mainfest文件...

所以，如果你有疯狂的错误检查清单。我不知道为什么这打破了广播。

一些更多的信息（编辑）：

要告诉尾巴这个问题是在最logcat中尝试做对提供者的操作时代的“加载提供者‘你的类名称’”。这似乎是一个相当罕见的消息，否则。我们只在网上找到了几个参考。

所以相关说明到底是最重要的....

来源

2012-06-26 16:20:54 larlin

SendBroadcast阻止来自ThreadPool的线程调用线程

回答

相关问题