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
