Get Even More Visitors To Your Blog, Upgrade To A Business Listing >>

What happens behind the scenes as Appium installs and launches an Android app? Examining and footnoting a log file.

This is part seven of of a seven-part blog series. Care to go back to the beginning?

Have you ever wondered what is happening behind-the-scenes as Appium launches an app? Well, there is one way to find out...

Today, we will be taking a look at the log files captured in the Appium console, generated after I launch the APIDemos-debug.apk Android app, with the help of Appium, onto an Android emulator.

... Actually, this blog article wasn't written in a day. It took more than a few weekends to thoroughly research everything... and I do mean everything!

There are possible errors or questions on the inner workings on Appium, with insightful statements such as ... "Huh? What's this?" ... They are highlighted in red.

Is there anything I am wrong about? Please let me know! I am a complete novice when it comes to Appium (although, I have been hideously busy).  I only started learning it in March of 2017. The reason I am blogging about this is because I actually want you to comment if I am completely off-base, or if I am error about the inner workings of Appium or the world of Android development.

What is an APK?

  • APK stands for Android Application Package

"Android Package Kit (APK) is the package file format used by the Android operating system for distribution and installation of mobile apps and middleware [...] To make an APK file, a program for Android is first compiled, and then all of its parts are packaged into one file. An APK file contains all of that program's code [...] resources, assets, certificates, and manifest file. As is the case with many file formats, APK files can have any name needed, provided that the file name ends in ".apk" [...] APK files are a type of archive file, specifically in zip format packages based on the JAR file format, with .apk as the filename extension. The MIME type associated with APK files is application/]" - Wikipedia, Android Package Kit. 

When you first start the Appium console, Appium patiently waits in the background...

[Appium] Welcome to Appium v1.6.4
[Appium] Appium REST http interface listener started on

... but when you feed a set of Desired Capabilites to it, and Appium finds an emulator matching them, a flurry of activity happens as it installs the app on the emulator. It will use a series of Android command line tools to inspect the emulator, find Android application packages that are running, and inspect these APKs, check if there are any special settings, and Appium will launch them.

How does the Appium Server start?
It works the similar way as common ChromeDriver, InternetExplorerDriver of Selenium project or PhantomJSDriver. They use subclasses of the DriverService.
This feature provides abilities and options of the starting of a local Appium node server. End users still able to open apps as usual. - Appium Java Client Docs, The Starting of an App Using Appium Node Server.

Let's review what is happening, section by section...

What Are We Feeding That Thing?

For this example, we are sending to Appium the code:

 final String URL_STRING = "";
URL url = new URL(URL_STRING);

File app = new File("ApiDemos-debug.apk");
DesiredCapabilities caps = new DesiredCapabilities();
caps.setCapability(MobileCapabilityType.DEVICE_NAME, "emulator-5554");
caps.setCapability(MobileCapabilityType.APP, app.getAbsolutePath());
caps.setCapability(MobileCapabilityType.PLATFORM_NAME, MobilePlatform.ANDROID);
AndroidDriver driver = new AndroidDriver(url, caps);
  • Appium Server is listening on
  • The Android emulator is on emulator-555-4, and if we use adb devices, we will see it in the list
  • The code above sets a String constant URL_STRING and a url variable the value of our old friend localhost, the Home IP, 
  • /wd/hub is our old friend, the Selenium Hub, part of the Selenium Grid. 
  • When a new instance of AndroidDriver is created, we are setting it to the Selenium Hub and Appium Server listening in at, and passing along the DesiredCapabilities. Appium will be connected to the Selenium Grid. 

"What is Selenium-Grid?

"Selenium-Grid allows you run your tests on different machines against different browsers in parallel. That is, running multiple tests at the same time against different machines running different browsers and operating systems. Essentially, Selenium-Grid support distributed test execution. It allows for running your tests in a distributed test execution environment.

"When to Use It

"Generally speaking, there are two reasons why you might want to use Selenium-Grid.

  • "To run your tests against multiple browsers, multiple versions of browser, and browsers running on different operating systems.
  • "To reduce the time it takes for the test suite to complete a test pass.
