Hi, On Aug 16, 11:24 am, Matt <[EMAIL PROTECTED]> wrote: > Hi all. I've been looking a bit into Java-to-native IPC via Binder as > well, and this thread has been very helpful. Hackbod, I have a > question for you regarding your previous post, though. You mentioned > that most of the guts of all of this are written in native C++, and > JNI'ed up to Java, but that no C++ IDL compiler currently exists, so > implementing Binder interfaces in native code is not possible at the > moment. However, I've been poking around in some of the stuff on the > Android filesystem, and symbol dumps of some of the native libraries > reveal classes that appear to represent native and proxy objects for > various Binder interfaces. For instance, libaudioflinger.so contains > classes such as BnAudioRecord/BpAudioRecord, BnAudioFlinger/ > BpAudioFlinger, etc. The naming scheme of these classes is indicative > of the marshalling code generated by OpenBinder's pidgen tool, or > something else written to export a similar interface. So, if there is > no C++ IDL compiler, where did these classes come from? Were they > hand-written (blegh...), or compiled with some as-yet-unreleased > internal tool, or generated through some other method that I'm not > understanding?
These were all written by hand. There are some macros and template classes to help in writing them, but no real tool support. > Other references in the native libraries indicate that IBinder and > friends, as well as IInterface, Parcel, etc. are all present in native > code (libutils.so, specifically.) Studying the Java AIDL output for a > simple interface, it seems that the remoting code is making fairly > straightforward use of the Java wrappers to Parcel and IBinder to send > parameters around. So, it would seem to me that you already have > pretty much everything you need to do native Binder stuff, save for a C > ++ interface compiler, which the above evidence suggests has to exist > in some form somewhere. Obviously you're going to have some trouble > getting native code to access a Java class that's getting itself > across the wire using Parcelable (although it seems like JNI could > come to the rescue here and allow you to construct a jobject* out of > it...), but if I just wanted an IPC interface that's sending ints, > strings, IBinders, etc. around, it seems that I wouldn't need a whole > lot beyond what's already been implemented. Am I missing something, > or is this an accurate assessment? The number of native IDL interfaces being written hasn't, at this point, justified the time needed to implement support for generating them from .idl files. Please understand, Java is our programming language. There are some places where native code is used, and some of this code needs to do IPC so finds it useful to use the internal native Binder classes to do that, but all application code and large chunks of the platform (including such fundamental pieces as the window manager, application manager, etc) are written in Java. If you are coming at this as a handset manufacturer, then native code might be interesting even in the somewhat brutal environment there is for it. But for an application developer, this is simply not an option. Whatever other reasons for this that there may be, at this point and for the foreseeable future there is no way no how we are supporting binary compatibility of these native C++ classes across platform releases. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
