Hi Thank you, I think I have a pretty good grasp on how the pieces fit together now.
On Fri, Jun 22, 2012 at 6:02 PM, Jay Slater <[email protected]> wrote: > Sure thing. Before I put down the code, I should mention that the native > side runs as root and the other end (an Android/Java service) runs as > android.uid.system-- we bundle both with our images. > > On the native side, the relevant part is this. I'm cheating with > SAMPLE_REQUEST_CODE-- I didn't get the base from somewhere authoritative > like I did in the service, and just declared it as a constant instead. I > may have missed some includes on the native side-- I still haven't cleaned > up. > > #include <binder/Binder.h> > #include <binder/IBinder.h> > #include <binder/IServiceManager.h> > #include <binder/Parcel.h> > > const char* SERVICE_NAME = "org.demo.helloworldservice"; > int helloworld() { > android::sp<android::IServiceManager> sm = > android::defaultServiceManager(); > android::String16* service_name = new android::String16(SERVICE_NAME); > android::sp<android::IBinder> mBinder = sm->getService(*service_name); > delete service_name; > > android::Parcel data; > android::Parcel reply; > unsigned int flags = 0; > > mBinder->transact(SAMPLE_REQUEST_CODE, data, &reply, flags); > return 0; > } > > And in the service: > > package org.demo.helloworldservice; > > import android.app.Service; > > import android.os.Binder; > import android.os.IBinder; > import android.os.Parcel; > import android.os.ServiceManager; > import android.util.Log; > > > public class HelloworldService extends Service { > private static final String SERVICE_NAME = > "org.demo.helloworldservice"; > > private static final int SAMPLE_REQUEST_CODE = > IBinder.FIRST_CALL_TRANSACTION + 0; > > private IBinder mBinder = null; > private IHelloworldService mHelloworldService = null; > > @Override > public IBinder onBind(Intent intent) { > return mBinder; > } > > @Override > public void onCreate(){ > super.onCreate(); > > mHelloworldService = new IHelloworldService(); > mBinder = mHelloworldService.asBinder(); > ServiceManager.addService(SERVICE_NAME, mBinder); > } > > class IHelloworldService extends Binder { > protected boolean onTransact(int code, Parcel data, Parcel reply, > int flags){ > switch(code) { > case SAMPLE_REQUEST_CODE: > //Parcel data is the same one that was passed from native > transact() > reply.write(1); > break; > default: > reply.write(0); > } > return true; > } > > public IBinder asBinder() { > return this; > } > } > } > > I don't know what significance, if any, the return value from onTransact > bears. As far as I can tell, it doesn't have any effect from this side. For > the communication with other Android-side apps, you could do another > service with .aidl and have it talk to this one. I haven't tried > communication the other direction (e.g. HelloworldService -> native), but I > doubt it's much more complicated than this was (just implement a Binder on > the native side and register it with IServiceManager). There's probably > some way to get .aidl to work on both sides, but for my purposes, it wasn't > worth the effort. > > You have a couple of options for getting non-root apps to talk to the root > HelloworldService, but those aren't hard to find information on (in the > Android Developers guide on services and on Binder). I'm not sure there's > any way around having to have another class for apps to talk to, which can > then talk to the package-local HelloworldService, though. > > Testing is pretty easy. HelloworldService has to be signed, but after that > you can uninstall/reinstall/start with am, and the native component can be > built, pushed, and started from adb shell. We're building the native > component in-tree, so it was a matter of a couple of seconds to build with > mm and push. > > Latency-wise it's proving to be pretty good. Even with the added overhead > of a Settings check, creation/broadcast/reception of a broadcast intent, > and copying of the intent payload into a text element, it can push out > easily 20-30 barcodes a second. > > Hope this helps. > > Jay > > > On Friday, June 22, 2012 9:28:40 AM UTC-4, neuron wrote: >> >> Hi >> >> Can you share any code on that project? I'm still in the start phase, and >> there are a few areas which I'm not too certain about. We need to allow >> other people access to this library, (aka building a sdk for this >> hardware). I'm having some permission issues going between our native >> daemon and building a non root installable library to connect to it. >> >> How do you do your testing by the way? Did you add your service >> to frameworks/base/cmds/**servicemanager/service_**manager.c and have to >> push the entire framework, or have you found another way of doing it? >> >> Best regards >> Anders >> On Thu, Jun 21, 2012 at 10:30 PM, Jay Slater <[email protected]>wrote: >> >>> As luck would have it, I actually just did exactly what you're talking >>> about, though we're only moving barcodes around, and on account of the >>> simplicity of the data we just used Binder to move everything. Native -> >>> Java was simple enough; we just implemented a Binder on the Java side and >>> put it into ServiceManager. The native daemon grabs the binder via the >>> native side of ServiceManager, and it's that simple. I'm not sure if we're >>> being entirely kosher with our usage, or if the latency would be low enough >>> to be useful for you, but it's certainly lower latency than the keyboard >>> wedge we were using before. >>> >>> >>> On Thursday, June 21, 2012 1:56:25 AM UTC-4, neuron wrote: >>>> >>>> Hi >>>> >>>> We are planning to bundle this with devices. So the highest performance >>>> lowest latency option is to send the ashmem fd through a binder? This was >>>> my original plan, but I had several people saying dont link directly to >>>> cutils, use the binder api instead, as it's a more stable interface. >>>> >>>> On Thursday, June 21, 2012 4:22:11 AM UTC+2, Dianne Hackborn wrote: >>>>> >>>>> Are you intending this to be a regular third party app that you build >>>>> against the SDK, or as something built against a specific version of the >>>>> source code that is bundled with the device? If the latter, why have you >>>>> been told to never touch it? (Though truth be told you will probably want >>>>> to use binder to transfer references to the ashmem region.) >>>>> >>>>> If the former, you can't do this as pure native code, you need to use >>>>> the SDK facilities like Service and the Binder interfaces in the Java >>>>> language, and you definitely aren't going to be running as anything like >>>>> root. >>>>> >>>>> On Wed, Jun 20, 2012 at 6:32 AM, neuron <[email protected]> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> I'm currently working on a project to port some hardware to android. >>>>>> We need to run it as a native daemon, (as root is fine), and to build a >>>>>> SDK >>>>>> so people can communicate with it. >>>>>> I've found a lot of different into on how to get this working. The >>>>>> hardware relies on low latency between hardware and client application. >>>>>> We've looked into ashmem, (and been recommended to not ever touch it), >>>>>> and >>>>>> the android Binder. >>>>>> >>>>>> My current attempt is building https://github.com/keesj/**Andro** >>>>>> id-HelloWorldService<https://github.com/keesj/Android-HelloWorldService> >>>>>> into >>>>>> android_source/packages/apps/**A**ndroid-HelloWorldService. Building >>>>>> this produces two c++ native applications. If I as root run them both >>>>>> they >>>>>> can communicate, but I can't get that to build an apk for a client side >>>>>> app, and I'm not sure how to go about doing it either. >>>>>> >>>>>> Am I doing about this the right way? We need low latency >>>>>> communication between the daemon and the client side applications. >>>>>> >>>>>> I think what I'll eventually end up with is: >>>>>> 1. Our current library, cross compiled to a shared library using >>>>>> gcc4.6 for arm. (GCC 4.5 or higher is a build requirement, current NDK is >>>>>> 4.4). >>>>>> 2. A daemon that links to the library above + has binder code. I was >>>>>> thinking just using init.d to start this on boot. >>>>>> 3. A client native library that connects to the binder above. (The >>>>>> one from HelloWorldService works, but I have to run it as root to get it >>>>>> to >>>>>> connect). >>>>>> 4. A java wrapper for the library above. >>>>>> 5. A demo app using our library. >>>>>> >>>>>> And I guess per device we put the hardware in we'll need to build >>>>>> step 2 and 3 and push them to the device. Installing #2 and possibly >>>>>> something in #3 as root. >>>>>> >>>>>> Best regards >>>>>> N >>>>>> >>>>>> -- >>>>>> unsubscribe: >>>>>> android-porting+unsubscribe@**go**oglegroups.com<android-porting%[email protected]> >>>>>> website: >>>>>> http://groups.google.com/**group**/android-porting<http://groups.google.com/group/android-porting> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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, 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. >>>>> >>>>> >> >> >> -- >> Weeks of coding can save you hours of planning. >> - http://code.google.com/p/**aagaande/<http://code.google.com/p/aagaande/> >> > -- > unsubscribe: [email protected] > website: http://groups.google.com/group/android-porting > -- Weeks of coding can save you hours of planning. - http://code.google.com/p/aagaande/ -- unsubscribe: [email protected] website: http://groups.google.com/group/android-porting
