Is it possible to create some kind of scripting with Genymotion?
I know there is shell commands, but I also need to simulate user touch (using adb input).
The idea is to create some simple test for my app, where the script will execute certain shell commands and adb as well.
Thanks
As Genymotion VMs are considered as a physical device by ADB, you can use MonkeyRunner.
This tool, provided by Google allows you to send touches events among other things.
You can script, using Python many inputs. Look at this gist, coming from this StackOverflow post, it gives good example for a complete gesture.
Related
I'd like to know if you have any references or tips to debug faster on real Android devices. I have a set of bash scripts to iterate rapidly over builds and signals, but sadly i waste a lot of time testing text inputs. I could hard-code but I am looking for a solution that is more universal between teams and projects. Typing directly on the device I am debugging would save me tons of time.
Do you know a way to achieve this using any tool or app?
Thanks
Some answers here partially solve my current answer:
ADB Shell Input Events
I guess we could create a software utility on a terminal to write from there to the phone and then we'd be done.
I'm trying to script a tap and hold on an Android device and I haven't worked out how.
I tried playing with the input command options but couldn't find anything relating to holding.
I've also looked at MonkeyRunner and could succesfully get the desired effect from a computer with the Android device connected, but couldn't run monkeyrunner on the device itself, without a computer.
Is there a way to script a tap and hold/tap down only/long tap on an Android device (I'm just using the shell for now) ? If so how ?
There are several ways to inject events. You can use Robotium or Monkeyrunner for testing. Or you can try to inject events directly this way.
Actually, there is no screencap utility out of box in Amazon Kindle Fire HD. Id'like to install it to /system/bin/ via adb to call from the command line (still via adb) at the moments when I need to have a screenshot and logcat is not enough to attach the to bug description.
There are some descriptions how to use screencap utility for such purpose: http://habrahabr.ru/company/intel/blog/152122/
(see
adb shell screencap /sdcard/screen.png
adb pull /sdcard/screen.png screen.png
adb shell rm /sdcard/screen.png
)
However, it seems that my device uses Android 2.3 Gingerbread, so there is no screencap utility out of box. So, the question are 1) Is there a way to push screencap of other Android versions to /system/bin/ 2) where I can download it online?
Other approaches working with adb shell are welcome.
I don't know exactly if this will help you, but I once happened to find out several other ways of capturing a screenshot. From what I know, they do not depend on the screencap but rather on the ADB daemon. All of them require your device to have USB debugging turned on.
I would really suggest trying this simple utility out: http://www.roman10.net/a-program-for-taking-screenshot-for-android-device-from-command-line/ which essentially reimplements the DDMS screenshot functionality without the whole GUI. It automatically writes it on your computer so there's no need for push/pull. It's pure Java so it's a great bonus.
Scroll down to the download section where you can download just the binary and test it out.
Another method would be to use MonkeyRunner described here: http://developer.android.com/tools/help/monkeyrunner_concepts.html. All you need to do is write a simple script which captures the screen, which is shown on the page from the link.
Unfortunately I don't know if android-tools-adb provides MonkeyRunner.
Another tool is Android Screenshots and Screen Capture: http://sourceforge.net/projects/ashot/
It just needs the Android SDK installed and I suspect it runs on the same principle as DDMS or the first program - from Roman10.
Hope that helps!
I am wondering if someone know what AT Commands are ? i tried to look further on Google but nothing is usefull.
Thank you.
As in the Hayes modem control commands? These are the commands used to gain the *AT*tention of a modem and cause it to interact with the phone system and/or computer (to test, read, set and execute commands). A tutorial can be found here: http://www.engineersgarage.com/tutorials/at-commands
AT commands are commands sent to control dial-up modems.
AT commands are the commands given to modem from the application side to get it's ATtention and execute commands. Please note that the AT commands may differ from device to device depending upon the manufacturer.
And as you have asked specifically for android, so follow the link too know how to send AT commands to Android.
Don't get confused when you see search results for AT commands but got the results for Hayes Commands, the AT commands are part of the Hayes commands.
Also you can find many good resources in the internet for AT commands in general. But again search carefully as the AT commands may differ from device to device.
I was using earlier adb to debug Android applications over wifi, usb - it was great.
Right now I am wondering if it is possible to connect phone with adb via bluetooth.
I did a quick research but didn't find anything - have you tried it already ?
It is not supported by the current adb software, however you could probably make it possible if you have a rooted device (or possibly even if not - see below) either by modifying adb or by using bluetooth to tunnel a channel it does support, such as tcp.
You would need to obtain the source for the adb program - the same source is used to build both the PC and the device versions. First step is to just build it with unmodified functionality, which may take a fair amount of build system modification unless you do so as a part of a complete android source build (the way it was intended to be done)
Then you would modify it to add a bluetooth channel as an option and install it on the device (why you need root) and in your path on the PC. You'd think you could run it from an alternate location on the PC, and you likely can as long as you use it from the command line, but if your fire up DDMS it may kill off the running adb server and launch a new one using the default in the path, so ultimately you'll have to put your modified version there.
IF you can already get your device to accept adb connections over tcp (possible with root, perhaps possible in some cases without) there is another option, which is to not modify ADB (or at least not modify the device side) and instead come up with something running on the device which accepts bluetooth connections and forwards the traffic via local loopback to the tcp port on which the stock adb is operating. This would save the trouble of having to rebuild adb.
If you have some kind of tethering or similar network-over-bluetooth solution, you might even be able to leverage that to carry adb-over-tcp-over-bluetooth without writing any code.
Finally note that it is not 100% essential that the adb daemon run as a more privileged userid or be installed in place of the official one - you can run an adb daemon as an ordinary application and do many of the expected things with it. However, whichever adb daemon is running first will grab the unix domain java debug socket, and so only that adb daemon will be able to provide the full java debug services. More primitive things like logcat, shell, running process list, push/pull, etc will at least partially work without this, provided that your adb daemon doesn't quit (modification may be required) when it is unable to claim the debug socket. If you can kill the official adb daemon and exploit a race condition, you may be able to get an unofficial one started before it restarts - you would probably need to have a script or program to do this and run it with setsid from the official adb shell, meaning you'd need to connect via USB first. At that point, you'd also be able to start your unofficial adb daemon running as the same userid as the official one.
You may want to spend some time estimating or testing if the performance (speed) will be satisfactory before investing in a lot of time setting this up for real.
I know this is a bit old but I seem to have found a post that does this. All credit goes to the author of fomori.org for finding this and making the information available. Today it helped me, maybe tomorrow I'll help you by making it easier to find.
Source