Connection between native binder application and java framework

[Markus]

Hi,

we are currently developping a native application (similair to
mediaservice), which should be accessed from Java by using binder. The
native application is running as service and it is listed by a call to
the tools service and ps, so it should be running.
The part, where we stuck is the connection to Java. we test the
connection by
Object test = this.getSystemService("NAME");
and check, if the reference is null. This works only, if the called
service is not listed by ps (but by service), if the service is
running, the result is null. Therefore, we added some permissions to
the manifest file of the java application. Now we get ACCESS errors,
which is fine, as we do not have the rights to access. The problem is,
that we could not yet find any function in the C/C++ code, which
enables us to change the access permissions for a certain tool or to
publish them. Is there any?

So what is the best way to connect a native binder service to a java
application? What must we add?

bye
Markus

[Dianne Hackborn]

You haven't mentioned a lot of the plumbing needed to make the connection from getSystemService() to something running in another process; I don't know if you just didn't bring it up, or haven't done any of it at all.

Anyway, you probably should not be using getSystemService().  This is for use currently only by the standard system, and adding something there means you are adding new standard platform APIs.  Thus, this should only be done for things that are destined to be accepted in to the base android platform before any developers can use it.

Rather, you should just do this yourself: publish the native side of your service as a Binder interface, and provide your own Java library that clients link with, which has an API to get an interface for the service in whatever form you want.  This may be either a raw aidl interface that apps call directly on, which is the Binder protocol with the service, or if you want to have more flexibility in the future for modifying your implementation without breaking apps you can wrap the raw aidl interface in a hand-written Java API, like we do for all of the core framework.

--
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.  All such questions should be posted on public forums, where I and others can see and answer them.

[Markus]

Hi Dianne,

thanx for your reply. For our target application, we will have to
change some
parts of Android to be able to fullfill our requirements anyway, so we
do not mind to
add stuff to the basic API of Android, which is not a common standard
and we
do not intend to offer endusers to use those extensions. Currently,
we are investigating, what is possible with Android, so we might
bring up more of those ideas of extending/changing standard API. At
the moment, we need a native application due to speed reasons, but we
want to have a GUI system to control our application. Actually, we
would
not mind to write that GUI in our native application but I do not
think
that we will be able to add this to our native application without
changing huge
parts of Android.
Therefore, we need a small communication API between the GUI and the
native application, which is able to send some commands and some
strings,
maybe some numbers. That Java interface stuff just seems to me like a
bit overblowing
for this purpose, so we would prefer something smaller...
With sockets, I would just send packages with an command ID and maybe
some parameters. We are looking for something similiar just by using
binder. getSystemService() seemed to be the right way to write
a rather small connection... Is there nothing small like sockets in
the Binder
Java stuff avaiable? This would make our live pretty much easier and
is flexible
enough for our purpose.

bye
Markus

> hack...@android.com

[freepine]

It seems all you want is kind of IPC mechanism to communicate between client app and your native service. Then I think Binder is quite appropriate for you task.

It's not necessary to call getSystemService. Instead, you can create a native server to register your own service in service manager, then create a c++ client class to communicate with the service (It's easy to obtain a proxy service handle from service manager via Binder framework) and wrap it as Java class via JNI.

For details, you can refer to mediaplayerservice's implementation under /framework/base/media.

[Dianne Hackborn]

On Thu, Dec 18, 2008 at 4:25 AM, Markus <vi...@in.tum.de> wrote:

thanx for your reply. For our target application, we will have to
change some
parts of Android to be able to fullfill our requirements anyway, so we
do not mind to
add stuff to the basic API of Android, which is not a common standard
and we
do not intend to offer endusers to use those extensions.

Please see the post I recently made on adding third party shared libraries to the system.  This should be the way you go about adding your own proprietary features.  As it shows, it is very easy to do, requiring only a couple files, and a couple more if you are going to also include native code that you access with JNI.
 

Currently,
we are investigating, what is possible with Android, so we might
bring up more of those ideas of extending/changing standard API.

No public API changes, ever.  Period.  We also strongly strongly strongly discourage people adding their own private APIs to the framework; these should be added as separate libraries as we show in the example.
 

At
the moment, we need a native application due to speed reasons, but we
want to have a GUI system to control our application. Actually, we
would
not mind to write that GUI in our native application but I do not
think
that we will be able to add this to our native application without
changing huge
parts of Android.

I have no clue what you are wanting to do, so it is very hard for me to address claims of you can't do this or have to do that or whatnot.  All I can say is, please avoid changing the framework, do this through a custom library.
 

Therefore, we need a small communication API between the GUI and the
native application, which is able to send some commands and some
strings,
maybe some numbers. That Java interface stuff just seems to me like a
bit overblowing
for this purpose, so we would prefer something smaller...

Look at the example.  It is nearly trivial.
 

With sockets, I would just send packages with an command ID and maybe
some parameters. We are looking for something similiar just by using
binder. getSystemService() seemed to be the right way to write
a rather small connection... Is there nothing small like sockets in
the Binder
Java stuff avaiable? This would make our live pretty much easier and
is flexible
enough for our purpose.

There is no such method as binder.getSystemService().  Do you mean ServiceManager.getService()?  If so, then yes this is a viable way to communicate with a private service -- you would just publish its IBinder interface with ServiceManager.addService() (either from native or Java code), and clients can retrieve it with ServiceManager.getService() (again either in native or Java code).  This requires no changes to the framework, and would be a reasonable approach.  Note that this is far far different than the this.getSystemService() you mentioned in your original e-mail, which is part of the higher-level framework and would require making changes there to add yourself to it.

But even so, unless you are planning on doing raw transact() calls on the IBinder instead of making life easier and generating interfaces with aidl, you are still probably going to want to have those interfaces and helper classes somewhere for apps to share...  and those should go in your own private shared library.  Maybe without JNI code if all of your native code is back behind an IBinder.

--
Dianne Hackborn
Android framework engineer

hac...@android.com

[Dianne Hackborn]

Yep.  You don't even really need to wrap it as a Java class -- the main reason we do this in the framework is to present in the SDK a more appropriate Java API that is more maintainable across releases.

hac...@android.com