The abstraction layers in Android are admittedly inconsistent. Audio and camera both use a C++ pure virtual interface (e.g. AudioHardwareInterface.h), while other places like LED's and blitter functions have a C struct of function pointers.
Because we run the actual device image in the emulator, any devices that aren't backed by a kernel driver in the emulator need a fake device (such as camera). For audio, we have a kernel driver for the emulator, but other devices like the G1 have a user space layer on top of the kernel driver. In this case, for the emulator, there is a shim that translates AudioHardwareInterface calls to kernel calls. How you surface the driver features to the application will depend on what you are trying to do. Most hardware features are abstracted by a native service, for example Surfaceflinger for 2D graphics, AudioFlinger for audio, CameraService (because CameraFlinger just sounded wrong) for the camera. This allows us to enforce security using the binder interface and to abstract away a lot of differences so that applications don't have to be written to work with specific hardware. I haven't looked at the compass code, but I can take you through the camera as an example. At the top of the stack is android.hardware.Camera, which is the Java object that the application instantiates when it wants to take a picture. This is a thin wrapper around android_hardware_Camera.cpp which is the JNI interface. This in turn is a wrapper around libs/ui/ Camera.cpp which is the proxy for the remote object in the camera service. And yes, libs/ui is a strange place for it, but it has some circular dependencies on Surfaceflinger, so that's where it ended up. Now it gets interesting because there is a binder interface called ICamera.h (pure virtual) which is implemented in ICamera.cpp which is the marshalling code for the IPC binder calls. Let's just take it on faith that the calls from the client result in a marshalled ICameraClient object appearing on the server side of the interface. Upon establishing a connection - provided that the application has permission to use the camera - the camera service instantiates a CameraHardwareInterface derived object, which is the HAL for the actual camera hardware. The camera service takes care of preview display and other low-level house-keeping functions that would be difficult to do in a Java app. The camera hardware driver can either be implemented as a kernel driver with a thin user space shim driver, or it can be implemented as a user space driver with a thin kernel driver (primarily to control access). This is one of the more complex device models. Other devices (like the LEDs) have a much simpler model. On Dec 18, 11:36 pm, "Mark.Li" <mark.lig...@gmail.com> wrote: > up > I'm interested in this issiue too, and I'm reading the code. As > you said,it is not easy to identify all the > files which need to be modified for adding a new one. > > Anybody who can give some clue? > Thank you in advance, > Mark lee --~--~---------~--~----~------------~-------~--~----~ unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
