ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #08844
Re: Programmatically unlocking Unity for testing
Michael Terry [2014-07-02 9:21 -0400]:
> I helped move the logic out of phablet-tools into unity8-autopilot. I
> wanted to be able to change the script as split greeter landed without
> phablet-tools caring about the implementation. And the QA folks seemed
> happy to have less unity8 logic in phablet-tools itself too.
Yes, moving logic out of phablet-tools into the phone itself is
generally the right direction IMHO. But again, the logic is now in a
package which isn't installed by default. Also, the current
helper.unlock() thing is really involved -- it needs autopilot,
emulates a swipe, etc. This is of course fine for testing unity itself
-- but for everything else (app testing) we don't care about that. We
just want to get the phone from "virgin install" to "we can start an
app and test it" with the least possible effort and potential breakage
as possible.
So I think there ought to be a simple way (D-BUS call, flag file,
etc.) to either disable the greeter (and then have to restart unity),
or unlock it with a D-BUS call (not a security issue, you are already
logged into the device anyway).
> Before I messed with it, the scripts were already rebooting before
> unlocking. I believe to ensure a clean environment. But with split
> greeter, you actually do need a reboot (well technically just a lightdm
Why is that? I don't want to restart the whole session, just unity8
within the session. Or possibly not even that.
> - Relying on external additional dependencies introduces another
> > point of potential breakage.
> >
>
> I actually considered that fact that it came from unity8 a benefit, because
> phablet-tools doesn't have to care about internals of unity8 greeter setup.
Right. But remember that we want to get away from changing the phone
to r/w and apt-get installing packages. We can probably make
unity8-autopilot work with autopkgtest's "apt-get download, unpack,
and set $*_PATH" approach for readonly; I haven't tried that yet, but
TBH I think this is a very brittle path and about 1000 times more
effort than what should be necessary to get the lock screen away.
> Not today. There is a DBus signal that will slide away the greeter, but
> won't actually unlock if you have a password set. So I don't think that's
> what you want.
That seems fine, at least as long as we don't ship the phone by
default to require a password. So I think it actually might be what I
want :-)
Thanks,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Follow ups
References