Merge lp:~doanac/phablet-tools/unlock_screen into lp:phablet-tools

[Andy Doan]

add option to phablet-test-run for unlocking the screen

This allows a user to pass "-u" to phablet-test-run. The
unlock_screen.py utility will be copied to the target and
then run right before executing the autopilot testsuite.

We've disputed where to put this in the past, but as we near the end of the release, we need a way to run tests with the screen unlocked. I've copied the unlock_screen.py script that the CI team inherited into the branch. Its mostly un-modified, but I did fix some pep8 complaints.

This adds a new "-u" option to phablet-test-run to unlock the screen.

[Sergio Schvezov (sergiusens)]

do we really need to rm this way?
108 + os.system('rm -f /tmp/mir_socket')

Can't we have unity use the env setup? This shouldn't be a problem once the autopilot tests for unity8 are fixed anyways, so I'm ok with it for now, but doing it with os.system instead of open?
101 + override_file = "~/.config/upstart/unity8.override"
102 +
103 + os.system(
104 + 'echo "exec unity8 -testability" > ~/.config/upstart/unity8.override')

Can't we make unlocking the default action?
21 + -u Unlock the greeter before running the testsuite

review: Needs Fixing

[Sergio Schvezov (sergiusens)]

Adding Saviq to the review; I read somewhere that he was going to detect app launch with upstart and unlocking automatically

[PS Jenkins bot (ps-jenkins)]

PASSED: Continuous integration, rev:209
http://jenkins.qa.ubuntu.com/job/phablet-tools-ci/212/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/phablet-tools-saucy-amd64-ci/155
    SUCCESS: http://jenkins.qa.ubuntu.com/job/phablet-tools-saucy-armhf-ci/155
    SUCCESS: http://jenkins.qa.ubuntu.com/job/phablet-tools-saucy-i386-ci/156

Click here to trigger a rebuild:
http://10.97.0.26:8080/job/phablet-tools-ci/212/rebuild

review: Approve (continuous-integration)

[Andy Doan (doanac)]

> do we really need to rm this way?
> 108 + os.system('rm -f /tmp/mir_socket')

was just copy/pasting the original. i'll fix that.

