Add your SDK
Home

Apps, SDKs and Everything in Between

Enjoy the best mobile SDKs news, tips & tricks, sent to you by mail

Android Developer? Here is what to pay attention to when using Google Play Services

September 21, 2015 8:09 PM

Most Android developers use Google Play Services. In a survey we run at SafeDK, we found that nearly 70% of all Android apps have at least one package of Google Play implemented, and often even more than that. From ads to analytics, through support of social media, cloud and push notifications, Google Play Services offer app developers a variety of capabilities, and it’s great. Having said that…there is also a downside to all this goodness.

In order to offer such rich support, Google Play Services module is comprised of many individual packages, and contains a whopping 29,000 method count which is problematic due to the 65K limit issue.

The Unbearable Lightness of Multidexing

Interestingly enough, based on SafeDK’s big data, we found that approximately half of the Android apps out there integrate the full module of Google Play Services, but actually use very few of the packages it contains. Naturally, Android developers would want to optimize their Google Play Services selection…

I’ve written about how to deal with this issue, in a previous post where I provided some insights on how to identify the packages that are right for you. I also touched on the number of methods each package adds to your app. 

But now, Google has released a new version of Google Play Services. And while some things have changed, the bottom line has barely shifted:

  • It still adds a large number of methods to your app.
  • You still must use the large “base” package in order to use any package.
  • You still have to use the entire play services (can’t pick-and-choose) to continue using the deprecated appstate package.

Continue Reading

Will Mobile SDKs Leave an Aftertaste for Android Marshmallow?

August 27, 2015 1:08 PM

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?

Continue Reading

The Marshmallows Are Coming: New Permissions Model is Almost Here

August 19, 2015 7:35 PM

Earlier this week, Google ended months of speculations and announced Android M will be decorated with fluffs of Marshmallow. And with the big name revealed, the official version has been released and it’s time for app developers to make the necessary adjustments towards the new version, set to hit mobile devices late this fall.

What adjustments are those? Well, perhaps the biggest and most exciting one is the new permissions model.

Since its’ inception, Android has employed a then innovative permissions approach. Each sensitive component was wrapped with its’ own set of permissions and each application had to both inform the user of what it will access, as well as request his approval for such accesses. Sensitive data like user’s personal information or location, as well access to the user’s own files or phone records, were no longer done in secret behind the scenes. This was certainly a big important step up from the way things used to be (and still are) with computer applications.

However, Android’s permissions model also had a few stings:

  1. It bombarded the user upon app installation with the often long and daunting list of permissions.
  2. It was a package deal – an ‘all or nothing’ situation.
  3. It was an ever-growing mayhem – Many actions were split into several permissions (for instance, read vs. write) and as features and capabilities continued to grow, so did the complex permissions model.
  4. Android displayed its’ own description of the permissions, a description that sometime sounded scarier than it was for the casual user.

With Marshmallow, that’s all about to change. Let’s see what it’s all about…

Continue Reading

When SDKs Update: To Upgrade or Not To Upgrade

August 5, 2015 12:34 PM

SDKs are on the rise, there’s no denying that. They’re a great way for developers to work out the more common pieces of code often found in mobile applications. These SDKs are the kind that will make their product whole on one hand, but on the other won’t be what sets their solution apart from all the rest.

More and more SDKs are being developed, released and integrated into increasing number of apps. The benefits and services offered to app developers become more versatile and intriguing as time goes by. No matter how much you may dread putting someone else’s code inside your app, it’s getting harder and harder to resist these temptations. Especially when developing them yourself may be too expensive and time consuming.

But much like your own app, SDKs are always trying to better themselves by offering new features, fixing bugs or security risks, etc. Which may sound lovely at first, until you realize a service you’re dependent on has changed. And while change may be a positive thing, it can also break things. So what do you do when an SDK offers a new version? Do you automatically upgrade or do you approach it with much more caution, hoping the current version you use will still be supported in the foreseeable future?

Actually, there are no real guidelines. No easy “do’s and don’ts” list. App developers are left pretty much to rely on their gut reaction and their thorough testing. So let me offer you some food for thought when making these tough decisions.

Continue Reading

Mobile SDKs: Use with Caution

July 22, 2015 11:19 AM

We’ve all heard of mobile SDKs. These off-the-shelf mobile services, which app developers integrate in your app for many purposes: advertising and payment, analytics and social, and many many more. No doubt these SDKs are a great help in your development process. They often offer unique functionalities, simplify your coding and save you precious time and money. It’s not a surprise that the 1,000 most popular apps contain on average 15 SDKs.

