unlock method didn't work

[haradreborn]

Hello, my .py script contains following code:

import fmbttizen, time
d = fmbttizen.Device()
d.enableVisualLog("device.html")
d.pressHome()
time.sleep(1)
d.refreshScreenshot()
if d.verifyBitmap("lock.png"):
d.swipeBitmap("lock.png", "east")
time.sleep(1)
d.pressHome()

My lock.png is a static central part of my lockscreen.png. When I run this script, my device is turn on and off (after 5 secpnds) then nothing happens, script was finished. It looks like this script don't have anough time to unlock the screen, because if I tap Back button to prevent tuning screen of - it works (but without any animation). How can I solve this?

[askervin]

There may be a couple of reasons why opening the screen lock does not work.

First, you may want to extend screen lock timeout. This is probably a good idea even if it would not solve this problem. For instance, keep display on up to five minutes of inactivity:

d.setDisplayBacklightTime(5 * 60)

Second, the first screenshot may not be from the lockscreen. You can check from device.html what graphics were actually received on the screenshot taken on the 6th line of your code. Check out the screenshot after refreshScreenshot() on device.html:

chromium device.html

If the screenshot is not from the lockscreen, time.sleep(1) on line on the 5th line is not long enough, you'll need to make it longer.

If the screenshot is from the lockscreen, the next question is if "lock.png" is recognised on it. If d.verifyBitmap("lock.png") returned False (see the next item on device.html), then it was not recognised. The reason may be in color palette or rendering differences. These can be overcome by giving an extra OIR (optical image recognition) parameter to verifyBitmap method. For instance, try d.verifyBitmap("lock.png", colorMatch=0.8). If extra parameters are really needed, it's convenient to write them to .fmbtoirrc file in the same directory where lock.png is located, so you do not need to write them everywhere in the test code. An example of .fmbtoirrc file with OIR parameters that are pretty robust against rendering/palette differences, but that is still very reliable (false positive matches are highly unlikely):

colorMatch = 0.9
bitmapPixelSize = 2
screenshotPixelSize = 2

If "lock.png" is successfully recognised on the lockscreen screenshot, then pretty much the last things that may go wrong is that the location of "lock.png" on the screen, and the distance of the swipe gesture. swipeBitmap("lock.png", "east") swipes from the middle of the "lock.png" area until the right edge of the display. Here's a reference bitmap that I used on Tizen 2.2 on my d.swipeBitmap("lockscreen-lock.png", "east") call:

...and you can adjust the distance of the swipe with the "distance" parameter. For instance,

d.swipeBitmap("lock.png", "east", distance=0.9)

swipes from the middle of the bitmap, towards the right edge of the display, and raises the "finger" after 90 % of the whole distance has been travelled.

Please let me know if you got the problem solved with these tips!

[haradreborn]

Thanks, d.setDisplayBacklightTime(5 * 60) works ok, and an image lock.png wasn't recognized, you was right. I have different lockscreen, and I think that for me it would be easy to swipe on the "Charge" word - is there any place where I can learn about API usage, that isn't presented in the tutorial?

[askervin]

I've just added an overview of fMBT GUI testing APIs here:

https://github.com/01org/fMBT/wiki/GUI-testing

Depending on the font, background and a bit of luck, this may work for you:

d.swipeOcrText("Charge", "east")

Unfortunately, OCR is quite unreliable, and sometimes you'll need magic like

d.swipeOcrText("Charge", "east", match=0.5)

to find a match. To make the test faster and more reliable, it's probably better to use a reference bitmap "charge.png" that contains the label.

[askervin]

Closing the issue.

[haradreborn]

Thanks!