[TIMOB-26382] Android: "appc run" should dismiss screen-lock before running built app
| GitHub Issue | n/a |
|---|---|
| Type | Improvement |
| Priority | Medium |
| Status | Reopened |
| Resolution | Unresolved |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | Android |
| Labels | android, build, cli, run |
| Reporter | Joshua Quick |
| Assignee | Joshua Quick |
| Created | 2018-09-11T20:33:43.000+0000 |
| Updated | 2018-10-23T21:16:20.000+0000 |
Description
*Summary:*
When doing an "appc run" to an Android device with the screen powered off or the screen-lock shown, the app will be ran in the background. The Android device will not automatically turn on the screen and dismiss the screen-lock. Ideally, it should.
*Reason:*
UI events such as "postlayout" will not occur in an Android app while it is running in the background. This is especially an issue for automated testing.
*Recommended Solution:*
Google recommends to invoke the "menu" key to dismiss the screen-lock for automated test.
https://developer.android.com/studio/test/monkeyrunner
We can do this via the "adb" command line as follows. Note that we need to invoke the "menu" key twice. Once to power on the screen (if off) and a second time to dismiss the screen-lock.
adb shell input keyevent KEYCODE_MENU
adb shell input keyevent KEYCODE_MENU
PR (master): https://github.com/appcelerator/titanium_mobile/pull/10318
FR Passed. Waiting for CR.
PR Merged.
Just a quick note because I was a bit confused and found this ticket: When I compile an app now (latest 7.5.0) and my screen is not switched off it will go into "edit home screen" mode and back to the first home screen before starting the app (I was on the third screen). Luckly It doesn't change anything on the screens but the behaviour is different and at first very confusing. Here is a video: http://migaweb.de/ti_home_bug.mp4
[~michael], Yes I have confirmed it with [~jquick] & its expected due to the only way this change can be done. You will see this when app is complied & installed using studio or CLI. If launched manually after the first install you won't see this behaviour.
you could check
adb shell dumpsys power | grep 'mHolding'before. It will output:mHoldingWakeLockSuspendBlocker=true // lock true/false mHoldingDisplaySuspendBlocker=true // screen on/offHmm... the behavior is harmless and doesn't bother me. But if this behavior bothers [~michael] and [~lchoudhary], then it might bother others too. I don't want this to turn into a tech-support issue for us. I'll have to re-think this. _*Edit:*_ _[~michael], your solution doesn't work on all devices. Have a look at the stackoverflow link below. I'd prefer to stick to public APIs to make this work, but we may be out of luck in this case._ https://stackoverflow.com/questions/35275828/is-there-a-way-to-check-if-android-device-screen-is-locked-via-adb
Reopening for now.
[~jquick] ah ok. But keep in mind that the "menu - menu" won't bring any benefit when your device has a pin/fingerprint lock and is switched off, since it won't unlock them (which I guess most user devices use). Perhaps we could check if it's an emulator or not.
Let's revert this change for now. I don't want this to turn into a tech-support issue. PR (master): https://github.com/appcelerator/titanium_mobile/pull/10396 Note that the intention of this change was to help with automated testing systems. Perhaps an alternative solution would be to run the "adb" command like I was doing via build plugin instead. Something to ponder later.