Varanus

The monitor lizards are large lizards in the genus Varanus.

Some time ago, our Android app got into a loop of sending data, due to some unlikely interactions between several different systems, which briefly overwhelmed our servers before we were able to turn it off. Fortunately, key code was behind an experiment. Otherwise, apps could have continued misbehaving for days, as there is no guarantee users would immediately update the app. It took an unusual combination of circumstances for this to happen, but this kind of problem seems to be a pervasive concern across the industry, and there are few tools to prevent it.

Furthermore, even at the best of times, mobile data can be hard to manage. Every now and then an article comes up about how a widely used app has eaten up users’ data. Unfortunately, there aren’t very many good tools for tracking how much data is sent, or what exactly is responsible for sending too much data in the first place.

Also, because updates are optional, all the code you’ve ever written is out there, somewhere (and we’ve had an Android app for almost as long as Android has existed!). If something goes wrong, you may not be able to push a fix to enough people, and with millions of users, all sorts of strange things can happen. While it’s unlikely that something goes catastrophically wrong and you can’t get enough people to update, it’s not impossible.

What Does Varanus Do?

In building out Varanus, we had two main goals:

1. Always be able to turn off unwanted data on the client, no matter what.
2. Observe how much traffic is generally being sent so we can spot if something weird happens.

With three constraints:

1. It should be exceptionally simple and hard to break.
2. It should work without anyone having to do anything.
3. It can be dropped into our different apps with minimal effort.

Also, since it seemed that a lot of people were concerned with this problem but lacked the resources to spend time fixing it, we saw this as an opportunity to contribute something useful to the community.

How Does It Work?

Basically, since all network traffic passes through Varanus, Android developers don’t even have to think about it for it to work. It counts the number of bytes and requests, and bins them by arbitrary categories of traffic that can be specified programmatically. An error message from the server (or CDN) then tells the app to hold off on sending more traffic for a bit—one message says to stop sending all traffic, and the other says to stop a specific category of traffic.

The code is entirely client-side, and no new backend infrastructure is needed (as long as you have a way of sending custom HTTP error codes from your server if necessary). Also, no coordination between devices is required, and turning off traffic is simple: all you need is a runbook.

Varanus is built around OkHttp interceptors, but with a bit of extra work, there’s no reason other clients couldn’t be supported. It’s also written entirely in Kotlin (like all new code at Yelp).

Where Can I Find More Details?

Take a look at the README, or the code itself. We have a sample app that explains how it should be used.

Rusty Jetpack

In preparation for targeting Android 10, Yelp’s Android apps were migrated to use Android X libraries. Unfortunately, with the size of our apps’ codebases, the provided migration tool in Android Studio didn’t work for us. Rusty Jetpack was then born as a Hackathon project to help ensure seamless adoption across many developers with little downtime.

What Does Rusty Jetpack Do?

The tool migrates all files in a git repository to use the new Android X package name spaces. This includes imports, fully qualified references, pro-guard declarations, and warnings about gradle packages that need to be changed. While this does mean the code won’t compile immediately after using the tool, most of the mundane work is taken care of. And best of all, it achieves all of this in under one second for our largest repository!.

Rusty Jetpack is critical to preventing downtime during migrations with rapidly changing codebases. Migrations can easily be kept up to date with the latest changes by re-running the tool, and then being distributed to developers (once the migration has been pushed) for quick adoption without major disruption.

To learn more, check out the repository here!

Back to blog