How and when to use a ContentProviderClient obtained using acquireUnstableContentProviderClient?

Question

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.

Comparative

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 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

Glandular

Thanks for the answer. Can you point to where AOSP android kills the process that is holding a ContentProviderClient when the ContentProvider goes away? Also as I mentioned in my question I believe that a ContentProvider can go away for more reasons than just crashing, what about when you are connecting to a ContentProvider that is in another APK and that APK is re-installed with an updated version? – Comparative

I'll try to lookup where the processes are killed. As for re-installing APK any processes that belong to that APK are killed - not just content provider. The provider starts when next time any application will access it. This part of the code which starts the content provider is in ActivityManagerService.java::startProcessLocked() – Glandular

I am not seeing any crash that occurs in the process that is holding an active ContentProviderClient obtained with ContentResolver#acquireContentProviderClient when that remote ContentProvider dies due to a crash. I posted my test code here: github.com/satur9nine/AndroidCallTest I will try another test where the ContentProvider is actually in another APK and that APK is uninstalled while the ContentProviderClient is active. – Comparative

Nevermind my previous comment. Android is a little funky in that when a thread throws an uncaught exception it keeps other threads running until the crash dialog is dismissed by the user. If the crash occurs while holding a stable ContentProviderClient then that holding process does crash. If the ContentProviderClient is unstable then you get android.os.DeadObjectException. – Comparative