Thanks Dianne. I think I am missing something very basic here. Please help me out. The way I understand it, atleast through the logs, all IPC calls across the binder are synchronous, i.e., Transact and corresponding OnTransact calls are serialized. Then, how could the threads run concurrently? Is this the case when two applications are accessing the same service?
-Ravi On Mar 14, 9:17 pm, Dianne Hackborn <[email protected]> wrote: > Yes they run concurrently, that is why they are separate threads. :) > > Currently the maximum number of threads in a process's thread pool is 16. > > > > On Sat, Mar 14, 2009 at 6:34 AM, rktb <[email protected]> wrote: > > > 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. > > -- > 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 -~----------~----~----~----~------~----~------~--~---
