Android Bug/Architectural Issue: How do I handle multiple versions of my own Content Provider?
I am writing a component that makes certain functionality available to any application running on an Android device (e.g. an advertising service, stock ticker cache, Snowball server, etc).
This functionality is useful for application developers, but not interesting to actual users i.e. my component should be included as part of a new application, but not require the end user to explicitly install the additional component themselves.
I expect that over time multiple applications installed on the phone will want to communicate with my component. As each new application will have a different certificate, I want to communicate between applications using an Android Content Provider. To save resources on the device (networking, caching, etc) only one instance of my component should be appointed to handle all queries.
This works well as Android only registers the first Content Provider for a given URI and then ignores the rest (throwing an “WARN/PackageManager: Skipping provider name xxxx name already used” error each time a new one is installed).
However if the registered Content Provider is uninstalled, it will immediately break all the other applications that rely on it, even though other instances of the component still exist.
Questions:
- Does anyone have any suggestions on how to better handle this situation?
- If I could reregister Content Providers I could handle situations like this, and upgrade components when newer versions are installed. Perhaps the Android OS could also handle this situation better, by tracking Content Provider naming collisions?
- Should I be looking at other communication methods to solve this issue?
package test;
import com.whitemice.MyComponentContentProvider;
public class TheirContentProvider extends MyComponentContentProvider {
public static final Uri CONTENT_URI =
Uri.parse( "content:// myComponentNamespace.theirApplicaitonNamespace");
}
As well as adding the custom provider to the Android manifest.
--provider
android:name="test.TheirContentProvider"
android:authorities=" myComponentNamespace.theirApplicaitonNamespace"
As this is a work time project, I will have to check if I can release the synchronisation code as a working example.
Edit 20090116 »Peli - Probably you should not mis-use getType()… String out), but I will now use query() instead. However, as my application is not compatible with any other software (i.e. my data exchange has no MIME type), I would be interested if anyone could provide a concrete example of where an inappropriate getType() response might cause problems.
Also, for simplicity I am not using intents.
»Dianne Hackborn - …Along those same lines, looking for your own special text in the authority to identify content providers you are going to work with is also kind-of screwy. Typically how we do this is attach meta-data to the component that whoever is interested in identifying specifically tagged components looks for. Look at the way input method service components are discovered in Cupcake as an example.
Here is a small component discovery rewrite, now using meta-data to mark valid Content Providers:
####AndroidManifest.xml####
—provider— android:name=”test.TheirContentProvider” android:authorities=”myComponentNamespace.theirApplicaitonNamespace” —meta-data android:name=”type” android:value=”myComponentNamespace”— —/provider—
####Java Code####
List—ProviderInfo— pis = androidContext.getPackageManager().queryContentProviders(null, 0, PackageManager.GET_META_DATA);
…
for(ProviderInfo pi:pis) { Bundle md = pi.metaData; if (md != null && md.getString(“type”) != null && md.getString(“type”).equals(“myComponentNamespace”)) {
//Congratulations you have now found a valid Content Provider //Note: keep looking as you might find more
} }
The upside of this is that the application developer can now deploy my Content Provider using any URI namespace they choose. However, I will still recommend the previous naming scheme to prevent damaging naming conflicts.
»Dianne Hackborn - …Also, have you thought about security at all? What kind of information is stored on the content provider? Who can access it?
My current application (an advertising server) treats this as an open/free to use API, with risk scenarios being managed mainly on the server side. My next application (component for peer-to-peer data sharing) will require a custom Android Permission for sending data. This is similar to the “android.permission.INTERNET” permission whereby the user still gets a say as to whether the application can send data off the phone. I am not yet confident enough in the security capabilities of Android and/or my knowledge of them, to implement an application that handles confidential data.
