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
-~----------~----~----~----~------~----~------~--~---

Reply via email to