Android Decompile Deepdive: Authenticator

Scott Meschke
Sep 3, 2016 · 4 min read

Android Decompile-Deepdive is a series where we take a popular, successful, impressive application and decompile it, seeing what things we can learn in the process.

Previous Deep Dive: TED: Blog and App

Today we’ll be investigating the Authenticator.

We’ll start by a quick dependencies overview, and then deep-dive into the fundamentals of Blizzard’s internal Android push-library. Finally we’ll check-out a few snippets for determining current thread, ADM checking, and root-access checking.

Dependency Analysis

It’s worth noting about the Jacoco dependency. I’m guessing they didn’t want to include that in their production build.

Most build systems (including Gradle) have a great deal of options for dependency management. You can declare them as compile, testCompile, or compileOnly.


Push is important.

But it takes quite awhile to set it up properly in projects. While the Android APIs for push are powerful, but aren’t exactly user-friendly.

In addition, as soon as you start throwing other providers and configurations into the mix (like ADM, and NetEase for Blizzard) it can get complicated.

We are going to investigate Blizzard’s internal Push library. The library is portable, and favors ease of use over flexibility.

Blizzard created 2 additional types to use with their notifications.

Custom sounds eh? What about KAPOW-WHAM-SPLOSION? I think users would love that..

BlizzardPush handles notification categories, account management, canceling notifications, and platform determination.

A minor note: The class has only static methods, even though there is required (and mutable) state…

Personally would prefer a static initialization factory, and received a BlizzardPush back that we could store wherever (or let our DI setup handle that for us).

BlizzardRegistration handles registering for push with Blizzard’s API.

You can see the convention over configuration obviously here.

The registration method does not accept a callback, but instead has hardwired connections to BlizzardPush with success or failure methods.

This abstract class handles incoming intents and determines what type they are:

Is this a deep-link?

Is this a Registration related PushToken?

Then the implementing app will take it from there.


Blizzard wrote the sendRegistrationToBlizzard() method in BlizzardRegistration so that it can be used synchronously (in a background thread) or from the main thread.

Blink-182 recently came out with a new album, but I don’t think “What’s my thread again” made the cut.

ADM stands for Amazon Device Messaging.

This is a stupid-simple check to see if ADM exists (we are on an amazon device).

If ADM is new to you, Amazon provides documentation here.

Interestingly, the Authenticator app checks on start-up if you have root-access. It then shows a warning dialog if you do.

They had multiple conditions for determining root-access (mostly from this stack-overflow post).

I thought those were lackluster and inconclusive, but they did have this check which seemed more reliably correct.


It’s a nice little internal library. There is a bit of strangeness in the APIs, but it would make it very easy to spin-up a new app with push.

It does a great deal of the work for the client including:

  • Determine Push provider and device platform.
  • Enforce and handle conventions around types of notifications
  • Handle push registration, cancellation, etc.
  • Built in category and action type to reuse.
  • Conventions and patterns for deep-linking, regions, ids, push services, and all sorts of other stuff that would be a pain to synchronize manually across multiple apps.
TBD — I’ll update this with a link to the next post once it’s done.

Enjoy the snippets?

Disagree with my analysis?

Have burning-hot fiery opinions about some random sentence above?

I’d love to hear from you, leave your comments below!