Added option to keep the screen on

[franga2000]

Implements a setting that keeps the screen on and the app above the keyguard when displaying a barcode (as discussed in #287).

(I noticed my previous PR was on an old version so this is the same but rebased to master)

Signed-off-by: Miha Frangež<miha.frangez@gmail.com>

[brarcher]

From experimenting with the change on an emulator, it seems that the FLAG_KEEP_SCREEN_ON alone does the trick, even when I configured a lock screen. What do the other two flags add, and why are they necessary?

[franga2000]

The first flag just makes the screen not turn off automatically.

The other two flags make the lock screen not appear over the app's window, even if the user turned off the screen manually. @sphh described it quite well in #287.

Double-checking this in the docs just now, I found that DISMISS_KEYGUARD is not strictly required (I really should stop writing code from memory!). It only affects insecure keyguards (i.e. swipe to unlock) and causes the phone to remain unlocked when closing the window. This is, if nothing else, inconsistent with the behavior on secured devices, so I'll remove it.

[brarcher]

Thanks for the change.

Do you think it would be possible to test this change in Robolectric? There are tests for this activity in LoyaltyCardViewActivityTest. There are a few tests which set settings. I've not tested window flags before to see if they are set, but I'm expecting it is possible. Could you look into adding a simple test?

[franga2000]

I doubt the kind of testing that Robolectric does would be of much use here. From what I've read about it, the best we could do is test whether the flags were actually set, but that would effectively just test whether the Window.addFlags method works.

A more interesting test would be whether the actual functionality of "screen doesn't time out" and "window stays above lock screen" works, but that would require something that runs on a full system. UIAutomator might be able to do it, but I'm not 100%.

[brarcher]

I doubt the kind of testing that Robolectric does would be of much use here. From what I've read about it, the best we could do is test whether the flags were actually set, but that would effectively just test whether the Window.addFlags method works.

I think that a Robolectric test would ensure that the behavior of setting/clearing the setting has the expected behavior on the Window's flag. I'd count that as a success! The UI Automator would be more interesting, however the test setup I have for the project does not easily support running an emulator, so I'd like to avoid that path if possible.

Is it OK to add a Robolectric test for the setting, showing that the Window flags are set as expected?

[franga2000]

Ok. I'll add in the following week when I get back to by workstation.