Thanks Dianne. We will try to put together the pieces and get back with more concrete questions.
-Ravi On Feb 11, 6:24 pm, Dianne Hackborn <[email protected]> wrote: > On Wed, Feb 11, 2009 at 1:43 PM, rktb <[email protected]> wrote: > > addService from Java: > > Next, I tried to read how services are added from Java. > > - I looked at frameworks/base/services/java/com/android/server/ > > SystemServer.java. > > - This translates to a call in frameworks/base/core/java/andrid/os/ > > ServiceManager.java and then to frameworks/base/core/java/andrid/os/ > > ServiceManagerNative.java. > > - Here, there is a remote call to call native "addService" in > > frameworks/base/cmds/runtime/ServiceManager.cpp. > > - The requested service is added to a KeyedVector "mServices". > > > Service as an application component: > >http://code.google.com/android/reference/android/app/Service.html > > A "system service" and an SDK-based application service made with Service > are very different things. The latter does not involve ServiceManager at > all, and ActivityManagerService (which -is- a system service) does all of > the arbitration, binding, etc of them. > > And all of this has nothing to do with what is going on in init, which is a > completely different world. At the point where you reach SystemService, > you've jumped up a number of layers of the stack. Service is up yet one > more layer. > > > Now, I am trying to see how I can launch a native service during > > runtime that has the following characteristics: (I am lost looking at > > the code and need some fresh ideas) > > - It needs access to a private directory that no other service can > > access -- For this, I was thinking of launching the service from a > > Java .apk file (through a JNI) because each application would have > > it's own private directory. > > - It needs to be accessible to other services, say mediaservice. > > - It needs a way to validate the calls, i.e., it should honor calls > > only from a trusted service. > > There isn't actually enough information here to make a good decisions. Some > things to keep in mind: > > - Going the Service route means that you can not start up until the rest of > the system has been brought up and the activity manager has started spawning > application processes. Also clients will need to go through the activity > manager Java APIs to use the service so they will need to be in processes > that were started by the activity manager. > > - Performing security checks is really a part of the interface. If you do > your IPC mechanism as a Binder interface you will do your security checks > the same basic way -- using Binder.getCallingUid() -- regardless of how the > service is started. > > - There is no general concept of "trusted" in Android. You get to define > who you trust, typically by defining a new Android permissions that is > granted to the UIDs who are allowed to access the functionality it protects. > > - If you want to have an isolated sand box independent of being a high-level > Service, you can: just define a uid for yourself, make a directory owned by > that uid, and there you are. The files in etc/permissions allow you to > granted higher-level Android permissions to lower-level uids you have > defined; there is also a C API you can call to do an IPC with the > higher-level system to check wheter a permission has been granted to a > particular uid. (The files in etc/permissions also allow you to associate a > gid with a permission, meaning any app processes whose uid holds that > permission will also be put in that gid, for linking filesystem-level > permissions to Android permissions.) > > - You can write your code as just a native process running native code with > a native Binder interface to it that is published in the service manager. > For simple things, if you define a corresponding interface in .aidl then > Java code can also call on it without any extra work. > > - If you want to publish your interface through the ServiceManager, it > should probably not be implemented as a high-level Service, since the > ServiceManager isn't really designed to deal with the issues of service > processes coming, going, and starting on demand, as a high-level Service > component does. > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" 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-framework?hl=en -~----------~----~----~----~------~----~------~--~---
