11941fd651
When accessing a content provider, there is a check for whether the provider can run in the caller's process; if so, even if the provider is currently published, we return to the caller that it can run locally. This check was broken -- it had an old condition that allowed content providers owned by the system UID to run in any other UID's process. This is wrong, since by definition the other UIDs would not be able to access the data under the original UID. We ran into this because the activity picker is part of the android platform manifest, so runs as the system process. However it needs to run as the user who invoked it, so when coming from the non-primary user we spin up a "system" process running as a uid of that user. Now when that process tries to access the settings provider, the broken check would think that a new instance of the settings provider should be created in the caller's process. Change-Id: I7bf495ed8370cb271bdaec073d5b7dda9e38c546