Skip to content

Tag: testing

ADB(Android Debug Bridge)


Android Debug Bridge (adb) is a versatile command line tool that lets you communicate with an emulator instance or connected Android device. It facilitates a variety of device actions, such as installing and debugging apps, and it provides access a Unix shell that you can use to run a variety of commands on an emulator or connected device. It is a client-server program that includes three components:

  • A client, which sends commands. The client runs on your development machine. You can invoke a client from a command-line terminal by issuing an adb command.
  • A daemon, which runs commands on a device. The daemon runs as a background process on each emulator or device instance.
  • A server, which manages communication between the client and the daemon. The server runs as a background process on your development machine.

adb is included in the Android SDK Platform-Tools package. You can download this package with the SDK Manager, which installs it at android_sdk/platform-tools/. Or if you want the standalone Android SDK Platform-Tools package, you can download it here.

How adb works –

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 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: 5554
Emulator 1, adb: 5555
Emulator 2, console: 5556
Emulator 2, adb: 5557
and so on…

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 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).

Enable adb debugging on your device –

To use adb with a device connected over USB, you must enable USB debugging in the device system settings, under Developer options.

On Android 4.2 and higher, the Developer options screen is hidden by default. To make it visible, go to Settings > About phone and tap Build number seven times. Return to the previous screen to find Developer options at the bottom.

On some devices, the Developer options screen may be located or named differently.

You can now connect your device with USB. You can verify that your device is connected by executing adb devices from the android_sdk/platform-tools/ directory. If connected, you’ll see the device name listed as a “device.”

Note: When you connect a device running Android 4.2.2 or higher, the system shows a dialog asking whether to accept an RSA key that allows debugging through this computer. This security mechanism protects user devices because it ensures that USB debugging and other adb commands cannot be executed unless you’re able to unlock the device and acknowledge the dialog.

For more information about connecting to a device over USB, read Run Apps on a Hardware Device.

Connect to a device over Wi-Fi –

adb is usually used over USB. However, it is also possible to use over Wi-Fi, as described here.

  1. Connect your Android device and adb host computer to a common Wi-Fi network accessible to both. Beware that not all access points are suitable; you may need to use an access point whose firewall is configured properly to support adb.

Note: If you are attempting to connect to an Android Wear device, force it to connect to Wi-Fi by shutting off Bluetooth on the phone connected to it.

  1. Connect the device to the host computer with a USB cable.
  2. Set the target device to listen for a TCP/IP connection on port 5555.
  3. $ adb tcpip 5555
  4. Disconnect the USB cable from the target device.
  5. Find the IP address of the Android device. For example, on a Nexus device, you can find the IP address at SettingsAbout tablet (or About phone) > Status > IP address. Or, on an Android Wear device, you can find the IP address at Settings > Wi-Fi Settings > Advanced > IP address.
  6. Connect to the device, identifying it by IP address.
  7. $ adb connect device_ip_address
  8. Confirm that your host computer is connected to the target device:
  9. $ adb devices
  10. List of devices attached
  11. device_ip_address:5555 device

You’re now good to go!

If the adb connection is ever lost:

  1. Make sure that your host is still connected to the same Wi-Fi network your Android device is.
  2. Reconnect by executing the adb connectstep again.
  3. Or if that doesn’t work, reset your adb host:
  4. adb kill-server

Then start over from the beginning.


Below are some of the adb commands:

  1. adb root – This shows if the connected device is running as root or no. If not it will display as cannot run in production builds.
  2. adb reboot sideload <> – ADB sideload is a different ADB mode that you can use to push and install a zip using one command from your computer. Most likely ADB sideload won’t be very useful for your average recovery user, but ADB sideload can be a huge time-saver for a ROM developer.
  3. adb shell ps [options] – Prints the process status.

Step by step:

Enter adb shell command while a device (or emulator) is connected.
(Command line prefix will be shell@android:/ $ after executing this command.)

