Secrets of Android Developer Options. Wireless Debugging: Yay or Nay? 🔎
Though a handful are used daily, majority of the developer options remain rarely used and covered with a sheet of mystery. Are they rightfully omitted or should we embrace them? In this blog post series we take a deep dive into Developer Options and accompanying SDK tools.
In today’s post we will define what Developer Options are and roll away our USB cable to review how easy it is to setup the Network Debugging.
What are Developer Options?
Developer Options are settings that assist with testing, profiling and debugging of the applications since Android Jellybean. Because these options can negatively affect usage of a device, they are hidden from your ordinary user. To enable them on the device, go to:
Settings > About > Build Number > Then tap 7 times
Inside the Developer Options is an additional security toggle that disables the developer settings to easily revert back to standard OS behaviour. The contents of Dev Options also differ between OS’ and manufacturers.
Wireless Debugging via USB Debugging
All Android Engineers are familiar with USB Debugging setting. When toggled on, having device connected to the computer with USB cable, it enables a recognised computer to automatically communicate with the device using the ADB interface.
This setup, however, requires our device and computer to be connected with a physical USB cable at all times. In the USB-less MacBooks and wireless charging era, isn’t the pesky cable, that is slithering everywhere on the desk and tangling up with others, a tad old-shool?
According to ADB documentation, we have an alternative, so let’s test it out! Once the USB connection has been established, Wi-Fi can be easily set up for connections instead of USB, provided that device and computer use the same Wi-Fi and the Wi-Fi setup accepts such communication.
Sounds cool? Let’s have a look at 2 easy ways to enable this feature.
Way 1: ADB Interface
- Connect the device to computer with USB, as always
- Learn the device’s IP address:
adb shell ip route - Set the device to expect network connection on port 5555:
adb tcpip 5555 - Connect the computer to the device using devices’ IP address:
adb connect 192.168.xx.xx
If the device runs on Cyanogen or Oxygen, there might be ADB over network option added to Developer Preferences directly, making the above steps 2 and 3 be performed automatically.
USB cable and Network connection can be established simultaneously and will appear as separate devices in the device list. The network connection, rather than the typical device number, will be specified with device IP address.
List of devices attached:
ABCD123456789 device
192.168.xx.yy:5555 deviceDo keep in mind that adb might give the following error performing commands without specifying target device
adb: error: failed to get feature set: more than one device/emulator
At this point we can put away our USB cable and enjoy wireless debugging. But wait, there is more!
Though straightforward, ADB Interface will not remember the connection once disconnected, so the steps need to be repeated each time after disconnecting, including plugging in the USB again. What is the point then?
The plugins to the rescue!
Way 2: Android Studio Plugins
Android Studio currently has a good few plugins that make the network connection very straightforward and automatic, such as ADB WiFi and ADB WiFi Connect.
These plugins require hardly any setup, but have the added benefit over the ADB of saving a previously authorised connection. Until the RSA authorisation is revoked on the device, the plugins can connect with it, without the need to replug the USB at all, even when connection was lost, making the experience very seamless.
Disconnecting from Wireless Debugging
When done, don’t forget to call Mischief Managed, otherwise anyone can read the device. Call
adb usb
to revert ADB to usb mode. The Plugins might have their own shortcut as well as automatic disconnection.
Security Note
Since Jelly Bean 4.2.2, ADB is using RSA to authenticate the connecting computer. The keys are exchanged during the USB connection, so unless the attacker tricks the device to authorise a new computer or steals the key themselves, the connection is as safe as other network operations. Revoke USB debugging authorisations setting also flushes all existing authorisations, so fire it up, if uncertain of what authorisations have been made previously. It is important to exercise caution when using the ADB over Network on public or untrusted network (if not avoiding it altogether in these situations).
Cyanogen and Oxygen systems do present user with a warning when toggling the setting on in Developer Options. ADB itself doesn’t provide any warning, nor does print any information how to revert back to usb, which would have been welcome.
The bad: Load and installation times
Due to the difference in the way data is transferred between USB and Network, there are significant time lags.
The app installs and screen captures have a lag between 5–20x worse than the USB on a benchmark performed on small private network. This bad performance is to be expected, given that physical connection is always faster. Testing my my private network with around 20 devices connected to it resulted in the below averages:
+---------------------+-----+---------+
| Test | USB | Network |
+---------------------+-----+---------+
| HelloApp install | 2s | 40s |
| Screen shot capture | 2s | 8s |
| Video capture | 7s | 20s |
+---------------------+-----+---------+Additionally, Vysor, Layout Inspector and a few other tools, that require to access visuals of the device, don’t appear to be working at all. This might be due to my network setting, however, and might not be the case for everyone.
On the plus side, Debugger, Logcat, simple ABD commands and tools like Stetho appear to be working as expected without much noticeable delay. This is satisfactory enough for me to definitely use network connection for debugging.
Conclusion
Wireless Debugging is a cool alternative to USB connection, especially when we cannot use or forgot the USB. Distance from the computer also doesn’t matter, as long as the devices are within the same network. The security concerns also can be addressed, if we are aware of the risks, just like with any network connections. I certainly will use it on occasion since the setup it super easy. However, outside of things like debugging and tracing logs, the time lag is significant and might be not acceptable for everyone. The app install times are already very slow, in comparison to something like ReactNative. Making it worse, seem like a madness if it can be helped. What about you, do you use USB or Network connection for development?
What’s next?
In the next post we are going to look at the Drawing section of the Developer Preferences to profile our apps. How useful and easy to use are these settings and how much can they help in boosting the layout performance?
