I would need to be able to take screen dumps for testing, and with ICS there is now a screen shot function, that can be invoked by pressing (and holding) volume down and power button.
Is there any way to script this function through adb? (As I understand it there's no public java API for it). I have tried to use KeyEvent from java to emulate power and volume button, and I have tried to use adb keyevent and adb sendevent without success. I suspect that the power button also generate some low level calls that are not generated with the above methods.
So do anyone know if it is possible to call the function from adb?
If this is not possible, do someone know where in the source code this screen shot function exist? Maybe I can figure something out by reading it.
update
source code for capture the screen is in "frameworks/base/services/surfaceflinger/services/surfaceflinger/SurfaceFlinger.cpp" in a function called screenCapture. I do not know if it is possible to call it from jni, but I will try, because it would be great if I could take a screen shot through java.
Otherwise, #edthethird had a solution through android.amberfog.com/?p=168 that will make it possible to take a screenshot with the commandline.
Thank you for the help everyone!
In the form of adb commands, the following works on ICS devices:
adb shell /system/bin/screencap -p /sdcard/img.png
adb pull /sdcard/img.png img.png
See: http://a-more-common-hades.blogspot.com/2012/01/screenshot-command.html
Well this has nothing to do with ICS, but in eclipse, look at a Devices tab. There is a tiny little camera icon on the far right. (From right to left, it is "box", "line", "upside down triangle", and "camera". Click on this camera to take a screen shot of the currently selected device.
This works on any version of Android, not only ICS.
See this question:
Screenshot of the Nexus One from adb?
Basically you can pull the framebuffer using adb and convert it into a usable image yourself, or you can just use the command line utility provided by Google. Looking round I think you may need to tweak that utility a little to get it to work on newer versions of Android.
As the other answer points out though, its probably less hassle to just do this from Eclipse, unless you're trying to automate testing.
After looking into the source code, there is a library that does exactly what I want.
frameworks\base\cmds\screencap\screencap.cpp
The program can be executed on android by /system/bin/screencap .
So it is possible to execute in Java on android by Runtime.getRuntime().exec();
A drawback is that you need a special certificate for taking screenshots.
Related
I am running calabash-android test for an android application. I need to attach images and videos to a particular section. I can reach the gallery section and after that, I could not select an item from the device library. Is there any way to keep a copy of video and image in my test directory and access the whenever needed? Or is there any solution to access the gallery. And one more thing is that I am integrating the test on Circle-ci later. And I don't know how can I manage it when it is on Circle-ci. All kind of help is appreciated.
Calabash only has access to your app, not anything outside of it.
You will be able to put together a solution using adb to interact with the screen, using touch or keyboard events. However, this will be tied to one specific screen size, as it's done by pixels.
adb shell input tap x y
You could put the images/videos in the directory so they are the most recent, then use adb touch events to select them? It's a bit hacky but it should work.
If I've understood your question correctly, the circle ci part should probably be split out into another question, as it isn't really tied to the previous bit.
EDIT: We ended up getting it to work by running
`adb shell input tap 200 200`
Using DDMS via Eclipse or through Monitor, it will take the screenshot, but when you copy to clipboard. You can't do anything with it. Gimp, Inkscape, LibreOffice don't recognise what is in the clipboard.
The save option is not that good because the quality it uses to save the png is awful. This makes it difficult to create good quality screenshots for your app. Because of the high resolution of devices the window of the captured screen goes outside the bounds of the desktop/workspace so you can't use a take a screenshot of that window.
Is there another trick to getting around this, like being able to change quality setting ddms saves images? or using adb shell to take screenshots. Is there a screen capture tool in Linux that can take screenshots across workspaces.
ATM I am taking two screenshot one for each workscape the window is on and then using GIMP to line up the images, this takes time, and it is frustrating.
Yes you can take screen shot using adb shell as
adb shell /system/bin/screencap -p /sdcard/img.png
It will be in your sdcard of emulator you can push it out to system ...
I think the above code works from ICS .
I know this question is ask number of times but wait i am asking something different.
I follow this post and able to take screen shot. but is it possible to take screen shot when my application is closed.
Supposed i set timer like after 1 hour and i close my app. Then exactly after 1 hour device need to take a screen shot whatever on a screen.
Is this possible with Background Services?
I already follow code and also did some research but is this possible?
Is it necessary to root device to take screenshot.
Please give me any hint or reference.
Thanks in advance.
Try using : call the methods in this library from service.
http://code.google.com/p/android-screenshot-library/
Android Screenshot Library (ASL) enables to programmatically capture screenshots from Android devices without requirement of having root access privileges. Instead, ASL utilizes a native service running in the background, started via the Android Debug Bridge (ADB) once per device boot.
DeveloperGuide
UPDATE:
The method mentioned in your reference will not work in that case, as it reads the view that are drawn and in application context. where as if application is closed then you cant get that context.( at-least on non rooted phone).
On rooted device you can read complete frame-buffer so no need to worry about the application context.
I did tried to use the ASL once and it worked out good for me.
I am testing an Android application with Sikuli, but each time the test runs the behaviour is different:
the test stops at the first command, not finding the first image
finds only some images and the test stops at a particular image which isn't found
finds all images and the test runs successfully
Sikuli is runned on Windows 7. Does anyone know if it's a problem of focus or something else and how to solve it?
Thanks
Maybe you can fix your recognition issue by changing the matching level. From Sikuli Gui :
Click on the image
In Pattern Settings > Matching Preview, drag the Similarity bar to a value below 1.0 (try different values)
You may also need to add a delay for the browse button to appear on the screen. You could try something like this
wait("Browse.png", 10 ) # Wait for up to 10s for the app to load
You might also try increasing the size of the picture that you are matching to. Try including nearby artifacts. Remember that you can change the location on the picture that is the mouse click point if your Browse button is not dead centre.
You can try any click action twice, using a try/except block.
Sometimes the vision algorithm just fails.
Running the Android Emulator (for anything) is paaaainffullly sloooow and arbitrary.
So, it pays with Android ems to make Sikuli statements a little "smarter,"
like this:
wait(browsebutton.png, 20)
onAppear(browsebutton.png, click(browsebutton.png))
Looks busier, but it makes the script "smart" in both waiting for the button, and then clicking it as soon as it appears (instead of waiting twenty seconds if it appears after five).
While debugging my app using Monkey (which is almost as fun as the real thing), I managed to crash! Yay, that's what it's for, right?
Looking at the log (and while watching) I noticed that Monkey is occasionally doing:
:Sending Flip keyboardOpen=true
which seems to be part of my problem. When this happens, the screen in the emulator rotates 90 degrees, but this is NOT the same as a regular rotation you get by hitting KEYPAD_7. Here's a picture:
It looks to me the emulator is emulating a keyboard opening (flip), which is subtly different from a rotation.
So the question is: How do I emulate that myself? Sure, running Monkey is neat, but waiting for it to randomly choose to send a keyboardOpen message is no way to debug a program.
Maybe use the --pct-majornav to restrict the monkey to just the 'major' nav events (I'm assuming keyboard changes are 'major', I'm not sure though).
You could also look into writing a specific test based on the different but similar monkeyrunner framework: http://developer.android.com/guide/developing/tools/monkeyrunner_concepts.html ... but I don't see any way to inject keyboard flip codes.
I found this relevant SO question:
Simulating opening/closing the hardware keyboard in emulator but the "answer" there is confusing and seems insufficient.
Not really your question, but related to your root issue:
Did you forget to include 'keyboardHidden' in the 'android:configChanges' section of the manifest file? (Or did you include it, but you don't handle the config change callbacks?)
The keyboard hide/reveal will restart your activity. You can either declare that you handle that restart, or if you don't, the OS will stop and restart the app itself.
See http://developer.android.com/guide/topics/resources/runtime-changes.html
Update
I believe this is the source for the monkey application's keyboard flip event. It looks like injecting a keyboard flip event would be relatively straight-forward: Open /dev/input/input0 and write 16 magical bytes into it.
Also, the source seems to have an undocumented --pct-flip option for controlling keyboard flip rates: link