Enter ps | grep <package_name_to_be_filtered> (i.e. ps | grep

C:>adb shell
shell@android:/ $ ps | grep
ps | grep
u0_a64 3353 2467 903744 52904 ffffffff 00000000 S
u0_a64 3426 2467 893964 49452 ffffffff 00000000 S

  1. adb shell top -m 10 | grep<packagename> – This top command is refreshing periodically, so one can get CPU usage through various stages of an app.
  2. adb shell getprop [options] > <filename>.txt – Gets the properties via the android property service or so called as build.prop file.
  3. adb shell setprop <key> <value> – Sets the property value for the given key.

Example: ro.product.device will be the key and you can change it by giving any value. Restart the device and you are good to go.

  1. adb shell screencap /sdcard/<filename>.png – This will capture the current screen and saves in to the file system of android. To save the screenshot taken to the system use the command adb pull /sdcard/<filename>.png
  2. adb shell screenrecord /sdcard/<filename>.mp4 – This command is used to record the screen.


To download the file from the device use the below command –

adb pull /sdcard/<filename>.mp4

Note: To stop the screen recording, press Ctrl-C, otherwise the recording stops automatically at three minutes or the time limit set by –time-limit.

adb shell screenrecord –size 1280*720 /sdcard/<filename>.mp4

The above command sets the video size to 1280×720.

adb shell screenrecord –bit-rate 6000000 /sdcard/<filename>.mp4

The above command sets the video bit rate for the video in 6Mbps. The default value is 4Mbps. You can increase the bit rate to improve video quality, but doing so results in larger video files.

adb shell screenrecord –time-limit <TIME>

The above command sets the maximum recording time, in seconds. The default and maximum value is 180 (3 minutes).

adb shell screenrecord –rotate

The above command rotates the output to 90 degrees. This feature is experimental.

adb shell screenrecord –verbose

The above command displays log information on the command-line screen. If you do not set this option, the utility does not display any information while running.


  1. adb logcat > <filename>.txt – Saves logs to a text file.

9a.adb logcat -v <format>

adb logcat -v brief Display priority/tag and PID of the process issuing the message (default format).adb logcat -v process Display PID only.)adb logcat -v tag Display the priority/tag only.adb logcat -v raw Display the raw log message, with no other metadata fields.adb logcat -v time Display the date, invocation time, priority/tag, and PID of the process issuing the message.adb logcat -v threadtime Display the date, invocation time, priority, tag, and the PID and TID of the thread issuing the message.adb logcat -v long Display all metadata fields and separate messages with blank lin

9b. adb logcat –b <buffer>

adb logcat -b radio View the buffer that contains radio/telephony related messages.

adb logcat -b event View the buffer containing events-related messages.

adb logcat -b main default

adb logcat *:V lowest priority, filter to only show Verbose level

adb logcat *:D filter to only show Debug level

adb logcat *:I filter to only show Info level

adb logcat *:W filter to only show Warning level

adb logcat *:E filter to only show Error level

adb logcat *:F filter to only show Fatal level

adb logcat *:S Silent, highest priority, on which nothing is ever printed


  1. adb shell dumpsys


dumpsys is an android tool that runs on the device and dumps interesting information about the status of system services.


Obvious benefits:

  1. Possibility to easily get system information in a simple string representation.
  2. Possibility to use dumped CPU, RAM, Battery, storage stats for a pretty charts, which will allow you to check how your application affects the overall device!


If you run dumpsys you would see a ton of system information. But you can use only separate parts of this big dump.

To see all of the “subcommands” of dumpsys do:

dumpsys | grep “DUMP OF SERVICE”




DUMP OF SERVICE SurfaceFlinger:

DUMP OF SERVICE accessibility:




DUMP OF SERVICE appwidget:




DUMP OF SERVICE batteryinfo:

DUMP OF SERVICE clipboard:

DUMP OF SERVICE connectivity:



DUMP OF SERVICE device_policy:

DUMP OF SERVICE devicestoragemonitor:

DUMP OF SERVICE diskstats:




DUMP OF SERVICE input_method:

DUMP OF SERVICE iphonesubinfo:



DUMP OF SERVICE media.audio_flinger:

DUMP OF SERVICE media.audio_policy:

DUMP OF SERVICE media.player:




DUMP OF SERVICE network_management:

