this issue allready made me some headache before I found the answer.
Using Windows
telnet localhost 5554
event send EV_KEY:KEY_MENU:1 EV_KEY:KEY_MENU:0
quit
Using Linux:
echo "event send EV_KEY:KEY_MENU:1 EV_KEY:KEY_MENU:0" | nc -q1 localhost 5554
Please keep in mind that you only can unlock the screen on a fresh
started emulator.
So your test should be in this order: 1. Start emu, 2. Unlock screen
3. Run robotium tests
This is not working if you have an allready running emulator and then
lock it to see if this works.
This detail kept me busy for hours before found out. Somehow the
solution seamed to work only sometimes unless I figured this out.
Hope I was able to help.
Regards,
Miroslav Simudvarac
--------------------------------------------
Simvelop GmbH
Wilhelmstr. 40
65582 Diez, Germany
Phone +49 6432 50 82 70
Fax +49 6432 80 09 621
Web www.simvelop.de
Mail in...@simvelop.de
Bankverbindung
Volksbank Limburg
BLZ 511 900 00
Kto.Nr.: 518 211 06
Registergericht Montabaur HRB 22502
Sitz der Gesellschaft ist Diez a.d. Lahn
Geschäftsführer:
Miroslav Simudvarac
> --
> You received this message because you are subscribed to the Google Groups "Robotium Developers" group.
> To post to this group, send email to robotium-...@googlegroups.com.
> To unsubscribe from this group, send email to robotium-develo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/robotium-developers?hl=en.
>
>
Regards,
Miroslav Simudvarac
--------------------------------------------
Simvelop GmbH
Wilhelmstr. 40
65582 Diez, Germany
Phone +49 6432 50 82 70
Fax +49 6432 80 09 621
Web www.simvelop.de
Mail in...@simvelop.de
Bankverbindung
Volksbank Limburg
BLZ 511 900 00
Kto.Nr.: 518 211 06
Registergericht Montabaur HRB 22502
Sitz der Gesellschaft ist Diez a.d. Lahn
Geschäftsführer:
Miroslav Simudvarac
That's suspiciously identical to an answer I posted on StackOverflow a
long time ago :)
However, I updated that answer[1] earlier this year to give an improved
solution that I discovered. As it's using "adb shell" rather than the
emulator telnet interface, it should work on both emulators and devices:
adb shell input keyevent 82
Alternatively, if you're running your tests in Hudson or Jenkins
continuous integration servers, the Android Emulator Plugin[2] will
automatically unlock the screen for you after its emulator has started up.
Regards,
Chris
[1]: http://stackoverflow.com/questions/3214531/#3366443
[2]: http://wiki.jenkins-ci.org/display/JENKINS/Android+Emulator+Plugin
A few thoughts inline:
On 18/03/11 22:56, Manoj Pahuja wrote:
> Thanks a lot for all the feedback from everybody (this group is
> great )and options for achieving this task. I was able to use all the
> options for achieving this task some or the other way. So here is my
> summary for future references:
>
> 1. If you are the developer or have access to the code of the
> application under test then the best and the easiest way of achieving
> this is using:
> http://developer.android.com/guide/topics/testing/activity_testing.html
>
> KeyguardLock keyguardLock =
> ((KeyguardManager)keyguardService).newKeyguardLock(TAG );
>
> if (enable) {
> keyguardLock.reenableKeyguard();
> } else {
> keyguardLock.disableKeyguard();
> }
> return true;
> }
In my opinion this is a nasty solution as it requires you to include an
extra permission in your application -- one that virtually no
application will need.
As you mention, you should remove this, but people forget: I've seen a
few apps released on the Market that still have this permission
included, when it really should have been removed.
If you can *automatically* only include this permission for test builds,
or automatically remove the permission when doing a release build, then
fine.
> 2. Second best method is to use adb shell commands to unlock it at
> boot of the emulator. The actual code would differ depending upon what
> method you use to call these commands. This of course has the
> limitation that it can be run only at the first start up of the
> emulator, once the emulator has started this command would do nothing.
You can run the "adb shell" command as often as you like. On the first
startup, it will open the Android menu, which should be harmless. On
each subsequent startup, it will press Menu, which will unlock the
screen, as desired.
> 3. Third method is telnet into the emulator and then use the EV_KEY to
> unlock it.
> telnet localhost 5554
> event send EV_KEY:KEY_MENU:1 EV_KEY:KEY_MENU:0
> quit
> You can put this in a bat or shell file and call it from your test to
> unlock the Home screen. This again has the limitation of being able to
> unlock at only the first boot and cannot be used to unlock the Home
> screen after the first boot.
This seems backwards. The home screen is not locked when you start an
emulator for the first time.
In any case, I wouldn't recommend this at all, since we have the more
reliable "adb shell" solution above. Which also should work on real
devices.
> 4. Fourth option is to use maven to unlock it.
> http://issues.hudson-ci.org/browse/HUDSON-7185
> This is very useful for CI purposes but is limited by inability to
> unlock the screen from eclipse. So if you are writing your tests in
> Eclipse you have to run the tests using command prompt if you need to
> unlock the screen.
Clarification: that bug report is about the Android Emulator plugin for
Jenkins/Hudson, and not Maven. The Maven solution mentioned there just
uses the "telnet" option above.
Finally, a further option is to use Android emulator snapshots.
Introduced in Android SDK Tools v9, the emulator now supports saving the
current state of the emulator (similar to other virtualisation products
like VMware).
So you could start the emulator once, so that it becomes unlocked, then
shut it down. Starting the emulator subsequently will immediately load
up a clean emulator with the screen unlocked (so long as you do not save
emulator state at shutdown (i.e. the "--no-snapshot-save" option).
BTW, this snapshot functionality will be automated and included in the
next release of the Android Emulator Plugin for Jenkins/Hudson.
Regards,
Chris