>
> Can't we have unity use the env setup? This shouldn't be a problem once the
> autopilot tests for unity8 are fixed anyways, so I'm ok with it for now, but
> doing it with os.system instead of open?
> 101 + override_file = "~/.config/upstart/unity8.override"
> 102 +
> 103 + os.system(
> 104 + 'echo "exec unity8 -testability" >
> ~/.config/upstart/unity8.override')

yeah, that's terrible. I'll fix.

> Can't we make unlocking the default action?
> 21 + -u Unlock the greeter before running the testsuite

I started with that approach. Given how close we are to the end, I thought this would offer the best chance of not causing a regression. If you are +1, then I'll make it default.

[lp:~doanac/phablet-tools/unlock_screen]

210. By Andy Doan on 2013-10-15

review comments from sergio for unlock_screen.py

211. By Andy Doan on 2013-10-15

make phablet-test-run default to unlocking the screen

also clean up the usage text so it displays properly on 80 columns

[PS Jenkins bot (ps-jenkins)]

PASSED: Continuous integration, rev:211
http://jenkins.qa.ubuntu.com/job/phablet-tools-ci/214/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/phablet-tools-saucy-amd64-ci/157
    SUCCESS: http://jenkins.qa.ubuntu.com/job/phablet-tools-saucy-armhf-ci/157
    SUCCESS: http://jenkins.qa.ubuntu.com/job/phablet-tools-saucy-i386-ci/158

Click here to trigger a rebuild:
http://10.97.0.26:8080/job/phablet-tools-ci/214/rebuild

review: Approve (continuous-integration)

[Michał Sawicz (saviq)]

The plan is that we should restart unity8 under testability and use an emulator from the unity8 suite to do this, directly in app tests.

We might build most of that *into* the unity8 emulator, like you would import it, tell it to unlock, and it would do the things it needs (restart unity8 under testability, introspect it and use stuff maintained by unity8 to unlock).

Otherwise we'll end up with 10 places unlocking unity8, none of which are reliable or the unity8 team has control over.

review: Disapprove

[Andy Doan (doanac)]

On 10/15/2013 05:26 PM, Michał Sawicz wrote:
> The plan is that we should restart unity8 under testability and use an emulator from the unity8 suite to do this, directly in app tests.

I'm all for that, but until now hadn't been given an indication this was
going to happen. Is there a bug or something I can subscribe to for
updates on progress for this?

[Christopher Lee (veebers)]

Hi Andy,

You're right this has been talked about but nothing has happened yet. I think right now this should change :-)

I've filed this bug: https://bugs.launchpad.net/unity8/+bug/1240261

I'm currently working on it now, hopefully I should have something useful pretty soon.

[Christopher Lee (veebers)]

Andy,

I put this together today: https://code.launchpad.net/~veebers/unity8/adding_unlock_emulator/+merge/191328

The intention being that you consume these functions (namely unlock_unity and restart_unity_with_testability) in the unlock script (both here and any other script that does something similar i.e. Utah (and I think there is another CI one?).
This means that lines 117 - 181 aren't copied about in n-many scripts.

I'm not 100% certain this fits exactly Saviqs vision (i.e. done within the test app), I'll touch base with him in his morning and clarify then.

Let me know if you have any questions or suggestions.

Chris

[Michał Sawicz (saviq)]

On 16.10.2013 06:53, Christopher Lee wrote:
> I'm not 100% certain this fits exactly Saviqs vision (i.e. done within the test app), I'll touch base with him in his morning and clarify then.

I'm OK with that, even though this still means each test setup needs to
call those explicitly - but at least the unity8 team is owning this and
will know in case things break.

[Andy Doan (doanac)]

On 10/15/2013 11:53 PM, Christopher Lee wrote:

> The intention being that you consume these functions (namely unlock_unity and restart_unity_with_testability) in the unlock script (both here and any other script that does something similar i.e. Utah (and I think there is another CI one?).
> This means that lines 117 - 181 aren't copied about in n-many scripts.
>
> I'm not 100% certain this fits exactly Saviqs vision (i.e. done within the test app), I'll touch base with him in his morning and clarify then.
>
> Let me know if you have any questions or suggestions.

Sounds like there are three ways we could consume this code:

1) call these two functions from phablet-tools
2) modify all our autopilot tests to call this (or a common base class
if possible).

I'm guessing we don't have time to accomplish 2 before we release. So do
we want to try 1 or just keep pushing for 2?

-andy

[Christopher Lee (veebers)]

Hi Andy,

Yep those make sense to me. I'll get https://code.launchpad.net/~veebers/unity8/adding_unlock_emulator/+merge/191328 approved/merged and we can go ahead with option 1 as soon as that's done.

We/I can this start working on making it consumable within the ap tests themselves etc.

[Sergio Schvezov (sergiusens)]

On Wed, Oct 16, 2013 at 4:24 PM, Andy Doan <email address hidden>wrote:

> On 10/15/2013 11:53 PM, Christopher Lee wrote:
>
> > The intention being that you consume these functions (namely
> unlock_unity and restart_unity_with_testability) in the unlock script (both
> here and any other script that does something similar i.e. Utah (and I
> think there is another CI one?).
> > This means that lines 117 - 181 aren't copied about in n-many scripts.
> >
> > I'm not 100% certain this fits exactly Saviqs vision (i.e. done within
> the test app), I'll touch base with him in his morning and clarify then.
> >
> > Let me know if you have any questions or suggestions.
>
> Sounds like there are three ways we could consume this code:
>
> 1) call these two functions from phablet-tools
> 2) modify all our autopilot tests to call this (or a common base class
> if possible).
>
> I'm guessing we don't have time to accomplish 2 before we release. So do
> we want to try 1 or just keep pushing for 2?
>

