How Fragmented Is Android?

I work on an Android app aimed at the North American market.<p>Android O, P and Q are 88% of our Android devices. By far and large, fragmentation is something I _never_ have to think about.<p>Jetpack libraries are here to handle it for us, as an abstraction layer between the OS and third party apps.<p>I would have mentioned that e.g. camera apps are an exception : here hardware fragmentation can be a pain. I was half surprised to see that Google is also working on that one with the camera x library.<p>There have been cases where the fragmentation bites us; and there might be in the future (although in all fainess my iOS colleagues sometimes have to create specific fixes as well) but the last time I had to scratch my head because of a device specific bug was years ago.<p>And at the time, I was already finding these articles deeply ridiculous.

Well, if you remove all iOS versions with &lt;3.42% penetration, then you should remove the same from the Android table and use 2 decimals for Android like for iOS.<p><a href="https:&#x2F;&#x2F;i.imgur.com&#x2F;0Ar0ta5.png" rel="nofollow">https:&#x2F;&#x2F;i.imgur.com&#x2F;0Ar0ta5.png</a><p>My point being: there ARE other iOS versions in use. I have a backup working iPhone 4 turned on right now. It won&#x27;t upgrade beyond iOS 5 (I think it&#x27;s iOS 5). But somehow the author ignores all those 0.1% iOS versions, yet shows them for Android (with 4 decimals no less).

The article concludes, as far as I can tell, it isn&#x27;t fragmented, it just has a bunch of recent enough versions on similar enough devices to run most apps.<p>Apps don&#x27;t care what version of Android you run, they care what API support you have, and apps can detect API support at runtime and adapt.<p>OTOH, the article fails to mention that Apple refuses to let you support devices after EOL, and even some of the oldest Android devices in existence can run even the newest Android, as long as you&#x27;re willing to upgrade the ROM yourself.<p>Phone hardware typically is literally falling apart after 3-5 years, any truly old phones are ones that users have chose to keep on life support but not upgrade their ROMs (or made the mistake of buying a phone from a consumer-hostile brand, which is, ultimately, the only valid argument for Android fragmentation).<p>The <i>only</i> company that is truly consumer hostile is Samsung. And, frankly, I don&#x27;t know why anyone would buy Samsung <i>or</i> Apple <i>or</i> even Google&#x27;s own Pixel series... OnePlus charged me $550 for a phone (the 6T) that has the same size screen (and its an AMOLED too), literally same parts, but with more RAM and storage, and a bigger battery, that is otherwise identical to a Pixel 3XL or a Samsung S9+ or whatever top tier extra large phone that costs $800-1300; and that new 7 Pro? Still an amazing deal, and OnePlus supports Android on their phones ridiculously long times.

Something that doesn&#x27;t get talked about as much is the differences between how manufacturers customize their OS. It has been talked about a fair bit on HN (<a href="https:&#x2F;&#x2F;dontkillmyapp.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;dontkillmyapp.com&#x2F;</a>), but it really is a huge problem.<p>I can be listening to music on my phone and One+ will just kill Pandora, or Spotify. I have to manually &quot;lock&quot; music apps and workout apps in One+&#x27;s task switching UI to keep them from being randomly killed <i>while in use</i>.<p>Hilariously enough I have one game on my phone that will always run in the background and never be killed, sucking down a lot power. Somehow even when not in the foreground it consumes massive CPU. I don&#x27;t think it is even malicious, just oddly programmed. I wish my music apps could pull off the same trick though!

These articles rarely go over what, if any, practical concerns there are. The Wintel market is even more fragmented, but that&#x27;s not really an issue in practice because the abstractions are more or less in the right place.

&gt; My POV is ... Apple leads the Mobile OS market share ... by a huge margin.<p>I&#x27;m having a really hard time understanding this statement. Does the author mean with respect to how updates are handled? It clearly cannot mean in terms of sheer number of installs, Android is clearly _leagues_ ahead of iOS in that regard.

