Top Banner
Interview Questions on Mobile Application Testing!!!…well I know very well, many of you must have been in search of this thing since so long.Starting from a beginner in this domain to an expert, everyone is very keen to know what are the different question they may come across in there interview.Here in my post I have shared some interview questions which me or my friends have come across in there interviews for the post of Mobile Software Testers.I hope this will help you:- 1. What is the difference between Mobile Testing and Mobile Application Testing ? 2. What is your approach while Testing Mobile Applications? 3. Have you ever written a Test Plan?What are the things specific to Mobile Application would you emphasis on while writing test plan for Mobile Applications? 4. Do you know Facebook?Tell me what are the High level test cases for Facebook Web Application and for Facebook Mobile Application? 5. Can you please let me know,the devices you have worked upon? 6. Testing of Mobile Application on Emulators.Can you let me know your view? 7. Have you ever worked on any automation tool for Testing Mobile Application? 8. Please tell me about your project.What kind of Mobile Applications have you worked upon? 9. Do you have Idea about Mobile Operating Systems? 10. Blackberry Devices have which Operating system? 11. What is current iOS (iphone OS) version? 12. You have two cases. 1st you can not disconnect your call and 2nd you can not send SMS from your devices.Tell me Severity and Priority in both the cases? 13. What are different Mobile Platforms/OS? 14. What are the different way you can install a Mobile Application? 15. Have you ever worked on Device Anywhere?Do you have experience of working on it? 16. Do you have Idea about application certification program like True Brew Testing(TBT),Symbian Signed Test Criteria,Java Verified Program? 17. See this application(Interviewer is given a Handset with a Mobile Application installed).Tell me what are the bugs in this Mobile application/Game.? 18. Have you ever worked on LBS Application ?
59
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Interview Questions

Interview Questions on Mobile Application Testing!!!…well I know very well, many of you must have been in search of this thing since so long.Starting from a beginner in this domain to an expert, everyone is very keen to know what are the different question they may come across  in there interview.Here in my post I have shared some interview questions which me or my friends have come across in there interviews for the post of Mobile Software Testers.I hope this will help you:-

1. What is the difference between Mobile Testing and Mobile Application Testing ?2. What is your approach while Testing Mobile Applications?3. Have you ever written a Test Plan?What are the things specific to Mobile Application would

you emphasis on while writing test plan for Mobile Applications?4. Do you know Facebook?Tell me what are the High level test cases for Facebook Web

Application and for Facebook Mobile Application?5. Can you please let me know,the devices you have worked upon?6. Testing of Mobile Application on Emulators.Can you let me know your view?7. Have you ever worked on any automation tool for Testing Mobile Application?8. Please tell me about your project.What kind of Mobile Applications have you worked upon?9. Do you have Idea about Mobile Operating Systems?10. Blackberry Devices have which Operating system?11. What is current iOS (iphone OS) version?12. You have two cases. 1st you can not disconnect your call and 2nd you can not send SMS from

your devices.Tell me Severity and Priority in both the cases?13. What are different Mobile Platforms/OS?14. What are the different way you can install a Mobile Application?15. Have you ever worked on Device Anywhere?Do you have experience of working on it?16. Do you have Idea about application certification program like True Brew Testing(TBT),Symbian

Signed Test Criteria,Java Verified Program?17. See this application(Interviewer is given a Handset with a Mobile Application installed).Tell me

what are the bugs in this Mobile application/Game.?18. Have you ever worked on LBS Application ?19. How will you test a Location Based Mobile Application?20. How will you perform Performance Testing for a Mobile Application?

Well there are lot more Mobile Application Testing  Interview Questions to be added.I will incorporate rest of the questions in My Next Post.Till then Have a Nice Time  :)

Adding some more Quetions provided by our Reader Mr.rajendra prasad reddy

Some mobile handset,messaging related, GPS related questions:-

1. Can you name some performance testing tool.2. Can you explain some file format for multimedia testing (audio and video)3. How to write bluetooth the test case for stress, give me 20 example.

Page 2: Interview Questions

4. Explain the WAP protocol stack.5. Explain the type of testing you have done in mobile application testing.6. How basic phone is different from smart phone in testing perspective7. Which android version you tested ?8. Write few scenarios for any feature in a mobile phone other than browser.9. Do you know about android?10. Explain the Architecture of android11. Load Testing on Mobile and Web application.12. Test conditions for touch screen mobiles(landscape and portrait).13. Explain about the mobile application project that you worked in previous company?14. How you did performance testing for mobile application in your previous organization.15. Can you name some performance testing tool. 12 What do you understand by Multimedia testing

in mobile devices.16. What is mobile memory leakage, have you tested that?, which tools have you used.17. On which mobile u have tested the browser?18. Types of devices tested during mobile application testing?19. writing high level scenario’s for any mobile features(I selected Calling)20. Different types of DRM21. What is combined delivery?22. Is it possible to transfer seperate delivery contents to memory card then to other phone?23. can we open seperate delivery files, if we have rights and contents copied from memory card?24. what different types of browser contents tested?25.Any idea of SDK?25. Any idea of VPN?26. Explain the type of testing you have done in mobile application testing.27. How GPRS works?28. How GPS works internally.29. What is GPS how did you tested30. About GPS and A-GPS.31. Write test cases on Camera feature.32. That are the mobile platforms you worked on?33. What is Android and what are the extra features in Android?34. A mobile number contains 10 digits, which kind of method you follow to test a mobile number on

a telephone keypad?35. What is Bluetooth and how you test them?36. what is the extension of android application?37. Explain abt tools used in Mobile Handset Testing.38. How to test SMS, MMS and what is Class1, class2 message.39. Test cases for Alarm , Settings , Media player , Browser , Bluetooth ?40. On which mobile u have tested the browser?41. What all the GSM mobile you have tested?42. Bug Tracking Tool – JIRA43. What are the BT profiles, give some examples.44. What BT profiles supported in Froyo and not supported in Eclairs.

Page 3: Interview Questions

45. What is the MMS size and is it network dependent ?46. Latest version of OMA DRM47. when message with 500 character sent what happens48. Write any five test cases for Messaging Subsystem?49. What kind of mobile application i have tested?50. What do you understand by Multimedia testing in mobile devices.

Testing Checklist for Mobile ApplicationsOctober 23, 2009 — anuragkhode

By-Anurag Khode,Copyright 2009-10

No. Module Sub-Module

Test Case Description Expected Result

1 Installation Verify that application can be Installed Successfully.

Application should be able to install successfully.

2 Uninstallation Verify that application can be uninstalled successfully.

User should be able to uninstall the application successfully.

3 Network Test Cases

Verify the behavior of application when there is Network problem and user is performing operations for data call.

User should get proper error message like “Network error. Please try after some time”

4 Verify that user is able to establish data call when Network is back in action.

User should be able to establish data call when Network is back in action.

5 Voice Call Handling

Call Accept

Verify that user can accept Voice call at the time when application is running and can resume back in application from the same point.

User should be able to accept Voice call at the time when application is running and can resume back in application from the same point.

6 Call Rejection

Verify that user can reject the Voice call at the time when application is running and can resume back in application from the same point.

User should be able to reject the Voice call at the time when application is running and can resume back in application from the same point.

7 Call Establish

Verify that user can establish a Voice call in case when application data call is running in background.

User should be able to establish a Voice call in case when application data call is running in background.

Page 4: Interview Questions

8 SMS Handling Verify that user can get SMS alert when application is running.

User should be able to get SMS alert when application is running.

9 Verify that user can resume back from the same point after reading the SMS.

User should be able to resume back from the same point after reading the SMS.

10 Unmapped keys Verify that unmapped keys are not working on any screen of application.

Unmapped keys should not work on any screen of application.

11 Application Logo Verify that application logo with Application Name is present in application manager and user can select it.

Application logo with Application name should be present in application manager and user can select it.

12 Splash Verify that when user selects application logo in application manager splash is displayed.

When user selects application logo in application manager splash should be displayed.

13 Note that Splash do not remain for fore than 3 seconds.

Splash should not remain for fore than 3 seconds.

14 Low Memory Verify that application displays proper error message when device memory is low and exits gracefully from the situation.

Application should display proper error message when device memory is low and exits gracefully from the situation.

15 Clear Key Verify that clear key should navigate the user to previous screen.

Clear key should navigate the user to previous screen.

16 End Key Verify that End Key should navigate the user to native OEM screen.

End Key should navigate the user to native OEM screen.

17 Visual Feedback Verify that there is visual feedback when response to any action takes more than 3 seconds.

There should be visual feedback given when response time for any action is more than 3 second.

18 Continual Keypad Entry

Verify that continual key pad entry do not cause any problem.

Continual key pad entry should not cause any problem in application.

19 Exit Application Verify that user is able to exit from application with every form of exit modes like Flap,Slider,End Key or

User should be able to exit with every form of exit modes like Flap,Slider,End Key or Exit option in application and from any point.

Page 5: Interview Questions

Exit option in application and from any point.

20 Charger Effect Verify that when application is running then inserting and removing charger do not cause any problem and proper message is displayed when charger is inserted in device.

When application is running then inserting and removing charger should not cause any problem and proper message should be displayed when charger is inserted in device.

