technology notes… mobile and embedded.

Archive for the ‘programing’ Category

An Android 101: Hardware and HAL

with 2 comments

Unlike traditional Linux based systems, Android applications communicate with the underlying hardware through Java APIs not by system calls.


             Figure 1: Android vs a Tradition Linux system.

Most of the ‘shared libs’ in the above diagram represent the HAL modules.  The Hardware Abstraction Layer or HAL is the glue between any device (part of the kernel) and the corresponding JNI interface.

The details about the HAL is usually not of interest to application developers. However it is an important module for hardware vendors and OEMs involved in  porting android into their own hardware and adding new hardware.

Folder structure:
   The HAL source code reside under the hardware folder . OEMs maintain a top level root directory and internally there are several HAL modules for the corresponding hardware.

On device ,the HALs live as .so’s  either in ‘/system/lib/hw’ or ‘/vendor/lib/hw’. The HAL modules follow a certain nomenclature as defined here . Android relies on this naming convention to load the right HAL module for a given hardware and board configuration.


The HALs get loaded by its clients using the  hw_get_module. This method relies on the values set to ro.hardware , ro.product.board and some other ro properties to load the correct .so. The complete list is here.
For eg. The SurfaceFlinger is the system wide compositor and the hardware composer is a HAL that abstracts device specific composition logic. The SurfaceFlinger loads the hardware composer using the hw_get_module method to get a handle of the HAL.

Each HAL implements a set of hooks which get called by their invoking service. The contract between the system service and the HAL is well defined. Device makers should ensure these interfaces are implemented as expected by the Android services. The figure below tries to show some of the HALs on the Android ICS version and key methods that HAL writes should implement.


With the newer versions of Android ,the scope of HALs have expanded and it is likely they will be used not just to abstract hardware but to abstract any device specific behavior.


1. Good site about  adding support for a Camera : http://processors.wiki.ti.com/index.php/TI-Android-DevKit-Camera_Porting_Guide
2. Patrick Brady’s Google I/O talk: https://sites.google.com/site/io/anatomy–physiology-of-an-android
3. Figure 1 courtesy: http://www.cmg.org/measureit/issues/mit78/m_78_3.pdf
4, Class diagrams created using Umbrello ,an open source UML Modeler.

Update:  Here is a new post on the same topic with much more detail:  http://www.opersys.com/blog/extending-android-hal


Written by sujai

June 25, 2012 at 7:42 am

An Android 101 : An overview on Binder framework.

with 2 comments

While the underlying platform makes use of Linux concepts, the Android applications are pretty unique. Unlike traditional Java apps, Android apps do not have a an entry point (like a main() function ).  The framework could invoke a particular entry point within an application to achieve the requested functionality.
Each android application is a mixture of several components . The components can be broadly grouped into 4 ‘component types’.  You could read more about components here.

[Image credit : Android binder thesis by  Thorsten Schreiber]

The different components may need to  exchange data and it is realized through inter component/ inter process communication .The communication works with so called intents.Intents are representations for actions to  be performed. Each intent is made of a URI and an ‘action’. The URI identifies the destination and action defines the operation to be performed on the component identified by the URI.  As we learn about components and interactions it becomes increasingly evident that IPC forms a major part of  the Android framework.

The Binder framework :
Unlike traditional Linux machines, Android uses its own mechanism for IPC called the Binder. Binder was originally developed as OpenBinder and was used as the IPC in BeOS . The current Binder implementation in Android is a customized implementation of the OpenBinder. This was mainly to ensure the new implementation uses a license that is compatible with the Android’s user space code.

Each Binder object is an implementation of the IBinder implementation . An important difference between Binder and other IPC mechanisms is the use of  Binder token. A binder token is value that uniquely identifies any  Binder. This capability to uniquely identify a binder across processes allows the binder id to act as a ‘shared token’ across multiple processes.

Communication model:
The Binder framework communication is a client server model . Each client initiates communication and waits for response from the server. Each client would have a proxy  object for the client side communication. The server side constitutes a pool of worker threads.The server shall spawn a new thread for each new Binder request from the client. The bridge between the client and the server process is the binder driver. The Binder driver is a character device that is part of kernel space. This module  ensures the client reaches the appropriate destination  across process boundaries.


                                                                    [Image credit : Android binder thesis by  Thorsten Schreiber]

AIDL : As with any other RPC , there is a need to write a proxy and stub class that would be interacting with the client and server. Developers  write the interface   for their remote services using AIDL .The AIDL parser takes care of generating Java classes for the proxy and stub and logic to convert data into parcels ,that the Binder middleware understands.
If you are in the business of writing AIDLs you should  keep in mind that the Binder protocol is always ‘request gives response’ there is no inbuilt constructs to provide asynchronous functions. Asynchronous mechanisms have to be built on  top  of the Binder framework.

Binder vs SysV IPC: You may wonder why not reuse SysV IPC that comes with Linux. The Binder documentation has good explanation on why Google  has stayed away from using SysV IPC.

