feat: consider NotificationShade and StatusBar as lock screen for newer android versions

[KazuCocoa]

I think we should relax locked screen condition logic for newer Android devices.
https://github.com/appium/appium-adb/blob/master/lib/tools/adb-commands.js#L615-L632

Newer Android devices (i tested a few real devices), lock screen is simply NotificationShade or StatusBar after keycode 62. But current our logic does not consider such case as locked screen. So, our lock never be succeeded.

When these app is focused, Appium can unlock them with https://github.com/appium/appium-android-driver/blob/9d120ba76df18ada8c5793af3d42f9b1aa4937cb/lib/android-helpers.js#L648-L679 , so I think we can consider NotificationShade and StatusBar as part of isShowingLockscreen.

(at least, an Android 7.1 real device had mShowingLockscreen. Haven't checked with android 8 and 9.)

[mykola-mokhnach]

should we be more restrictive about .+NotificationShade and .+StatusBar regexps to avoid false positives?

[mykola-mokhnach]

for example .+\sNotificationShade\b

[KazuCocoa]

ah, could be to tune the regex. Let me try.

[mykola-mokhnach]

also would it be possible to split this long line? Maybe we could simply move the regexp itself into constants, which should also speed up the API call

[mykola-mokhnach]

I was also checking some finding regarding screen locked state. We could also test if solutions from https://stackoverflow.com/questions/35275828/is-there-a-way-to-check-if-android-device-screen-is-locked-via-adb work for us

[KazuCocoa]

Yea, i tried some stuff like power. But for example adb shell dumpsys power | grep 'mHolding' was both true in both lock/unlcok in devices when the device's screen was one. ( I checked this behavior with a few nexus devices and a samsung device)
NotificationShade and StatusBar are the most reasonable way to consider possible lock/unlock (at least after power on button)...

[mykola-mokhnach]

Yes, I saw some comments about the output there is not very reliable. What if we check the NFC state first and fall back to this method if it is disabled?

Something like:

1. adb shell dumpsys nfc | echo FAIL
2. if FAIL is printed then fall back to the current method
3. Otherwise check if the output contains mScreenState=\w+UNLOCKED

[KazuCocoa]

The nfc command returned outputs but it did not have mScreenState in my checked devices before..

Oh, I just found Screen State: ON_UNLOCKED. No mScreenState tho.

adb shell dumpsys nfc | grep 'Screen State'
Screen State: ON_UNLOCKED

It was ON_LOCKED or OFF_LOCKED when that was locked.
No unlocked word in the nfc output, so potentially we can check only ON_UNLOCKED or _UNLOCKED match.

Let me check more devices

[mykola-mokhnach]

Btw, this is how the check is implemented in Android itself: https://android.googlesource.com/platform/packages/apps/Nfc/+/refs/heads/master/src/com/android/nfc/ScreenStateHelper.java#32

[mykola-mokhnach]

Also, how Google checks if the device screen is ready in internal tests: https://android.googlesource.com/platform/cts/+/ab9e203328a3edc5c40c5887bfc5bc8e9ba92769/tests/app/src/android/app/cts/ActivityManagerProcessStateTest.java#159

[KazuCocoa]

Thanks, I dug in dumpsys focusing on keyguard. Then, it seems the below condition is the most reliable.
mIsShowing=false && mInputRestricted=false

They existed since Android OS 6. I haven't checked on OS 5 tho. Non smart phone like Android TV did not have it.

So, the primary is current way -> fallback to this keyguard is the most reliable so far, I think.

• unlocked

    KeyguardServiceDelegate
      ....
      KeyguardStateMonitor
        mIsShowing=false
        mSimSecure=false
        mInputRestricted=false
        mCurrentUserId=0
        ...

• locked

    KeyguardServiceDelegate
      ....
      KeyguardStateMonitor
        mIsShowing=true
        mSimSecure=false
        mInputRestricted=true
        mCurrentUserId=0
        ...

[mykola-mokhnach]

Please add an indentation here to enhance the readability. The comment also makes sense