21 Low Battery Verify that when application is running and battery is low then proper message is displayed to the user.

When application is running and battery is low then proper message is displayed to the user telling user that battery is low.

22 Removal of Battery

Verify that removal of battery at the time of application data call is going on do not cause interruption and data call is completed after battery is inserted back in the device.

Removal of battery at the time of application data call is going on should not cause interruption and data call should be completed after battery is inserted back in the device.

23 Battery Consumption

Verify that application does not consume battery excessively.

The application should not consume battery excessively.

24 Application Start/ Restart

1. Find the application icon and select it 2. “Press a button” on the device to launch the app. 3.Observe the application launch In the timeline defined

Application must not take more than 25s to start.

25 Application Side Effects

Make sure that your application is not causing other applications of device to hamper.

Installed application should not cause other applications of device to hamper.

Page 6: Interview Questions

26 External incoming communication – infrared

Application should gracefully handle the condition when incoming communication is made via Infra Red [Send a file using Infrared (if applicable) to the device application presents the user]

When the incoming communication enters the device the application must at least respect one of the following: a) Go into pause state, after the user exits the communication, the application presents the user with a continue option or is continued automatically from the point it was suspended at b) Give a visual or audible notification The application must not crash or hung.

These are 10 general principles for user interface design which we should keep it in mind while testing usability. Given below are the points:

Visibility of system status

Match between system and the real world

User control and freedom

Consistency and standards

Error prevention

Recognition rather than recall

Flexibility and efficiency of use

Aesthetic and minimalist design

Help users recognize, diagnose, and recover from errors

Help and documentation

I have listed down few scenarios which will throw some light on usability testing.

Touch

Sidebars are not easy to use on touchscreens.

Fingerprints are more visible on darker backgrounds.

There must be a way to go back or undo an action, as touching the wrong item is done quickly.

The full screen should be used.

Common operations directly visible on screen.

Minimize keyboard input.

Icons & Buttons

Buttons should have the right size and be suitable to big fingers.

Buttons in the same place of the screen to avoid confusion.

Natural and consistent icons.

Buttons that have the same function should have the same color.

Menu

Page 7: Interview Questions

Contextual menus are used very often, it should not be overloaded because it has to be used quickly.

Text

Keep text simple and clear.

Short sentences and paragraphs are better readable.

The usage of headers will make a text better readable.

Bullets for lists will make a tekst better readable.

Typing text in a textbox should start with an uppercase letter.

The font size should be big enought, not too big and not too small.

Messages

Confirmation messages should be avoided, a click performs the action directly.

When the app starts downloading a lot of data, the user should be warned.

A Complete Guide to Install and Use ADB on Windows?

Android Debug Bridge, often abbreviated as ADB, is a command line utility

for communicating with any connected Android Device or any instance of

Android Virtual Device. It is a tool that is specially used by developers who need to communicate

with their device the most from computers for various purposes including that of testing a

developed app, viewing log cat, accessing system files of an android devices, etc. 

ADB is very useful tool for both developers and other android users as well. Developers can

access ADB from the platform-tools folder within their Android SDK installation directory while

other can download ADB from here. Since, it is a command line tool user must know how to use

the command prompt. There are two ways to get started with using ADB. One is to navigate to

the folder which contains adb.exe and then issue/run commands and other set the path to the

folder that contains ADB in Environment Variables and then run ADB from any directory in the

command prompt. You can set the PATH by following these simple steps:

1. Extract ADB to a location and get the path of the directory that contains adb.exe . If you

extracted to ADB folder in D: drive then your path will be D:\ADB.

2. Right Click on Computer icon on desktop and then select Properties.

3. On the right sidebar in properties window click Advance System Settings.

4. Navigate to Advance tab and then click Environment Variables at the bottom of the System

Properties window.

Page 8: Interview Questions

5. Select any User Variable and then look for Path variable in the System variable (just below

user variable). See figure below for reference.

6. After selecting Path variable, click on Edit button and then in the Edit System

Variable window leave Variable name as Path and then in Variable values go to the end of the

text and then put a semicolon (;) and then type or paste your path from above. In our case

add ;D:\ADB at the end of theVariable values field. Make sure you don’t remove the paths that

are already there. If you remove them your system might become unstable. In simple terms, just

append your ADB path in the Variable value field.

7. Press Ok and then close any remaining windows.

Now, you are ready to use ADB from any directory in the command prompt. Just open the

command and then type adb help to list useful adb commands and help file. Now, you

can install applications or games, view log cat, even use adb shell command to issue command to

any of your connected android devices. ADB Shell lets you run Linux commands just like you do

with terminal emulator or shell commander. The only difference is you will get large screen to

view and large keyboard to type commands. The most important thing to remember is to enable

USB Debugging on your device or else ADB won’t work. To enable USB Debugging go

toSettings>Applications>>Development and then check USB Debugging option.

Here are some frequently asked questions and their answers.

Q. How do I install applications using ADB?

A. Either run adb install command. To do so copy the app to the directory that contains adb.exe

otherwise use full path to your application instead of app name.

Also, if you downloaded the zip from above you will find a Drag and Drop Files Here.bat file. As

it name says you can simply drag and drop any app you want to install to this file and it

will install it automatically in any connected device. Note that some zip files that have Android

Manifest.xml file can be installed using ADB like apk files. You can use any archive explorer

like WinRar to make sure if your zip has Android Manifest file or not.

Q. How to view log cat with adb?

A. To view log cat simply run the command adb logcat. Or, if you are comfortable with terminal

emulator you can type adb shell to get to the terminal and then type logcat and press enter to

view the log cat. Notice that second method is similar to using terminal emulator. You can run

many other commands that can be run on android/Linux in this shell.

Page 9: Interview Questions

Q. How do I copy files/directory to my phone or android emulator?

A. To copy files to your phone use adb push command. If you want to copy cm7.zip to root of

your sdcard then run adb push cm7.zip /sdcard/cm7.zip command. Make sure you have the file

in same folder as adb.exe is otherwise you will need to provide full path to your file.

Q. How do I copy files/directory from my phone or emulator?

A. To copy files from your device run adb pull command. If you want to copy camera.apk app to

your pc then run adb pull /system/app/Camera.apk /Camera.apk. You might need to remount

system as read write before you can copy file to/from system folder. To remount your system

files as read write run adb remount command.

These are some basic questions mostly asked about ADB. You can find more information on

using ADB at Android Developer’s Website. If you need any help or have problem using ADB

please feel free to ask in comments below.

Mobile Application Testing- A Quality Approach

The ever increasing demand of mobile devices has given a push to software developers in taking the traditional web applications to mobile environment. The challenge is to provide user experience as similar and seamless across various mobile devices as possible in spite of the limitations which the mobile environment poses, adopting an agile methodology to develop the mobile applications for a diversified device environment, hardware and networking considerations.

Mobile device markets that includes Smartphones, Tablets, PDAs etc. is growing dynamically making the mobile application developers strive to deliver most robust, scalable applications with quality assurance Every device platform creates a unique testing environment challenging the mobile application developers to follow different testing strategies. Here we shall see how different types of testing approaches can be taken up for a variety of mobile platforms.

Numerous different mobile platforms available for mobile applications to name a few:

Apple’s iOS

Google’s Android

Nokia’s Symbian, Maemo and MeeGo

Palm/HP’s WebOS

Samsung’s Bada

RIM’s BlackBerry OS., and many more.

Page 10: Interview Questions

As mentioned, every platform needs a different testing approach. A combination of manual and automation testing can be done for an effective outcome.Following are different types of manual testing for mobile environment:

Functionality Testing:Functional testing mainly includes finding device specific bugs and navigational issues of application. This type of testing should be done at the initial stage when the application is under development. In functional testing we can check database or network queries with response times, crashes and memory issues. Functionality testing of a mobile application is a black-box type of testing to assure that the application is functioning as per the business specifications.

Usability Testing:Usability testing encompasses mobile interface testing, application navigation testing, and intuitiveness of the application, consistency, and soberness of color scheme. An ISO standard defines usability as “the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use”.In Usability testing ease and efficiency of the user and content verification will be tested as defined in common Usability guidelines.

Network Connection Testing:Every mobile application which utilizes internet needs to be tested under different networks. These are a few networks for testing applications:

2G (GPRS, CDMA, EDGE), 3G and WiFi.

This is a necessity because most of the times the server responses are different for different type of networks. This testing helps us check application behavior under different networks.

Installation Testing:While installing, the application should install required softwares automatically on the device. And while uninstalling the application, it should remove all the available content and databases from the device which are used by application.

Performance Testing:Performance testing is required for finding memory related issues in application when data is excessive, due to devices having less memory as compared to simulator, this testing is required to be done on device only. By this testing approach, we can find the stability and performance of application under excessive data.

Stress Testing:This testing is required for getting the application response time while clicking on different buttons regressively and adding more data on device. We can get different crashes and hangings of application while running the application for long time.

In absence of mobile devices, simulators have always played a vital role for testing mobile device applications, although device testing is always the ideal way as it represents more likely end user scenarios, the significance of simulators in testing cannot be ignored. To have an effective testing with the help of a simulator, it’s necessary to explore all the capabilities of simulator.

