How and when to use the ContentProviderClient obtained using the purchaseUnstableContentProviderClient method?

Question

How is ContentProviderClient obtained with ContentResolver#acquireContentProviderClient(...) different from ContentResolver#acquireUnstableContentProviderClient(...) ?

It seems I would write the same code, no matter what method I used. Will there be some leak in my application if the purchased ContentProvider disappears and I used the unstable method to acquire the client?

So, I assume that if the ContentProvider you want to use works in the same process or if it works in system_server , you can continue and acquire the client using a stable method, otherwise you should use an unstable method if another process or application crashes , which hosts the ContentProvider, will be uninstalled / reinstalled during its use. But this leads me to ask if there is any advantage to using a stable version of the retrieval method, why not just always use the unstable version of the method just in case?

And what exactly do they mean when they say the following?

This disables the mechanism in the platform cleanup processes, which are dependent on the content provider if that content provider leaves.

Answer 1

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 get a DeadObjectException - which you need to handle in your code.

You will need to write additional code with an unstable version to handle recovery when you receive a DeadObjectException . You can see the default android implementation for the query method in ContentResolver.java

As I understand it, your application will not leak due to the use of an unstable version.

As for why you did not decide to use the unstable version always - I consider it the other way around. Very few applications will need to be processed and restored due to a failure of the content provider. The easiest approach is to let your application die and restart. Content provider crashes should be extremely rare: memory corruption, disk corruption, etc. Unless you have your own provider, which is expected to crash for some specific / strange reason, you will not need to use an unstable version.

This disables the mechanism in the platform cleanup processes, which are dependent on the content provider if that content provider leaves.

It is the logic of the platform to kill all the processes that use the content provider. This means that your application will not be killed if you use an unstable version.