But SDKs are not really your code. It is actually someone else’s code interleaved with your own, yet you are liable for it. You are responsible for it in the eyes of Apple, Google and most importantly – your users. Why is this a problem? Well, in this post, I’ll explain two major domains of risk when using SDKs, and spice it up with a few real-life stories.

1. Security, Privacy and Compliance

The dark side of app permissions

Once hosted in the application, the SDK is part of the application code and can access any user data that the application was granted access to. If the app can access users’ location, contacts or private files, so does each and every SDK in the app.

We often see Android SDKs containing code similar to this:

if (context.checkCallingOrSelfPermission(“android.permission.ACCESS_FINE_LOCATION”)
              == PackageManager.PERMISSION_GRANTED) {
     Location userLocalLocation =
                localLocationManager.getLastKnownLocation("gps");
}

The SDK simply checks if the app was granted a permission to access the user’s location, and if so it takes advantage of it and accesses the GPS as well. We can often see that SDKs send this information to external servers.

Let this be a cautionary tale to all you folks integrating SDKs: what the SDK doesn’t tell you may hurt you. In the case above, the SDK could simply not declare using the Location permission and only exploit it should your app have it. All might be done behind the scenes, and worse – behind your back and on your watch.

Continue Reading

The Holy Gradle: Setting Up Your Android Build on a Build Server – Part 2

July 15, 2015 8:11 AM

In my previous post I went over some basic terms used by Gradle and the Android build system, and over the flow of the build. With these understandings at hand, we are now ready to go over concrete steps and set up our build server, without Android Studio, or in fact without any GUI tools at all.

For the sake of this post I will assume you are setting up your new build environment on a Linux server, and you don’t have the Linux GUI at your service, only the command line. Of course, it can all be set up on a Windows or Mac machine just as well.

Let’s also assume that your user on the build machine is called “user”, and therefore your typical home directory would be /home/user.

Now let’s go step by step:

1. Download and install the JDK

First download the JDK you work with. I have downloaded JDK7 from Oracle’s site. If your Linux environment doesn’t support rpm – you will need to download the tar.gz version and extract it, for example to /home/user/.

2. Download and install Gradle

You can download Gradle’s latest release from here. The binary distribution will do, no need for the complete distribution. I chose to use Gradle 2.4.

By the way, There is the option of avoiding the explicit installation of Gradle if you are using the Gradle Wrapper, but let’s leave this topic aside. Personally I think that if you are setting up your build server, the better approach is to explicitly download the Gradle version you want. Once downloaded, extract the zip file, for example under /home/user.

Continue Reading

The Holy Gradle: Setting Up Your Android Build on a Build Server – Part 1

July 7, 2015 10:47 AM

If you are using Android Studio, then you’ve seen Gradle in action. Yep, Gradle is the engine behind the build system used in Android Studio, which is, together with Google’s Android plugin for Gradle, responsible for building your Android application and producing the final .apk files.

Gradle is a powerful build tool, written in a simple script language called Groovy. It takes care of a lot of the plumbing related to building an application – resolving dependencies, downloading artifacts from repositories and determining which tasks need to run in order to build your app. Gradle then runs the tasks that compile, merge, handle resources etc until your app is ready. Gradle is also simple to configure. Typically, with a few declaration lines in your build.gradle you are ready to go.

But this is exactly what makes Gradle somewhat complex to understand, because a lot of the work is done under the hood, typically by plugins, some built-in (like the java plugin), and some being 3rd party plugins, like the Android plugin and the SafeDK plugin. If you are someone like me that likes understanding what’s going on behind the scenes – it’s not always that easy.

There’s of course a lot to tell about Gradle and the Android build system. So much, in fact, that this is just the first out of a two-part story (part 2 coming next week). In these couple of posts I’ll focus on a specific topic – I’ll try to guide you through setting up an environment where you can compile an Android application using Gradle, but without the Android Studio IDE. Why would you want to do that? Well, it has to do with buzzwords like “build server”, “continuous integration” etc. While you can build and deploy your app in Android Studio, if you have multiple people working on the app, you may want a central build server with a consistent environment, where you continuously integrate, run automated tests, produce versions for your QA team and produce the final versions. This is btw one of the nice things in Android Studio – the fact that you can completely decouple the build system from the graphical IDE.