Simulator versus device testing:Simulators are mainly used for functional testing of basic flows. Simulators are not used for performance and usability testing, but the final testing is conducted on actual devices so crashes and hangings can be identified. One cannot get quality application while relying only on simulator. Device

Page 11: Interview Questions

testing is necessary for all the applications, as with device testing we can understand the application behavior on different networks.

Simulator:Is a software application that can accurately imitate a mobile phone. Simulator is mainly used by developers to check the functionalities implemented under development phase.

Let’s discuss the pros and cons of using simulators:

Pros :

- Helps in isolating issues which are not volatile network connection dependent- Provides a wide variety of testing over different types of device simulators for the same build- Allows to test the same build in multiple device screens. Cons :

- Simulators of older generation handsets don’t resemble the device as closely- Some issues which are hit by the speed at which input was given cannot be reproduced easily- Hardware/Firmware environment variations detectable in device testing only- Device testing is always preferred as it represents more likely end user scenarios.

Device: Is the actual handset where application installed and runs.There are some pros and cons while using real devices for testing as well.

Pros:

- Finds actual issues of application.- Finds crashes, memory leak issues which can not found on simulators.- Checks application over 2G and 3G and different networks- Checks application behavior while incoming call, SMS, MMS and alarm.Cons:

- Expensive for compatibility testing of application over wide range of devices- Consumes more time for adding excessive test data for testing purpose.

Checklist to follow while testing a mobile application:Following is a basic checklist which is required while testing mobile application for any platform:

1. Installation & Uninstallation: To verify whether the application can be installed & uninstalled successfully.2. Network Connectivity:

The application can use simultaneous connections properly

The application follows the GSM Offline profile correctly when making connections.

When GSM Offline profile is selected, application cannot take network connection or send an SMS/MMS

The application can utilize WLAN, 2G and 3G networks correctly.

Performance of application during network connectivity problem.

Page 12: Interview Questions

3. Call/SMS/alarm handling: Verify that Application pauses and resumes for the same state when there is an incoming phone call/SMS/MMS/Alarm notification.

4. Check the look & feel of the application

5. Content: Check if enough information is displayed

6. The application must function as defined in the Help, user’s guide, or functional specification

7. Performance : Application and inner pages load time.

Automation Testing:

Automation testing is usually extended to perform tasks impossible with manual testing in large applications. An automated software testing tool is capable of playing pre-recorded and predefined actions. The results are mapped to the expected behavior and report the success or failure of these manual tests. Once automated tests are created they can easily be repeated. Having experienced the efficiency of automated software testing, it has become an important part of an application testing.Automation tools available for testing:Mainly mobile testing is done manually on actual devices. Some of the following tools are available in to test the functionality as well as usability of application.

1. Robotium for Android

2. Testquest, try, and digia for Symbian

3. FoneMonkey for IPhones

4. Memory sweep for IPhone

5. Other tools: eggplant, VNC Robot, Hopper and TestQuest.

Advantages and Limitations of Automation Tools:

Advantages:- Multiple tests can run in less time with fewer resources- Automated Tools run tests faster than human users- Can reuse tests on different versions of an application.Limitations:- Unable to test all the functionalities and Usability of application through automation tools- Proficiency is required to write the automation test scripts for application different functionalities- Debugging the test script if any error is present in the automation test script- Storing and maintenance of test data is difficult.

AndroidAndroid is a mobile operating system initially developed by Android Inc. Android was bought by Google in 2005. Android is based upon a modified version of the Linux kernel. The Android operating system software stack consists of Java applications running on a Java-based, object-oriented application framework on top of Java core libraries running on a Dalvik virtual machine featuring JIT compilation.

Page 13: Interview Questions

Libraries written in C include the surface manager, OpenCore media framework, SQLite relational database management system, OpenGL ES 2.0 3D graphics API, WebKit layout engine, SGL graphics engine, SSL, and Bionic libc.

Features

Application framework enabling reuse and replacement of components Dalvik virtual machine optimized for mobile devices Integrated browser based on the open source WebKit engine Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the OpenGL

ES 1.0 specification (hardware acceleration optional) SQLite for structured data storage Media support for common audio, video, and still image formats (MPEG4, H.264, MP3, AAC,

AMR, JPG, PNG, GIF) GSM Telephony (hardware dependent) Bluetooth, EDGE, 3G, and WiFi (hardware dependent) Camera, GPS, compass, and accelerometer (hardware dependent) Rich development environment including a device emulator, tools for debugging, memory and

performance profiling, and a plugin for the Eclipse IDE

Android Architecture

The following diagram shows the major components of the Android operating system. Each section is described in more detail below.

Page 14: Interview Questions

Applications

Android will ship with a set of core applications including an email client, SMS program, calendar, maps, browser, contacts, and others. All applications are written using the Java programming language.Application Framework

By providing an open development platform, Android offers developers the ability to build extremely rich and innovative applications. Developers are free to take advantage of the device hardware, access location information, run background services, set alarms, add notifications to the status bar, and much, much more. Developers have full access to the same framework APIs used by the core applications. The application architecture is designed to simplify the reuse of components; any application can publish its capabilities and any other application may then make use of those capabilities (subject to security constraints enforced by the framework). This same mechanism allows components to be replaced by the user.Underlying all applications is a set of services and systems, including:

A rich and extensible set of Views that can be used to build an application, including lists, grids, text boxes, buttons, and even an embeddable web browser

Content Providers that enable applications to access data from other applications (such as Contacts), or to share their own data

A Resource Manager, providing access to non-code resources such as localized strings, graphics, and layout files

A Notification Manager that enables all applications to display custom alerts in the status bar An Activity Manager that manages the lifecycle of applications and provides a common

navigation backstack

Page 15: Interview Questions

For more details and a walkthrough of an application, see the Notepad Tutorial.Libraries

Android includes a set of C/C++ libraries used by various components of the Android system. These capabilities are exposed to developers through the Android application framework. Some of the core libraries are listed below:

System C library - a BSD-derived implementation of the standard C system library (libc), tuned for embedded Linux-based devices

Media Libraries - based on PacketVideo's OpenCORE; the libraries support playback and recording of many popular audio and video formats, as well as static image files, including MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG

Surface Manager - manages access to the display subsystem and seamlessly composites 2D and 3D graphic layers from multiple applications

LibWebCore - a modern web browser engine which powers both the Android browser and an embeddable web view

SGL - the underlying 2D graphics engine 3D libraries - an implementation based on OpenGL ES 1.0 APIs; the libraries use either

hardware 3D acceleration (where available) or the included, highly optimized 3D software rasterizer

FreeType - bitmap and vector font rendering SQLite - a powerful and lightweight relational database engine available to all applications

Android Runtime

Android includes a set of core libraries that provides most of the functionality available in the core libraries of the Java programming language.Every Android application runs in its own process, with its own instance of the Dalvik virtual machine. Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The VM is register-based, and runs classes compiled by a Java language compiler that have been transformed into the .dex format by the included "dx" tool.The Dalvik VM relies on the Linux kernel for underlying functionality such as threading and low-level memory management.Linux Kernel

Android relies on Linux version 2.6 for core system services such as security, memory management, process management, network stack, and driver model. The kernel also acts as an abstraction layer between the hardware and the rest of the software stack.

Update history

Android has seen a number of updates since its original release. These updates to the base operating system typically fix bugs and add new features. Generally each update to the Android operating system is developed under a code name based on a dessert item. The code names are in alphabetical order.

1.0 Released 23 September 2008

1.1

On 9 February 2009, Android 1.1 update for Android was released for T-Mobile G1 Only. Included in the update were: Multiple resolved issues

Page 16: Interview Questions

API changes Maps adds details and reviews Screen timeout longer when using

speakerphone "Show" & "Hide" Dialpad included in-call

menu Support for saving attachments from MMS Support for marquee in layouts

1.5 (Cupcake)Based on Linux Kernel 2.6.27

On 30 April 2009, the official 1.5 (Cupcake) update for Android was released.[39][40] There were several new features and UI updates included in the 1.5 update:[41]

Ability to record and watch videos through camcorder mode

Uploading videos to YouTube and pictures to Picasa directly from the phone

A new soft-keyboard with text-prediction Bluetooth A2DP and AVRCP support Ability to automatically connect to a

Bluetooth headset within a certain distance New widgets and folders that can populate

the Home screens Animated screen transitions

1.6 (Donut)Based on Linux Kernel 2.6.29

On 15 September 2009, the 1.6 (Donut) SDK was released.[43][44] Included in the update were:[42]

An improved Android Market experience An integrated camera, camcorder, and

gallery interface Gallery now enables users to select multiple

photos for deletion Updated Voice Search, with faster response

and deeper integration with native applications, including the ability to dial contacts

Updated search experience to allow searching bookmarks, history, contacts, and the web from the home screen

Updated technology support for CDMA/EVDO, 802.1x, VPNs, and a text-to-speech engine

Support for WVGA screen resolutions Speed improvements in searching and

camera applications Gesture framework and GestureBuilder

Page 17: Interview Questions

development tool Google free turn-by-turn navigation

2.0 / 2.1 (Eclair)Based on Linux Kernel 2.6.29

On 26 October 2009, the 2.0 (Eclair) SDK was released.[46] Changes include:[47]

Optimized hardware speed Support for more screen sizes and

