I'm not trying to be argumentative for the sake of being argumentative Dianne, but if that was the case, how could the IPC calls to the remote process be resolved if they are only declared in the manifest for the service project which is in a different *.apk? This would mean that android was accidentally (presumably) bypassing the requirement to declare your exposed service interfaces in your manifest.
BTW, I would presume that there is an implementation of the class in the local client's *.apk because otherwise the client would have to use late/explicit binding to the interfaces exposed by the service... This should be true anytime you write a client. The bone of contention appears to be one of two things. Either it should be impossible to start a remote service from a class name or some other local to the client reference, or the operating system should handle starting a remote service from a class name 'properly' so that the main service thread can callback into the client instead of just the service's thread pool being able to. In either case, it would be nice if the documentation about starting services recommended using a global service name for starting remote services, although I would certainly know less about Android if that were the case, lol... Is there a formal specification for the behavior of services in this regard? I certainly don't mean any of my comments to sound critical of Android, it really is fantastic (if given to renaming things that had perfectly valid names before :) ), and VERY easy to use. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
