Unlocking the emulator or device for Android test

Question

I am writing Android functional tests. I need the device to be awake and the application to be visualized in order for them to work. I have consulted with Android developers for that. However, there are several problems with the proposed solution:

• The proposed method now has several deprecated methods. Android API now advises me to use flags on the window:

This class was deprecated in API level 13. Use FLAG_DISMISS_KEYGUARD and/or FLAG_SHOW_WHEN_LOCKED instead; this allows you to seamlessly hide the keyguard as your application moves in and out of the foreground and does not require that any special permissions be requested. Handle returned by newKeyguardLock(String) that allows you to disable / reenable the keyguard.

I tried this suggestion, however, as opposed to the deprecated solution, the flag one jsut does not work for me - it does not unlock the device. I also found sources confirming the instability of the flag solution (e.g. the comments on this answer).

• The second problem is that I need to add permissions to the application under test. I find this as quite wrong approach (modifying the code under test in order to be able to test it). I found several places that advise me to use src/debug/AndroidManifest.xml for that (this one and this one for example). However, it just not happen as stated - the debug Mainfest does not get included to the deployed things on the device. Is it related to the way I build and deploy? I use Eclipse for development (ADT). Will this manifest injection work only if I use build tool like ant?

---

All in all - can somebody advise on a stable solution for unlcoking and keeping awake the device while my test are being executed?

EDIT

I have now found that Robotium also included unlockScreen method in their latest version of the framework. It uses exactly the window flags proposed above and is also not working on my device.

Answer 1

I had similar troubles with both the deprecated and the new methods. Eventually, I ended up with this hack, simply sending an upwards swipe gesture to unlock:

KeyguardManager keyguardManager = (KeyguardManager) InstrumentationRegistry.getContext().getSystemService(Context.KEYGUARD_SERVICE);
if (keyguardManager.isKeyguardLocked()) {
  UiDevice device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation());
  int x = device.getDisplayWidth() / 2;
  int startY = device.getDisplayHeight();
  int endY = 0;
  device.swipe(x, startY, x, endY, 50);
}

It relies on the particulars of the lock screen, but it works surprisingly well so far.

Answer 2

So far only thing that's working for me is to launch wake device script right before testing. Script unlocks device from cli by sending key events to all devices. Unlocking part is important in my experience, some devices won't allow you to unlock them from cli (you still need to swipe), in that case I recommend to look after "no lock" app on Google Play, it should help but may not work on all devices.

I am working on Gradle plugin that would do the same right before running instrumentation tests during Gradle build process.

Answer 3

I've had the same problems with unreliable unlocking when running Robotium tests. I did not find a solution to programmaticly unlock devices that worked reliably, but there are two things that I did as a work-around.

• Just disable the lock screen (Settings -> Security -> Screen lock -> None). Not ideal but at the end of the day, reliable tests are the important thing.

• Enable "Stay Awake" settings to keep the screen from turning off due to inactivity (Settings -> Developer options -> Stay awake). Some OEM/phones either don't have that option or still turn off anyways, so for those pesky devices I installed the KeepScreenOn app.

Warning: leaving the screen on, sitting on the home screen, for 24 hours a day may cause some screen burn-in/ghosting. I'm not sure if this is permanent, but be aware of this. In our case, we were using dedicated test devices so it was not a big deal.

Also note that since the phones will have their screen on at all times, you may want to dim the brightness to use less battery power (charging over USB can be slow sometimes).

Answer 4

Instance of UiDevice has wakeUp() method

This method simulates pressing the power button if the screen is OFF else it does nothing if the screen is already ON. If the screen was OFF and it just got turned ON, this method will insert a 500ms delay to allow the device time to wake up and accept input.

However it is not known to me that similar method exist for unlocking screen so my current solution is to remove lock pattern (Set to NONE on testing device)