Android statistics: May 2018

It's not long ago that I posted about the Android statistics of April 2018, but new statistics have been released by Google, so it's time for an update.
https://developer.android.com/about/dashboards/

Statistics, facts and trends

Versions over time

Click to expand versions over time image.
Facts about the Android versions compared to previous month:
  • Android 8.1, 8.0 and 7.1 are increasing in market share
  • Android 7.0 is stabilizing and will not increase much further, if at all
  • Android 6.0 and 5.1 are decreasing in market share with +- 1% per full month
  • Android 5.0 and 4.4 are decreasing as well, but at a lower pace

Codenames over time

Click to expand codenames over time image.
Facts about the Android codenames compared to previous month:
  • Android Oreo has a steady increase in market share
  • Android Nougat is reaching the top but is still increasing slowly
  • Android Marshmallow and Lollipop have a steady line downwards
    • It will take +- 1 year before these reach 10-15% market share
  • Android KitKat is decreasing and it will take +- 6 months before it will reach 5%

General trends

No changes from previous post.
  • New Android versions take about one to two months after release before we see them appearing in the statistics
  • It takes at least 6 months after first appearance in the statistics to gain +- 5% market share
  • For each codename, from the point it has 5% to the point it's on the #1 position takes about 1 year
  • It can take up to a year after the version/codename has reached it's full potential before it starts to show a steady decrease in market share
  • Steady decreasing versions will loose +- 10% market share per year
  • Decreasing versions that have reached the 10% market share line will loose +-5% in the following year
Location: Wassenaar, Netherlands

Comments

Post a Comment

Popular posts from this blog

PowerShell - How to overcome Azure VM's fixed resolution limitation

Image
Intro This is the first in a series of PowerShell blogposts. I don't know a lot of PowerShell so I'm going to cover this part very short. What is PowerShell? PowerShell is a very powerful framework you can use to automate tasks. For more info, use Google or check the Wiki:  https://en.wikipedia.org/wiki/PowerShell For my current project we use Azure VM's that we use as selenium-grid (hub and nodes). And Visual Studio Online for kicking off builds. So I started to use a fair share of PowerShell in my test automation process. During the setup I came accross a couple of problems that I want to share with you all which I'll spread across a couple of posts. And we start with Azure VM's that have a fixed resolution of 1024 x 768 and how to overcome this issue/limitation. Azure VM's resolution limitation  Let's start with the problem we faced. Our website under test, requires the test machine to have at least a certain resolution ( Which is > 1024 ...
Read more

TA Basics: Website Test Automation on mobile devices via Appium server

Image
Recently I have been focussing on test automation with mobile devices. Specifically Android and iOS (no Windows phone because that platform is as good as dead at the moment). I first wanted to make a complete manual from setting up software and devices/simulators up to a small test script. But due to lack of time I'll focus on specific parts. If you have any questions reguarding the setup, feel free to contact me. So all that said, let's get to the point. The internet is full of blogposts, video's and examples of people testing mobile apps. However I don't test an app, I want to do some web test automation on mobile devices. It took me quiet some time to figure out what exactly I had to use to get it all to work as needed for my project. Setup Mac mini running OSX 10.13.4 High Sierra (Mac machine is needed for iOS simulation) Ruby version 2.5.0p0 (2017-12-25 revision 61468) [x86_64-darwin17] Appium desktop version 1.4.1 (with Appium server 1.7.2) lapis_laz...
Read more

Test Automation on real devices versus emulator/simulator

Image
Emulators and simulators look like a cheap alternative compared to testing on real devices. And that is true if you only look at the value of the device. But it's not per see true if you look at the quality of the test results. In this blogpost I'll show a real life example where testing on an iOS simulator failed to reveil a bug that was present on a real device. Website design (desktop versus mobile) Unlike the desktop (where there is enough space to show everything at once), the mobile view is limited and therefore part of the information is shown at the time. Our website is following Google's Material design as much as possible, so the mobile site works a bit like the Gmail application on your phone. The hamburger menu is visible at first, but when you open an item (like an e-mail in the Gmail app), the menu button transforms into a back button. So when you want to get back to the menu you need to press the back button first. When you do press the back button, the...
Read more