Hi,
- What do the methods startThreadPool() and joinThreadPool() do during
the process of launching a service, e.g., mediaplayer service in the
file main_mediaserver.cpp?
int main(int argc, char** argv)
{
sp<ProcessState> proc(ProcessState::self());
sp<IServiceManager> sm = defaultServiceManager();
LOGI("ServiceManager: %p", sm.get());
AudioFlinger::instantiate();
MediaPlayerService::instantiate();
CameraService::instantiate();
ProcessState::self()->startThreadPool();
IPCThreadState::self()->joinThreadPool();
}
- I have a service that I am using and see multiple threads on the
server side. Below is a snippet of the log.
03-13 19:52:58.143 26 45 V IMyTest: BnMyTest::onTrasact ...
tid=45
03-13 19:52:58.143 26 44 V IMyTest: BnMyTest::onTrasact ...
tid=44
03-13 19:52:58.183 26 26 V IMyTest: BnMyTest::onTrasact ...
tid=26
03-13 19:52:58.213 26 45 V IMyTest: BnMyTest::onTrasact ...
tid=45
03-13 19:52:58.213 26 44 V IMyTest: BnMyTest::onTrasact ...
tid=44
03-13 19:52:58.233 26 45 V IMyTest: BnMyTest::onTrasact ...
tid=45
03-13 19:52:58.233 26 26 V IMyTest: BnMyTest::onTrasact ...
tid=26
03-13 19:52:58.233 26 184 V IMyTest: BnMyTest::onTrasact ...
tid=184
If I read this correctly, the service is running on a process with
pid=26. But, the "onTransact" calls happen on multiple threads. I did
verify that the "Transact" calls occur in all one thread (on the
application process). Though there appear to be multiple threads (ids)
running, it looks like the calls are serialized. How come there are
multiple threads? Is there a way to control the number of threads
running on the server process?
Thanks,
Ravi
On Feb 12, 3:13 pm, rktb <[email protected]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
