Grokking Android

Getting Down to the Nitty Gritty of Android Development

Surprising Statistics on Library Usage in Android Apps

By 2 Comments

AppBrain published statistics on library usage on Android. This list of libraries is very interesting and to me quite surprising.

These stats are presented on three tabs: “Ad networks”, “Social SDKs” and “Development tools”. Here I care about development tools only.

For example the two most-used libraries are those of the leading analytics providers, Google and Flurry. No surprises here. But what is surprising, is that together they are used by less than 14 per cent of all apps. Why is this number so low? I would have guessed that most apps, that need an internet permission anyway, would also use one of these packages. After all, we are interested in usage patterns, aren’t we? How else should independent developers improve their app, since they do not have the means to conduct extensive and costly usability studies?

Even though only about 13.5 % of all apps available in the store use these packages, 36 % of all installed apps have this package on board. If you drill down into the data (by clicking on the library) you see, that more successful apps use analytics more often than others. Together both libraries are used in 60 % of the top apps. Quite a difference. Still I wonder why the developers of less successful apps do not care about these data. Maybe because for top-developers much more money is at stake?

The third library in the list is the Android Support Library. Also no surprise here. But while 6 per cent use this library only a shockingly low 0.96 % also use ActionBarSherlock. Huh? Why is that? This is IMHO depressing – and, no, I have no affiliation with +Jake Wharton at all. But I think the actionbar pattern is very useful and should be part of most apps. And Android’s design guidelines think so as well:

The action bar is arguably the most important structural element of an Android app.

ActionBarSherlock is such a a great library to support this pattern on older versions of Android as well – so why not use it?

Another surprise is the near absence of gaming libraries. I could only spot libGDX, AndEngine and Unity3D which are used by roughly 1 per cent of all available apps each. With 6 % usage among installed apps it’s a bit better. But, come on! About 25 per cent of all installed apps are games. Why then are there not more gaming libraries in use? Do game developers love to write their own engines? Well probably. But nearly all of them?

The picture is quite different for the tab “Ad networks“. Admob is used by 33.49 % of all available apps and 46.99 % of all installed apps. Whow! That’s finally a number I am not surprised about. Well, perhaps that one network is that dominant. But that ad networks are used a lot, that’s no surprise. We see ads every day – and most of use make use of these networks as well.

But still: To me some of these stats simply make no sense. Maybe some of you can explain these numbers? Or are these numbers what you would have expected anyway?

Wolfram Rittmeyer lives in Germany and has been developing with Java for many years.

In recent years he shifted his attention to Android and blogs about anything interesting that came up while developing for Android.

You can find him on Google+ and Twitter.

2 thoughts on “Surprising Statistics on Library Usage in Android Apps”

  1. I suspect many of the “professional software companies” are coming from the iOS world and don’t really dig that much into the Android world, don’t really care about any community, and so they probably never heard about the more or less popular(?) libraries. Some have done big efforts to port iOS controls to Android and probably are re-inventing the wheel over and over again. If they would only take use of what the Android community offers then development would not only be more productive but the resulting app would better integrate into the Android ecosystem. So not using common libraries is rather a mistake. Looking at the quality of the majority of apps is already proof enough!

    I was once working for a company that focused on mobile development and one day we’ve got a company ask us to develop a framework to share game achievements to Twitter, Facebook, etc. I got never around to estimate our efforts for some reason (huh? 😉 ) but it’s another sign that companies are spending money on re-developing such great features each time again, even though there’s already built-in support in the OS.

    I understand that big game developers use their existing engines and port them to the various platforms they are supporting. And small “hobby developers” are probably developing their own engines based on some tutorials. But for better stability and less “fragmentation issues” it would probably be better if they would use existing game engines instead.

    Besides, I don’t use any Google or Flurry statistics in my apps yet because I rather want to avoid the Internet permission when it’s not really needed. If you add such stuff, then you’ll probably also need location and phone call ID permissions and then you’ve got plenty of users getting suspicious on it!

    1. Wolfram Rittmeyer

      Yes, those ports of iOS apps often look like the developers are not part of the Android community.

      But I my guess (!) is that at least half of all apps are made by independent developers. And those are hard-pressed for time anyway. So this alone should be reason enough to look for libraries, shouldn’t it? Better quality (better tested). Faster development. And often better looks.

      As for the analytics libraries: Yes, they require an internet permissions. But if your app requires it anyway (e.g. because it must download data), than I would add it. It is still a privacy issue – but with IP anonymization I think that’s okay.

      BTW: Flurry only needs internet permission. With location permissions it will track these data as well:

      And Google needs internet permission and check network state permission:

Leave a Reply

Your email address will not be published. Required fields are marked *