Develop Reference

Android: The right way to debug an running application (runtime errors/log)

I am new to Android development. I have been going through the tutorials.
I would like to know which is the right way to debug / log an application during its execution. I am guessing I should be able to execute my application directly on my android device and be able to view a log or so to catch runtime errors and logs?
How could I accomplish this ?
I am using this to install the application on my phone
adb install <path to apk>
p.s. I am sure this question might seem like something I should already know. But I could not figure it out :) Hence I am here :)

You can build on the command line with ant. See this guide.
& install it by using adb on the command line.
adb install MyApp.apk
path of apk with file extension
update
for getting logcat or crash report
do this way:
adb logcat
note: make sure only one device is connected to adb bridge
for filtering:
check this & this.

Pass adb options/parameters to android gradle tasks (install, connectedCheck, etc)

In the Android gradle plugin there are options for aapt and dex but I can't find where I can pass parameters to the adb used by tasks such as install and connectedCheck (and any other that would use adb to complete).
My problem is that I want to pass the -H flag pointing to a remote adb. The use case is to run my tests on a remote machine (and then maybe, machineS). I believe this was possible with Android Maven plugin but I want to do it in Gradle now.
I have access to both machines and have tested that I can list and install a package using the -H flag but it seems like that android-gradle is hard coding 127.0.0.1.
If anyone has a working example of running the tests on different adb hosts could you please share it here?

I ran into the same issue and found a working solution by setting the environment variable ANDROID_ADB_SERVER_ADDRESS. I discovered it by digging through the adb source code.
You can see it also checks for ANDROID_ADB_SERVER_PORT and ANDROID_SERIAL if you need to change either of those too.

I'm facing the same problem. This guy wrote a java app (linked in the third comment to the post) that forwards adb connections to a remote adb server. This might be a workaround?

Interface Android robotium testing with Teamcity

As this was not answered (Maybe did I not find it) previously, I investigated on the following question :
How to perform automated functional tests on Android devices with robotium, and report them to continuous integration server like TeamCity?