One of the design requirements of Binder is to ensure there is no ‘resource leak’ when any service dies improperly . i.e.Ensure that any kernel level resources (like semaphores/binder objects)  are cleared up in case the parent process is killed or crashes prematurely. There is no way to release a SysV semaphore if the process that created it is explicitly killed or it crashes. Killing processes automatically to make room for new ones is very common with the Android framework.

For an in-depth discussion on Binders, you could refer to some of the links below that I used to learn about Binders.

1. eLinux Binder documentation : http://elinux.org/Android_Binder
2. A nice ppt with implementation details : http://blog.kmckk.com/archives/3676340.html
2. NDK reference documentation about SYS V IPC :  <NDK INSTALL ROOT>\docs\system\libc\SYSV-IPC.html .
3. Comparison of IPC mechanisms : http://lwn.net/Articles/466304/
4. A good overview on OpenBinder : http://www.osnews.com/story/13674/Introduction-to-OpenBinder-and-Interview-with-Dianne-Hackborn/

Written by sujai

December 28, 2011 at 11:27 pm

3G in India.

with 2 comments

I was pleasantly surprised to hear the news. 3G has finally arrived in India!!  The news brought some nostalgic thoughts in me. The first project  in my career was an application for a 3G telephone !

This was  circa 2002 when phones were still 3 line displays in  India. Our company was planning to launch its first 3G device with VideoTelephony.  We had just launched a   ‘camera phone’ and the obvious use case on a camera device with connectivity was Video telephony.

Our team was tasked with developing UI for the Video telephony app. The feature had pretty dense specifications catering to several use cases and error scenarios. What made the project more interesting was there were no
counterparts to refer to and there were lengthy discussions every  night on the use cases.


Our team had a major part in developing this UI above.  The coding was done and things were pretty silent for a very long time.  But then came the real deal. A build was prepared to demo the application   to the chief of a prominent 3G operator .But the phone crashed right after  the app was closed. The issue was root caused to a module we had developed!

I still remember the days that followed that.That week was my initiation into  a career that filled with nigh outs and firefighting.  Nightouts, email escalations ,hourly updates , RCA , TIGER/SWAT team. I learnt  all these  terms that week!

After about one week,we identified the root cause of the problem. A build was made and world order was restored!

My first project was not just about night outs. After several weeks, our team simulated  the first 3G call over 2 Anritsu boxes in our labs .It was the first time (ever) that a live Video call was demoed at our labs. That feeling was surreal!!

Technology  has caught up so fast … Video Telephony is a reality in India today. If you happen to use Motorola A835 or any other 3G video telephone device of Motorola (non Android) , I have a part on it 🙂

Written by sujai

May 16, 2010 at 4:34 pm

Memory consumption of your program.A quick and dirty way.

leave a comment »

Happy New Year too all ! Hope the New Year turns out a good one for all of us.

This year,  I would like to write more ‘code’ and blog more about hands on programing tips and topics. With this in mind,  here is the first hands on tip I thought of putting as my first post for the year.

One of the metrics that is measured  in Desktop and Embedded Linux programs  would be its ‘startup time’  and memory (RAM) usage . Owing to its virtual memory , there is no ‘static ‘ way to estimate  RAM usage of a program.

Here is a quick & dirty way to identify the memory consumption your Linux program. This relies on the page-faults that occur as soon as the program is started .

A  gross estimate on the total page faults that happen over an interval by cat’ing /proc/vmstat and look at the page-in count (pgpgin).

As long as your program is the main thing running, and the only work that’s starting up between two checks of that value, the vast majority of those page faults will have been for you.
It’s also useful to look at that value when the device seems to be running sluggishly — when I’ve done that, the page fault count is rising very rapidly, indicating thrashing due to too much memory in use, and too little left for a usable page/file cache.

eg: Before starting your app:
# cat /proc/vmstat
nr_dirty 0
nr_writeback 0
nr_unstable 0
nr_page_table_pages 677
nr_mapped 8151
nr_slab 1231
pgpgin 166187
pgpgout 33
pswpin 0
pswpout 0

After starting app and allowing the initial UI to come up, run the command again:
# cat /proc/vmstat
nr_dirty 0
nr_writeback 0
nr_unstable 0
nr_page_table_pages 711
nr_mapped 8012
nr_slab 1139
pgpgin 172090
pgpgout 33
pswpin 0
pswpout 0

The difference in pdpgin gives an estimate on the memory usage by your application on startup.

So what does these esoteric names mean .Here is a reference on what these terms mean.

pgpgin      –  Number of kilobytes the system has paged in from disk per second.
pgpgout     –  Number of kilobytes the system has paged out to disk per second.
pswpin      –  Number of kilobytes the system has swapped in from disk per second.
pswpout     –  Number of kilobytes the system has swapped out to disk per second.

The following statistics are only available by kernels from 2.6.
pgfault     –  Number of page faults the system has made per second (minor + major).
pgmajfault  –  Number of major faults per second the system required loading a memory page from disk.

Written by sujai

January 6, 2009 at 10:41 am

%d bloggers like this: