Android Decompile Deepdive: Battle.net Authenticator
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 Battle.net 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
General Java
- Google Dagger
- Jacoco Agent (oops)
Android Specific
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.
Deep-Dive
Blizzard Push Library
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.
Notification Types
Blizzard created 2 additional types to use with their notifications.
BlizzardPush
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).
Blizzard Registration
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.
Notification Event Handler
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.
Extras
What’s my thread again?
Blizzard wrote the sendRegistrationToBlizzard() method in BlizzardRegistration so that it can be used synchronously (in a background thread) or from the main thread.
Simple ADM Checking
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.
Root Access Check
Interestingly, the Battle.net 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.
Wrap-up
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 battle.net 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.
Next in the Android Decompile-Deepdive Series:
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!
