After months of waiting, the official new Android SDK is here – Android 6.0 (better known as Android Marshmallow) has been officially released for developers. First unveiled last May at Google I/O 2015, Android Marshmallow introduced some great new features. One such feature is a new permissions model, called Runtime Permissions, and app developers are going to have to make the necessary adjustments to their apps to deal with this new model. But one very important thing they might not be aware of – the code of the 3rd party tools they are using: the SDKs.

Here at SafeDK we’re constantly thinking about them. How they improve the development process and boost apps on one hand, but are the subject of bugs and security breaches on the other. We’re constantly trying to mediate over that gap, putting a little more love and trust into “this love and hate relationship of app developers and SDK developers”, as our CEO Orly Shoavi puts it. So naturally when we heard of the new permissions model, we sighed “finally…” and then quickly came to think “but what about the SDKs?”

Let’s back up a moment and talk about this new permissions model. Android M (planned to be released around the end of Q3 2015) deprecates the concept of pre-approving a long list of permissions during app install, as well as the ‘take it or leave it’ deal apps and users have today. Starting with Android Marshmallow, users will have the ability to selectively choose which permissions to grant, and moreover will be able to revoke permissions in the Settings screen later on, much like in iOS. The app, on the other hand, will get the opportunity to explain why it requires specific permissions, and will no longer be able to rely on them being granted in advance – every single time an app wants to access some service guarded by a permission, it will have to ascertain it has that permission (and gracefully handle the scenario in which the user declines to grant it). Sounds like a big leap forwards for Android, wouldn’t you say?

Sounds Great, Why Should I Care About the SDKs in My App?

That’s a good question. Say you’ve gone over every single piece of your code and adjusted it to work with the new Runtime Permissions model. You’ve asked if you have the permission, displayed a nice message when needed, handled both the case of sesame openings and not getting pass the bouncer and into the party. All seems to be working fine.

But then you have the 3rd party SDKs. If you’re on a fixed version, then you can be certain their code is pre-Android M and they won’t handle it so gracefully. They might try to access some component without being aware that permission can now be denied and handle the return value awfully (either bad user experience or worse – an app crash). Even if you’re updating to a new version, it’s still quite the risk since you’re left guessing and exploring if they’ve handled Runtime Permissions. Now before you start hyperventilating, I’ll tell you that over at the SafeDK Marketplace we will track down SDKs that have released new Marshmallow-compatible versions and mark them as such, to help you understand which of your apps does what. Furthermore, our kickass App’s X-Ray widget that reports which SDKs reside within apps, will soon be enhanced to also tell you which ones are M-compatible (contact us for a free trial).

What will happen to non-compatible Code?

In order to understand the importance of having Marshmallow-compatible SDKs, we must first understand how Android M will behave under fire.

When an app tries to access some permission it is not allowed, Android will simply return some sort of empty result (rather than crash the app with a SecurityException as is the case today, and will likely still be for permissions not declared in the manifest). The danger then arises when the party receiving the result assumes it cannot be empty and tries to access it with the proper if-else checks. This could easily result in constant app crashes and an increase in uninstalls.

So while you may have covered your own code, you’re still pretty much in the dark about how your SDKs behave. Now you might think the solution is just as easy as wrapping each one of your calls to the SDKs with a try-catch and that might work, only SDKs sometimes also have background services and broadcast receivers, as well as sometimes being launched through the layout XML and not your code directly. So it’s a bit more complicated than that.

The OnCreate Paradigm

Most SDKs make their first appearance during the application’s onCreate (or the launcher activity’s onCreate). If you’re using SDKs, especially the popular ones, you’ve bound to have noticed that. That means one of two things: either the SDK assumes it has access to a permission and crashes your app before it’s even launched (we’ll call that the worst case scenario), or it handles everything gracefully but does not initialize. And that may spawn a whole new sets of problems during the app run where the SDK may assume that it was initialized.

Let’s focus on that second one for a second. It’s not as acute as it may sound, however it means that when your app runs for the very first time, you won’t get the benefit of your SDKs. Best case they’ll simply do nothing on that first run before you get the chance to ask for permissions yourself in the Android M proper way. Worst case is either they won’t handle that first initialization properly or once you do request and receive permissions, the SDKs will “kick into gear” but will still assume they’ve been properly initialized and then the mayhem of unexpected behavior, app crashes, and all things wrong with user experience ensues.

Note that since the internet permission is granted automatically, most SDKs might be initialized or able to access the network, but their behavior regarding other permissions are still a wildcard.

The Extreme Scenario of Malevolent SDKs

I believe one of the worst nightmares for app developers, right up there with them crashing their app, is if an SDK is brazen enough to ask for app permission itself. The SDKs intentions may not be all that malicious, however it may be frowned upon the app developer itself.

Just imagine the SDK – and not you – prompting the user for permission. I would imagine that might be annoying to app developers. Moreover, before prompting the user, the best practice would be to call a method call shouldShowRequestPermissionRationale in order to know if to display some short message to the user explaining why the permission is needed, or if the user has marked that he does not wish to be prompted again. If an SDK doesn’t adhere to this flow, it’ll be annoying the user. Of course, the user has no idea it’s not the app, nor does he care, and he might quickly uninstall and down vote your app. All because the SDK took the liberty of trying to obtain the permission itself so it can work properly.

Be the King of your Own App: SafeDK In-App Protection

Much before Android M, we recognized the problems that app developers may face when using SDKs. We’ve heard their fears, their worries, and their war stories. We developed a unique mechanism we call In-App Protection that allows app developers to get live data about how their SDKs behave in the wild (such as performance issues, crashes, the frequency of location accesses and more) as well as offer them the ability to control and deactivate them in real-time when required, either in full, or simply accessing a component (like Location or Network, even in Android M!) or even under a set of criteria (say for specific Android versions, manufactures, countries and so on). Register for a free demo at our website, and we will be happy to show our magic in action!