The fault of fragmentation lies at many levels, including distributors. The bookstore at my alma mater in the Midwest is normally great at promoting modern tech products, but they recently started pushing two models of a phone with KitKat at $100+ pricepoints. That&#x27;s Android 4.4, which was deprecated in 2015. Who are these phones for? They&#x27;re not even suitable for computer science students, because trying to learn Android development with a KitKat device is incredibly suboptimal.

I know this post is about Android versions but I recently launched a new service and have been watching user agents and I’ve been pleasantly surprised to see no matter the Android version, it’s almost always running Chrome 73&#x2F;Firefox 66. I have a user running Android 5.5.1, another on some version of 4! Yet they’re on modern browsers. This isn’t true for anyone on an old iOS. Those users are stuck with old browsers, which is quite sad for the user and developer.

I&#x27;m not a professional app developer. A year ago I invested few months to develop an app I wanted to have. Today it has few thousand users.<p>Fragmentation doesn&#x27;t bother me. Yes, on some devices the app crashes, on others the sound lag is unbearable. I don&#x27;t really care, as long as it works fine on most devices. Two things infuriate me, though. Enough to never again spend another minute developing for android.<p><i>Every</i> time I enter android studio, it wants to update. The studio wants to update. Suddenly it&#x27;s incompatible with build system (yes, the build system has dependencies on IDE version!). Then gradle wants to update. Then SDK. Then IDE again. It&#x27;s never-ending cycle of updates. Each update has 20% chance to cause build errors on this project (Love2D for Android). Each error has a cryptic message, and it&#x27;s resolved by something completely unrelated to error message. Usually it&#x27;s solved by bumping up the minimal SDK version and thus cutting off some percentage of potential users. I dread each and every attempt to re-build my app.<p>The second thing is recent requirement to provide 64-bit version of each app. My app depends on framework written in C++ with additional libraries in C. I can&#x27;t and won&#x27;t spend time to get the build for 64-bit version working. Google sent me a mail that &quot;All new apps and app updates are required to provide 64-bit versions of any 32-bit native code they provide&quot;. So I won&#x27;t be able to update existing app to existing users ever again, for non-technical reasons.<p>Fragmentation I can deal with. All web developers deal with it daily. But Google&#x27;s treatment of development is horrible and I don&#x27;t want any part of it. Because of this I&#x27;ve transitioned to web as platform. At least I can be safe that anything I build will be runnable in 10 or 20 years.

Old Android devices that cannot be upgraded is a headache for service that can&#x27;t afford to lose customers who still use old smartphone.<p>One of the colleague once estimated that just giving a new Android phone to all customers who is still using annoyingly old phone is better solution than supporting old Androids. He calculated the cost of supporting old Android(amount of time wasted multiplies by engineer&#x27;s wage). He concluded that it&#x27;s actually cheaper for a company to give every old android users of our service a new phone than diligently supporting old Android versions. Also, it greatly improve the QoL of engineer.<p>Sadly, our company never executed this plan.

We support API versions 19-26 on our Android side, and it&#x27;s a pretty major pain. The permissions model is different, background services work completely different, and then there is the tendency for things to just stop being supported (looking at you, GCM). Compared with the Apple ecosystem it&#x27;s incredibly jolting. I mean, I get it. Android started from the opposite end of the spectrum from Apple, and now they&#x27;re sort of meeting in the middle. But it&#x27;s been a much smoother ride working with iOS over the last couple of years than it has been working with Android.

I have an ipad 3 (yah the original ipad on its 3rd iteration). Apple was supporting os updates until fairly recently. The thing is that none of the modern apps tested or cared about something that old. So even if was technically supported the experience was borderline unusable. Even the core ipad usage was klunky. Stuff gets old and we move on.

I&#x27;ve been tracking the data from Google&#x27;s Android dashboards over time : <a href="https:&#x2F;&#x2F;www.bidouille.org&#x2F;misc&#x2F;androidcharts" rel="nofollow">https:&#x2F;&#x2F;www.bidouille.org&#x2F;misc&#x2F;androidcharts</a><p>From these observations, it seems that Android&#x27;s fragmentation is getting worse, and that newer versions of Android have more and more trouble establishing themselves as the dominant version. In fact, JellyBean was the last version to reach more than 50%.

