Sure, most statistics are „pure fabrication“ and indicators at best. Keep that in mind while reading this article All I write here is based on statistics collected of about 13.000 selected apps – out of how many millions? And was my selection subjective? Of course I´ve left out a lot; after all, my app listings should not bomb you with duplicates and low-quality-apps, but give you a good selection (with good, again, being quite subjective). Moreover, some areas are not covered altogether (e.g. games and some „asocial stuff“ like Facebook & Co).
But that doesn´t mean my stats are useless. Though not being perfect, you will see there´s a lot we can learn even from such a small, subjective collection. After all, those 13k apps cover a lot! And learning something about apps in general, we will see there´s an essence we can apply to the „object of our desire“ in special. Count everything here as a „raw guide“, and we should be fine
The average app
So what does the average app look like according to IzzyOnDroids site statistics? In short: It requires 8 permissions, costs 0.70 EUR, and was last updated 1.5 years ago.
Oops. That old? Why so? Many (good) apps have been abandoned by their resp. developers, unfortunately. If they still seemed useful and were available in any of the markets linked from here, I saw no reason to remove them1. Those bring down this value. On the other side, about 50% of the apps listed here had releases within the last 12 months.
Apparently good news also for the price we have to pay per app: about 80% of all apps come free-of-charge. But, as the last pie chart shows, we may have to pay by other means: permissions2. If the „average app“ requests about 8 permissions, this does neither mean an app requesting less is automatically „good“ (think of a torch light app just requesting
READ_CONTACTS: only two permissions, none of them needed, indicating this one spies on you) – nor that an app requesting more than eight permissions is automatically „bad and greedy“ (think of an app to remote-control your device from your computer, where you want read/write contacts, calendars, mails, short messages, call logs and more plus getting notified about incoming calls or even initiate calls – these features alone would require more than ten permissions).
Speaking of permissions: apart from the fact how their „requested amount“ distributes across all apps, there´s another statistic worth looking at. Are there certain categories in which apps request excessively many permissions? And if so, is that justified?
If someone wants to sell you something „really cheap“, there´s usually a catch. Looking at the first chart, the leading category on „average permissions per app“ is „cheaper calls“; an app in this category on average request 23 permissions. In words: twenty-three! No other category has such a high number (even our greedy, so-called „Anti-Virus“ apps stay below 20). This should at least raise an eye brow, shouldn´t it? So lets take a look here. There´re a indeed a bunch of permissions making much sense: read/write access to contacts and call logs: check. Make phone calls: well, sure. Even internet and SIP. Internet calls might need account stuff (list accounts, use credentials), and payment might happen via your Google account. Sums up to a bit more than ten permissions. Granted, some apps additionally offer messaging services (short messages). If they allow for video calls, they might need the camera. All in all, for most of the apps here most of the permissions indeed seem to be justified. But what for do they need your location, read your „social stream“, play with sync settings? Some even want access to your mail. So as usual, better check twice – even if the permissions requested are fewer
Big surprise in the second graph here: about 80% of all apps want the
INTERNET permission. Who would have thought that! Along goes the permission to check whether there´s a network connection available (I rather wonder why this number is lower, as before using the network an app should check if it´s available). Next comes access to your SD card: read and write both with about 63%, again no big surprise. About 35% of all apps want to keep your device awake in certain situations.
READ_PHONE_STATE meanwhile got down to number 8 with about 29% – that´s some good news, as about a year ago it was on number 5 with more than 35%. A change in the Google Play Store policies might be responsible here, forbidding ad modules to access the device-ID for identification. A bit surprising: Access to your location doesn´t come in before „number 9“ (at less than 25%). Intuitively one certainly had guessed on a higher number for that. Our top-ten ends with apps which want to start right when the device has booted: 24% of all apps listed here want that.
No, I did not forget about the third graph – but that´s a really special one and worth its own chapter. You might know there are not only those permissions defined by the Android OS, but each app can additionally define its own permissions. This is usually done if it provides some interface to other apps, and the dev wants to protect access to that interface so the user knows when another app makes use of it. This is the case with many of the Google apps; the best known candidates belonging to the Google Play Store app: Billing and License Check. So by those permissions we can see how many apps have been glued to the Google ecosystem: according to my stats, more than 35%. So if you happen to run a device without Google Apps3, what does this mean to you? Such an app might miss some functionality4 – or it might refuse to start or even to be installed at all (what my graph calls „hard glue“). Luckily it seems only about 15% of the apps are „hard glued“, and in some cases it can be worked around5. But as soon as an app wants to verify its license, you´re doomed: no open-source implementation of that part is available6. Which means, a bit more than 10% of the apps won´t work for you – unless the devs provide you with an alternative7.
Not all permissions are counted here. As I wrote, apps can define their own permissions – and other apps can request them. Additionally to that, some apps request „bogus permissions“ – i.e. permissions that do not even exist. That´s either due to spelling errors, bad guesses, mistakenly requesting the permission group instead of the permission, or listening to wrong or outdated tutorials: I´ve identified 18 „bogus permissions“ so far, requested 396 times by 304 apps. Top candidates are pre-Android-1.0 permissions like
android.permission.ACCESS_GPS and bad guesses like
android.permission.WRITE_INTERNAL_STORAGE8. As this usually goes unnoticed for multiple versions of an app we can deduce those permissions are not only „bogus“ – but the „intended permission“ was never really needed.
Besides: if you think this can only happen to inexperienced developers, you´re wrong. It even happened to Koush (his Helium Backup requests the permission group
Other interesting notes
If you´ve got a bunch of data at hand, you might get curious on „strage combinations“ – and indeed I´ve found some. For example, 3% of the apps request the License Check permission though they are available for free, while about 1.5% are paid and still want to be paid more (in-app-billing).
It comes at no surprise that the Google Play Store is by far the largest „mall“ of Android apps. So about 90% of the apps listed here at IzzyOnDroid are available there. Still, more than 25% are available at alternative places like F-Droid and in the Aptoide Apps repository.9 While the Play Store definitely has more than a million apps, you can find 1.800 apps at F-Droid and about 100.000 apps in the Apps repository of Aptoide. The XPosed repository will soon hit the 1k mark as well – while the new repo found at this site just holds less than 100 apps. There are apps found in multiple places, while others are only available in one of the mentioned stations.
If you have ideas for other types of statistics which I might have missed, let me know: if they sound interesting, I might go and update this article
Apps in the listings here get removed when they´ve not been available for more than 6 months – or when they´ve not been updated for more than 4 years while having a rating below 3. The first happens automatically, the latter manually (so there may be a delay with that kind of removal). ↩︎
Which you might not even notice, e.g. if you´re not using GMail you won´t access that part of the app at all. ↩︎
An app using the Google Maps API will refuse to be installed due to a missing library; my article on microG shows a work-around for this by using an open source implementation of that API which integrates OpenStreetmap instead. ↩︎
Nor is that likely to ever happen: no dev dares to „touch the heart“ of Googles business here, it might pay badly. ↩︎
An app might utilize different means of checking your legit use, and only refuse working if all of them fail – or it might just restrict its functionality if the check fails. ↩︎
Note that this site by far doesn´t cover all places – especially the Amazon Apps store was not accounted for. ↩︎