In my app I have some objects with gps positions. At the moment the only thing I do with them is showing them on a map but I plan to implement other features which need to know the users location. I don’t want to add the location permission to my app because some users may not want to use these features.
My idea was to have a separate apk (a kind of plugin) which only supplies the main app with location information so that only the plugin needs to request the location permission.
Is it possible to let the plugin share a system service (the LocationManager) directly without creating a custom service with an incompatible interface so that the main app can use the LocationManager of the plugin. This would make it possible to use existing classes like MyLocationOverlay or others. The main app could pass a ContextWrapper to these classes like this:
public static class LocationContext extends ContextWrapper {
public LocationContext(Context base) {
super(base);
}
@Override
public Object getSystemService(String name) {
if (name.equals(LOCATION_SERVICE)) {
// Return the LocationManager service of the plugin here...
}
return super.getSystemService(name);
}
}
Not sure if I quite understand your question, but it is possible for one application to load classes from another app and thus avoid crossing process boundaries. The key is having the same android:process and android:sharedUserId attributes in your manifests for both aps. Then the apps will run in the same Linux process on the device. You can then use reflection APIs to programmatically load App A’s classes from App B and vice versa. If App A is already on the Market, you would probably need to release a new version that adds the process and sharedUserId attributes, and then release App B with these same attributes.