Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 42e44711 authored by Jing Ji's avatar Jing Ji
Browse files

Fix a race condition in acquiring content provider 

Client could be stuck at the lock before toggling the waiting flag,
meanwhile the publishing of the provider could been holding the lock
and check that flag, thus result in not notifying the client.

Now setting the flag with the global lock held.

Bug: 186228106
Bug: 190034355
Test: atest CtsContentTestCases:android.content.cts
Test: atest FrameworksCoreTests:android.content
Change-Id: I7c7a3326c302cc01e52a9a5d78ea9d089be0dcae
parent 327a2716

services/core/java/com/android/server/am/ContentProviderHelper.java

+27 −26
Original line number Diff line number Diff line
@@ -501,7 +501,6 @@ public class ContentProviderHelper { 


            mService.grantImplicitAccess(userId, null, callingUid,

                    UserHandle.getAppId(cpi.applicationInfo.uid));

        }



            if (caller != null) {

                // The client will be waiting, and we'll notify it when the provider is ready.
@@ -529,10 +528,12 @@ public class ContentProviderHelper { 
                                ContentResolver.CONTENT_PROVIDER_READY_TIMEOUT_MILLIS);

                    }

                }

            // Return a holder instance even if we are waiting for the publishing of the provider,

            // client will check for the holder.provider to see if it needs to wait for it.

                // Return a holder instance even if we are waiting for the publishing of the

                // provider, client will check for the holder.provider to see if it needs to wait

                // for it.

                return cpr.newHolder(conn, false);

            }

        }



        // Because of the provider's external client (i.e., SHELL), we'll have to wait right here.

        // Wait for the provider to be published...