[DAEMON-163] Windows OS: /system-info/1.x/info command is not responding

Description

Attachments

Comments

1. Ewan Harris 2017-11-17 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
2. Chris Barber 2017-11-17 I believe this was due to DAEMON-166 which is now fixed.
3. Satyam Sekhri 2017-11-18 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"
4. Eric Merriman 2017-11-21 Hello [~cbarber], please fix this one next if you would.
5. Kondal Kolipaka 2017-11-21 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]
6. Ewan Harris 2017-11-21 Believe the windows emulators is due to DAEMON-175, investigating android currently
7. Ewan Harris 2017-11-21 [~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 running appc appcd config set android.sdkPath VALUE, where VALUE is equal to ti config android.sdkPath to 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 :)
8. Ewan Harris 2017-11-21 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
9. Ewan Harris 2017-11-21 Filed DAEMON-177
10. Chris Barber 2017-11-22 There were many bugs fixed in Android and Genymotion detection and I can no longer reproduce the problem, so resolving as fixed.

JSON Source