I had a similar response to this that I wiped earlier. The problem with 2
is, once we test on desktop and desktop is unity8 and you run locally you
are going to end up killing your own session. So first we have to make sure
this doesn't happen.

[Omer Akram (om26er)]

I have a branch that calls the unity8 provided helpers to make sure the screen is unlocked. Also I had a chat with thomi and he believes that the unlocking logic should not be used inside each App' test suite and external tools like phablet-test-run should take care of that.

https://code.launchpad.net/~om26er/phablet-tools/unlock_screen/+merge/195529

Unmerged revisions

211. By Andy Doan on 2013-10-15

make phablet-test-run default to unlocking the screen

also clean up the usage text so it displays properly on 80 columns

210. By Andy Doan on 2013-10-15

review comments from sergio for unlock_screen.py

209. By Andy Doan on 2013-10-15

add option to phablet-test-run for unlocking the screen

This allows a user to pass "-u" to phablet-test-run. The
unlock_screen.py utility will be copied to the target and
then run right before executing the autopilot testsuite.

208. By Andy Doan on 2013-10-15

add unlock_screen.py utility for target device

=== modified file 'phablet-test-run'
--- phablet-test-run	2013-09-25 14:39:02 +0000
+++ phablet-test-run	2013-10-15 19:17:48 +0000
@@ -24,19 +24,25 @@
 NOSHELL=0
 RETVAL=0
 VERBOSE=""
+UNLOCK_SCREEN=1
 
 print_usage() {
     cat << EOF
-usage: $0 [-s SERIAL] [-s] [-n] [-v] [-p PACKAGENAME] [-c PACKAGE] [-o DIR] [-a ARTIFACT] testsuite
+usage: $0 [-s SERIAL] [-s] [-n] [-U] [-v] [-p PACKAGENAME] [-c PACKAGE] [-o DIR] [-a ARTIFACT] testsuite
 
   Run the specified testsuite on the device
 
   -s SERIAL        Device serial number
-  -p PACKAGENAME   Additional package to be installed, may be used multiple times
-  -c PACKAGE       Copy and install local package to device, may be used multiple times
+  -p PACKAGENAME   Additional package to be installed, may be used multiple
+                   times
+  -c PACKAGE       Copy and install local package to device, may be used
+                   multiple times
   -n               Stop the shell during the test run
   -o DIR           Test report and artifacts output dir
-  -a ARTIFACT      Artifact to fetch after the test, may be used multiple times (requires -o)
+  -a ARTIFACT      Artifact to fetch after the test, may be used multiple times
+                   (requires -o)
+  -U               By default the greeter is unlocked before a test runs. This
+                   disables that logic.
   -v               Run autopilot with -v option for more verbose output
 EOF
 }
@@ -86,8 +92,16 @@
     exec_with_adb_user initctl start unity8
 }
 
+unlock_screen() {
+    adb push /usr/share/phablet-tools/target/unlock_screen.py /tmp/
+    exec_with_adb_user python /tmp/unlock_screen.py
+}
+
 run_test() {
     exec_with_adb chmod 666 /dev/uinput
+
+    [ $UNLOCK_SCREEN -eq 1 ] && unlock_screen
+
     # adb shell always returns 0, so we have to do some hackery to get the
     # actual RC from the test
     {
@@ -123,7 +137,7 @@
     fi
 }
 
-while getopts a:c:hno:p:s:v opt; do
+while getopts a:c:hno:p:s:Uv opt; do
     case $opt in
     a)
         ARTIFACTS="$ARTIFACTS $OPTARG"
@@ -137,6 +151,7 @@
         ;;
     n)
         NOSHELL=1
+        UNLOCK_SCREEN=0
         ;;
     o)
         RESULTDIR=$OPTARG
@@ -147,6 +162,9 @@
     s)
         ANDROID_SERIAL=$OPTARG
         ;;
+    U)
+        UNLOCK_SCREEN=0
+        ;;
     v)
         VERBOSE="-v"
         ;;

