But, these threads don't run concurrently...right? I am trying to understand what kind of precautions the native library needs to take in the case of multiple threads.
-Ravi On Mar 14, 3:49 am, Freepine <[email protected]> wrote: > startThreadPool() will spawn a new thread into the thread pool which talks > with binder driver, while joinThreadPool() will put the calling thread > itself into thread pool. > > It seems there is no API to control the maximum number of binder threads in > the pool, and sometimes driver will tell the process to spawn new thread > automatically via BR_SPAWN_LOOPER command. > > On Sat, Mar 14, 2009 at 1:01 PM, rktb <[email protected]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