"Selenium-Grid is used to speed up the execution of a test pass by using multiple machines to run tests in parallel". - Selenium HQ Docs, Selenium Grid

[HTTP] --> POST /wd/hub/session {"desiredCapabilities":{"app":"/Users/ventmahe/code/basic_appium_framework/ApiDemos-debug.apk","platformName":"Android","deviceName":"emulator-5554"}}
  • The desired capabilities are being posted via HTTP, to the Selenium Grid that Appium is connected to, much as if you were submitting a web form, POST-ing it to another service. 

[MJSONWP] Calling AppiumDriver.createSession() with args: [{"app":"/Users/ventmahe/code/basic_appium_framework/ApiDemos-debug.apk","platformName":"Android","deviceName":"emulator-5554"},null,null,null,null]

  • Next, we have the Mobile JSON Wire Protocol calling the Appium Driver Method, create session with the arguments we passed into the DesiredCapabilites: where the app is located (the absolute path), the platform name (Android), and the deviceName (emulator-5554). 
  • See official documentation on the JSON Wire Protocol.
  • See the Mobile JSON Wire errors that can be thrown in the Appium Base Driver on Appium's GitHub site. 
The Mobile JSON Wire Protocol

[BaseDriver] Event 'newSessionRequested' logged at 1495296256238 (12:04:16 GMT-0400 (EDT))

  • The Appium Base Driver registers when the new session was requested in Greenwich Mean Time (-400) since I am in Quincy, MA when the request was made. Eastern Daylight Time.
  • What is the Appium base driver? 
"This is the parent class that all appium drivers inherit from. Appium drivers themselves can either be started from the command line as standalone appium servers, or can be included by another module (appium) which then proxies commands to the appropriate driver based on Desired Capabilities.
"An appium driver is a module which processes Mobile Json Wire Protocol commands and controls a device accordingly. The commands can either come in over HTTP as json api requests, or they can be passed to the driver object programmatically as already-parsed json object (without the HTTP headers and junk).
"The appium Base driver already includes the mjsonwp module, which is the HTTP server that converts incoming requests into json objects that get sent to the driver programmatically.
"The appium Base driver already has all the REST api routes, validation, and error codes supplied by mjsonwp.
"Appium drivers are designed to have a single testing session per instantiation. This means that one Driver object should be attached to a single device and handle commands from a single client. - Github / Appium / Appium-Base-Driver / lib / basedriver

[Appium] Creating new AndroidDriver (v1.17.1) session
[Appium] Capabilities:
[Appium] app: '/Users/ventmahe/code/basic_appium_framework/ApiDemos-debug.apk'
[Appium] platformName: 'Android'
[Appium] deviceName: 'emulator-5554'

  • Rather boring, isn't it? Watching the same values we already know pass from one service to another to another? But Appium is about to spin up a new AndroidDriver... it read that the platformName is "Android".

[AndroidDriver] AndroidDriver version: 1.17.1
[BaseDriver] Session created with session id: 4bc8afe6-7aa5-4ac8-a42b-55890e777f6d
[AndroidDriver] Getting Java version
[AndroidDriver] Java version is: 1.8.0_121

  • Here we see that the Android Driver has finally been created! And the Appium Base Driver created a new session for it! 

[ADB] Checking whether adb is present
[ADB] Using adb from /Users/ventmahe/Library/Android/sdk/platform-tools/adb

  • What's ADB? It's the "Android Debug Bridge!", part of the command line tools in the Android Software Development Kit. I installed it as a package deal with Android Studio. Yes, technically you can download platform tools as a standalone toolset, but the Android Developers peoplr throw warning after warning that it is not and will not be supported...
"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 devices. It locates emulators by scanning odd-numbered ports in the range 5555 to 5585, the range used by the first 16 emulators. Where the server finds an adb daemon (adbd), it sets up a connection to that port [...]

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

"[...] 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". - Android Studio, ADB

