AndroidViewClient
AndroidViewClient copied to clipboard
dtmilano
device.wake() toggles screen
With adbclient, the device.wake() command presses the power button, toggling the sleep/wake state of the screen. If the screen is awake already and you issue device.wake() the screen will go to sleep.
This is an issue because I often want to ensure that the screen is awake prior to taking a screenshot (otherwise, you get a blank screenshot). As is, I don't think there is a method to determine if the screen is awake.
I have two thoughts on this:
(1)
Perhaps look into sending the wake event like ChimpManager does (http://androidxref.com/4.3_r2.1/xref/tools/swt/chimpchat/src/main/java/com/android/chimpchat/ChimpManager.java#376). This approach ultimately writes "wake\n" to a socket connection to the monkey daemon on the device. Looking through AndroidViewClient's AdbClient script, does this talk to only ADB on the host (the PC the script runs on) or does AdbClient also talk to the device's monkey daemon directly? Talking to the monkey daemon directly may be valuable. I think I have some proof-of-concept code for this if you want it.
(2)
This method could use adb shell dumpsys power and look at the mWakefulness attribute. This may vary from device to device, but on my Nexus 7 it returns "Asleep" if the device is asleep and "Awake" when the screen is on already.
The commands abd shell input keyevent 82 and adb shell input keyevent 26 are the relevant ones in this case. It appears that they have different functionality depending on the Android version you are running [Reference: http://android.stackexchange.com/questions/40916/unlock-screen-with-adb-android-4-2]
On my Nexus 7 running 4.2.2 I observed the following:
If the screen is awake, input keyevent 82 unlocks a locked screen and opens the menu if the screen is already unlocked.
If the screen is not awake, input keyevent 82 does nothing.
On the other hand, input keyevent 26 wakes and sleeps the screen. When the screen goes to sleep, it is locked if a lock screen is enabled in Settings.
On an HTC Incredible running 2.3.7, I observed the following:
If the screen is awake and unlocked, input keyevent 82 opens the menu and input keyevent 26 sleeps and locks.
If the screen is awake and locked input keyevent 82 does nothing and input keyevent 26 sleeps
If the screen is not awake (and locked) neither command does anything.
I'm trying to avoid as much as possible the connection with monkey. I like your idea of using dumpsys power, I give it a try.
I am trying to do a IsScreenOn() function in order to call wake() only if the screen is off. So far, I found that "dumpsys power" has mScreenOn variable but on my GalaxyS2 it stays always on so it's not universal. "dumpsys window policy" had 3 variables that seems to toggle depending on the screen state (mScreenOnEarly, mScreenOnFully and mOrientationSensorEnabled). This seems to work on my GalaxyS2, Nexus5 and on the emulator (4.4).
I had a similar problem and was able to solve it using the below script. The device I was using was set to swipe to unlock, hence the "swipe" action in there. But you can change that depending on the type of lock you have set or remove it all together if you don't have the lock screen enabled.
result="$(adb shell dumpsys input_method | grep -c "mScreenOn=true")"
if [ "$result" == 1 ]; then
echo "Screen is already on."
else
echo "Turning screen on."
adb shell input keyevent 26
sleep 2
adb shell input swipe 900 1100 200 1000 150
fi
Hope that helps! Cheers.
Is AdbClient.isScreenOn() returning a wrong value in your case?
If yes, what's the device, android version, etc.
No, I didn't even use that. I just meant I had faced a problem of trying to get the screen's status and then performing some action based on it. This is the script that worked for me. Sorry if I misunderstood the question.
Update - Derp. I didn't even notice this was about a specific topic. I was searching for something else and found this and thought perhaps I might actually be able to help, but I was wrong. Sorry. Feel free to delete my comments as they are off topic.