=== modified file 'setup.py'
--- setup.py	2013-09-23 01:43:32 +0000
+++ setup.py	2013-10-15 19:17:48 +0000
@@ -26,6 +26,9 @@
         author_email='[e-mail]',
         license='GPLv3',
         packages=find_packages(exclude=("tests",)),
+        data_files=[
+            ('share/phablet-tools/target', ['target/unlock_screen.py']),
+        ],
         scripts=PYTHON_SCRIPTS + SH_SCRIPTS,
         test_suite='tests',
     )

=== added directory 'target'
=== added file 'target/unlock_screen.py'
--- target/unlock_screen.py	1970-01-01 00:00:00 +0000
+++ target/unlock_screen.py	2013-10-15 19:17:48 +0000
@@ -0,0 +1,92 @@
+#!/usr/bin/env python
+
+from autopilot import introspection
+from autopilot.display import Display
+from autopilot.input import Pointer, Touch
+import dbus
+import os
+import sys
+
+
+def help():
+    print("""Usage:
+Run the script without any argument to unlock with assertion
+
+option -q:
+Execute with parameter -q to unlock the screen quickly without introspection.
+""")
+
+
+def _rm(path):
+    if os.path.exists(path):
+        os.unlink(path)
+
+
+def start_unity_in_testability():
+    override_file = os.path.expanduser("~/.config/upstart/unity8.override")
+
+    with open(override_file, 'w') as f:
+        f.write("exec unity8 -testability\n")
+
+    print("Stopping Unity")
+    os.system('/sbin/stop unity8')
+    _rm('/tmp/mir_socket')
+
+    print("Taking screen lock (#1235000)")
+    bus = dbus.SystemBus()
+    powerd = bus.get_object('com.canonical.powerd', '/com/canonical/powerd')
+    powerd_cookie = powerd.requestSysState(
+        "autopilot-lock", 1, dbus_interface='com.canonical.powerd')
+    print("Starting Unity with testability")
+    os.system('/sbin/start unity8')
+    print("Releasing screen lock (#1235000)")
+    powerd.clearSysState(powerd_cookie, dbus_interface='com.canonical.powerd')
+
+    _rm(override_file)
+
+
+def unlock_screen():
+    input_device = Touch.create()
+    pointing_device = Pointer(input_device)
+    conn = "com.canonical.Shell.BottomBarVisibilityCommunicator"
+    unity8 = introspection.get_proxy_object_for_existing_process(
+        connection_name=conn)
+    greeter = unity8.select_single("Greeter")
+    x, y, w, h = greeter.globalRect
+    tx = x + w
+    ty = y + (h / 2)
+
+    pointing_device.drag(tx, ty, tx / 2, ty)
+    try:
+        greeter.shown.wait_for(False)
+    except AssertionError:
+        print("THE SCREEN DIDN'T UNLOCK THE FIRST TRY, NOW ATTEMPTING "
+              "A BLIND SWIPE")
+        unlock_screen_blind(greeter)
+
+
+def unlock_screen_blind(greeter=None):
+    input_device = Touch.create()
+    pointing_device = Pointer(input_device)
+    x, y, w, h = Display.create(preferred_backend='UPA').get_screen_geometry(0)
+    tx = x + w
+    ty = y + (h / 2)
+
+    pointing_device.drag(tx, ty, tx / 2, ty)
+    if greeter is not None:
+        try:
+            greeter.shown.wait_for(False)
+            if greeter.shown is False:
+                print("THE SCREEN IS NOW UNLOCKED")
+        except AssertionError:
+            print("THE SCREEN DIDN'T UNLOCK, RESTART THE DEVICE AND RUN "
+                  "THE SCRIPT AGAIN")
+
+
+if len(sys.argv) >= 2 and sys.argv[1] == '-q':
+    unlock_screen_blind()
+elif len(sys.argv) >= 2 and sys.argv[1] == '-h':
+    help()
+else:
+    start_unity_in_testability()
+    unlock_screen()