Wifi Support & Checks #48
Conversation
Added functions and changed device descriptions to include the model, device name and connection type.
Changed the transfer and installation procedures to use the AMDeviceSecure* APIs which support both direct (USB) and indirect (WIFI) connections.
Adds checks to ensure we don’t attempt to debug over WIFI which (afaik) isn’t supported.
Allows the detection of multiple devices. Still uses the first found if only deploying, waits for a USB-connected device if trying to start a debug session. Commands with a “static” device ID will ignore the previous logic.
Signed-off-by: Shazron Abdullah <[email protected]>
|
Merged into master. Did a quick test of deploying an app, it detects the app name and deploys the app successfully through USB. |
|
Note that I squashed your 6 commits into one. |
|
Hi, thanks for the quick work! I hope you didn't have any issues with the code and formatting :) Assuming everything works well, the only open issue would be how to debug using Wifi if at all possible. Another thing I thought and might just do it one of these days is to exploit the "newly" found powers and do a mass deploy. I believe this would be best suited on a secondary tool but that would require some factoring of the code. Let me know your thoughts. |
|
No worries, please file a pull request when the time comes :) As usual, I'm not worried about new features as long as the current functionality still works. |
2 participants
This pull request is built on top of #47 that tries to diagnose bug #11.
This replaces most app installations calls by the AMDeviceSecure* versions of the API which correctly supports Wifi deployment. I'm unable, and think it's not possible, to start a debug session over Wifi, but with this pull request we're now able to deploy apps wirelessly.
I've implemented checks to detect attempts of debugging over Wifi and instead of a puzzling "assert" log, it will explain the problem. Devices are also better identified to help diagnose and find the culprit.
Additionally, if attempting to start a debug (or list connected devices with the debug flag active) it will now wait for a USB connected device. On timeout it will fallback to the previous/default behaviour of returning the first device found. If the debug flag is off or a specific device ID is set the behaviour stays unchanged (first device is used).