Reputation: 15042
How is using a ContentProviderClient
obtained with ContentResolver#acquireContentProviderClient(...)
any different from ContentResolver#acquireUnstableContentProviderClient(...)
?
It seems like I would write the same code regardless of which method I used. Is there going to be some kind of leak in my app if the ContentProvider acquired goes away and I used the non-unstable method to acquire the client?
So I guess that if the ContentProvider you want to use is running in the same process or if it is running in system_server
then you can go ahead and acquire the client using the stable method, otherwise you should use the unstable method in case the other process crashes or the app hosting the ContentProvider is uninstalled/reinstalled while you are using it. But that leads me to ask is there some kind of advantage to using the stable version of the acquire method, why not just always use the unstable version of the method just in case?
Also what exactly do they mean when they say the following?
This turns off the mechanism in the platform clean up processes that are dependent on a content provider if that content provider's process goes away.
Upvotes: 4
Views: 3413
Reputation: 1122
If you use acquireContentProviderClient
then your process will be killed if the Content provider dies.
If you use acquireUnstableContentProviderClient
then your process will not be killed if the content provider dies - instead you will get a DeadObjectException
- which you need to handle in your code.
You would need to write extra code with the unstable version to deal with recovery when you get a DeadObjectException
. You can see default android implementation of query
method in ContentResolver.java
As far as I understood there would be no leak in your application caused by use of the unstable version.
As to why not chose to use the unstable version always - I believe its the other way round. Very few applications would need to handle and recover from a content provider crash. The easiest approach is to let your application die and restart. A content provider crash is supposed to be extremely rare - memory corruption , disk corruption etc . Unless you have your own provider which is expected to crash for some specific/weird reason you would not need to use the unstable version.
This turns off the mechanism in the platform clean up processes that are dependent on a content provider if that content provider's process goes away.
This is the platform logic to kill all processes that use the content provider. This means your application will not be killed if you use the unstable version
Upvotes: 8