As I did not find any answer on that specific question, I investigated. Here is the output of my investigation and a quick How-To in order to help people perform automated functional tests on Android applications using robotium, and then report the results to a continuous integration server like TeamCity. Please note that this may not be the best solution, but I felt that people might be in the same situation as me. So here it is !
The following libraries have been used :
Robotium (https://code.google.com/p/robotium/) : This is an Android test automation framework. It helps you to perform automated tests like click on buttons, fill text automatically, and a lot of other things.
Android Junit Report
(http://zutubi.com/source/projects/android-junit-report/) : This library is very useful to publish test result to an exploitable xml format. If you want to run your tests through Eclipse, you will see the results of your tests on the go, but in order to export them, this library is very useful
Assuming that you have an Android project to test, create an Android Test Project (Eclipse does have a nice workflow to create it for you) and set it up to work with Robotium. A pretty clear detailed instruction on how to do it can be found here : https://code.google.com/p/robotium/wiki/Getting_Started
Then, you need to add Android Junit Report to your project in order to be able to fetch the results of your tests. In order to do so, add the Android Junit Report *.jar library in your lib folder and add it to your build path (in Eclipse : Project -> Properties -> Java Build Path -> Libraries -> Add External Jar).
You also have to change the test runner of your project. In the AndroidManifest.xml of your test project add the following :
<instrumentation
android:name="com.zutubi.android.junitreport.JUnitReportTestRunner"
android:targetPackage="<insert your package ex:com.alth.myproject" />
Once this is done, you should be able to run your tests properly. The results of the tests should be available in your device (in the following folder /data/data//files/junit-report.xml)
The next step is to configure your TeamCity build steps to perform all the different needed action to run your tests. Please note that my solution might not be the optimal one !
Build step 1 : Clean - Command Line runner - This build step may be optional depending of how you decide to create your build.xml files and such build decisions.
rm -rf <report folder>
rm -rf <Project build.xml>
rm -rf <Test project build.xml>
android update project -p <Path to your project>
android update test-projecct -m <Path to your project, relative to the test project> -p <Path to your test project>
Build step 2 : Launch AVD - Command Line runner - This build step launches the android virtual device. This step may be optional if you decide to run the tests on an actual device.
emulator -avd <nameOfYourAvd> -no-boot-anim &
sleep 45
The & avoids build to be interrupted by the virtual device launch (It is basic shell command). The sleep command is used to try to let the AVD be ready for the next build step
Build step 3 : Test app release - Ant runner : Build the test project, install it on the virtual device
Path to build xml file : <Path to your test project>/build.xml
Additional Ant command line parameters : -f <Path to your test project>/build.xml clean debug install -Dsdk.dir=<Path to your android sdk>
Build step 4 : AVD Unlock - Command line runner : Unlock the AVD screen for testing purpose
bash avdUnlock.sh
Body of avdUnlock.sh here : (http://pastie.org/7919761). This script is sending informations on regular AVD port in order to unlock the screen. This may be improved by sending the command only to a specific port and changing build step 2 to add a specific port to the emulator launch. This is however not really part of this how-to
Build step 5 : Launch tests - Command line runner : Launch the tests
adb shell pm list instrumentation
adb shell am instrument -w <insert your test package ex:com.alth.myproject.test>/com.zutubi.android.junitreport.JUnitReportTestRunner
The first adb command could be removed. This is only for debug purpose in order to see which instrumentation has been installed on the device.
Build step 6 : Fetch tests - Command line runner : Retrieve tests report from the device
adb pull /data/data/<insert your project package ex:com.alth.myproject>/files/junit-report.xml <report folder>/junit-report.xml
Build step 7 : Final emulator kill - Command line runner : Kill the running android virtual device
adb emu kill
Additional Build Features : XML report processing - Report type : Ant JUnit
Monitoring rules : <report folder>/*.xml
This How-to is clearly not optimal but answer the original question. Doing so, it is possible to fetch the android functional tests report and feed it to teamcity in order to monitore test results.
I hope this will help someone, and I would try to answer to your questions if you have some.
Al_th

Perl Script to run Junit test cases and unistall apk

What I want my Perl script to do is..
Run the specific Junit test cases from windows command line.
Uninstall the Apk file from android device or emulator.
I am having difficulty in getting started with 1.For step2 , I guess I can use
adb uninstall package name
Thanks.

You don't have to launch eclipse to run junit test cases.
Try running the Junit tests through script using command line.
More information here. http://www.jsystemtest.org/?q=node/44

Why does MonkeyRunner fail when called using TeamCity

I have a monkeyrunner script that connects to an Android device and deploys an APK on it.
serial = '12345JKL'
device = MonkeyRunner.waitForConnection(deviceId=serial)
device.installPackage(path_to_apk)
This works flawlessly when I execute the script using the Windows command shell.
"C:\dev\android\tools\monkeyrunner.bat" "C:\dev\my_script.py" -psome_parameter
The problem is that I want to have my_script.py executed by a TeamCity (Enterprise 6.0.3) build configuration on the same PC: this fails.
Please find the stack trace here: http://pastebin.com/CjWy95c3
First I thought that TC was messing with the parameters of the script. But the command from the TC build log
[00:55:12]: Starting: "C:\dev\android\tools\monkeyrunner.bat" "C:\dev\my_script.py" -psome_parameter
in directory: C:\some_dir
was the same as in the command shell and accordingly the script could connect to the device and worked fine when I copied the command into a command shell while C:\some_dir was my current directory.
I was not able to reproduce this error outside of TC.
I want to emphasize that this all happens on the same PC (Win 7 x64). The script works when executed from the command shell but fails (always when trying to connect to a device) when triggered by the TC build configuration.
I can't think of a reason why this happens and would be very happy if somebody could point me in the right direction.
Many thanks in advance
Edit: As it turns out the problem isn't limited to MonkeyRunner.waitForConnection() but also occurs when calling MonkeyRunner.sleep(5). Stacktrace
Can it be that MonkeyRunner and TeamCity don't go along well with each other?

This is probably caused by a problem with your imports. The problem with your imports is likely because of the way that TeamCity calls MonkeyRunner. I would guess that it has to do with the current directory being messed up. Try using
import os
os.chdir("path")
to change your current directory at the top of your .py script. (Before you import monkeyrunner) I would try changing it to the directory with MonkeyRunner.

After a colleague and I have investigated the problem for three days, we could not find the source of this problem. But when we used another machine as the build agent, the issue was gone. We still don't know what caused this NullPointerException.