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

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

Email

* 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 2

Comments(0)Filed under: System Design and Verification, ISX, android, Java, Monkey

In Part 1 of this series on Android System Verification I provided the basics about how to run the Android emulator. When I initially looked at the emulator I was looking for information about available verification techniques, primarily at the system level. I surmised that many Android projects aggregate the available software, add some new custom software to support a specific hardware platform, enable the wide range of available applications, and put all of this together to create a product. Android provides a very high level of design reuse, which is great, but reuse can also be error prone. In fact, hardware verification engineers commonly tell stories about how they pay very close attention to verification on a new design and take nothing for granted. Then, on "derivative" designs less attention is paid to verification (since not much is changing is should take less time) and sometimes issues escape the verification process. Interestingly, the escapes usually have to do with design blocks that were throughly verified and used on previous projects, but when placed into new circumstances had a problem. ISX users also describe how software changes can cause hardware issues to come out in hardware blocks that were fine on the previous project. My hypothesis is that embedded software is the same. Typically it runs very well in some set of circumstances, but when things change around it may not behave as well.

Here are a few testing techniques available in Android:

  • Java Unit Testing
  • Monkey
  • Emulator Console

I'm going to skip over Java unit testing, since my focus is on system verification, not individual blocks of Java code.

Monkey provides a way to generate pseudo-random streams of user events. It is meant to stress test applications, just as if a monkey was pounding on the keyboard or screen (and hopefully not breaking it). Monkey takes a seed as input to a random generator so that the tests are repeatable. It can be applied to either all of the Android software applications or can be constrained to a list of packages or a category of packages. Monkey is actually a program running inside the device (the trade off between generating stimulus inside a system vs. from the outside is a topic for another time). Because it is run on the target system, it is started using the Android Debug Bridge (adb), a tool providing many useful services for interacting with a target device from the host machine.

Monkey is started using adb shell, for example:

% adb shell monkey –v 500 –s 2

will run monkey on all of the software with verbose mode on, random seed 2, and 500 events generated. Monkey appears to be useful for testing application and cheaper than hiring an actual monkey to do the testing.

The emulator console turned out to be more interesting for me because it allows hardware commands to be sent to the system. As I mentioned in Part 1 I feel like big improvements are possible in the hardware stimulus generation and checking that is currently used in Virtual Platforms like the Android emulator. The emulator console can dynamically query and control the simulated device over a telnet connection.

To connect to the console use:

% telnet localhost 5554

Here is the output of the help command, you can read about all the commands in the documentation

Photobucket

 

Using the emulator console you can issue a variety of hardware commands, here are the main categories of commands:

  • event: simulate a key press
  • power: various things about the battery and AC state (charging/discharging)
  • network: modify network parameters related to the speed and delay of the network
  • gsm: commands to make calls, accept them, put them on hold, hang up, etc.
  • geo: set the GPS coordinate for mapping applications like Google Maps
  • sms: send a message

Use the documentation details to issue these commands from a telnet session and see things happen on the phone, it's pretty cool. My kids were convinced it was a real phone and somebody was trying to call me. The emulator actually rings when a call comes in.

Here are some screen shots I took of the emulator running.

 

Photobucket

Of course, the GPS shows I'm located in Minnesota.

MAP

 

SMS

 

Give it a try, and next time we will get into how to use this telnet connection for automated verification.

Jason Andrews

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 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.