Actual code where ServiceManager does addService and getService

[Victor Ronin]

Hi,

I am learning my way around in AOSP (for version 4.0) and I am trying
to understand how ServiceManager works. I got the main idea and I read
regarding IBinder/Binder.

Also, I found Java code under
/frameworks/base/core/java/android/os - ServiceManagerNative.java,
ServiceManager.java

Also I found C++ code under
/frameworks/base/lib/binder

However, all code which I found calls addService or getService from
other places. And I can't find the place where they are actually
implemented (as example add services to some array or check that array
for existence of such service).

Regards,
Victor

[freakingtux]

Hi,

Here is what I understand from it. There are really two kind of services, native/system services  and application services

System services run as system users and register themself directly by name to the native service manager (this is not ServiceManagerNative.java) . the native service manager

himself is as binder service with a special binder id (namely 0) getSystemService("name"). See

https://github.com/keesj/gomo/wiki/AndroidNativeBinder (again this only my view of the world)

Normal Android activities and services work totally differently. Activities are started by ActivityManagerNative via an ActivityThread that might be spawned from zygote or from an existing jvm instance. The activity /thread calls back to the ActivityManagerNative and registers itself to the ActivityManager.  Now when somebody binds to a non native service it is in the ActivityManagerNative that the magic happens. See

https://github.com/keesj/gomo/wiki/AndroidApplicationStartup

Patches are most welcome!

Greetings

Regards,
Victor

[David Herges]

However, all code which I found calls addService or getService from
other places. And I can't find the place where they are actually
implemented

frameworks/base/cmds/servicemanager/service_manager.c 

There's the service manager implementation. Is it that what you're looking for? 

[Victor Ronin]

Thank you. That's exactly what I was looking for.

The location "cmds" is kind of strange (I thought that it's a
service) :)

One more question on this subject. Do you have any idea why there is
onTransact methods in these two files?
/frameworks/base/core/javan/android/os/ServiceManagerNative.java,
ServiceManager class and
/framework/base/libs/binder/IServiceManager.cpp, BnServiceManager
class

As I understand there should be only one ServiceManager and no other
parts of AOSP should have server side implementation of it.

[freakingtux]

Hello

On Tuesday, February 14, 2012 10:42:56 PM UTC+1, Victor Ronin wrote:

Thank you. That's exactly what I was looking for.

The location "cmds" is kind of strange (I thought that it's a
service) :)

One more question on this subject. Do you have any idea why there is
onTransact methods in these two files?
/frameworks/base/core/javan/android/os/ServiceManagerNative.java,
ServiceManager class and
/framework/base/libs/binder/IServiceManager.cpp, BnServiceManager
class

Please read the wiki pages I sent earlier  The first letter(s) of the class tell something 

about them. I as in Interface , B as in Base class, Bn as in Base native and Bp as in Base proxy.

I = Interface defines an object that will be accessible over binder B = Base implementation Bn = Base native (local object implementation) Bp = Base proxy

Greetings

[Victor Ronin]

I glanced through it before and I read it now. Thanks, it has a lot of
useful info. However it looks like I lack some of basic knowledge
regarding Binder which leads to the problems with understanding some
things from this wiki page.

[freakingtux]

Hi,

On Wednesday, February 15, 2012 5:31:19 PM UTC+1, Victor Ronin wrote:

I glanced through it before and I read it now. Thanks, it has a lot of
useful info. However it looks like I lack some of basic knowledge
regarding Binder which leads to the problems with understanding some
things from this wiki page.

I have tried to write down what I know but it still is a bit fuzzy :p

Reading the source code of 

https://github.com/keesj/Android-HelloWorldService/blob/master/libhelloworldservice/include/IHelloWorld.h

might help you. Also a good read about the original openbinder probject here

http://www.angryredplanet.com/~hackbod/openbinder/docs/html/index.html

good luck.

[David Herges]

basic knowledge
regarding Binder which leads to the problems with understanding some
things from this wiki page.

Basically, it's synchronous IPC based on shared memory. There are "data" and "reply" memory segments. Binder IPC calls works as follows:

a) calling process (or application) writes something into "data"

b) receiving process (or app) reads "data", performs some action based on the input data, and writes output data to "reply"

c) calling process reads from "reply"

The Binder framework just provides a convenient API around that low-level concept. The 'transact' method is invoked by the calling process/app to initiate the IPC transaction/call. It's matched by 'onTransact' by the receiving process/app.

Stub/Proxy are high-level implementations around that basic stuff. They handle references pointing to the remote process/app, do the (un-)marshalling of data from shared memory; i.e. developers can work with high-level interfaces and do not need to care about that the lower layers of Binder IPC.

Here's also a good explanation of the Binder framework (chapters 4-6):

Android Binder: Android Interprocess Communication. Thorsten Schreiber, Ruhr-Universität Bochum.

URL: https://www.nds.rub.de/media/attachments/files/2011/10/main.pdf

Cheers!

[ramakrishna k]

Hi All,

I have a question about system service.

what factors to be considered and what is that it qualifies to be a system service?

how can i decided i should write a system service?

thanks

ramakrishna

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

[Dianne Hackborn]

It runs in the system process, must always be running the entire device is running, and if it crashes or misbehaves it brings down the entire device.

Generally, if you are wondering, you shouldn't be creating one.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Kees Jongenburger]

Hi

On Tue, Feb 21, 2012 at 11:19 AM, ramakrishna k <kra...@gmail.com> wrote:

Hi All,

I have a question about system service.

what factors to be considered and what is that it qualifies to be a system service?

how can i decided i should write a system service?

The general trend should be to try and write services as non system services. If it is possible to

write a service as a standard android service you should not mess up with the platform

Normal services

-Follow the application life-cycle . They can be started on demand and stopped on low memory

-Require you to bind to them (asynchronously) as their lifecycle is managed by the activity manager.

-Are easy to write, debug and deploy

-Can be deployed on standard application

Services that bind directly to the naming service 

-Require you to modify the platform (the naming service) or run as system user

-if run in the system server process can crash your full system

-usually run all the time (but can be started/stopped by setting system properties)

-When run inside the system server will "always" be there. this is quite nice as you can to a getService("bla") synchronously

I found you need to run such services when you modified the system itself. If for example you are adding hardware support

you will often find you can not use standard services. Such services will also use internal API's. That said you can also achieve

a lot and access many API's by running your APK in the system server (setting the user to the system user) this of course requires proper singing.

The thing really is to understand there are different things

-Services stated in the system server and system services as services stated by init. 

Greetings