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的線程調用線程

回答

相關問題