DUMP OF SERVICE notification:


DUMP OF SERVICE permission:




DUMP OF SERVICE screenshot:



DUMP OF SERVICE simphonebook:

DUMP OF SERVICE statusbar:

DUMP OF SERVICE telephony.registry:


DUMP OF SERVICE usagestats:


DUMP OF SERVICE wallpaper:



Some Dumping examples and output

1) Getting all possible battery statistic:

$~ adb shell dumpsys battery


You will get output:

Current Battery Service state:

AC powered: false

AC capacity: 500000

USB powered: true

status: 5

health: 2

present: true

level: 100

scale: 100


temperature: 271 <———- Battery temperature! %)

technology: Li-poly <———- Battery technology! %)


2)Getting wifi informations

~$ adb shell dumpsys wifi



Wi-Fi is enabled

Stay-awake conditions: 3


Internal state:

interface tiwlan0 runState=Running

SSID: XXXXXXX BSSID: xx:xx:xx:xx:xx:xx, MAC: xx:xx:xx:xx:xx:xx, Supplicant state: COMPLETED, RSSI: -60, Link speed: 54, Net ID: 2, security: 0, idStr: null

ipaddr gateway 192.168.x.x netmask dns1 192.168.x.x dns2 DHCP server 192.168.x.x lease 604800 seconds

haveIpAddress=true, obtainingIpAddress=false, scanModeActive=false

lastSignalLevel=2, explicitlyDisabled=false


Latest scan results:


Locks acquired: 28 full, 0 scan

Locks released: 28 full, 0 scan


Locks held:


3) Getting CPU info

~$ adb shell dumpsys cpuinfo



Load: 0.08 / 0.4 / 0.64

CPU usage from 42816ms to 34683ms ago:

system_server: 1% = 1% user + 0% kernel / faults: 16 minor 0% = 0% user + 0% kernel / faults: 160 minor

tiwlan_wq: 0% = 0% user + 0% kernel

usb_mass_storag: 0% = 0% user + 0% kernel

pvr_workqueue: 0% = 0% user + 0% kernel

+sleep: 0% = 0% user + 0% kernel

+sleep: 0% = 0% user + 0% kernel

TOTAL: 6% = 1% user + 3% kernel + 0% irq


4)Getting memory usage information’s

~$ adb shell dumpsys meminfo ‘your apps package name’



** MEMINFO in pid 5527 [] **

native   dalvik    other    total

size:     2868     5767      N/A     8635

allocated:     2861     2891      N/A     5752

free:        6     2876      N/A     2882

(Pss):      532       80     2479     3091

(shared dirty):      932     2004     6060     8996

(priv dirty):      512       36     1872     2420



Views:        0        ViewRoots:        0

AppContexts:        0       Activities:        0

Assets:        3    AssetManagers:        3

Local Binders:        2    Proxy Binders:        8

Death Recipients:        0

OpenSSL Sockets:        0




heap:        0         MEMORY_USED:        0

PAGECACHE_OVERFLOW:        0         MALLOC_SIZE:        0


If you want see the info for all processes, use ~$ adb shell dumpsys meminfo


  1. adb shell netstatUsing the above command we can get the current network statistics of a system or can be used to get details of a desired application. More details.
  2. adb pull <path of the from device> <local machine path>

Using the above command we can pull specific file from the connected device to the local machine (PC).

Example: adb pull /sdcard/test.txt e:\


  1. adb push <local> <remote>Using this command we can push a specific file to the device.
    Example: adb push d:\test.apk /sdcard/
  2. adb shell lsThe above command is used to list out all the files.
    Example: adb shell ls /system/bin
  3. adb shell cdThe above command helps to change the directory.
    Example: adb shell cd /system.
  4. adb shell rmRemoves the desired file from the android system.
    Example: adb shell rm /sdcard/filename.txt

    Use rm -i /sdcard/<file name>.txt to get a prompt before deletion.

  5. adb shell mkdirThe above command is used to make directories.
    Example: adb mkdir /sdcard/test
  6. adb shell pwdPrints the current working directory.
    Example: If current dir is system/bin, the same will be displayed.
  7. adb shell cpCopies files to the destination from source given.
  8. adb shell mvTo move or rename files.
    Example: adb shell mv /sdcard/test.txt /sdcard/test_renamed.txt
    The above example will rename the selected file.
    Example: adb shell mv /system/bin /system/tmp
    The above example will move the files from bin folder to tmp.
  9. adb installUse the above command to install apk on an emulator or connected device.
    Example: adb install <path of apk>

    adb install -l test.apk to forward lock application

adb install -r test.apk to replace existing application

adb install -t test.apk to allow test packages

adb install -s test.apk to install application on sdcard

adb install -d test.apk to allow version code downgrade

adb install -p test.apk  to partial application install


  1. adb uninstallUse the above command to uninstall an apk installed on emulator or connected device.
    Example: adb uninstall <Package name>
    adb uninstall -k to Keep the data and cache directories around after package removal.


  2. adb shell pm list packagesPrints all packages, optionally only those whose package name contains the text in <FILTER>.

    adb shell pm list packages -f See their associated file.

adb shell pm list packages -d Filter to only show disabled packages.

adb shell pm list packages -e Filter to only show enabled packages.

adb shell pm list packages -s Filter to only show system packages.

adb shell pm list packages -3 Filter to only show third party packages.

adb shell pm list packages -i See the installer for the packages.

adb shell pm list packages -u Also include uninstalled packages.

adb shell pm list packages –user <USER_ID> The user space to query.


  1. adb shell pm pathPrints the path to the APK of the given package.
    Example: adb shell pm path
    Output: package:/system/priv-app/TeleService/TeleService.apk
Leave a Comment

Mobile Application Testing

Mobile Application Testing

If anybody wants to use / copy this tutorial to their Website or Blog please feel free to contact me at my personal email id:
Manual Testing


1. What is Mobile Application Testing?

2. Difference Between Mobile Testing and Mobile Application Testing.

3. Mobile Application Extensions and Small intro about Android Platform.

4. How to Test a Mobile Application?

Automation Testing

Click on the below Topics to Lean Automation Testing.

It will take only 2-3 days to learn If you are good at Java.

1. Robotium for Android Application Testing.


1. What is Mobile Application Testing?

It is somewhat similar to software testing but the testing will be performed on a mobile device instead of performing on a system.

Types of Mobile application Testing are: 

1. Installation testing.

2. Functional Testing.

3. Memory Leakage Testing.

4. Interrupt Testing.

5. Usability testing.

6. Certification Testing.

7. Performance Testing.

8. Integration Testing.

9. System Testing.

10. Accessibility Testing.

11. Adhoc(Monkey) Testing.

The all above points will be discussed in chapter 4:


2. Difference Between Mobile Testing and Mobile Application Testing.

Mobile Testing

– Mobile Testing is testing of Mobile Handsets or Devices.

– Here we mainly concentrate on Native applications(Blot wares).

– Testing all the core like SMS, Voice calls, Connectivity(Bluetooth), Battery(Charging), Signal receiving, Network are working correctly.

– Testing is conducted on both hardware and software.

Mobile Application Testing

– Mobile Application Testing is the testing of mobile applications which we are making as third party for the targeted mobile handset.

– Some core feature of the mobile are tested just to see that your application has not created any side effects on the device functionality.


3. Mobile Application Extensions and Small intro about Android Platform.

Below are some Mobile Platforms given with respective File Extensions

1. Android – .apk (Android application package file)

2. Iphone – .ipa (iOS application archive file)

3. Symbian – .sis (Software Installation Script)

4. J2ME – .jad and .jar (Java Application Descriptor and Java ARchive)

5. RIM – .alx and .cod

6. Windows Mobile – .cab

7. Bada – .jad and .jar (Java Application Descriptor and Java ARchive)

Android Platform

Testing Purpose we should have to know about the android architecture as well as about Android Versions. Details On this discussed below:

Architecture of Android:

Android operating system is a stack of software components which is roughly divided into five sections and four main layers as shown below in the architecture diagram:

Image and video hosting by TinyPic

