11

A Provider is implemented in application and application updates provider data and triggers a remote service which queries the provider to retrieve the stored values.The application is closed after sometime but service keep on accessing the content provider.At some point the following error is thrown in logcat and the remote service is crashed.

"Killing app (pid 1724) because provider is in dying process "

I googled for this error and couldn't find information about why this error occurs.

UPDATE: In one of the places context returned by getApplicationContext is used instead of Service to get contentresolver to query the content provider. Does it cause any problem?

Suresh
  • 9,495
  • 14
  • 49
  • 63

5 Answers5

7

TL;DR

Use unstable ContentProviderClient.

Here is explanation from other author: https://stackoverflow.com/a/33562256/87383

LONG READ

Faced the same issue and resolved (workaround) it next way:

First of all you should understand the difference between ContentResolver.registerContentObserver and ContentResolver.query

So, ContentResolver.registerContentObserver simply connects your local ContentObserver instance with ContentService. It's achieved by creating a "bridge" using ContentObserver.Transport class instance (which is basically a binder) and passing it to the ContentService. See ContentObserver.getContentObserver()

Why it's important ? Because those observers are not managed (registered) by ActivityManagerService.

So, what's special about ContentResolver.query method ? To answer this question we have to look at ContentProviderClient. Because actual queries are performed through ContentProviderClient instances which are responsible for contacting with remote ContentProvider.

And there are two "types" of ContentProviderClient - stable and unstable. Unstable clients are managed by your application. But stable one is managed by Android for you so when application is stopped, ActivityManager knows that it's time to kill all clients.

See this commit for more details on unstable content provider clients: https://android.googlesource.com/platform/frameworks/base/+/6ae8d1821822296df0606c9cd1c46708cc21cb58

Oleksandr
  • 3,761
  • 8
  • 50
  • 80
4

Hmm, hard luck, no answers so far. I figured out what has caused the crash last week! I guess i should share that here.

Provider P is defined in application A which has a service S1 that disables the package and kills the package for some reason. Now there is another application B that has service S2 and uses the provider P. At some point service S1 disables some components of application A package and kills the process, that makes provider to find all the processes that are connected to it and kills those one by one, this makes the process in which application B is running to die with error "Killing app because provider is in dying process.

Moving the provider to a new application solved the issue so that it runs in its own process solved the issue.

Suresh
  • 9,495
  • 14
  • 49
  • 63
  • I face the same problem, and found the killing app source code, just as you said: here:https://android.googlesource.com/platform/frameworks/base/+/6ae8d1821822296df0606c9cd1c46708cc21cb58%5E!/ – dreamtale Oct 28 '15 at 09:35
  • "Moving the provider to a new application"? There's an `android:process=":otherProcessInSameApp"` that you can put on anything in the manifest. – TWiStErRob Sep 08 '16 at 15:30
  • note: killing App A can happen because of an application update, for example – keybee Oct 02 '19 at 13:40
0

try this solution:

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

And it had not restarted the main process when the package uninstalling, that supply the provider...

zhiweiofli
  • 1
0

I encountered the same issue. In my case, the provider is not a 3rd party but provided by system package. The log indicate that the provider has crashed, and since my IntentService is using that provider, my IntentService got killed as a result.

For my case, I modified my IntentService to return START_STICKY in onStartCommand(). This helps in my case because after my service got killed, the OS restart my service again and rerun everything.

Extract from the documentation about START_STICKY flag:

... if this service's process is killed while it is started (after returning from onStartCommand(Intent, int, int)), then leave it in the started state but don't retain this delivered intent. Later the system will try to re-create the service. Because it is in the started state, it will guarantee to call onStartCommand(Intent, int, int) after creating the new service instance ...

This mode makes sense for things that will be explicitly started and stopped to run for arbitrary periods of time, such as a service performing background music playback.

https://developer.android.com/reference/android/app/Service.html#START_STICKY

VCD
  • 889
  • 10
  • 27
0

The following forum post seems relevant. https://groups.google.com/forum/?fromgroups#!topic/android-developers/7aOLy1DXdhQ

It appears that if there is a process "A" running a content provider and a process "B" with a cursor (or ContentObserver) to that content provider and process "A" dies due to, for example, an uninstall of "A"'s package.

phreed
  • 1,759
  • 1
  • 15
  • 30