Android 杀戮app<；我的服务>；（pid 1724）因为供应商<；我的供应商>；正在染色过程中<；我的应用程序>；

提供程序在应用程序中实现，应用程序更新提供程序数据并触发远程服务，该服务查询提供程序以检索存储的值。应用程序在某个时间后关闭，但服务继续访问内容提供程序。在某个时间点，logcat中会抛出以下错误，远程服务将被删除崩溃了

“正在终止应用程序（pid 1724），因为提供程序正在消亡”

我在谷歌上搜索了这个错误，找不到关于为什么会发生这个错误的信息

---

更新：在其中一个地方，使用getApplicationContext返回的上下文而不是服务来获取contentresolver以查询内容提供程序。有什么问题吗

嗯，真倒霉，到目前为止还没有答案。我找到了导致上周车祸的原因！我想我应该在这里分享

提供者p是在应用程序A中定义的，应用程序A有一个服务S1，该服务禁用包并出于某种原因终止包。现在还有另一个应用程序B，它拥有服务S2并使用提供者P。在某个点上，服务S1禁用应用程序A包的某些组件并终止进程，这使提供者能够找到连接到它的所有进程并逐个终止这些进程，这使得应用程序B正在运行的进程死亡，错误为“因为提供程序正在死亡，所以终止应用程序”

---

将提供程序移动到新的应用程序解决了问题，使其在自己的流程中运行解决了问题。

以下论坛帖子似乎与此相关。

如果有一个进程“a”运行一个内容提供商，而有一个进程“B”带有指向该内容提供商的游标（或ContentObserver），并且进程“a”由于卸载“a”的包而死亡。请尝试以下解决方案：

Context ctx = context.createPackageContext("package of the provider", Context.CONTEXT_IGNORE_SECURITY);
cursor = ctx.getContentResolver().query(uri, null, null, null, null);
// do something with cursor 

并且在卸载包时，它没有重新启动主进程，这提供了提供程序…

TL；DR

使用不稳定的ContentProviderClient

以下是其他作者的解释：

长时间阅读

面临同样的问题，并以下一种方式解决（变通）：

首先，你应该理解和之间的区别

因此，ContentResolver.registerContentObserver只是将本地ContentObserver实例与ContentService连接起来。这是通过使用ContentObserver.Transport类实例（基本上是一个绑定器）创建一个“桥”来实现的并将其传递给ContentService。请参阅

为什么它很重要？因为这些观察员不是由管理（注册）的

那么，ContentResolver.query方法有什么特别之处呢？要回答这个问题，我们必须看一下。因为实际的查询是通过负责联系远程ContentProvider的ContentProviderClient实例执行的

有两种“类型”的ContentProviderClient和。不稳定的客户端由您的应用程序管理。但是稳定的一种由Android为您管理，因此当应用程序停止时

---

有关不稳定内容提供商客户端的更多详细信息，请参阅此提交：

我遇到了相同的问题。在我的情况下，该提供商不是第三方，而是由系统包提供的。日志表明该提供商已崩溃，并且由于我的IntentService正在使用该提供商，因此我的IntentService被终止

对于我的情况，我修改了我的IntentService，在

onStartCommand（）

中返回

START\u STICKY

。这对我的情况很有帮助，因为在我的服务被终止后，操作系统会重新启动我的服务并重新运行一切

从有关

START\u STICKY

标志的文档中摘录：

…如果此服务的进程在启动时被终止（在 从

onStartCommand（Intent，int，int））返回
，然后将其保留在
已启动状态，但不保留此交付意图。稍后，系统
将尝试重新创建服务。因为它处于已启动状态，
它将保证在之后调用
onStartCommand（Intent，int，int）
正在创建新的服务实例

这种模式对于将被显式启动和启动的事物是有意义的
停止以运行任意时间段，如服务
播放背景音乐

我会稍微更改标题，而不是和。我面临同样的问题，找到了杀戮应用程序的源代码，正如您所说：“将提供商移动到新应用程序”？这里有一个
android:process=“：otherProcessInSameApp“
您可以在清单中放置任何内容。注意：例如，由于应用程序更新，可能会终止应用程序A