Linux kernel
At the bottom of the layers is Linux – Linux 2.6 with approximately 115 patches. This provides basic system functionality like process management, memory management, device management like camera, keypad, display etc. Also, the kernel handles all the things that Linux is really good at such as networking and a vast array of device drivers, which take the pain out of interfacing to peripheral hardware.


On top of Linux kernel there is a set of libraries including open-source Web browser engine WebKit, well known library libc, SQLite database which is a useful repository for storage and sharing of application data, libraries to play and record audio and video, SSL libraries responsible for Internet security etc.

Android Runtime
This is the third section of the architecture and available on the second layer from the bottom. This section provides a key component called Dalvik Virtual Machine which is a kind of Java Virtual Machine specially designed and optimized for Android.

The Dalvik VM makes use of Linux core features like memory management and multi-threading, which is intrinsic in the Java language. The Dalvik VM enables every Android application to run in its own process, with its own instance of the Dalvik virtual machine.

The Android runtime also provides a set of core libraries which enable Android application developers to write Android applications using standard Java programming language.

Application Framework
The Application Framework layer provides many higher-level services to applications in the form of Java classes. Application developers are allowed to make use of these services in their applications.

You will find all the Android application at the top layer. You will write your application to be installed on this layer only. Examples of such applications are Contacts Books, Browser, Games etc.

Android Application Activity Lifecycle

The life cycle of an activity with main methods as shown below:

Image and video hosting by TinyPic

onCreate() This is the first callback and called when the activity is first created.

onStart() This callback is called when the activity becomes visible to the user.

onResume() This is called when the user starts interacting with the application.

onPause() The paused activity does not receive user input and cannot execute any code and called when the current activity is being paused and the previous activity is being resumed.

onStop() This callback is called when the activity is no longer visible.

onDestroy() This callback is called before the activity is destroyed by the system.

onRestart() This callback is called when the activity restarts after stopping it.

If you know this much it is enough to Go ahead with Mobile application testing in Android platform.


4. How to Test a Mobile Application?

1. Installation testing:

To Verify application can be installed successfully.

Different ways of Installing an application to Android Device:

1(a). OTA(Over The Air) : We can install our application by using android play store app on the mobile or else by browsing into Google playstore website. This can be done using WiFi as well as by using GPRS connection.

1(b). Sideloading From Your PC : To do this we need ADB(Android Debug Bridge). This is a very simplest way to install any 3rd party app to your device, most of the time we test engineers prefer this way only.

Just download and Install Android SDK to your system and follow the below steps:

1. Download the application (APK) file to a folder of your choice on your computer.

2. Connect the phone to the computer through the USB port.

3. Enable installation of non-market applications on your phone:

a. On your phone, open the Applications menu (i.e., the tab in the bottom center of the
phone’s home screen) and click on the Settings application, then select Applications
from the Settings menu.

b. Make sure that the first selection, Unknown Sources, is checked so that you can install
an APK file from a location other than the Android Market. A warning message about
the phone being vulnerable to attack will be displayed. Select OK to continue if you
trust the APK file you are about to download. You can change this setting back after the
current installation is complete.

4. Turn on “USB debugging” on your phone: open the Applications menu and select Development,
then enable USB debugging.

5. Open a command/terminal window:

• On Windows, select Start > Run> then type ‘cmd’.
• On Mac OS X, open the Applications folder, select Utilities, then Terminal.
• On Linux, select Applications > Accessories > Terminal.

6. In the command/terminal window, enter the following command:


adb install <APK_FILE_PATH><APK_FILE>

2. Functional Testing:

Testing the functionality of the application with respect to given requirements of the application.

2(a). Application LOGO Test: Testing the logo of the application to check whether the app which is under test have used the proper logo as per the requirement specification or not.

2(b). Application Splash Screen Test: To verify that when user selects application logo in application manager splash is displayed.
Note that Splash do not remain for more than 3 seconds.

2(c). Application Background Image Test: To test whether the application under test is using the proper Background image as per given requirement specification or not.

2(d). Font style / size / color: Testing the Font size/style/color as per requirement specification.

2(e). Layout: Testing the layouts with respect to given requirement specification.

