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.
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.
Important notice: The Method Count Continues to Grow
The most important thing to know about the new version of Google Play Services (7.8.0) is that the overall method count has grown.
In fact, the mandatory base package has made an 8.6% leap and has increased by 687 methods. For developers struggling to stay under the 65K limit, that’s an issue. It just might be the nudge that throws them over the border into the land of multidex, which is mostly characterized by a slower compilation process.
The overall method count has increased by 5.6% from 28,175 methods to 29,760 – over 1,000 methods have been added! Some of that may be attributed to a new package called Mobile Vision, which has over 400 methods.
Personally, I believe that’s a challenge developers can overcome, since Google have given the capability of only using certain selected packages. So if you’re still using the entire pack, it’s time to stop and employ the super-easy method to reduce your count of methods.
Not 100% sure which packages you’re actually using? Run your app through the SafeDK App X-Ray and find out, or run your competitors’ apps to find out what they are doing…
Let’s Get Down to the Numbers: Methods per Package
Below is the summary of the new 7.8.0 version, detailing how many methods each package contains, the dependencies it has and how the method count has changed compared to the previous version (7.5.0):
|Package||Method Count||in 7.5.0||Added Packages||Total Method Count||in 7.5.0|
* Google Ads and Google Analytics have another dependency called “tagmanager” which has 936 methods in both versions.
It’s interesting to see how even when some packages have hardly changed (or reduced their method count), their overall size grew due to the growth in the base package.
Lose those Excess Methods
There is no real good reason to have unused code inside your app, especially with the 65K limit. It’s always good practice to only keep the code that you use. And since I believe that Google will (and should) continue to provide app developers with as many enrichments as possible (with the option to use only some of them), I advise you to take a look at my previous post and only use the packages you truly need for your app.
By the way, this suggestion is not for Google Play Services only. Any third-party library you’re no longer using shouldn’t be compiled in your app. Run your app through the SafeDK App X-Ray to see which SDKs you’re no longer using.
In our next post, we will provide some insights on how many unused third-party tools (SDKs) are in apps. Stay tuned, it’s pretty surprising.