From the article: &quot;So the Android ecosystem is split between at least 1,728 combinations of OS - Brand - Device Model&quot;<p>It&#x27;s actually _much worse_ than this. Here&#x27;s a review of the &quot;Samsung Galaxy S10+&quot;: <a href="https:&#x2F;&#x2F;www.anandtech.com&#x2F;show&#x2F;14072&#x2F;the-samsung-galaxy-s10plus-review" rel="nofollow">https:&#x2F;&#x2F;www.anandtech.com&#x2F;show&#x2F;14072&#x2F;the-samsung-galaxy-s10p...</a><p>This &quot;device model&quot; is actually two devices with completely different SoCs. There is no meaningful sense in which these two phones are one device. Sometimes the manufacturers document this, sometimes they just start selling a phone that identifies itself by the same name as an existing phone but with a GPU that has completely different performance characteristics.

&gt;<i>12.X has about 80.5% market share...</i> [of the iOS market] <i>My POV is ... Apple leads the Mobile OS market share ... by a huge margin</i><p>That&#x27;s a rather dubious view of market share, parsing the definition to include only the most recent version of an OS. Under that mode of accounting, I&#x27;m sure MacOS enjoys market share &quot;dominance&quot; briefly after each October update of Windows. But if we extend Android version back just to 8.x then ~46% of all android devices are accounted for, and 46% of Android&#x27;s total 75% of mobile install base is still quit a bit more than 80% of iOS&#x27;s 23% mobile install base.<p>And even that I don&#x27;t really care about. iOS is a great OS. What I don&#x27;t like are sloppy definitions and methodology in something that presents as data analysis.<p>It&#x27;s a stretch to say each manufacturer that puts what amounts to little more than a custom skin and vendor-specific apps constitutes its own distinct fragment. So too is it disingenuous to represent each point-release of Android as a separate fragment, especially when the author goes on to lump all iOS 12.x point versions together.<p>I&#x27;d also say that fragmentation, in some small way at least, works in favor of android users that have older versions installed because apps can&#x27;t just target the latest version given that vendors don&#x27;t push the latest updates to all users. It means older devices can still get many&#x2F;most new apps on their devices. Contrast this to Apple, where not updating to the latest version can have an impact on app availability much sooner, while updating the OS tends to degrade (in my subjective experience) user experience significantly when you hit the second or third such update. Last time I had to update my kid&#x27;s ipad to a newer iOS version it basically killed it. It was necessary so she could play minecraft again, but the device became unbearably slow, and minecraft crashed anyway. (My solution was to &quot;upgrade&quot; to an $80 kindle fire kids version, which plays minecraft quite nicely. <i>That</i> I&#x27;ll admit is absolutely its own fragment of Android though)

Most people never have to deal with this though - I wonder what the % of these figures are things like Smart TV&#x27;s and various other Android devices.<p>For the most part it isn&#x27;t a problem for us - we require Android 6+ and for the phone to have various sensors.<p>Some of our customers can&#x27;t afford the latest or greatest Android devices - that&#x27;s fine - we will do our best to support them.<p>Could Android do what iOS does? To a degree yes, they would just have to cripple phones forcing people to make the choice between newer software and a slower phone or leaving something that works just fine as it is....

Khronos likes to talk about Vulkan support on Android.<p>The reality is that thanks for it being an optional API, introduced in version 7, only flagships have proper support.<p>And even then, each OEM provides a different version, with their own set of instructions.<p>Hardly any better than GL ES.<p>Now they are doing it compulsory on Android 9, upgradable via the store, with GL support being supported via ANGLE.<p>Guess what, first you need to get a device with Android 9 on it.<p>This just an example among many others across other API surface areas.<p>So much for Java on mobiles being too much of fragmented system that Google was going to sort out with their solution, hence the need to undercut Sun.