2(f). Back Key: Verify that back key should navigate the user to previous screen or should close the application with proper exit popup dialog(Again it depends on Requirement specification).

2(g). Application Start/Restart: 
i. Find the application icon and select it
ii. Observe the application launch In the timeline defined.
iii. Application must not take more than 25s to start

2(h). Exit Application: Verify that user is able to exit from application with every form of exit modes like Flip, Slider, End Key or Exit option in application and from any point.

3. Memory Leakage Testing

Memory leakage happens when a computer program or application is unable to manage the memory it is allocated resulting in poor performance of the application and the overall slowdown of the system. As mobile devices have significant constraints of available memory, memory leakage testing is crucial for the proper functioning of an application.

4. Interrupt Testing

An application while functioning may face several interruptions like incoming calls or network coverage outage and recovery. The different types of interruptions are:

  • Incoming and Outgoing SMS and MMS.
  • Incoming and Outgoing calls.
  • Incoming Notifications.
  • Battery Removal.
  • Cable Insertion and Removal for data transfer.
  • Network outage and recovery.
  • Media Player on/off.
  • Device Power cycle.

An application should be able to handle these interruptions by going into a suspended state and resuming afterwards.

5. Usability testing

Checking the user-friendliness of the application is known as Usability testing.

We have to verify if the application is achieving its goals and getting a favorable response from users. The application should have to give the results in very few steps or in few clicks.

The best example for this is: If you are booking a movie ticket by using some application, user should get the ticket booked in a very short amount of time / only by using 3-4 activities maximum!!

6. Certification Testing

Use this command : (Jarsigner is in your Java bin folder goto java->jdk->bin path in cmd prompt)


$ jarsigner -verify -verbose -certs my_application.apk

If you see “CN=Android Debug”, this means the .apk was signed with the debug key generated by the Android SDK (means it is unsigned), else u will find something for CN. for more details…p-signing.html

How do developer signs their apps: 

Dev creates a keystore file by using the below cmd:


$ keytool -genkey -v -keystore my-release-key.keystore
-alias alias_name -keyalg RSA -keysize 2048 -validity 10000

To show you how it works I have given a screen shot of creating one below:

Image and video hosting by TinyPic

After generating key we have to follow the following steps:

  • Right click on project > Android Tools > Export Signed Application Package
  • The Export Android Application wizard appears.
  • Select the project I want to export, click Next.
  • The Keystore Selection screen appears.
  • Select the keystore and enter the password.

Image and video hosting by TinyPic

After this just give the path of the .apk file that has to be released.

Image and video hosting by TinyPic

7. Performance Testing

This testing process is undertaken to check the performance and behavior of the application under certain conditions such as low battery, bad network coverage, low available memory, simultaneous access to application’s server by several users and other conditions. Performance of an application can be affected from two sides: application’s server side and client’s side. Performance testing is carried out to check both.

This is done by performance test engineers. They use specific tools for this, for example: LoadRunner, Apache JMeter etc…

8. Integration Testing

Testing the data flow between two modules(activities) is called to be as Integration Testing.

This is done after finishing of Functional Testing.

The reason why we do Integration Testing is to make sure that all the activities are connected together properly or not.

9. System Testing

It is a end to end testing of the application where in Testing Environment is similar to production.

Here we test the data flow from the beginning to the end, If something is broken we have to report it as a bug.

We perform system testing after finishing of Integration Testing.

We perform system testing to make sure that end to end scenarios of the application is working properly or not.

10. Accessibility Testing

Accessibility testing is a subset of usability testing where the users under consideration have disabilities that affect how they use the application. The end goal, in both usability and accessibility, is to discover how easily people can use application and feed that information back into improving future designs and implementations.

This testing is done after completion of system testing.

11. Adhoc Testing(Monkey Testing)

Testing the application in a random way is called to be as Adhoc or Monkey Testing.

Monkey Testing is done after completion of full software testing and reporting of all the bugs is done. And also when the product is almost stable.

The reason why we perform this testing is,

  • To some how brake the product.
  • To find more number of bugs.
  • To make the software more stable.
Leave a Comment