It’s been almost five months now since Google announced the new generation of Firebase with great fanfare at this year’s Google I/O, and true enough mobile developers have been adapting. In fact, our research at SafeDK uncovers that nearly 8% of top apps are already actively using Firebase, with Firebase Crash Reporting definitely leading the pack in strength (and that’s just a sneak peek spoiler at our next Android SDK Market Report).

But if you’re a mobile developer and have tried integrating Firebase then you may have found yourself feeling more confused than anything else.

You see, Firebase is this big SDK from the house of the rising Google that answers many of a developer’s needs with the premise being “and it’s all completely free”. Analytics, Crash Reporting, Database, Storage space, Push Notifications and more. Some aren’t even mobile SDKs, just great services for developers such as hosting services and so on.

But Google already has a huge amazing all-you-need-ever-wanted-and-can-ask-for SDK. It’s called the Google Play Services. An SDK which over 96% of [Android] developers use, according to our research. And well, that’s exactly where the confusing parts kick in.

For all of you TL;DR folks – Firebase is actually a part of Google Play Services. What does that mean? Well, read on.

Get Firebase. Apply Google Play Services. Huh?!

Step 1 of the confusion begins with the integration guide. The title says it all. Step 1 get Firebase. Step 2 apply Google Play Services.

dependencies {
  // ...
  compile ''

apply plugin: ''

And here begins the fun where Firebase and Google Play Services interleave and become almost interchangeable. In fact, Google Play Services release note specify:

“In this release, Firebase APIs are now available in Google Play Services and include new products”.

So which SDK am I using when I’m only using Google Play Services? Can I use Firebase by only using Google Play Services? And which Firebase am I getting? Well, both, yes and all.

And here lies the secret – Firebase is part of Google Play Services. It is not really a separate SDK. However! Using Google Play Services as a whole is discouraged, to say the least. Developers are encouraged to only pick and choose the play services packages they need. In doing so, they “lose” Firebase capabilities. In order to get them back, you need to specify which Firebase packages you require, just like the other play services packages.

Am I Using Firebase or Google Play Services? | SafeDK Blog

Honey, I’ve Split the Google Play Services!

Since Firebase uses Play Services as its building ground it also relies on some of the more basic Google Play classes. So in order to easily facilitate Firebase access to these classes, they have been taken out of the play services base package and received a new home of their own.

The ramification is that the previously 20-packages-play-services SDK has expanded and is now 23 packages. For instance, the auth package was moved out of the base package to its own Google Account Login package to work better with Firebase Authentication.

Not that it affects method count that much, play services is already a monstrosity that keeps on growing. But developers who did right by their dex and have only integrated the play services packages they require might find themselves in need of adding more packages after a compilation that was once so smooth is now facing errors.

SafeDK’s SDK Android Market Report Reveals 96% of the top apps use Google Play Services. Get the full report now!

Firebase Ads == AdMob

So you might think to yourself that if Firebase is merely another set of packages within Google Play, the confusion can end here.

Firebase introduces a new package for advertising which you can bring into your app using the following gradle line:

compile ''

But wait… this advertising package is called AdMob. AdMob is the advertising package in Google Play Services that you can bring with this gradle line:

compile ''

Well, I’m puzzled…

Truth is, the two refer to almost the same package. Using the firebase-ads line would bring AdMob which still resides in the play services package and so you will get the same features and functionalities as with play-services-ads. The difference between the two is more in their AAR properties than in the code itself.

So why play mind games with us? Firebase was branded as its own SDK. Since you can – and should – pick and choose, you might end up only wanting to use Firebase capabilities. Yet, you probably still need AdMob. If not for the ads or mediation themselves, than for the AdvertisingID. So if I had to venture a guess, I’d say it to keep Firebase brand.

The same is true for the invites package. Looks like it was just branded as Firebase Invites but the code and package is still that of play services. Much like AdMob, the code here still comes inside the libraries and AARs, rather than the path.

Then again, why the Firebase integration guide still tells you to use App Indexing with ‘play-services-appindexing’ escapes me completely. I did mention it’s very confusing, right?

SafeDK In-App Protection

Firebase Analytics vs. Google Analytics

And now for the final stroke on the proverbial camel’s back. Google Play has its own Analytics package. It’s a well-known package supplying many interesting insights and event tracking for app developers.

Firebase introduces a whole new package for Analytics. It’s so fundamental in Firebase that it is actually officially referred to as “Firebase Core” rather than Firebase Analytics. It has its own dashboard with its own set of mobile-specific analytics. For instance, you can easily track how many males over 40s from Norwegia are clicking a certain button when it’s blue and how many when that color’s green. Great insights.

But then… which do I use? It makes little sense using both. Yet, play services still offers the plain old Analytics package. However Firebase Analytics gives you plenty of analytics by just being in your buildscript, without you as a developer needing to do anything else. It’s just for tracking specific events and scenarios that you need to add code. In fact, if you don’t even include the firebase-core package and just write the “apply plugin” line in your gradle buildscript, you’ll still get these analytics with no further involvement on your part.

SafeDK X-Ray: Find the SDKs Within!

Setting the mobile world afire. Firebase.

The introduction of Firebase is definitely a blessed event for mobile app developers, taking Google Play Services a few steps forward in providing a complete and versatile library of capabilities and features to developers.

But it comes with a few labor pains. Libraries that are given two different names. Two different libraries with similar capabilities that developers aren’t necessarily quick to tell apart.

Using a Firebase package but still being required to login with Play Services first.

Using a Firebase package in gradle but still importing Play Services classes in code.

And so on.

So the key is solving all of this confusion is to understand this is as simple as a game of marketing. Google introduced brilliant new capabilities with Firebase. But they are much more than just simple additions to the Play Services SDK. At the very least, the new packages are a lavish expansion. So instead of hiding them under “new features from the same old same old”, and to give them the promotion they deserve, the new packages were branded with a new name, a new logo, a new everything. To draw developers and tickle their curiosity.

I doubt any other addition to Google Play Services got this much attention or publicity. As our research clearly indicated, it clearly paid off. Firebase is quickly being adapted by developers in light speed terms compared to its relatively short existence here on mobile earth.