[AndroidDriver] Retrieving device list
[ADB] Trying to find a connected android device
[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[AndroidDriver] Using device: emulator-5554

  • Oh! Good! It found my Android device, an Android emulator! 
  • It is as if it entered from the command line,  adb devices

[ADB] Checking whether adb is present
[ADB] Using adb from /Users/ventmahe/Library/Android/sdk/platform-tools/adb
[ADB] Setting device id to emulator-5554

  • Now, it is setting the device id it found, using adb. 
  • Hrm. Can it be assumed that if adb was there a split second ago, that adb is still present? 

[BaseDriver] Using local app '/Users/ventmahe/code/basic_appium_framework/ApiDemos-debug.apk'
[AndroidDriver] Checking whether app is actually present
[AndroidDriver] Starting Android session

  • The Appium Base Driver takes from the Desired Capabilities the path and name of the Android app, passes it to the Android Driver, which checks if the app is truly there.
  • It's there? Awesome! Android Driver starts a new Android session!

[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","wait-for-device"]

  • What are those args? Those arguments? 
  • -P: port. -s: serial_number.
  • Wait-for-device waits only as long as the arg daemon has properly started, then exists. 
  • ADB clients all listen to TCP Port 5037 to communicate with a server request.

[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","echo","ping"]

  • Is there a device still connected? Yes?
  • If so, let's start adb running, listening in at Port 5037 for any incoming Appium server messages, once again. 
  • "Shell" starts a remote interactive shell in the target device. From here, you can start various shell commands:

[Logcat] Starting logcat capture
"Logcat is a command-line tool that dumps a log of system messages, including stack traces when the device throws an error and messages that you have written from your app with the Log class [...]
"You can run logcat as an adb command or directly in a shell prompt of your emulator or connected device. To view log output using adb, navigate to your SDK platform-tools/ directory and execute":
adb logcat
-- Developer.Android.Studio / Command Line / LogCat

[AndroidDriver] Pushing settings apk to device...

  • Do we have any special settings to go with the apk? 

[ADB] Getting install status for io.appium.settings

  • IO.Appium.Settings is "a small and simple Android application that deals with the system settings. Then the application shuts down. [...] Toggle settings in Android device or emulator".
  • Official docs are

[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","pm","list","packages","io.appium.settings"]
[ADB] App is installed

  • Once again, we are getting connected devices. 
  • We are going to run the Android Debug Bridge from where Android Studio installed it on my local machine. 
  • What are the arguments? The port is 5037, where Appium has been set up to listen in. 
  • The serial number is set to emulator 5554, our emulator we have running. 
  • This time, though, as we go into the shell in the emulated device, we are going to make a call to the ADB Package Manager (pm) to list all packages. We want to see if io.appium.settings are there. 
  • Need help? Read Android Central and Ten Basic Android Commands You Should Know. 
From Developer.Android.Com / ADB: 

"Within an adb shell, you can issue commands with the package manager (pm) tool to perform actions and queries on application packages installed on the device. While in a shell, the syntax is:[...]  pm command
"You can also issue a package manager command directly from adb without entering a remote shell. For example:[...] adb shell pm uninstall com.example.MyApp

list packages [options] filter: Prints all packages, optionally only those whose package name contains the text in filter.

-f: See their associated file.
-d: Filter to only show disabled packages.
-e: Filter to only show enabled packages.
-s: Filter to only show system packages.
-3: Filter to only show third party packages.
-i: See the installer for the packages.
-u: Also include uninstalled packages.
--user user_id: The user space to query.

[ADB] Getting package info for io.appium.settings
[ADB] Getting connected devices...
[ADB] Checking whether aapt is present
[ADB] Using aapt from /Users/ventmahe/Library/Android/sdk/build-tools/23.0.1/aapt
[ADB] 1 device(s) connected

  • AAPT is the Android Asset Packaging Tool. 
$ aapt
Android Asset Packaging Tool

aapt l[ist] [-v] [-a] file.{zip,jar,apk}
List contents of Zip-compatible archive.

aapt d[ump] [--values] WHAT file.{apk} [asset [asset ...]]
badging Print the label and icon for the app declared in APK.
permissions Print the permissions from the APK.
resources Print the resource table from the APK.
configurations Print the configurations in the APK.
xmltree Print the compiled xmls in the given assets.
xmlstrings Print the strings of the given compiled xml assets.
  • "This tool is part of the SDK (and build system) and allows you to view, create, and update Zip-compatible archives (zip, jar, apk). It can also compile resources into binary assets". -
  • After getting the package info, checking it is there in the above step, we are going to use this tool to spy inside the package. 

[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","dumpsys","package","io.appium.settings"]
[ADB] Cannot read version codes of /Applications/ and/or io.appium.settings. Assuming correct app version is already installed

  • Hrm... settings_apk-debug.apk and/or io.appium.settings could not be found. I don't think I set up anything special. Maybe they can't be found because they are not there? 
  • Once again, we are using the Android Debug Bridge to go to the shell, and use the Android shell commands to investigate what is going on inside the emulator that is running. 
"Dumpsys System Diagnostics. [...] The dumpsys tool runs on the device and provides information about the status of system services. [...] If you run adb shell dumpsys, you’ll get diagnostic output for all system services, which is usually more than you want. For more manageable output, specify the service you would like to examine. For example, the following command:

"$ adb shell dumpsys input

"provides system data for input components such as touchscreens or built-in keyboards". - Source.Android.Com / DumpSys

[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","getprop",""]
[ADB] Device API level: 25

  • First step... make sure a connected device is running. 
  • Next step? Let's shell into the running emulator, entering it by port 5037, the Appium server, choosing emulator-5554.
  • This time, we are using the adb shell command "getprop" to investigate "". 

... Each Android device and emulator has a list of "build properties".

"Android has a single text file named 'build.prop' that determines lots of various system-wide settings on your device. You need root access to edit this file, since it’s stored on the system partition—but the various lines of codes it contains are actually easy to interpret and modify".

... Here, we are grabbing the root property "build version sdk", meaning, what version of operating system?

... It's API 25.

[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","dumpsys","package","io.appium.settings"]
[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","pm","dump","io.appium.settings"]

  • Still have an emulator? If so, let's do another adb shell script "dumpsys", looking for the particular package "io.appium.settings". 
  • Still have a emulator? If so let's use the adb shell script command package manger to do a "dumpsys" to take a look at the input output settings for Appium and throw it onto the screen. 
io.appium.settings is a "A small and simple Android application that deals with the system settings. Then the application shuts down." according to

[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","pm","grant","io.appium.settings","android.permission.WRITE_SETTINGS",";","pm","grant","io.appium.settings","android.permission.ACCESS_MOCK_LOCATION",";"]

  • Is the Android device connected? Here is where it gets good! 
  • This time, we are going to go to the device and use the shell script package manager to do something quite different... we are going to get READ AND WRITE PERMISSIONS! Are you excited? I'm excited! The Appium Server is now going to grant us permission to read and write files on the device. 
See all the WRITE_SETTINGS: Appium could have made our phone vibrate, answer a call, leave a voicemail, whatever. 

Instead we are going to grant to io.appium.settings to ACCESS_MOCK_LOCATION:
  • "Create mock location sources for testing or install a new location provider. This allows the app to override the location and/or status returned by other location sources such as GPS or location providers". - Android Permissions
... I know it has been a while... but I want to mention that the only way the Android Debug Bridge ("adb") has this power over our emulator or physical Android device because we gave it to adb.

"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 numberseven times. Return to the previous  screen to find Developer options at the bottom.
"On some devices, the Developer options screen might 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 theandroid_sdk/platform-tools/ directory. If connected, you'll see the device name listed as a 'device.'" - Developer.Android.Com / ADB

[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","pm","grant","io.appium.settings","android.permission.WRITE_SETTINGS",";","pm","grant","io.appium.settings","android.permission.ACCESS_MOCK_LOCATION",";"]

  • And we are going to do the exact same thing we did before... huh? 

[AndroidDriver] Pushing unlock helper app to device...

  • Appium has a helper app to unlock and "wake up" a device. See 
  • Since Appium now has been given read and write permissions, it can install the unlock helper app to your device, no problem. 

[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","install","/Applications/"]

  • There it goes! After being pushed onto your device, the helper app, unlock_apk-debug.apk, is now being installed.

[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","install","/Applications/"]

  • Um, and there it goes again, attempting to install appium-unlock? But it was just done!

[ADB] Application '/Applications/' already installed. Continuing.

  • Yes, we know it was already installed. Next! 

[ADB] Device API level: 25
[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","appops","set","io.appium.settings","android:mock_location","allow"]

  • Before, we had to get permissions to use MOCK_LOCATION? Now, we are setting it, with an Android adb shell script program called "appops". 
  • We had "pm", the package manager allows you to install and uninstall software "packages" (such as out Android apps).
  • Now, we have "appops" the App Operations manager that allows us to set the Android property "io.appium,.settings" mock location to "allow".  
"Create mock location sources for testing or install a new location provider. This allows the app to override the location and/or status returned by other location sources such as GPS or location providers". - Android Permissions

[ADB] Getting device platform version
[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","getprop",""]

  • What is the device platform version? First, let's check if we can get the connected device. It's all good?
  • Let's use the adb command, part of the Android Command Line tools, installed on our local computer as a packaged deal when I installed "Android Studio", the only way the Android Developers wanted it. 
  • We are going to communicate through port 5037 with our emulator, attached at "emulator-5554" and shell into the emulator.
  • The shell command Appium is using this time? Getprop. We are getting the Android emulator's root property build version release.

[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","wm","size"]

  • Same thing as above! We are using the shell program "wm" to get the size. "wm" is the windows manager. (Want to read more? See the section on "Display" in Developer.Android.Com

[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","getprop","ro.product.model"]
[ADB] Current device property 'ro.product.model': Android SDK built for x86

  • And now, Appium is checking through ADB the root product model. 
  • It finds the Android Software Development Kit was built for the x86 architecture, that is Intel's x86 (as apposed to the AMD chipset)

[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","getprop","ro.product.manufacturer"]
[ADB] Current device property 'ro.product.manufacturer': unknown

  • Who manufactured the device that is running? It is listed as unknown because it is an emulator. 

[AndroidDriver] Parsing package and activity from app manifest

  • What is a package? "A package is a namespace that organizes a set of related classes and interfaces. Conceptually you can think of packages as being similar to different folders on your computer. You might keep HTML pages in one folder, images in another, and scripts or applications in yet another. Because software written in the Java programming language can be composed of hundreds or thousands of individual classes, it makes sense to keep things organized by placing related classes and interfaces into packages". - Java Tutorials, What is a Package?
  • What is an activity? "An activity is a single, focused thing that the user can do. Almost all activities interact with the user, so the Activity class takes care of creating a window for you in which you can place your UI with setContentView(View). While activities are often presented to the user as full-screen windows, they can also be used in other ways: as floating windows (via a theme with windowIsFloating set) or embedded inside of another activity (using ActivityGroup)." - Developer.Android.Com / Activity 
  • What is the app manifest?

According to Developer.Android.Com / Manifest-Intro:

"Every application must have an AndroidManifest.xml file (with precisely that name) in its root directory. The manifest file provides essential information about your app to the Android system, which the system must have before it can run any of the app's code.
  • "Among other things, the manifest file does the following:
  • "It names the Java package for the application. The package name serves as a unique identifier for the application.
  • "It describes the components of the application, which include the activities, services, broadcast receivers, and content providers that compose the application. It also names the classes that implement each of the components and publishes their capabilities, such as the Intent messages that they can handle. These declarations inform the Android system of the components and the conditions in which they can be launched.
  • "It determines the processes that host the application components.
  • "It declares the permissions that the application must have in order to access protected parts of the API and interact with other applications. It also declares the permissions that others are required to have in order to interact with the application's components.
  • "It lists the Instrumentation classes that provide profiling and other information as the application runs. These declarations are present in the manifest only while the application is being developed and are removed before the application is published.
  • "It declares the minimum level of the Android API that the application requires.
  • "It lists the libraries that the application must be linked against".

[ADB] Checking whether aapt is present

  • Is the Android Asset Packaging Tool there? This aapt tool will help you view, create, and update your APKs.

[ADB] Using aapt from /Users/ventmahe/Library/Android/sdk/build-tools/23.0.1/aapt
[ADB] Extracting package and launch activity from manifest

  • Now we are going to examine the manifest for the package and launch activity.

[ADB] badging package:
[ADB] badging act:

  • In order to launch a package, we are going to need to know two things: The name of app package, and the app activity, just as when we were attempting to launch and app via Appium Desktop.

[AndroidDriver] Parsed package and activity are:

Found it!

  • App package:
  • App Activity:

[AndroidDriver] Remote apk path is /data/local/tmp/29649242b53e9a67ba855b067422713c.apk

  • Appium is going to take where APIDemos-debug.apk is located in our local computer, and upload it to our Android device (our emulator in this case) somewhere in a temporary directory. 
  • ADB has an "install" command which installs an apk onto a device. 

[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","ls","/data/local/tmp/29649242b53e9a67ba855b067422713c.apk"]

  • Adb now going to check that it is there, accessing the emulator through port 5037, on device emulator-5554, using the Unix shell command "ls", listing the directory, and checking that the apk is there.  

[AndroidDriver] Checking if app is installed
[ADB] Getting install status for
[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","pm","list","packages",""]
[ADB] App is installed

  • As a belt-and-suspenders approach, Appium is checking if the app is truly installed by shelling into the emulator-5554 using the package manager to list all packages to make sure that is listed on the device. And it is! 
[AndroidDriver] Apk is already on remote and installed, resetting
[AndroidDriver] Running fast reset (stop and clear)
[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","am","force-stop",""]

  • Something must be wrong with the Appium code. It looks like the app is installed and running twice? 
  • For the second instance we are doing a "force-stop", stopping the app from running. 

[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","pm","clear",""]

  • Now, we are going to clear the app's cache using the Package Manager. The app data has been stored in the cache for easy retrieval, and must be erased.

[AndroidDriver] Extracting strings from apk /Users/ventmahe/code/basic_appium_framework/ApiDemos-debug.apk undefined /var/folders/0h/hf79m7zj1xz1hdk0m3t091v8221rx6/T/

  • Now, we are extracting strings in the manifest xml. Not sure what this means

[ADB] Extracting strings for language: default
[ADB] Device API level: 25
[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","getprop","persist.sys.locale"]
[ADB] Current device property 'persist.sys.locale':

  • As we start extracting the contents of the manifest.xml file, we found that the language has been set to be "default" and the operating system is API level 25.
What is locale? How can you set it through the command line?

From ProfWeb / Setting the Locale:
"The locale (language and country) may be set using the Settings button in the Launcher, choose Language & Input it will immediately change the interface language [...]
"Note: You can only do this if you are either using an AVD or you have rooted your device [...]
Modification can only be done if you have root access so on an AVD or a rooted device. To see the current information:
  • "getprop persist.sys.language
  • "getprop"

[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","getprop","ro.product.locale"]
[ADB] Current device property 'ro.product.locale': en-US

  • Now, we are using adb for grabbing from root the value of the root property, product locale. It is listed as "en-US".
  • "en-US" is the language code for "English - United States" given by the Internet Engineering Task Force (IETF) language tag.
Note that we can have:
  • en-GB: British English
  • en-US: American English
  • en-CA: Canadian English
  • en-IN: Indian English
... Each has its own pronunciations, spellings.

Want to drown in information? Read BP47: Tags for Identifying Languages, on

[ADB] No strings.xml for language 'en', getting default strings.xml

  • Why would there be no strings.xml? What does this mean? 

[ADB] Reading strings from converted strings.json

  • Eh?

[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","push","/var/folders/0h/hf79m7zj1xz1hdk0m3t091v8221rx6/T/","/data/local/tmp"]

  • The app activity is at /var/folders/0h/hf79m7zj1xz1hdk0m3t091v8221rx6/T/
  • We are going to push this into a temporary file /data/local/tmp. 

"Use the pull and push commands to copy files to and from an device. 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 a device". - Developer.Android.Com / ADB
  • Why does Appium do it this way, with a "push" of the directories, instead of an "adb install TheApk.apk"?

[AndroidBootstrap] Watching for bootstrap disconnect

Next, we are going to talk about AppiumBootstrap.
  • If you want to create a really quick Android app, you can use AndroidBootstrap at, whose sourcecode is at

  • Android Bootstrap uses Appium-ADB which defaults to port 4724. It allows us to perform all adb operations on android device and then some.

[ADB] Forwarding system: 4724 to device: 4724
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","forward","tcp:4724","tcp:4724"]

  • Here, we are setting up port forwarding, for appium to listen to what is happening on the emulator.
  • Readying Android Bootstrap! 
  • Appium-Android-Bootstrap according to Appium's GitHub documentation, is a "JavaScript interface, and Java code, for interacting with Android UI Automator. The system allows ad hoc commands to be sent to the device, which are executed using Android's UIAutomator testing framework".
[UiAutomator] Starting UiAutomator

From Developer.Android.Com / Testing-Libraries / UI Automator:

"The UI Automator testing framework provides a set of APIs to build UI tests that perform interactions on user apps and system apps. The UI Automator APIs allows you to perform operations such as opening the Settings menu or the app launcher in a test device. The UI Automator testing framework is well-suited for writing black box-style automated tests, where the test code does not rely on internal implementation details of the target app.
"The key features of the UI Automator testing framework include:
  • A viewer to inspect layout hierarchy. For more information, see UI Automator Viewer.
  • An API to retrieve state information and perform operations on the target device. For more information, see Access to device state.
  • APIs that support cross-app UI testing. For more information, see UI Automator APIs .
  • Requires Android 4.3 (API level 18) or higher.

[UiAutomator] Moving to state 'starting'
[UiAutomator] Parsing uiautomator jar
[UiAutomator] Found jar name: 'AppiumBootstrap.jar'

  • UIAutomator signals that it is starting on your local machine. 
  • It is searching through the UIAutomator java archive file (like a zip file, but for Java).
  • It is looking for AppiumBootstrap's jar file. 

[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","push","/Applications/","/data/local/tmp/"]

  • We are now pushing the directory structure and files for Appium Bootstrap onto the emulator, using ADB into the /data/local/tmp temporary file on the emulator. The UIAutomator will now run, one instance on the emulator or actual device, and one on the computer where Appium Server is running.

[ADB] Attempting to kill all uiautomator processes

[ADB] Getting all processes with uiautomator
[ADB] Getting connected devices...
[ADB] 1 device(s) connected
[ADB] Running '/Users/ventmahe/Library/Android/sdk/platform-tools/adb' with args: ["-P",5037,"-s","emulator-5554","shell","ps"]
[ADB] No uiautomator process found to kill, continuing...
  • ADB is making sure no other uiautomator processes are running on the emulator or actual device it just pushed the UIAutomator to. If there are leftovers from previous attempts run, we don't want them interfering. 
From Developer.Android.Com / Testing-Libraries / UI Automator: "The UI Automator testing framework provides a UiDevice class to access and perform operations on the device on which the target app is running. You can call its methods to access device properties such as current orientation or display size. The UiDevice class also let you perform actions such as:
  • "Change the device rotation
  • "Press a D-pad button
  • "Press the Back, Home, or Menu buttons
  • "Open the notification shade
  • "Take a screenshot of the current window"

[UiAutomator] Starting UIAutomator
[ADB] Creating ADB subprocess with args: ["-P",5037,"-s","emulator-5554","shell","uiautomator","runtest","AppiumBootstrap.jar","-c","","-e","pkg","","-e","disableAndroidWatchers",false,"-e","acceptSslCerts",false]

  • Did it work? Did pushing UIAutomator and Appium Boostrap work? Can we now, finally, have the Appium Server controlling what is on the actual Android device or (in this case) emulator?
  • We are going to connect to the emulator once again, using adb shell, but this time we are

This post first appeared on Adventures In Automation, please read the originial post: here

Share the post

What happens behind the scenes as Appium installs and launches an Android app? Examining and footnoting a log file.


Subscribe to Adventures In Automation

Get updates delivered right to your inbox!

Thank you for your subscription