[DAEMON-163] Windows OS: /system-info/1.x/info command is not responding
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Critical |
| Status | Resolved |
| Resolution | Fixed |
| Resolution Date | 2017-11-22T18:18:49.000+0000 |
| Affected Version/s | Appc Daemon 1.0.0 |
| Fix Version/s | Appc Daemon 1.0.0 |
| Components | androidlib, appcd-plugin-android |
| Labels | n/a |
| Reporter | Kondal Kolipaka |
| Assignee | Chris Barber |
| Created | 2017-11-17T10:54:32.000+0000 |
| Updated | 2017-11-22T18:18:49.000+0000 |
Description
/system-info/1.x/info command hangs on the windows machine. It's an intermittant issue.
Looks like it's getting into recursive loop on "Detecting devices info"
Attachments
| File | Date | Size |
|---|---|---|
| appc_master34_windows_tiinfo.json | 2017-11-21T05:10:44.000+0000 | 14268 |
| appcd_master34_windows_dump.json | 2017-11-21T05:12:29.000+0000 | 720282 |
| appcd_master34_windows_systeminfo2.json | 2017-11-21T05:10:44.000+0000 | 3736 |
| dump.txt | 2017-11-18T14:44:24.000+0000 | 270125 |
| start_debug.txt | 2017-11-17T10:56:39.000+0000 | 400237 |
To clarify on the windows plugin, it's perfectly normal to see those logs. The windows plugin is not pretty right now it basically loops on a setInterval, we detect for devices every couple seconds, visualstudios every 5 minutes etc. Because of windows being windows we need to take a step back and re-evaluate how windowslib functions, so windowslib v2 (really v1), was punted out of daemon v1 What this looks to be is a bug in the android plugin for a system with no Android info, Chris is currently on it
I believe this was due to DAEMON-166 which is now fixed.
Still seeing the issue of no response for system-info on Windows OS with Appc CLI 7.0.0-master.33 Attached "dump.txt" for the log output from "appc appcd dump"
Hello [~cbarber], please fix this one next if you would.
With the latest daemon system-info command doesn't hang but the Windows and Android emulators are empty. Here is the environment: Appc CLI : 7.0.0-master.34 Appc Daemon: 1.0.0-13 Appc SDK : 7.0.0.v20171117152921 OS: Windows 10 Pro Please find the attached files. [^appc_master34_windows_tiinfo.json] [^appcd_master34_windows_systeminfo2.json] [^appcd_master34_windows_dump.json]
Believe the windows emulators is due to DAEMON-175, investigating android currently
[~kkolipaka] Could you try this for me and upload the logs
appc appcd start
appcd appcd logcat > logs.txt
appc appcd exec /android/1.x/info
That should give us full logs for the android plugin starting and detecting. Here's my thoughts so far after reviewing the logs The ti info output finds the SDK because it has the config set. Maybe try runningappc appcd config set android.sdkPath VALUE, where VALUE is equal toti config android.sdkPathto point the daemon towards it This could be impacting the emulator detection (which is coupled to SDK detection as it need SDK info to populate target/api-version/sdk-level), going to put this theory to the test now. But I believe the above _should_ let you move on, working to test that theory currently :)Ok I can reproduce this issue in the following situation - Renamed my sdk to /Users/eharris/Library/Android/foo so that daemon wouldn't pick it up, that is to say my SDK is now not in a default location we scan - Added /Users/eharris/Library/Android/foo/platform-tools to my path so that we could find adb - Ran appc exec /android/latest/info Investigating why, will probably fork off into a separate ticket
Filed DAEMON-177
There were many bugs fixed in Android and Genymotion detection and I can no longer reproduce the problem, so resolving as fixed.