resolutions Revamped UI New Browser UI and HTML5 support New contact lists Better contrast ratio for backgrounds Improved Google Maps 3.1.2 Microsoft Exchange Server by Exchange

ActiveSync 2.5 support Built in flash support for Camera Digital Zoom MotionEvent class enhanced to track multi-

touch events[48]

Improved virtual keyboard Bluetooth 2.1 Live Wallpapers

The 2.0.1 SDK was released on 3 December 2009.[49]

The 2.1 SDK was released on 12 January 2010.[50

2.2 (Froyo) Based on Linux Kernel 2.6.3 On 20 May 2010, the 2.2 (Froyo) SDK was released.[51] Changes included:[52]

General Android OS speed, memory, and performance optimizations[53]

Additional application speed improvements courtesy of JIT implementation[54]

Integration of Chrome's V8 JavaScript engine into the Browser application

Increased Microsoft Exchange support (security policies, auto-discovery, GAL look-up, calendar synchronization, remote wipe)

Improved application launcher with shortcuts to Phone and Browser applications

USB tethering and Wi-Fi hotspot functionality

Added an option to disable data access over mobile network

Updated Market application with batch and

Page 18: Interview Questions

automatic update features[53]

Quick switching between multiple keyboard languages and their dictionaries

Voice dialing and contact sharing over Bluetooth

Support for numeric and alphanumeric passwords

Support for file upload fields in the Browser application[55]

Support for installing applications to the expandable memory

Adobe Flash 10.1 support[56]

Support for extra high DPI screens (320 dpi), such as 4" 720p[5

2.3 (Gingerbread) Based on Linux Kernel 2.6.35

On 6 December 2010, the 2.3 (Gingerbread) SDK was released.[58] Changes included:[59]

Updated user interface design Support for extra-large screen sizes and

resolutions (WXGA and higher)[57]

Native support for SIP VoIP telephony Support for WebM/VP8 video playback, and

AAC audio encoding New audio effects such as reverb,

equalization, headphone virtualization, and bass boost

Support for Near Field Communication System-wide copy–paste functionalities Redesigned multi-touch software keyboard Enhanced support for native code

development Audio, graphical, and input enhancements

for game developers Concurrent garbage collection for increased

performance Native support for more sensors (such as

gyroscopes and barometers) A download manager for long running

downloads Improved power management and

application control Native support for multiple cameras Switched from YAFFS to the ext4

filesystem[60]

3.0 (Honeycomb)[ Changes will include:[61]

Page 19: Interview Questions

Optimized tablet support with a new user interface

Three dimensional desktop with redesigned widgets

Refined multi-tasking Browser enhancements including tabbed

web pages, form auto-fill, bookmark syncing with Google Chrome, and private browsing

Support for video chat using Google Talk

Ice Cream Sandwich Possible mid-2011 release

Handset layouts The platform is adaptable to larger, VGA, 2D graphics library, 3D graphics library based on OpenGL ES 2.0 specifications, and traditional smartphone layouts.

Storage SQLite, a lightweight relational database, is used for data storage purposesConnectivity Android supports connectivity technologies including GSM/EDGE, IDEN,

CDMA, EV-DO, UMTS, Bluetooth, Wi-Fi, LTE, and WiMAXMessaging SMS and MMS are available forms of messaging, including threaded text

messaging and now Android Cloud to Device Messaging Framework (C2DM) is also a part of Android Push Messaging service.

Web browser The web browser available in Android is based on the open-source WebKit layout engine, coupled with Chrome's V8 JavaScript engine. The browser scores a 93/100 on the Acid3 Test

Java support While Android applications are written in Java, there's no Java Virtual Machine in the platform and Java byte code is not executed. Java classes get recompiled into Dalvik executable and run on Dalvik virtual machine. Dalvik is a specialized virtual machine designed specifically for Android and optimized for battery-powered mobile devices with limited memory and CPU. J2ME support can be provided via third-party-application such as the J2ME MIDP Runner.[66]

Media support Android supports the following audio/video/still media formats: WebM, H.263, H.264 (in 3GP or MP4 container), MPEG-4 SP, AMR, AMR-WB (in 3GP container), AAC, HE-AAC (in MP4 or 3GP container), MP3, MIDI, Ogg Vorbis, WAV, JPEG, PNG, GIF, BMP.[65]

Streaming media support

RTP/RTSP streaming (3GPP PSS, ISMA), HTML progressive download (HTML5 <video> tag). Adobe Flash Streaming (RTMP) is supported through Adobe Flash Player plugin. Apple HTTP Live Streaming is planned to be supported through stagefright media player. Microsoft Smooth Streaming is planned to be supported through the awaited port of Silverlight plugin to Android. Adobe Flash HTTP Dynamic Streaming is planned to be supported through an upgrade of the Flash plugin.

Additional hardware support

Android can use video/still cameras, touchscreens, GPS, accelerometers, gyroscopes, magnetometers, proximity and pressure sensors, thermometers,

Page 20: Interview Questions

accelerated 2D bit blits (with hardware orientation, scaling, pixel format conversion) and accelerated 3D graphics.

Development environment

Includes a device emulator, tools for debugging, memory and performance profiling. The integrated development environment (IDE) is Eclipse (currently 3.4 or 3.5) using the Android Development Tools (ADT) Plugin.

Market The Android Market is a catalog of applications that can be downloaded and installed to Android devices over-the-air, without the use of a PC.

Multi-touch Android has native support for multi-touch which was initially made available in handsets such as the HTC Hero. The feature was originally disabled at the kernel level (possibly to avoid infringing Apple's patents on touch-screen technology).[67] Google has since released an update for the Nexus One and the Motorola Droid which enables multi-touch natively.[68]

Bluetooth Support for A2DP and AVRCP were added in version 1.5;[41] sending files (OPP) and accessing the phone book (PBAP) were added in version 2.0;[47] and voice dialing and sending contacts between phones were added in version 2.2.[52]

Videocalling he mainstream Android version doesn't support videocalling,[69] however some handsets could have a customized version of the operating system which supports it, either via UMTS network (like the Samsung i9000 Galaxy S) or over IP.

Multitasking Multitasking of applications is available.[70]

Voice based features

Google search through Voice is available as Search Input since initial release.[71] Also launched Voice actions supported on Android 2.2 onwards.

Tethering Android supports tethering, which allows a phone to be used as a wireless/wired hotspot (All 2.2 Froyo phones, unofficial on phones running 1.6 or higher via applications available in the Android Market, e.g. PdaNet). To allow a laptop to share the 3G connection on an Android phone software may need to be installed on both the phone and the laptop[72]

Hardware running Android

The Android OS can be used as an operating system for cellphones, netbooks and tablets, including the Dell Streak, Samsung Galaxy Tab and other devices.[73][74]

The world's first TV running Android, called Scandinavia, has also been launched by the company People of Lava.[75]

The first commercially available phone to run the Android operating system was the HTC Dream, released on 22 October 2008

Google's flagship smartphones

A list of Android phones that are marketed by Google and contain the "Pure Google" Android experience.

Nexus One manufactured by HTC Nexus S manufactured by Samsung

Page 21: Interview Questions

Testing Fundamentals

The Android testing framework, an integral part of the development environment, provides an architecture and powerful tools that help you test every aspect of your application at every level from unit to framework.

The testing framework has these key features:

Android test suites are based on JUnit. You can use plain JUnit to test a class that doesn't call the Android API, or Android's JUnit extensions to test Android components. If you're new to Android testing, you can start with general-purpose test case classes such as AndroidTestCase and then go on to use more sophisticated classes.

The Android JUnit extensions provide component-specific test case classes. These classes provide helper methods for creating mock objects and methods that help you control the lifecycle of a component.

Test suites are contained in test packages that are similar to main application packages, so you don't need to learn a new set of tools or techniques for designing and building tests.

The SDK tools for building and tests are available in Eclipse with ADT, and also in command-line form for use with other IDES. These tools get information from the project of the application under test and use this information to automatically create the build files, manifest file, and directory structure for the test package.

The SDK also provides monkeyrunner, an API testing devices with Python programs, and UI/Application Exerciser Monkey, a command-line tool for stress-testing UIs by sending pseudo-random events to a device.

This document describes the fundamentals of the Android testing framework, including the structure of tests, the APIs that you use to develop tests, and the tools that you use to run tests and view results. The document assumes you have a basic knowledge of Android application programming and JUnit testing methodology.

The following diagram summarizes the testing framework:

Page 22: Interview Questions

Test Structure

Android's build and test tools assume that test projects are organized into a standard structure of tests, test case classes, test packages, and test projects.

Android testing is based on JUnit. In general, a JUnit test is a method whose statements test a part of the application under test. You organize test methods into classes called test cases (or test suites). Each test is an isolated test of an individual module in the application under test. Each class is a container for related test methods, although it often provides helper methods as well.

In JUnit, you build one or more test source files into a class file. Similarly, in Android you use the SDK's build tools to build one or more test source files into class files in an Android test package. In JUnit, you use a test runner to execute test classes. In Android, you use test tools to load the test package and the application under test, and the tools then execute an Android-specific test runner

Test case classes

Android provides several test case classes that extend TestCase and Assert with Android-specific setup, teardown, and helper methods.

AndroidTestCase

A useful general test case class, especially if you are just starting out with Android testing, is AndroidTestCase. It extends both TestCase and Assert. It provides the JUnit-standard setUp() and tearDown() methods, as well as well as all of JUnit's Assert methods. In addition, it provides methods for testing permissions, and a method that guards against memory leaks by clearing out certain class references.

Page 23: Interview Questions

Component-specific test cases

A key feature of the Android testing framework is its component-specific test case classes. These address specific component testing needs with methods for fixture setup and teardown and component lifecycle control. They also provide methods for setting up mock objects. These classes are described in the component-specific testing topics:

Activity Testing Content Provider Testing Service Testing

Android does not provide a separate test case class for BroadcastReceiver. Instead, test a BroadcastReceiver by testing the component that sends it Intent objects, to verify that the BroadcastReceiver responds correctly.

ApplicationTestCase

You use the ApplicationTestCase test case class to test the setup and teardown of Application objects. These objects maintain the global state of information that applies to all the components in an application package. The test case can be useful in verifying that the <application> element in the manifest file is correctly set up. Note, however, that this test case does not allow you to control testing of the components within your application package.

InstrumentationTestCase

If you want to use instrumentation methods in a test case class, you must use InstrumentationTestCase or one of its subclasses. The Activity test cases extend this base class with other functionality that assists in Activity testing

Contexts for testing

Android provides two Context classes that are useful for testing:

IsolatedContext provides an isolated Context, File, directory, and database operations that use this Context take place in a test area. Though its functionality is limited, this Context has enough stub code to respond to system calls.

This class allows you to test an application's data operations without affecting real data that may be present on the device.

RenamingDelegatingContext provides a Context in which most functions are handled by an existing Context, but file and database operations are handled by a IsolatedContext. The isolated part uses a test directory and creates special file and directory names. You can control the naming yourself, or let the constructor determine it automatically.

This object provides a quick way to set up an isolated area for data operations, while keeping normal functionality for all other Context operations.

Page 24: Interview Questions

Running Tests

Test cases are run by a test runner class that loads the test case class, set ups, runs, and tears down each test. An Android test runner must also be instrumented, so that the system utility for starting applications can control how the test package loads test cases and the application under test. You tell the Android platform which instrumented test runner to use by setting a value in the test package's manifest file.

InstrumentationTestRunner is the primary Android test runner class. It extends the JUnit test runner framework and is also instrumented. It can run any of the test case classes provided by Android and supports all possible types of testing.

You specify InstrumentationTestRunner or a subclass in your test package's manifest file, in the instrumentation element. Also, InstrumentationTestRunner code resides in the shared library android.test.runner, which is not normally linked to Android code. To include it, you must specify it in a uses-library element. You do not have to set up these elements yourself. Both Eclipse with ADT and the android command-line tool construct them automatically and add them to your test package's manifest file.

Note: If you use a test runner other than InstrumentationTestRunner, you must change the <instrumentation> element to point to the class you want to use.

To run InstrumentationTestRunner, you use internal system classes called by Android tools. When you run a test in Eclipse with ADT, the classes are called automatically. When you run a test from the command line, you run these classes with Android Debug Bridge (adb).

The system classes load and start the test package, kill any processes that are running an instance of the application under test, and then load a new instance of the application under test. They then pass control to InstrumentationTestRunner, which runs each test case class in the test package. You can also control which test cases and methods are run using settings in Eclipse with ADT, or using flags with the command-line tools.

Neither the system classes nor InstrumentationTestRunner run the application under test. Instead, the test case does this directly. It either calls methods in the application under test, or it calls its own methods that trigger lifecycle events in the application under test. The application is under the complete control of the test case, which allows it to set up the test environment (the test fixture) before running a test. This is demonstrated in the previous code snippet that tests an Activity that displays a Spinner widget.

To learn more about running tests, please read the topics Testing in Eclipse, with ADT or Testing in Other IDes.

Seeing Test Results

The Android testing framework returns test results back to the tool that started the test. If you run a test in Eclipse with ADT, the results are displayed in a new JUnit view pane. If you run a test from the command line, the results are displayed in STDOUT. In both cases, you see a test summary that displays the name of each test case and method that was run. You also see all the assertion failures that occurred. These include pointers to the line in the test code where the failure occurred. Assertion failures also list the expected value and actual value.

Page 25: Interview Questions

The test results have a format that is specific to the IDE that you are using. The test results format for Eclipse with ADT is described in Testing in Eclipse, with ADT. The test results format for tests run from the command line is described in Testing in Other IDEs.

monkey and monkeyrunner

The SDK provides two tools for functional-level application testing:

The UI/Application Exerciser Monkey, usually called "monkey", is a command-line tool that sends pseudo-random streams of keystrokes, touches, and gestures to a device. You run it with the Android Debug Bridge (adb) tool. You use it to stress-test your application and report back errors that are encountered. You can repeat a stream of events by running the tool each time with the same random number seed.

The monkeyrunner tool is an API and execution environment for test programs written in Python. The API includes functions for connecting to a device, installing and uninstalling packages, taking screenshots, comparing two images, and running a test package against an application. Using the API, you can write a wide range of large, powerful, and complex tests. You run programs that use the API with the monkeyrunner command-line tool.

Debugging TasksThis document offers some helpful guidance to debugging applications on Android.

Tools

The Android SDK includes a set of tools to help you debug and profile your applications. Here are some tools that you'll use most often:

Android Debug Bridge (ADB)

Provides various device management capabilities, including moving and syncing files to the emulator, forwarding ports, and running a UNIX shell on the emulator.

Dalvik Debug Monitor Server (DDMS)

A graphical program that supports port forwarding (so you can set up breakpoints in your code in your IDE), screen captures on the emulator, thread and stack information, and many other features. You can also run logcat to retrieve your Log messages.

Traceview

A graphical viewer that displays trace file data for method calls and times saved by your application, which can help you profile the performance of your application.

logcat

Page 26: Interview Questions

Dumps a log of system messages. The messages include a stack trace when the device throws an error, as well as Log messages you've written from your application. To run logcat, execute adb logcat from your Android SDK platform-tools/ directory or, from DDMS, select Device > Run logcat. When using the ADT plugin for Eclipse, you can also view logcat messages by opening the Logcat view, available from Window > Show View > Other > Android > Logcat.

Log is a logging class you can use to print out messages to the logcat. You can read messages in real time if you run logcat on DDMS (covered next). Common logging methods include: v(String, String) (verbose), d(String, String) (debug), i(String, String) (information), w(String, String) (warning) and e(String, String) (error). For example:

Log.i("MyActivity", "MyClass.getView() — get item number " + position);

The logcat will then output something like:

I/MyActivity( 1557): MyClass.getView() — get item number 1

Logcat is also the place to look when debugging a web page in the Android Browser app. See Debugging Web Pages below.

For more information about all the development tools provided with the Android SDK, see the Tools document.

In addition to the above tools, you may also find the following useful for debugging:

Eclipse ADT plugin

The ADT Plugin for Eclipse integrates a number of the Android development tools (ADB, DDMS, logcat output, and other functionality), so that you won't work with them directly but will utilize them through the Eclipse IDE.

Developer Settings in the Dev Tools app

The Dev Tools application included in the emulator system image exposes several settings that provide useful information such as CPU usage and frame rate. See Debugging and Testing with Dev Tools below.

Debugging and Testing with Dev Tools

With the Dev Tools application, you can enable a number of settings on your device that will make it easier to test and debug your applications.

The Dev Tools application is installed by default on all system images included with the SDK, so you can use it with the Android Emulator. If you'd like to install the Dev Tools application on a real development device, you can copy the application from your emulator and then install it on your device using ADB. To copy the application from a running emulator, execute:

adb -e pull /system/app/Development.apk ./Development.apk

Page 27: Interview Questions

This copies the .apk file into the current directory. Then install it on your connected device with:

adb -d install Development.apk

To get started, launch the Dev Tools application and select Development Settings. This will open the Development Settings page with the following options (among others):

Debug app

Lets you select the application to debug. You do not need to set this to attach a debugger, but setting this value has two effects:

It will prevent Android from throwing an error if you pause on a breakpoint for a long time while debugging.

It will enable you to select the Wait for Debugger option to pause application startup until your debugger attaches (described next).

Wait for debuggerBlocks the selected application from loading until a debugger attaches. This way you can set a breakpoint in onCreate(), which is important to debug the startup process of an Activity. When you change this option, any currently running instances of the selected application will be killed. In order to check this box, you must have selected a debug application as described in the previous option. You can do the same thing by adding waitForDebugger() to your code.

Show screen updates

Flashes a momentary pink rectangle on any screen sections that are being redrawn. This is very useful for discovering unnecessary screen drawing.

Immediately destroy activities

Tells the system to destroy an activity as soon as it is stopped (as if Android had to reclaim memory).  This is very useful for testing the onSaveInstanceState(Bundle) / onCreate(android.os.Bundle) code path, which would otherwise be difficult to force. Choosing this option will probably reveal a number of problems in your application due to not saving state.

Show CPU usage

Displays CPU meters at the top of the screen, showing how much the CPU is being used. The top red bar shows overall CPU usage, and the green bar underneath it shows the CPU time spent in compositing the screen. Note: You cannot turn this feature off once it is on, without restarting the emulator.

Show background

Displays a background pattern when no activity screens are visible. This typically does not happen, but can happen during debugging.

Page 28: Interview Questions

These settings will be remembered across emulator restarts.

Debugging Web Pages

See the Debugging Web Apps document.

Top Debugging Tips

Dump the stack trace

To obtain a stack dump from emulator, you can log in with adb shell, use "ps" to find the process you want, and then "kill -3 ". The stack trace appears in the log file.

Display useful info on the emulator screen

The device can display useful information such as CPU usage or highlights around redrawn areas. Turn these features on and off in the developer settings window as described in Setting debug and test configurations on the emulator.

Get system state information from the emulator (dumpstate)

You can access dumpstate information from the Dalvik Debug Monitor Service tool. See dumpsys and dumpstate on the adb topic page.

Get application state information from the emulator (dumpsys)

You can access dumpsys information from the Dalvik Debug Monitor Service tool. See dumpsys and dumpstate on the adb topic page.

Get wireless connectivity information

You can get information about wireless connectivity using the Dalvik Debug Monitor Service tool. From the Device menu, select "Dump radio state".

Log trace data

You can log method calls and other tracing data in an activity by calling startMethodTracing(). See Running the Traceview Debugging Program for details.

Log radio data

By default, radio information is not logged to the system (it is a lot of data). However, you can enable radio logging using the following commands:

adb shell logcat -b radio

Capture screenshots

Page 29: Interview Questions

The Dalvik Debug Monitor Server (DDMS) can capture screenshots from the emulator. Select Device > Screen capture.

Use debugging helper classes

Android provides debug helper classes such as util.Log and Debug for your convenience.

Also see the Troubleshooting document for answers to some common developing and debugging issues.

Configuring Your IDE to Attach to the Debugging Port

DDMS will assign a specific debugging port to every virtual machine that it finds on the emulator. You must either attach your IDE to that port (listed on the Info tab for that VM), or you can use a default port 8700 to connect to whatever application is currently selected on the list of discovered virtual machines.

Your IDE should attach to your application running on the emulator, showing you its threads and allowing you to suspend them, inspect their state, and set breakpoints. If you selected "Wait for debugger" in the Development settings panel the application will run when Eclipse connects, so you will need to set any breakpoints you want before connecting.

Changing either the application being debugged or the "Wait for debugger" option causes the system to kill the selected application if it is currently running. You can use this to kill your application if it is in a bad state by simply going to the settings and toggling the checkbox.

Android Debug Bridge

Android Debug Bridge (adb) is a versatile tool lets you manage the state of an emulator instance or Android-powered device. It is a client-server program that includes three components:

A client, which runs on your development machine. You can invoke a client from a shell by issuing an adb command. Other Android tools such as the ADT plugin and DDMS also create adb clients.

A server, which runs as a background process on your development machine. The server manages communication between the client and the adb daemon running on an emulator or device.

A daemon, which runs as a background process on each emulator or device instance.

You can find the adb tool in <sdk>/platform-tools/.

When you start an adb client, the client first checks whether there is an adb server process already running. If there isn't, it starts the server process. When the server starts, it binds to local TCP port 5037 and listens for commands sent from adb clients—all adb clients use port 5037 to communicate with the adb server.

The server then sets up connections to all running emulator/device instances. It locates emulator/device instances by scanning odd-numbered ports in the range 5555 to 5585, the range used by emulators/devices. Where the server finds an adb daemon, it sets up a connection to that port. Note that

Page 30: Interview Questions

each emulator/device instance acquires a pair of sequential ports — an even-numbered port for console connections and an odd-numbered port for adb connections. For example:

Emulator 1, console: 5554Emulator 1, adb: 5555Emulator 2, console: 5556Emulator 2, adb: 5557 ...

As shown, the emulator instance connected to adb on port 5555 is the same as the instance whose console listens on port 5554.

Once the server has set up connections to all emulator instances, you can use adb commands to control and access those instances. Because the server manages connections to emulator/device instances and handles commands from multiple adb clients, you can control any emulator/device instance from any client (or from a script).

The sections below describe the commands that you can use to access adb capabilities and manage the state of an emulator/device. Note that if you are developing Android applications in Eclipse and have installed the ADT plugin, you do not need to access adb from the command line. The ADT plugin provides a transparent integration of adb into the Eclipse IDE. However, you can still use adb directly as necessary, such as for debugging.

Issuing adb Commands

You can issue adb commands from a command line on your development machine or from a script. The usage is:

Adb [-d|-e|-s <serialNumber>] <command>

When you issue a command, the program invokes an adb client. The client is not specifically associated with any emulator instance, so if multiple emulators/devices are running, you need to use the -d option to specify the target instance to which the command should be directed. For more information about using this option, see Directing Commands to a Specific Emulator/Device Instance.

Querying for Emulator/Device Instances

Before issuing adb commands, it is helpful to know what emulator/device instances are connected to the adb server. You can generate a list of attached emulators/devices using the devices command:

adb devices

In response, adb prints this status information for each instance:

Serial number — A string created by adb to uniquely identify an emulator/device instance by its console port number. The format of the serial number is <type>-<consolePort>. Here's an example serial number: emulator-5554

State — The connection state of the instance. Three states are supported: o offline — the instance is not connected to adb or is not responding.

Page 31: Interview Questions

o device — the instance is now connected to the adb server. Note that this state does not imply that the Android system is fully booted and operational, since the instance connects to adb while the system is still booting. However, after boot-up, this is the normal operational state of an emulator/device instance.

The output for each instance is formatted like this:

[serialNumber] [state]

Here's an example showing the devices command and its output:

$ adb devicesList of devices attached emulator-5554  deviceemulator-5556  deviceemulator-5558  device

If there is no emulator/device running, adb returns no device.

Directing Commands to a Specific Emulator/Device Instance

If multiple emulator/device instances are running, you need to specify a target instance when issuing adb commands. To so so, use the -s option in the commands. The usage for the -s option is:

adb -s <serialNumber> <command>

As shown, you specify the target instance for a command using its adb-assigned serial number. You can use the devices command to obtain the serial numbers of running emulator/device instances.

Here is an example:

adb -s emulator-5556 install helloWorld.apk

Note that, if you issue a command without specifying a target emulator/device instance using -s, adb generates an error.

Installing an Application

You can use adb to copy an application from your development computer and install it on an emulator/device instance. To do so, use the install command. With the command, you must specify the path to the .apk file that you want to install:

adb install <path_to_apk>

Page 32: Interview Questions

For more information about how to create an .apk file that you can install on an emulator/device instance, see Android Asset Packaging Tool (aapt).

Note that, if you are using the Eclipse IDE and have the ADT plugin installed, you do not need to use adb (or aapt) directly to install your application on the emulator/device. Instead, the ADT plugin handles the packaging and installation of the application for you.

Forwarding Ports

You can use the forward command to set up arbitrary port forwarding — forwarding of requests on a specific host port to a different port on an emulator/device instance. Here's how you would set up forwarding of host port 6100 to emulator/device port 7100:

Adb forward tcp:6100 tcp:7100

You can also use adb to set up forwarding to named abstract UNIX domain sockets, as illustrated here:

adb forward tcp:6100 local:logd

Copying Files to or from an Emulator/Device Instance

You can use the adb commands pull and push to copy files to and from an emulator/device instance's data file. Unlike the install command, which only copies an .apk file to a specific location, the pull and push commands let you copy arbitrary directories and files to any location in an emulator/device instance.

To copy a file or directory (recursively) from the emulator or device, use

adb pull <remote> <local>

To copy a file or directory (recursively) to the emulator or device, use

adb push <local> <remote>

In the commands, <local> and <remote> refer to the paths to the target files/directory on your development machine (local) and on the emulator/device instance (remote).

Here's an example:

adb push foo.txt /sdcard/foo.txt

Listing of adb Commands

The table below lists all of the supported adb commands and explains their meaning and usage.

Page 33: Interview Questions

Category Command Description Comments

Options

-d Direct an adb command to the only attached USB device.

Returns an error if more than one USB device is attached.

-e Direct an adb command to the only running emulator instance.

Returns an error if more than one emulator instance is running.

-s <serialNumber> Direct an adb command a specific emulator/device instance, referred to by its adb-assigned serial number (such as "emulator-5556").

If not specified, adb generates an error.

GeneralGeneral

devices Prints a list of all attached emulator/device instances.

See Querying for Emulator/Device Instances for more information.

help Prints a list of supported adb commands.

version Prints the adb version number.

Debug

logcat [<option>] [<filter-specs>]

logcat [<option>] [<filter-specs>]

Bugreport Prints dumpsys, dumpstate, and logcat data to the screen, for the purposes of bug reporting.

Jdwp Prints a list of available JDWP processes on a given device.

You can use the forward jdwp:<pid> port-forwarding specification to connect to a specific JDWP process. For example: adb forward tcp:8000 jdwp:472jdb -attach localhost:8000

Data

install <path-to-apk> Pushes an Android application (specified as a full path to an .apk file) to the data file of an emulator/device.

pull <remote> <local> Copies a specified file from an emulator/device instance to your development computer.

push <local> <remote> Copies a specified file from your development computer to an emulator/device instance.

Ports and Networking

forward <local> <remote> Forwards socket connections from a specified local port to a specified remote port on the emulator/device instance.

Port specifications can use these schemes:

tcp:<portnum> local:<UNIX

domain socket name>

dev:<character

Page 34: Interview Questions

device name> jdwp:<pid>

ppp <tty> [parm]... Run PPP over USB.

<tty> — the tty for PPP stream. For example dev:/dev/omap_csmi_ttyl.

[parm]... — zero or more PPP/PPPD options, such as defaultroute, local, notty, etc.

Note that you should not automatically start a PPP connection.

Issuing Shell Commands

Adb provides an ash shell that you can use to run a variety of commands on an emulator or device. The command binaries are stored in the file system of the emulator or device, in this location:

/system/bin/...

You can use the shell command to issue commands, with or without entering the adb remote shell on the emulator/device.

To issue a single command without entering a remote shell, use the shell command like this:

adb [-d|-e|-s {<serialNumber>}] shell <shellCommand>

To drop into a remote shell on a emulator/device instance, use the shell command like this:

adb [-d|-e|-s {<serialNumber>}] shell

When you are ready to exit the remote shell, use CTRL+D or exit to end the shell session.

The sections below provide more information about shell commands that you can use.

Examining sqlite3 Databases from a Remote Shell

From an adb remote shell, you can use the sqlite3 command-line program to manage SQLite databases created by Android applications. The sqlite3 tool includes many useful commands, such as .dump to print

Page 35: Interview Questions

out the contents of a table and .schema to print the SQL CREATE statement for an existing table. The tool also gives you the ability to execute SQLite commands on the fly.

To use sqlite3, enter a remote shell on the emulator instance, as described above, then invoke the tool using the sqlite3 command. Optionally, when invoking sqlite3 you can specify the full path to the database you want to explore. Emulator/device instances store SQLite3 databases in the folder /data/data/<package_name>/databases/.

Here's an example:

$ adb -s emulator-5554 shell# sqlite3 /data/data/com.example.google.rss.rssexample/databases/rssitems.dbSQLite version 3.3.12Enter ".help" for instructions.... enter commands, then quit...sqlite> .exit

Once you've invoked sqlite3, you can issue sqlite3 commands in the shell. To exit and return to the adb remote shell, use exit or CTRL+D.

UI/Application Exerciser Monkey

The Monkey is a program that runs on your emulator or device and generates pseudo-random streams of user events such as clicks, touches, or gestures, as well as a number of system-level events. You can use the Monkey to stress-test applications that you are developing, in a random yet repeatable manner.

The simplest way to use the monkey is with the following command, which will launch your application and send 500 pseudo-random events to it.

$ adb shell monkey -v -p your.package.name 500

For more information about command options for Monkey, see the complete UI/Application Exerciser Monkey documentation page.

Other Shell Commands

The table below lists several of the adb shell commands available. For a complete list of commands and programs, start an emulator instance and use the adb -help command.

adb shell ls /system/bin

Enabling logcat Logging

The Android logging system provides a mechanism for collecting and viewing system debug output. Logs from various applications and portions of the system are collected in a series of circular buffers, which then can be viewed and filtered by the logcat command.

Page 36: Interview Questions

Using logcat Commands

You can use the logcat command to view and follow the contents of the system's log buffers. The general usage is:

[adb] logcat [<option>] ... [<filter-spec>] ...

The sections below explain filter specifications and the command options. See Listing of logcat Command Options for a summary of options.

You can use the logcat command from your development computer or from a remote adb shell in an emulator/device instance. To view log output in your development computer, you use

$ adb logcat

and from a remote adb shell you use

# logcat

Filtering Log Output

Every Android log message has a tag and a priority associated with it.

The tag of a log message is a short string indicating the system component from which the message originates (for example, "View" for the view system).

The priority is one of the following character values, ordered from lowest to highest priority:o V — Verbose (lowest priority)o D — Debugo I — Infoo W — Warningo E — Erroro F — Fatalo S — Silent (highest priority, on which nothing is ever printed)

You can obtain a list of tags used in the system, together with priorities, by running logcat and observing the first two columns of each message, given as <priority>/<tag>.

Here's an example of logcat output that shows that the message relates to priority level "I" and tag "ActivityManager":

I/ActivityManager(  585): Starting activity: Intent { action=android.intent.action...}

To reduce the log output to a manageable level, you can restrict log output using filter expressions. Filter expressions let you indicate to the system the tags-priority combinations that you are interested in — the system suppresses other messages for the specified tags.

A filter expression follows this format tag:priority ..., where tag indicates the tag of interest and priority indicates the minimum level of priority to report for that tag. Messages for that tag at or above the

Page 37: Interview Questions

specified priority are written to the log. You can supply any number of tag:priority specifications in a single filter expression. The series of specifications is whitespace-delimited.

Here's an example of a filter expression that suppresses all log messages except those with the tag "ActivityManager", at priority "Info" or above, and all log messages with tag "MyApp", with priority "Debug" or above:

adb logcat ActivityManager:I MyApp:D *:S

The final element in the above expression, *:S, sets the priority level for all tags to "silent", thus ensuring only log messages with "View" and "MyApp" are displayed. Using *:S is an excellent way to ensure that log output is restricted to the filters that you have explicitly specified — it lets your filters serve as a "whitelist" for log output.

The following filter expression displays all log messages with priority level "warning" and higher, on all tags:

adb logcat *:W

If you're running logcat from your development computer (versus running it on a remote adb shell), you can also set a default filter expression by exporting a value for the environment variable ANDROID_LOG_TAGS:

export ANDROID_LOG_TAGS="ActivityManager:I MyApp:D *:S"

Note that ANDROID_LOG_TAGS filter is not exported to the emulator/device instance, if you are running logcat from a remote shell or using adb shell logcat.

Listing of logcat Command Options

Option Description

-b <buffer>Loads an alternate log buffer for viewing, such as event or radio. The main buffer is used by default. See Viewing Alternative Log Buffers.

-c Clears (flushes) the entire log and exits. -d Dumps the log to the screen and exits.-f <filename> Writes log message output to <filename>. The default is stdout.-g Prints the size of the specified log buffer and exits.

-n <count>Sets the maximum number of rotated logs to <count>. The default value is 4. Requires the -r option.

-r <kbytes>Rotates the log file every <kbytes> of output. The default value is 16. Requires the -f option.

-s Sets the default filter spec to silent.

-v <format>Sets the output format for log messages. The default is brief format. For a list of supported formats, see Controlling Log Output Format.

Stopping the adb Server

Page 38: Interview Questions

In some cases, you might need to terminate the adb server process and then restart it. For example, if adb does not respond to a command, you can terminate the server and restart it and that may resolve the problem.

To stop the adb server, use the kill-server. You can then restart the server by issuing any adb command.

Dalvik Debug Monitor

Android ships with a debugging tool called the Dalvik Debug Monitor Server (DDMS), which provides port-forwarding services, screen capture on the device, thread and heap information on the device, logcat, process, and radio state information, incoming call and SMS spoofing, location data spoofing, and more. This page provides a modest discussion of DDMS features; it is not an exhaustive exploration of all the features and capabilities.

DDMS ships in the tools/ directory of the SDK. Enter this directory from a terminal/console and type ddms (or ./ddms on Mac/Linux) to run it. DDMS will work with both the emulator and a connected device. If both are connected and running simultaneously, DDMS defaults to the emulator.

How DDMS works

DDMS acts as a middleman to connect the IDE to the applications running on the device. On Android, every application runs in its own process, each of which hosts its own virtual machine (VM). And each process listens for a debugger on a different port.

When it starts, DDMS connects to adb and starts a device monitoring service between the two, which will notify DDMS when a device is connected or disconnected. When a device is connected, a VM monitoring service is created between adb and DDMS, which will notify DDMS when a VM on the device is started or terminated. Once a VM is running, DDMS retrieves the the VM's process ID (pid), via adb, and opens a connection to the VM's debugger, through the adb daemon (adbd) on the device. DDMS can now talk to the VM using a custom wire protocol.

For each VM on the device, DDMS opens a port upon which it will listen for a debugger. For the first VM, DDMS listens for a debugger on port 8600, the next on 8601, and so on. When a debugger connects to one of these ports, all traffic is forwarded between the debugger and the associated VM. Debugging can then process like any remote debugging session.

DDMS also opens another local port, the DDMS "base port" (8700, by default), upon which it also listens for a debugger. When a debugger connects to this base port, all traffic is forwarded to the VM currently selected in DDMS, so this is typically where you debugger should connect.

For more information on port-forwarding with DDMS, read Configuring your IDE to attach to port 8700 for debugging.

Tip: You can set a number of DDMS preferences in File > Preferences. Preferences are saved to "$HOME/.ddmsrc".

Known debugging issues with DalvikDebugging an application in the Dalvik VM should work the same as it does in other VMs. However,

Page 39: Interview Questions

when single-stepping out of synchronized code, the "current line" cursor may jump to the last line in the method for one step.

Difference between Android Cupcake, Donut, Eclair and Froyo…..

Nowadays products of cellphones with Android operating system are gaining popularity but many people are not aware with the version of Android operating system installed in their cell phones. Up to now there are many version of Android operating system which is Android Cupcake, Donut, Éclair, Froyo and Gingerbread. Each version of Android operating system is difference and usually an update to the previous version.

Maybe all you hub readers are already acquainted to these names of Android operating system but it is better we know the specific differences in each operating system.

Android Cupcake 1.5

The Android 1.5 Cupcake operating system is an update to the previous android 1.1 operating system software which was launched in February 2009. Cupcake new specification was: 

Having the ability to record and watch the video through the camcorder.

Upload video to YouTube and upload the pictures to Picasa

New applications of soft-keyboard with text-prediction functionality.

Bluetooth A2DP and AVRCP support.

Having the ability to automatically connect to a Bluetooth device with a certain distance.

New widget and folders can be gathered at the home screen.

Movement screen was done automatically

Android Donut

Android released an updated version which is Android version 1.6 and Google Android called it the Donut. The version was released in 30 April 2009 with the ability to: have increase functionality in android market

Having integrated camera, video recorder and display gallery

New gallery application allowing users to choose multiple photos to be deleted

Applications of voice search is updated to be more responsive and integrated with other applications including the ability to search contacts.

Enhanced search application to search for bookmarks, history, contacts, and web from home screen

Improved technology support for CDMA / EVDO.802.1x, VPNs, and text to speech engine. Supports resolution WVGA screen

Speed improvement in searching and camera applications

Page 40: Interview Questions

Improvement in speed-search application and camera applications.

Eclair Android ver. 2.1

Android Eclair ver 2.1 was an updated version of Android Donut with the ability of: Optimized hardware speed

Supports for higher screen size and screen resolution

Revamped User Interface

New user interface in a browser and support for html5

List of new contacts

Better white-black ratio for better backgrounds

Increasing functionality of Google Maps (3.1.2)

Support for Microsoft Exchange

Support for camera flash

Addition of Digital Zoom

Enhanced virtual keyboard on the application

addition Bluetooth 2.1

Live Wallpapers

Android Froyo ver. 2.2

Android was updated to Android Froyo operating system 2.2. Having the ability to: Optimizing the speed and performance of Android OS

Integration of chrome v8 JavaScript into a browser application

Enhanced support for Microsoft Exchange

Enhanced applications launcher with shortcuts towards phone and browser application

USB tethering functionality and Wi-Fi hotspots.

Addition of an option to disable data access, mobile network

Applications android market which has been updated with automatic update feature.

 Quick Switching Between multiple keyboard languages and dictionaries.

Voice dialing and various contacts via Bluetooth

Support for file uploads in the browser application

support for Adobe Flash 10.1

Page 41: Interview Questions

One of the things that most felt when changing from Eclair to Froyo is the increased performance of mobile phones. It can also be measured through the application benchmark commonly used in Android (Quadrant).Based on benchmarks conducted performance was increased to two-fold increase from the previous system (Eclair). The tests included testing of processor performance in multimedia processing, up to the graphics capability to handle 3-dimensional (3d) content.

In addition, existing free memory is greater than ever. If the user usually only get about 100MB, now can use about 250MB of 512MB total available memory. Automatically it is increasing performance despite users run many applications simultaneously.

Other notable features were:

We could place application on the SD Card. Unlike the previous operating system that could only put applications on the main memory. Through Froyo, users can put all the installation files on an external memory.

Record videos with HD quality. If the previous user can only record moving images at a maximum resolution of 800 X 480 pixels, not anymore. Thanks to Froyo, video capture resolution can be increased up to 1280 X 720 pixels. Equivalent to half the quality of High Definition.

Can be used as Hotspot. After upgrading to Froyo, users will see a new icon on the existing suite of applications that is, Wi-Fi Hotspot. As the name suggests, this application allows mobile phone users used as an access point.

In addition, there are more additional applications such as Flashlight, App Sharing, and Navigation. Especially for the navigation map, only available in beta version and cannot be used in several locations.

Android 2.3 Gingerbread and Its Best New Features

The latest Android release, Gingerbread, is coming, but we can peek at it in the software developer's kit.

Here's what's new and notable in Android 2.3: better typing, darker looks, detailed battery and memory

reports, and more.

Google has "launched" Gingerbread, which, for them, means that users of the Android SDK can create a

virtual Android device running 2.3, update their apps to utilize new APIs in the system, and otherwise

play around. They've also released an official video, explained the Android highlights, offered up

an official user guide (direct PDF link), and shown off Gingerbread in a stylized Nexus.

But for the big-picture view of what's new, we created our own little virtual Gingerbread phone and

poked around. Here's what you'll see when your own Android phone hits Android 2.3.

Note: Because this involves a tour of the SDK, we don't have access to any of Google's proprietary apps,

like the Gmail client, the Calendar, or especially the supposedly much-improved Market. We'll add in

shots and links to other sites where those aspects have seen coverage.

Page 42: Interview Questions

Where Android 2.2 and earlier were full of metal notification shades, white Menu buttons, and comparatively incongruous dark Settings pages, Gingerbread has partly unified the look and feel of Android's controls behind a dark theme with Orange highlights. Not that some themed phones, like on HTC's Sense platform, didn't have some dark looks of their own. But Gingerbread looks more consistent across its many aspects—menus, widgets, apps, and all.

New Keyboard and Text Tools

Selecting text on earlier Android versions was, frankly, a pain in the butt: press and hold the text area, choose "select text," move an oddly Windows-like cursor around with your tracking device (or try to make the world's most precise finger selection), then press and hold again and hit "copy," then press and hold again and hit "paste." There's still some press-and-hold to paste, but selecting text got a lot easier. When you're trying to move your cursor around to fix up your text, a new "handle" appears diagonally to the actual cursor, and it's a lot easier to grab onto and move about. When you're actually selecting text, two different handles appear, in iPhone-like style (or Sense-like style, perhaps), that define the boundaries of your selection.

As for the keyboard itself, it looks somewhat similar, but there's a few things going on behind the scenes:

Google says the soft, on-screen keyboard has its keys "reshaped and repositioned for improved

targeting."

While you're typing, the current character you've pressed is more apparent, and the automatic

suggestions for the word you're trying at is made more clear at the top of the keys (the white-on-

black text helps with that, too).

Select a word by single-tapping on it, and you can quickly replace that word with suggestions from

the dictionary that seem like what you were trying for. If you're familiar with the Voice Actions

input on Android 2.2, the word suggestion/replacement is a lot like that.

Entering numbers and symbols no longer requires switching to the Sym/Alt keyboard mode.

Simultaneously tapping Shift and a letter, or the "?123" key and a symbol, enters the character that's

above the main key. There's also a pop-out menu of accents, symbols, and other special characters

when you hold-and-slide certain keys.

Gingerbread vs Honeycomb – Features, Pros and Cons

Android is another operating system out of all those out there for those Smartphone platforms. The Android software was purchased by Google Inc a few years back. It is full of different key applications and mainly based on the Linux Kernel. As there are many versions of specific Operating Systems out there, so is the case with Android too. And the recent versions of Android include Éclair 2.1, Fro-yo 2.2, and Gingerbread 2.3 and Honeycomb 3.2 which we are here to discuss about.

Page 43: Interview Questions

Brief Overview of Features

This discussion is not something to be piled up in limited words, as both versions are full of some

awesome features. But what we have here as an advantage, is their uses in two different mediums.

Actually, Honeycomb is the first Android platform entirely designed for devices with large screens such

as tablets and it is the first version of the platform designed to support symmetric multi processing in a

multi core environment. Whereas Gingerbread was an update to the present Froyo version in the

Smartphone.  One feature that I really like about Gingerbread is the SIP communication feature. It

decreases the voice calling revenue so users can call each other for lower rates, or even free, if they have a

good data connection.

On the other hand, Gingerbread has a better DSP manager/equalizer that gives a boost to the settings. It

also has better and advanced brightness control settings. Frankly, many users reverted back to the old

version of Android, i.e Froyo, because they din’t find any attractive new features in Gingerbread.

Talking about Honeycomb, it was great to see that Android very much further enhanced its great

multitasking and switching features. In addition, it also increased the ability to copy-paste, incorporated a

better chrome browser, and a more improved drag-drop and multitouch system. And, if you are a gamer,

Honeycomb is a better option for you, as it is designed for the graphics card on board and thus you can

have an awesome experience using it.

Features Comparisons

Gingerbread Honeycomb

- Advanced Microsoft Exchange Support - New Optimized Tablet UI

- Wi-Fi hotspot functionality - Redesigned widgets

- Animated GIFs supported in browser - Elegant Notification Bar

- Adobe Flash 10.1 supported - Customizable Home Screen

- Support for extra high DPI screens - Action-bar

- Extra Large Screen Size supported - Improved Keyboard, Copy/Paste

- SIP Communication Supported - Browser Enhancements

- Support for WebM/VP8 video playback - Visual multi-tasking

- Improved Copy and Paste functionality - Multiselect, Clipboard, Drag-and-drop

- Redesigned Multi Touch Software Keyboard - New Connectivity options

- Enhanced support for native code - Support for Multi-core Processors

- Support for multiple cameras - Hardware acceleration for 2D graphics

Page 44: Interview Questions