As part of a porting project I would like to call an Android remote service from c++. I found some example code here: http://www.androidenea.com/2010/03/share-memory-using-ashmem-and-bind... - though I have not been able to build it. I found numerous code examples by downloading Android source and have focused my attention on the code in frameworks/base/libs.
Using this code as an example, I have coded an implementation that makes use of resources not exposed in the standard NDK SYSROOT, primarily binder (using binder.h). This code compiles, but I am struggling with linkage.
I have an issue with Lunch, so I cannot currently build the Android sources. As an alternative, I have pulled /system/lib from a 3.1 AVD (my target platform) and am linking against those libraries along with those in SYSROOT. At this point I have two unresolved references, both from the Android shared libraries:
home/parallels/jack/android_3.1_libs/libutils.so: undefined reference to `pread64' /home/parallels/jack/android_3.1_libs/libcutils.so: undefined reference to `__system_property_set' collect2: ld returned 1 exit status make: *** [/media/JACKUBUNTU/eclipse_workspace/SemaphoreClientC/obj/ local/armeabi/SemaphoreClientC++] Error 1
libutils and libcutils are required by libbinder. I have tried various corrections, including adding -lc to the library list.
First - being new to Android - I am hoping for a sanity check that there is not some simpler way to achieve my goal of calling remote services from c++. Failing that, perhaps someone could assist me in resolving my linkage problem.
Thanking all in advance,
Brad
My Android.mk -------------------
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := SemaphoreClientC++
Neither of libcutils, libutils, libbinder are exposed by the NDK, which means that applications should never link against them. Because they are not exposed, their implementation can heavily be modified between platform releases. This probably explain why you have a linking problem.
I'm sorry but applications should never use the Binder from native code, its binary interface is (intentionally) not stable to allow this.
Whatever hacks you may find on the internet, they are just that: fragile hacks that will break (or are already broken) in the future without notice.
On Fri, Nov 18, 2011 at 9:41 PM, Brad Justice <bradleypjust...@gmail.com>wrote:
> Using this code as an example, I have coded an implementation that > makes use of resources not exposed in the standard NDK SYSROOT, > primarily binder (using binder.h). This code compiles, but I am > struggling with linkage.
> I have an issue with Lunch, so I cannot currently build the Android > sources. As an alternative, I have pulled /system/lib from a 3.1 AVD > (my target platform) and am linking against those libraries along with > those in SYSROOT. At this point I have two unresolved references, both > from the Android shared libraries:
> home/parallels/jack/android_3.1_libs/libutils.so: undefined reference > to `pread64' > /home/parallels/jack/android_3.1_libs/libcutils.so: undefined > reference to `__system_property_set' > collect2: ld returned 1 exit status > make: *** [/media/JACKUBUNTU/eclipse_workspace/SemaphoreClientC/obj/ > local/armeabi/SemaphoreClientC++] Error 1
> libutils and libcutils are required by libbinder. I have tried various > corrections, including adding -lc to the library list.
> First - being new to Android - I am hoping for a sanity check that > there is not some simpler way to achieve my goal of calling remote > services from c++. Failing that, perhaps someone could assist me in > resolving my linkage problem.
> -- > You received this message because you are subscribed to the Google Groups > "android-ndk" group. > To post to this group, send email to android-ndk@googlegroups.com. > To unsubscribe from this group, send email to > android-ndk+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/android-ndk?hl=en.
> Neither of libcutils, libutils, libbinder are exposed by the NDK, which > means that applications should never link against them. > Because they are not exposed, their implementation can heavily be modified > between platform releases. This probably explain why you have a linking > problem.
> I'm sorry but applications should never use the Binder from native code, > its binary interface is (intentionally) not stable to allow this.
> Whatever hacks you may find on the internet, they are just that: fragile > hacks that will break (or are already broken) in the future without notice.
> On Fri, Nov 18, 2011 at 9:41 PM, Brad Justice <bradleypjust...@gmail.com>wrote:
> > As part of a porting project I would like to call an Android remote > > service from c++. I found some example code here:
> > Using this code as an example, I have coded an implementation that > > makes use of resources not exposed in the standard NDK SYSROOT, > > primarily binder (using binder.h). This code compiles, but I am > > struggling with linkage.
> > I have an issue with Lunch, so I cannot currently build the Android > > sources. As an alternative, I have pulled /system/lib from a 3.1 AVD > > (my target platform) and am linking against those libraries along with > > those in SYSROOT. At this point I have two unresolved references, both > > from the Android shared libraries:
> > home/parallels/jack/android_3.1_libs/libutils.so: undefined reference > > to `pread64' > > /home/parallels/jack/android_3.1_libs/libcutils.so: undefined > > reference to `__system_property_set' > > collect2: ld returned 1 exit status > > make: *** [/media/JACKUBUNTU/eclipse_workspace/SemaphoreClientC/obj/ > > local/armeabi/SemaphoreClientC++] Error 1
> > libutils and libcutils are required by libbinder. I have tried various > > corrections, including adding -lc to the library list.
> > First - being new to Android - I am hoping for a sanity check that > > there is not some simpler way to achieve my goal of calling remote > > services from c++. Failing that, perhaps someone could assist me in > > resolving my linkage problem.
> > -- > > You received this message because you are subscribed to the Google Groups > > "android-ndk" group. > > To post to this group, send email to android-ndk@googlegroups.com. > > To unsubscribe from this group, send email to > > android-ndk+unsubscribe@googlegroups.com. > > For more options, visit this group at > >http://groups.google.com/group/android-ndk?hl=en.
> So what is the recommended way to call a remote service from a C or C+ > + executable? I still need to accomplish this goal.
> You would have to use JNI to call it through the VM. > On Nov 20, 5:31 am, David Turner <di...@android.com> wrote: > > Neither of libcutils, libutils, libbinder are exposed by the NDK, which > > means that applications should never link against them. > > Because they are not exposed, their implementation can heavily be > modified > > between platform releases. This probably explain why you have a linking > > problem.
> > I'm sorry but applications should never use the Binder from native code, > > its binary interface is (intentionally) not stable to allow this.
> > Whatever hacks you may find on the internet, they are just that: fragile > > hacks that will break (or are already broken) in the future without > notice.
> > On Fri, Nov 18, 2011 at 9:41 PM, Brad Justice <bradleypjust...@gmail.com > >wrote:
> > > As part of a porting project I would like to call an Android remote > > > service from c++. I found some example code here:
> > > Using this code as an example, I have coded an implementation that > > > makes use of resources not exposed in the standard NDK SYSROOT, > > > primarily binder (using binder.h). This code compiles, but I am > > > struggling with linkage.
> > > I have an issue with Lunch, so I cannot currently build the Android > > > sources. As an alternative, I have pulled /system/lib from a 3.1 AVD > > > (my target platform) and am linking against those libraries along with > > > those in SYSROOT. At this point I have two unresolved references, both > > > from the Android shared libraries:
> > > libutils and libcutils are required by libbinder. I have tried various > > > corrections, including adding -lc to the library list.
> > > First - being new to Android - I am hoping for a sanity check that > > > there is not some simpler way to achieve my goal of calling remote > > > services from c++. Failing that, perhaps someone could assist me in > > > resolving my linkage problem.
> > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "android-ndk" group. > > > To post to this group, send email to android-ndk@googlegroups.com. > > > To unsubscribe from this group, send email to > > > android-ndk+unsubscribe@googlegroups.com. > > > For more options, visit this group at > > >http://groups.google.com/group/android-ndk?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "android-ndk" group. > To post to this group, send email to android-ndk@googlegroups.com. > To unsubscribe from this group, send email to > android-ndk+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/android-ndk?hl=en.
My guess is to call java from your c++ code; however that java method is static... so then the question becomes, how to call an android rpc from a static method?
On Nov 21, 2011 9:46 AM, "David Turner" <di...@android.com> wrote:
> On Mon, Nov 21, 2011 at 4:43 PM, Brad Justice <bradleypjust...@gmail.com> wrote:
>> So what is the recommended way to call a remote service from a C or C+ >> + executable? I still need to accomplish this goal.
> You would have to use JNI to call it through the VM.
>> On Nov 20, 5:31 am, David Turner <di...@android.com> wrote: >> > Neither of libcutils, libutils, libbinder are exposed by the NDK, which >> > means that applications should never link against them. >> > Because they are not exposed, their implementation can heavily be modified >> > between platform releases. This probably explain why you have a linking >> > problem.
>> > I'm sorry but applications should never use the Binder from native code, >> > its binary interface is (intentionally) not stable to allow this.
>> > Whatever hacks you may find on the internet, they are just that: fragile >> > hacks that will break (or are already broken) in the future without notice.
>> > On Fri, Nov 18, 2011 at 9:41 PM, Brad Justice <
>> > > Using this code as an example, I have coded an implementation that >> > > makes use of resources not exposed in the standard NDK SYSROOT, >> > > primarily binder (using binder.h). This code compiles, but I am >> > > struggling with linkage.
>> > > I have an issue with Lunch, so I cannot currently build the Android >> > > sources. As an alternative, I have pulled /system/lib from a 3.1 AVD >> > > (my target platform) and am linking against those libraries along with >> > > those in SYSROOT. At this point I have two unresolved references, both >> > > from the Android shared libraries:
>> > > libutils and libcutils are required by libbinder. I have tried various >> > > corrections, including adding -lc to the library list.
>> > > First - being new to Android - I am hoping for a sanity check that >> > > there is not some simpler way to achieve my goal of calling remote >> > > services from c++. Failing that, perhaps someone could assist me in >> > > resolving my linkage problem.
>> > > -- >> > > You received this message because you are subscribed to the Google Groups >> > > "android-ndk" group. >> > > To post to this group, send email to android-ndk@googlegroups.com. >> > > To unsubscribe from this group, send email to >> > > android-ndk+unsubscribe@googlegroups.com. >> > > For more options, visit this group at >> > >http://groups.google.com/group/android-ndk?hl=en.
>> -- >> You received this message because you are subscribed to the Google
Groups "android-ndk" group.
>> To post to this group, send email to android-ndk@googlegroups.com. >> To unsubscribe from this group, send email to
In addition, I need access to ashmem to share data between processes. The Android MemoryFile class is not suitable as I need to access the data in situ - copying the data will result in an unacceptable performance penalty. Up till this point I have been assuming that I could follow the recommendations in this post in android-platform:
>Dave Sparks > More options Feb 24 2009, 7:14 pm >For security reasons, you cannot access shared memory by name. You >pass a file descriptor through the binder interface. See the IMemory >implementations for examples of how ashmem is used.
Is it possible to follow this recommendation without breaking the rule regarding use of the Binder interface from NDK code? Has anyone out there successfully implemented shared memory?
>> Dave Sparks >> More options Feb 24 2009, 7:14 pm >> For security reasons, you cannot access shared memory by name. You >> pass a file descriptor through the binder interface. See the IMemory >> implementations for examples of how ashmem is used.
> Is it possible to follow this recommendation without breaking the rule > regarding use of the Binder interface from NDK code? Has anyone out > there successfully implemented shared memory?
I *think* you can do it without breaking the rules, but you'll have to do the IPC in Java:
-- Use 'ashmem' to create a shared memory area -- Create an .aidl interface which passes a ParcelFileDescriptor -- Implement the .aidl interface in Java rather than C++. -- Pass in the ashmem FD -- Retrieve the numeric FD from the ParcelFileDescriptor, and use mmap to access it from the other process.
Before API level 13, you'll need to write your own Java marshalling and unmarshalling code and use Binder.writeFileDescriptor, instead of using aidl and ParcelFileDescriptor.
> In addition, I need access to ashmem to share data between processes. > The Android MemoryFile class is not suitable as I need to access the > data in situ - copying the data will result in an unacceptable > performance penalty. Up till this point I have been assuming that I > could follow the recommendations in this post in android-platform:
> >Dave Sparks > > More options Feb 24 2009, 7:14 pm > >For security reasons, you cannot access shared memory by name. You > >pass a file descriptor through the binder interface. See the IMemory > >implementations for examples of how ashmem is used.
> Is it possible to follow this recommendation without breaking the rule > regarding use of the Binder interface from NDK code? Has anyone out > there successfully implemented shared memory?
> Thanks in advance,
> Brad
> -- > You received this message because you are subscribed to the Google Groups > "android-ndk" group. > To post to this group, send email to android-ndk@googlegroups.com. > To unsubscribe from this group, send email to > android-ndk+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/android-ndk?hl=en.
> For security reasons, you cannot access shared memory by name. You
> pass a file descriptor through the binder interface. See the IMemory
> implementations for examples of how ashmem is used.
> Is it possible to follow this recommendation without breaking the rule > regarding use of the Binder interface from NDK code? Has anyone out > there successfully implemented shared memory?
> I *think* you can do it without breaking the rules, but you'll have to do > the IPC in Java:
> -- Use 'ashmem' to create a shared memory area > -- Create an .aidl interface which passes a ParcelFileDescriptor > -- Implement the .aidl interface in Java rather than C++. > -- Pass in the ashmem FD > -- Retrieve the numeric FD from the ParcelFileDescriptor, and use mmap to > access it from the other process.
> Before API level 13, you'll need to write your own Java marshalling and > unmarshalling code and use Binder.writeFileDescriptor, instead of using > aidl and ParcelFileDescriptor.
> Cheers
> Adrian
> -- > You received this message because you are subscribed to the Google Groups > "android-ndk" group. > To post to this group, send email to android-ndk@googlegroups.com. > To unsubscribe from this group, send email to > android-ndk+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/android-ndk?hl=en.
I have coded a solution for calling a remote service from native code. In a nutshell, you create an intermediate Java object that binds to the remote service via AIDL. It publishes an interface that maps into the remote service methods you wish to call. The native code instantiates the object and then calls through this object to invoke the remote methods.
I have a test app that seems to be working well using this method.
Bradley, your work is very inspiring. I spent a week on making JNI remote calls work both ways: java calling native, and native calling java. I am most grateful to Jurij Smakov for his fully explained JNI example<http://android.wooyd.org/JNIExample/>. But JNI's GetObject, GetField, NewObject, CallMethod, and method signatures are really painful to deal with. I have hundreds of functions to export this way... I need to define an abstraction layer based on JNI to make message and signal sending (Java/Native) easier. Do you have any idea how to abstract that easily?
On Wednesday, December 7, 2011 7:50:43 PM UTC-5, Brad Justice wrote:
> I have coded a solution for calling a remote service from native code. > In a nutshell, you create an intermediate Java object that binds to > the remote service via AIDL. It publishes an interface that maps into > the remote service methods you wish to call. The native code > instantiates the object and then calls through this object to invoke > the remote methods.
> I have a test app that seems to be working well using this method.
I am afraid that I have no recommendations for you - I have yet to work on a project where the number of calls made the standard "brute force" approach impractical. There may be others on this forum who are familiar with tools to automate the process.
You could build a generic call gate that passed a data blob from which you extract details of the call and parameters yourself, though I am unconvinced it would make the job easier.
On Tuesday, August 28, 2012 7:33:36 AM UTC-7, Emeric Vigier wrote:
> Bradley, your work is very inspiring. > I spent a week on making JNI remote calls work both ways: java calling > native, and native calling java. > I am most grateful to Jurij Smakov for his fully explained JNI example<http://android.wooyd.org/JNIExample/>. > But JNI's GetObject, GetField, NewObject, CallMethod, and method signatures > are really painful to deal with. I have hundreds of functions to export > this way... I need to define an abstraction layer based on JNI to make > message and signal sending (Java/Native) easier. Do you have any idea how > to abstract that easily?
On Monday, November 21, 2011 1:08:10 PM UTC-8, Cacau wrote:
> I don't think it is possible to use shared memory in java > On Nov 21, 2011 1:55 PM, "Brad Justice" <bradley...@gmail.com<javascript:>> > wrote:
>> In addition, I need access to ashmem to share data between processes. >> The Android MemoryFile class is not suitable as I need to access the >> data in situ - copying the data will result in an unacceptable >> performance penalty. Up till this point I have been assuming that I >> could follow the recommendations in this post in android-platform:
>> >Dave Sparks >> > More options Feb 24 2009, 7:14 pm >> >For security reasons, you cannot access shared memory by name. You >> >pass a file descriptor through the binder interface. See the IMemory >> >implementations for examples of how ashmem is used.
>> Is it possible to follow this recommendation without breaking the rule >> regarding use of the Binder interface from NDK code? Has anyone out >> there successfully implemented shared memory?
>> Thanks in advance,
>> Brad
>> -- >> You received this message because you are subscribed to the Google Groups >> "android-ndk" group. >> To post to this group, send email to andro...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> android-ndk...@googlegroups.com <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/android-ndk?hl=en.
