Mobile Apps / Development

Tips & Tricks: Testing & Debugging Android Apps

Matthew Potter

25 Jan 2021

Android app development often involves a sprawling array of different tools and technologies — Java, Kotlin, AndroidX, Jetpack, Kotlin Coroutines, RxJava, Dagger 2 and so on. It’s no surprise, then, that the tools available to us to make sure that our apps are behaving just the way we want are just as diverse, and just as powerful as the tools which we use to make our software in the first place — a lot of which can be found either on your phone, or in your IDE.

In this article, we’re going to take a little look through some of those features, some of which are relatively recent additions, which make Android development a more accessible experience for developers, and how we can make use of them to empower ourselves, deliver better software and make our lives just a little bit easier. 

The Layout Inspector

The Layout Inspector has been around for a long while in Android Studio, being shuffled around from place to place, but recently it has experienced somewhat of an overhaul with a slew of interesting new features incorporated into it. Easily one of the most useful tools in the entire IDE, we can use it to obtain living captures of our app and inspect the view hierarchy in order to help resolve bugs which might cause strange layout issues. 

A really nice semi-recent addition is the ability to view your layout in three dimensions — if you run your app on a device running API 29 or up, you can expand out the layers of that layout. Previously, this kind of thing was accomplished using tools like Scalpel, which would be bundled into debug versions of your app, but it’s now a part of the Android Studio Layout Inspector — and that’s a great thing!  

The main advantages of having this particular tool embedded in the IDE is that you don’t have to worry about adding in extra dependencies in order to get this effect, which is what you would have had to do a year or so ago, and ease of use — you can pull down a snapshot of the view hierarchy and examine it as much as you like, rather than having to keep your app running on your debugging device where circumstances may be transient and layout bugs many not be easily replicable. 

Wireless Debugging

While in the past it has been possible to do wireless debugging, with the latest version of Android it’s become far easier to set up your device as a deployment target via Android Studio over your local WiFi network. 

In the olden days, you would need to hook up your device via USB, then fire up a terminal and punch in a series of ADB commands, like so:

adb tcpip $PORT

adb connect $IP_ADDRESS:$PORT

Where  $IP_ADDRESS is the IP address of your device on your WiFi network, and $PORT is some arbitrary TCP port that isn’t already in use, typically 5555. In my experience it was pretty flaky, especially on some particularly cheap devices. Sometimes the device would refuse connection for no discernible reason; other times it would be slow and prone to instability issues. Either way, the experience was not ideal. 

However, Android 11 has come to the rescue with brand new wireless debugging capabilities, including the ability to directly pair with any Android 11 device on your network that has wireless debugging turned on. This option is found inside the Developer Options in the phone’s settings, and even has a quick settings tile so you can enable and disable it from your system tray. 

You can either enable wireless debugging via scanning a QR code, or by punching a code into your terminal window. I tend to use the latter, since it’s pretty straightforward; you’ll be presented with a dialog box that contains a code and an IP address/port number combination, and after running:

adb pair $IP_ADDRESS:$PORT

You’ll be prompted to enter your code. It’ll pair once you’ve done that, and then you can select your device as a deployment target and as a debuggable device. 


This one is slightly more esoteric, but if you’re ever doing development which involves the NDK, this relatively new tool will very likely come in handy. GWP-ASan is a Google-developed tool which will help identify free-after-use and heap buffer overflow (and underflow) bugs, all of which are notoriously common varieties of bugs and can often be extremely difficult to chase down. It’s opt-in, but the cost of doing so is pretty minor, and the way it works is extremely interesting. It is also extremely battle-hardened — for example, it’s used in Chromium for identifying the above-mentioned varieties of bugs.

Effectively, the tool selects a tiny, random slice of memory that it’ll monitor, and if it ever detects any of the kinds of defects it’s designed to pick up on, a crash will be triggered. GWP-ASan will collate as much diagnostic information about the state of the process at that time as it can, and put it all into a report. The actual footprint of the tool despite everything it does is pretty small — it’ll roughly grab around 70 kilobytes of memory for itself upon starting up your process — and ithe degree of impact it has on app performance is very minor. 

Currently, GWP-ASan enabled for random system apps upon device boot, but opting in is simple change to your app’s manifest. 

By Matthew Potter, Software Engineer at GrowthOps

GrowthOps Digital is a full-service digital agency that offers end to end digital marketing services such as Google Ads, Social Media, Partnership Marketing, and more. Speak to us about your growth needs today.