Well since neither are in the NDK, neither are "stable" interfaces. I don't know what "more stable" means in that context -- either one could change. On the other hand, both are used extensively by Android, so they aren't changed gratuitously since that would impact a lot of code. On the other other hand, if you are worried about binary compatibility, C++ APIs are often less stable than C+ APIs, since a simple change such as adding a virtual method can break binary compatibility, and that is something that could easily happen since it just requires recompiling the code using it.
If you want to stay at the C++ level, I think you can use the MemoryDealer class which is a convenience wrapper around ashmem and Binder for sharing memory. On Wed, Jun 20, 2012 at 10:56 PM, neuron <[email protected]> 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/** >>> Android-HelloWorldService<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: >>> android-porting+unsubscribe@**googlegroups.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. >> >> -- > 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
