A TestFairy Gotcha for Social API Developers

History

If you don’t know who or what TestFairy is, a brief background. Mobile application development has a number of challenges, the least of which is how to take your app build and distribute it to your testers. iOS is notorious for being a pain in the ass to distribute for, as it requires registration of all of the test devices on developer.apple.com, inclusion of those registered devices in “provisioning profiles”, signed IPA packages that contain the build and provisioning profile, and so on and so forth. Once you actually have a build put together properly to distribute, you have to distribute it. E-mail receiver lists, a shared Dropbox folder perhaps, or a webpage with the build and instructions on how to install it. It really is a headache.

The friendly folks at TestFlight recognized exactly what a headache it was and put together a really great application to manage the packaging, distribution, and management of iOS test builds. Seriously, it is awesome. It was even more awesome when they added the ability to distribute Android apps (remember the classic pattern, develop for iOS first, then for Android).

Unfortunately, that awesomeness came to an end when the parent company of TestFlight was bought by Apple.. Immediately after the acquisition the ability to manage Android application builds through TestFlight went bye-bye. Well, it was fun while it lasted.

So, all a sudden searches for “testflight android” and “testflight alternative” took a jump on Google in the cold winter of 2014, and one of the sites that filled the void was TestFairy. We were one of the ones searching for an alternative; sending Android APKs around via e-mail is so 2013.

TestFairy Goodness (and Gotcha!)

With our brief history out of the way, we can get into how cool TestFairy is. In short, TestFairy allows you to upload Android builds, invite testers to try the build out, generate e-mails when there are crashes of the test build. One of our favorite features is TestFairy will actually create a little movie of what the user is doing in your app while they are doing it. Want to see what led up to the crash? Play the movie. How cool is that?

This blog post isn’t about how cool TestFairy is, however. It is about a pesky gotcha if you are developing with either the Facebook or Google+ APIs, which we do. Most Facebook or Google+ API developers know that you have to provision in either the Facebook Developers App page or Google Developers Console APIs & Auth page your “hash”. This “hash” takes on the form of something like P7Ori9vVUPT/u5D+N6IdWKO263c= for Facebook or 3F:B3:AB:8B:DB:D5:50:F4:FF:BB:90:FE:37:A2:1D:58:A3:B6:EB:77 for Google+.

By its very definition, a hash is computed by applying a (wait for it) hashing algorithm against some given content. Change the content, and the hash changes. For Android development, the hash is applied to the signing key used to sign the application. Change the signing key, and your hash changes. There are dozens of StackOverflow posts about integrating either the Facebook or Google+ API that come down to using a signing key whose hash is not provisioned on the respective developer console. The most common scenario that we have come across is Developer A builds the application and signs it with his development key. Developer B tries to run the application and it works (because Developer A put their hash in the developer console for the social API in question). Developer B then builds the same code and gets authorization failure messages. Sure enough, Developer B signed with his key, whose hash was not provisioned, and, well, what do you expect?

So what does TestFairy have to do with all this? Yeah, we’re getting to that. TestFairy’s awesome features; instrumentation, custom application icons with a cute Android watermark, application movies; don’t materialize out of thin air. The reality is the APK build that you upload to TestFairy gets modified to include all of these nifty doodads. And when this modification occurs the application is re-signed. Read that again: re-signed. To put another way, it’s not signed with the key you signed it with when you uploaded the build.

To their credit, TestFairy recognizes if you have used the Facebook SDK and tells you up front. You need to update your Facebook application on the developer console to include this hash:

If you don’t include that hash, well, your use of the Facebook API won’t work. So we go to the Facebook developer page for our application and add the hash. Note we have a few others as well – as many as we need for whoever is authorized to sign and deliver our application (of course we’ve blurred our other hashes, though we probably didn’t need to):

What TestFairy doesn’t currently detect is whether or not you are using the Google+ API. That’s probably a feature they are looking to adding, or perhaps we are using the Google API+ in a nonstandard way and its not detectable. Who knows. Regardless, it wasn’t detected for our app and we will admit: it bit us. Live and learn as they say. To ensure that your use of Google+ still works with builds uploaded to TestFairy, you need to make sure and update your application in the Google+ developers console with the hash that TestFairy provides. To find your new Google+ hash, select your app in TestFairy, and find the Settings button. You will see in a tab called Build Settings something like this:

The last line, the one starting with 3F:B3:AB contains the hash signature for Google+. Go over to your Google developers console and add a Client ID for Android application. In the Google console it is called a Certificate fingerprint as shown below.

If everything else is set up correctly (which, with these social APIs there can be a lot to misconfigure) your use of Google+ should now work correctly with a build uploaded to TestFairy!