Home > Community > Blogs > System Design and Verification > android system verification part 3
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the System Design and Verification blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Android System Verification - Part 3

Comments(2)Filed under: System Design and Verification, Specman, android

In Part 2 of this series on Android System Verification I provided the basics on how to use the Android emulator console to connect to the built in telnet server and send commands to the emulator. These commands represent hardware events related to power, network, gsm, geo, and sms. In this installment I will describe how to automate this connection by using a C program to send the emulator commands.

After sending commands via telnet it was clear that typing commands is not a good way to do verification and something that must be automated. It's probably the equivalent of typing commands at the Incisive Simulator prompt to set signal values and read signal values.

Unfortunately, telnet is not the easiest thing to automate by scripting because it requires more than just piping input into a terminal or running shell script. I could think of various ways to try to get telnet to start and pipe input to it using the shell or something like expect.

Here is a possible script:

     cmd2="power status"
     telnet localhost 5554  << EOF

I even thought of trying an xterm in slave mode using xterm -S. But what I came to realize is there is no easy way to do this.  Even if such a script did work (which it did not for me), it's not very convenient to create a verification flow that would somehow generate commands and put them into a script in a reactive way. After trying a few different ideas, I gave up on this approach. If anybody out there has any interesting ideas to automate the telnet connection please share them.

In the end I settled on the approach of using a C program to open the socket just as the telnet client would and send the commands over the socket. This provides the needed control and it's easy to take the C program and connect it to the verification environment.

To get started I figured out how to write a C program that will connect to the telnet server and have a C API that is similar to the commands I could type using the manual connection.

Here is the approach:

  • Use socket() and connect() to establish the connection to the emulator console
  • Create a C API for a set of emulator commands
  • Test the sending of commands as well as the reception of the command results using a stand-alone C program
  • Once the program is working remove the main() and turn it into a .so file and use it as a bridge between Specman and the emulator console

The first task was to figure out what kind of socket to use and the appropriate parameters to connect to a telnet server. One good reference I use often is Advanced Programming in the UNIX Environment. There are many other examples you can find by searching.

Once the socket was setup, I figured out how to use send() to send a command and capture the output coming back from the Android console using a recv() call. To make things easier I decided to decouple the send and receive by putting the receive operation in a separate thread.

In the end I ended up with an API that can setup the connection, send the supported emulator commands, and close the connection.

     int ac_init();        /* returns 0 if everything is OK */
     void ac_quit();       /* close the connection */

     /* Do various kinds of commands */
     void do_gsm(gsm_operation_t op, char *ops)
     void do_sms(sms_operation_t op, char *ops)
     void do_network(net_operation_t op, char *ops)
     void do_geo(char *ops)
     void do_power(power_operation_t op, char *ops)

Since this is just for demonstration purposes I skipped the return values on the command API and just used perror(). I also created a log file with a history of the commands that can be turned on in case things go wrong and to learn about the traffic that is going back and forth.

The command API has enumerated types to provide the sub-commands for each operation. For example, the gsm operations can be any of:

     typedef enum
     } gsm_operation_t;

The ops argument provides the specific details in string form, such as the phone number in the case of making a call.

Using this API we can write a simple C program to make a call:

     int main(int argc, char *argv[])
         ac_init("localhost", 5554);
         do_gsm(GSM_CALL, "4088943000\n");

The full source code is available. 

To compile it as a stand-alone program use:

     %  gcc -g -o android_console android_console.c -lpthread -DMAIN

To run 

     % ./android_console

The code is for demonstration only. It assumes the emulator is running on the same machine using the default port. I'm sure there are many improvements that can be made so feel free to send contributions.

Amazingly enough I couldn't find any tips or clues about how other people have developed any kind of automated test environment using the Android emulator. It seems like a common task to be done, but maybe nobody has had time to share it.

Now we are ready to use the C code as a bridge to connect a Specman verification environment so we can start to generate as many interesting sequences as possible using randomization and constraints. This is where we will pick up next time.

Jason Andrews



By Achim Nohl on December 4, 2009
Hi Jason,

First of all I must say that this is a very informative and useful blog! I am also working with Android 2.0 and have developed a SystemC based Virtual Platform to enable Android bring-up and test that I have also presented at ARMTechcon3.

Qemu is a very powerful emulator. I think one reason why people are not using it for either software or hardware testing is because they simply do not know about its capabilities. Thus, your blog is just perfect to change that. Another reason might be that the emulator, as it is, might be used differently in a test environment than a real device. E.g. consider the following use-cases:

(1) You want to test your radio-interface-layer (RIL) daemon software that is interacting with your own modem

(2) You want to system test your modem chip using Android and the RIL as a driver

For 1, as a software (black-box) tester you would interact with the emulator using the abstract GSM commands (e.g. gsm call) provided by adb. But, in case of testing a real device you would send real AT commands (e.g. RING\rOK\r) via a serial interface such as a UART. Thus, there is quite some work in the test-harness to be done to re-use the test-framework with the emulator and the real device.

For 2, you want to have RIL on the emulator communicate with your own modem chip that is on a prototype board connected e.g. via the host UART, or that is running as RTL o a simulator etc. You need to be able to hook that up with the emulator.

There is a solution for 1 and 2 even with the emulator and your proposed TCP socket solution. The emulator can be adapted and compiled. The page source.android.com/download describes all you need to build Android 2.0 and the full SDK on your own. Once you have done that you can go an adapt the emulator. If we stick with the RIL example, the qemu code you want to look at is in “external/qemu/telephony/modem_driver.c”. Here in the function “modem_driver_init” a modem is created. This modem is nothing else as a simple structure defining function pointers for receiving and sending AT commands as simple char strings. Here is the point where you want to add you custom functions that hook up the modem to your real modem. It will work in a very similar way with GPS, sensors etc. You do not even have to have adb working for that and you can debug your design under test synchronously with the test framework. Hopefully this information is useful.

Still there are some drawback with the emulator. When running Android compiled for the emulator, it is using a pseudo-channel to have the hardware adapation layer modules (e.g. modem, gsm, lights) communicate directly with the emulator. Thus, it is not going via a serial device on the linux filesytem (e.g. /dev/tty1). Thus, both Linux/Android for the emulator will be different from your Linux on a real device.  This is not the case if you use a real Virtual Platform that provides interfaces to the software such as UART, GPIOs, SSPs in the same way as real HW does. Also, through virtualized IO capabilities you can easily hook those interfaces up to e.g. an emulator, a host interface or a test framework. On our website (www.coware.com) we provide a free version of a Virtual Platform that illustrate those capabilities.

Furthermore, debugging the Linux kernel and native code in the Hardware Adaptation Layer/Java Native Layer and all its shared objects is not exactly fun on the emulator. Debugging kernel and user-space at the same time is a challenge. Using a Virtual Platform and an OS aware analysis framework you can nicely debug the interaction between all layers of the Android SW stack from Java down to the kernel without any debug daemons etc.

I am looking forward to your next blog.

Best regards,


By Neta Zmora on March 5, 2010
For automating telnet-based testing you can use the open-source 'expect' application.
See for example: www.osix.net/.../article

Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.