after starting a new app cannot get proxy object for unity8

[Omer Akram]

I am writing integration tests that make sure tapping on the OSD 'accept' button opens the dialer app (more similar tests as well). The problem is that my tests run fine for the first time, but if try to run the test the second time it fails because it seems that after dialer-app is started I cannot get autopilot interface for unity8.

To reproduce this problem

1. Ensure unity8 is running with the testability driver:
      stop unity8 ; initctl set-env QT_LOAD_TESTABILITY=1 ; start unity8
2. Download the attached python script
3. push it to the phone's /home/phablet
4. run it and it will print the unity8' Notification object
5. Now start any random app (keep it open or close it)
6. execute the python script again

You will see the below error and after a wait of many seconds the Notification object will indeed be printed

ERROR:dbus.proxies:Introspect error on :1.604:/com/canonical/Autopilot/Introspection: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
<autopilot.introspection.dbus.Notification object at 0x1c32c90>

[Thomi Richards (thomir-deactivatedaccount)]

Hi,

I'm able to reproduce the delay, but you get a proxy object in the end, so I'm not sure what the problem is here. Is it just that things take a bit longer?

We can take a look at why it's taking longer, but unless this is critical, I doubt we'll get to it in the next few days.

[Omer Akram (om26er)]

Yes the problem is the delay, its not a small delay, takes 20-30 seconds. Let me explain the case here, we have an automated script which makes a dummy call to our phone but there is a limited time till the incoming call keeps ringing and we can only pick the call if we have access to the unity8 object but due to this bug the incoming call dialog is missed.

One workaround would be change the incoming call script to wait for a longer time but I believe that source is not what we (Canonical) develop, so getting changes there can be a pain.

Another thing is that we are not writing a single test, rather I am going to write few more cases as well and we may need to workaround this bug for other test cases as well.