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 appli
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
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.
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 callonStartCommand(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
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.
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...