But does this fragmentation actually matter? For most apps which are at most accessing some sort of online data, like a web shop, chat apps, etc. you just target the lowest API that has the features you want and it&#x27;s compatible with all newer Android OS releases.<p>I would think the real fragmentation that developers have to consider is in things like screen size, or custom APIs by hardware vendors. In my experience, it&#x27;s the difference between Samsung&#x27;s bluetooth stack and Android&#x27;s own

I work at a company that distributes an Android SDK specifically for East&#x2F;West&#x2F;Southern Africa and South Asia. So far (and we are extremely early stage) we&#x27;ve seen 2,992 unique make&#x2F;model combinations, and from there the OS ranges from v4.3 - 9.0 and everywhere in between. There&#x27;s a huge backward compatibility problem in these markets -- we had to build our own dual sim API because of it. Device specific issues are extremely real, and as far as I can tell, Google does not have a great strategy for these markets that make up a not insignificant (and growing) portion of their market share. Android users who are sensitive to data usage&#x2F;costs don&#x27;t upgrade their OS often, and have secondhand or imported devices with some kind of customized OS.<p><a href="https:&#x2F;&#x2F;medium.com&#x2F;use-hover&#x2F;hover-launches-v1-0-stable-and-scalable-f65e33731090" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;use-hover&#x2F;hover-launches-v1-0-stable-and-...</a>

1) Do this analysis for your own user base, universal stats may not be relevant.<p>2) It&#x27;s more helpful to look at aggregations on cuts that will impact your product and codebase. e.g. % of devices above API level 19, % of users with each screen size grouping, what % of our users are on tablets, etc. These answer questions when you should drop support for an API, when you should start using new features, how many different UI mocks you need. Those are the relevant questions.<p>3) Do test your UX across a couple different phones categories. Samsung &amp; vanilla Android have different button placements and icons.<p>4) There are plenty of libraries and tools available to handle this problem. I won&#x27;t say it&#x27;s not something to think about, but it&#x27;s usually pretty low on my list.

Should be more fragmented, until it gets to the point where I don&#x27;t have to have ads kicking in my teeth daily.

In practice this is a non issue, even for larger apps with a big user base. This is just trolling.

Last I checked, for our popular mobile game, there were over 28,000 different models of Android phones represented in the analytics from a single day. Multiply that by Android versions, manufacturers, hardware specs... it’s a mess that is hard to wrangle.

I&#x27;m wondering if letting your app support very old OS versions is a good thing. You get more customers but aren&#x27;t the ones with the old OS more likely be the ones causing the most problems (= work) because they aren&#x27;t very tech savvy?

&gt; ...owners (hopefully) buy a new Android device which offers latest updates.<p>A new Android device will get one “latest update”. Before the user buys it. After that, it will be just as fragmented as the rest.

But what this article doesn&#x27;t take into account is that Android is obviously split over tons of devices while iOS is, of course, set for Apple devices

&gt; The vast majority of iPhone users update to the latest version quite fast and flawlessly.<p>Has this person ever been around iPhone owners when a new update comes out? I seem to remember a ton of lamentation at every step of slower speed, worse battery, laggy UI, moved features, removed features, and the like.<p>Yeah, there&#x27;s a lot of different Android versions out there. Who cares? Other than security updates, it&#x27;s pretty much a non-issue. Developers target the version they want to support and publish their app online.

I&#x27;m surprised to see Marshmallow (6.0) below Ice Cream Sandwich (4.0)

This is asinine. Android&#x27;s support library makes fragmentation a non-issue for the vast majority of applications.

Android is, as all US technology, a counterparty risk.

every article preaches the same absurd fallacy: &quot;<i>users</i> update the OS more in so or so&quot;<p>Users have absolutely no say! Planed obsolence does.<p>every single device could be running the latest version just fine. But the manufacturer intentionally decide to not offer (or allow!) the update on not cases.<p>This is pure greed over consumer rights (or respect).<p>want the latest security patch on your 2yr old $600 device? too bad, trhow it in the landfill and buy a new one (often with worse features)