2. Contents
• Android Framework Design Categories
• Java Framework Components
• Callbacks On Binder
• Native C++ Services
• Binder Callbacks From Native Service
• Ashmem And MemoryFile
• Native Daemon Interacting With Java Framework on Local Sockets
3. Android Framework Design Categories
Android framework components can be designed and implemented in 3 major categories.
1. Manager class and the corresponding framework service are implemented in Java.
2. Manager class in Java and the framework service is implemented in native layer(C++).
3. Native daemon written in C++ talks to the manager component implemented in Java using
local Sockets.
4. Manager class acts as mere proxy( in cases 1,2) ,checking permissions and delegating the
actual work to the framework service.
4. Java Framework Components
• Manager is a java class acting as a proxy for the framework service also implemented in Java.
• Listeners/callbacks from the framework can be implemented using binder as the application is a
separate process and the framework service runs in a separate process(probably system server).
• Framework Services can talk to devices using JNI in this method.(Bluedroid source code can be
referred for additional details).
• When using JNI the invocation happens in the same process and doesn’t require Binder.
6. Native C++ Services
Services are implemented in the native layer in the
following cases:
• Interaction with hardware device is more.
• Huge data exchange from hardware.
• Have restrictions in using JNI
Reference: AudioFlinger/SurfaceFlinger are implemented
as native services , and can be used as reference.
Following snippet of code represents the main
function of a Native (C++) Service :
//get service manager instance to register the native
service
sp<IServiceManager> sm =
defaultServiceManager();
//Register a service with the SERVICE_NAME
sm->addService(String16(SERVICE_NAME),new
demo_api::DemoAPI());
//Start Service and Loop waiting for requests
ProcessState::self()->startThreadPool();
IPCThreadState::self()->joinThreadPool();
7. Binder Callbacks From Native Service
• The application can receive callbacks from native services ,in the same way as java services.
• Referring to the aidl file, add Binder transaction numbers for the listeners in sequential order
starting from FIRST_CALL_TRANSACTION in the native service header file.
• Call transact method of the binder object with the binder transaction numbers and the magic
happens ,invoking the corresponding callback in Java layer.
9. Ashmem And MemoryFile
• Ashmem, MemoryFile combination helps to avoid memory copies from Java to C++ layer and vice versa.
• Create Ashmem region in the Native C++ daemon
• Pass the file descriptor of the Ashmem region to the framework component running in the Java layer in a
callback.
• Using the file descriptor received create a MemoryFile object and by the Magic of Ashmem ,the data can be
read just like normal stream.
• Saves the “per application” heap(48 MB/64 MB) from growing beyond the limit as data is shared and not
copied into application heap.
Reference:
https://vec.io/posts/andriod-ipc-shared-memory-with-ashmem-memoryfile-and-binder
10. Native Daemon Interacting With Java
Framework on Local Sockets
• Native daemon written in C++ acts as a Local Server
• Framework component from Java layer connects to the Local Server
• Data and control commands are transferred using the connected socket.
• RILD daemon in Android is a typical example of this type of implementation.
RIL (JAVA)
Rild
(C++)
Sockets