Hi Thanks for the information, I'll definitly check out MemoryDealer!
On Fri, Jun 22, 2012 at 6:42 PM, Dianne Hackborn <[email protected]>wrote: > 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. > > -- 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
