Thanks Dave.
On Mar 16, 12:04 pm, Dave Sparks <[email protected]> wrote:
> Unless otherwise specified, all binder calls are synchronous to the
> calling process (usually referred to as the client process). They are
> completely asynchronous to the callee (usually referred to as the
> server process).
>
> What this means is that the caller will block in the binder call until
> the server thread has completed the requested action. On the server
> side, the binder request is picked up by on the worker threads, it
> proceeds serially until the work is complete, and then returns the
> result to the caller across the binder. It is possible for multiple
> worker threads to be concurrent within the server process acting on
> behalf of different clients, and perhaps even different threads of the
> same client.
>
> On Mar 14, 8:09 pm, rktb <[email protected]> wrote:
>
> > 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
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