Here I’ll go over some terms and mechanisms which are essential for part 2, where I’ll detail the steps to set up your independent build server.

OK, so let’s dive in.

Continue Reading

Reducing Your Method Count: The Google Play Services Edition

June 30, 2015 3:50 PM

Avid Android developers have longed faced a headache-inducing problem with their apps. The number of methods an app can have is limited. Well, it used to be limited. At long last, the good folks at Google provided a solution last October, but it was far from ideal. Though very easy to implement, the multidex solution complicated and prolonged compilation time significantly. Not standing still, starting with Lollipop (Android 5.0), the entire Android virtual machine was revolutionized to offer a much more endurable solution, the kind that even improves on the regular compilation time.

However, for the time being, the Lollipop solution isn’t ideal too. It requires developers to develop against Lollipop only, which could be problematic since most apps want to be compatible with wider ranges of audiences and might fear using features that aren’t available in earlier Android versions. So right now, the Lollipop solution is a good future-Android solution, but might not have much impact in the foreseeable present.

So what can be done in the meantime? We all agree that you shouldn’t give up on features and capabilities, just to avoid reaching the 65K limit. But there is no doubt that the best practice would still be to reduce your application method count.

So how can you still try to reduce your method count without losing that little spark that makes your app special?

Continue Reading

Solving Android’s 65K Limit (Part 2): The Lollipop Generation

June 23, 2015 3:57 PM
 

If you’ve read my previous post about breaking Android’s 65K limit (and if you hadn’t, what are you waiting for?), you’re already pretty familiar with Android’s 65K limit, why it exists and how to solve it. Which means you’ve been itching to know what the future of multidexing has in store (and what does a tooth-fairy-supporting candy-on-a-stick has to do with it).

As small recap to start with, if you will:

Since its’ inception, Android ran a virtual machine called Dalvik. The Dalvik VM ran a compiled file called dex (Dalvik Executable) which has a tiny limitation – even though the file contains the entire code for the application, its id field was limited to 4 hexadecimal digits. So when an application had over 0xffff methods (=65,536 in decimal), the dex file simply could not be created, meaning applications with so many methods could not be created.

That posed a problem as applications became more and more diverse and complex, and as many developers looked to speed their development process by not doing everything from scratch, but by using more and more third-party libraries (SDKs) that help them achieve their goals faster.

Android released a support library which helps you create an application with over 65K methods. In a nutshell, the compilation process to of Java bytecode to dex was enhanced so that once the limit is reached, a secondary dex file is created. The support library then offered a static method Multidex.install which is called when the app is being launched and tells the class loader to look for methods in places other than the one dex file is expects.

However, we’ve seen the solution is not ideal. Issues ranging from prolonged compilation time to a static process repeating every single time the app is launched made the multidex solution a workaround compromise rather than something Android developers could truly trust. What might be the most burning issue is the lack of ability to predex (compile the not-likely-to-change parts of your app to dex only once; Again, for more information, take a look at part 1).

Continue Reading

Solving Android’s 65K Limit: The Unbearable Lightness of Multidexing

June 16, 2015 7:39 PM
 

If you’ve been developing for Android for some time now, you might have encountered a little thing called “The 65K limit”. You must have at least heard about it around the water cooler. There were times were Android developers dreaded it.

You see, the Android system put an almost arbitrary limit on the number of methods an Android application can have. A limit which may have sounded reasonable in the past but is near far-fetched in today’s terms. The limit itself, which stands roughly around 65,000 methods, may sound a bit excessive. “What are the odds I’ll ever reach that?” a novice Android developer may be thinking. However, applications are using more and more third-party libraries (otherwise known as SDKs – Software Development Kits). Just imagine writing your app and wanting a library to help you parse JSON objects, wanting to connect to a social network such as Facebook, or looking to make a profit for your effort by displaying ads in your app. All of these libraries add more methods to your app, and slowly that high limit doesn’t seem so unreachable.

Adding insult to injury, Google themselves contributed massively to the problem, with their Play Services SDK containing a whopping 29,000 methods! That number is almost inconceivable – that is nearly half of the limit (In an upcoming post, I will describe how you can reduce the number of methods you get from this SDK. Stay Tuned).

Today, however, things are different and solving the limit issue is quite simple. So simple, actually, that many apps found refuge in it. Today there are apps in the Play Store with well over 80K methods!

Continue Reading