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/Android-HelloWorldService into >> android_source/packages/apps/Android-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: [email protected] >> website: 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. > > -- unsubscribe: [email protected] website: http://groups.google.com/group/android-porting
