I work on an Android app aimed at the North American market.
Android O, P and Q are 88% of our Android devices. By far and large, fragmentation is something I _never_ have to think about.
Jetpack libraries are here to handle it for us, as an abstraction layer between the OS and third party apps.
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.
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.
And at the time, I was already finding these articles deeply ridiculous.
It sounds like you're rolling with whatever Google's latest 'solution' to fragmentation is, so of course it's not going to be an issue: Google is dropping old devices for you so they never even appear in your console stats.[1] This is a perfectly valid business decision to take on your end, but it doesn't mean that the problem doesn't still exist... only that you aren't having to deal with it. I've got several still functional 4.x-5.x devices (thanks to stellar upgrade policies) that can't even use the market anymore (so much for compatibility libraries being the solution)[2] I've also done Android development and years ago stopped believing that the real solution they have to offer is anything other than throw your devices away after a few years. Me bitter? Only when I read posts saying fragmentation is a solved problem on Android ;-)
[1] You say that O/P/Q are 88% of your devices but they only represent 38.7% of devices accessing the market (Q doesn't even show up) per https://developer.android.com/about/dashboards. Likely the solution Google has provided ignores a significant chunk of devices out there. When they announce these new initiatives, they tend to support the most widely-used and recent devices while quietly ignoring the rest. A valid strategy, but hardly comprehensive. (yeah, yeah... this time is different)
[2] Technically, they can still access the market, they just can't download anything. Probably either some web API breakage or no longer supported version of something on the device.
+1 I have a few hobby apps on the app store that gave had a few thousand downloads. Not a huge sample but generally speaking it's N+ that has the vast majority of users. My apps are fairly standard or are games - most API levels since M seem to basically cover everything I need 99% of the time.
I have no interest AT ALL in the manufacturer of the device.
Fragmentation simply doesn't feel like an issue, at least to me.
I’ve been doing iOS since 2008 and the “specific fixes” are definitely more common these days! iOS used to be a simple platform with one standard phone size and tablet size but it started to increase in complexity with all the new devices today (I’m looking at you iPhone X). iOS 6 -> iOS 7-8 was such a pain to main backward compatibility because of all the navigation/status bar changes.
I still find iOS to be my preferred platform but the “it just works” feeling is no longer there.
...then you're fine and fragmentation is most likely a non-issue. OTOH, if you require
- openGL or 3D graphics calls
- read/write to removable storage
- video streaming, HLS streaming, or even local video file playback
- downloads/network fetches of larger amounts of files/data
- multi-touch UX
- rear and/or front or any specific camera access
- actually any hardware sensor/broadcaster/receiver access (gyro, accel, flashlight, bluetooth)
- OS manipulation (custom keyboard, replace default telephony/texting, modify native modals such as share view, register with the OS as a share-target, etc)
...then enjoy lopping off a chunk of your userbase (which you may have to specify manually, although Google helps with this) or struggling to write lots of OS detection switch statements with custom logic for handling each of these things. Working on an app that does 4+ of the things from the latter list, Android fragmentation has been and will continue to be a problem, even if it isn't really at any given point.
If we just want apps which move blobs of text back and forth between views and across the network, then yes fragmentation is not an issue.
The Q is of course: how many do you need to support. This is the same as with browsers. If you have to code for blind people using IE6 with JS off, you are coding for the lowest common denominator. This happens.
If you can just code for "The 90% with a reasonably modern browser, at least one working eye and JS enablded" then you are in a different situation.
Fragmentation hurts the people in the first camp that need to support 99% or more, for example if you are coding an app for a government service and not for a startup.
> 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.
The irony, is that Android was originally designed to be a Camera OS. So its still fragmented in the thing it set out to do.
Sure. Plenty of people can ignore the cheaper devices. But if you work for a government agency, you may not be able to. Or a bank. Or a utility. Or a telecom provider. Or a 1000 other businesses.
It's been awhile since I've done Android development, but are you including the Kindle devices in your numbers? Best I can tell the latest FireOS is based on Nougat.
"O, P and Q are 88% of our Android devices" - this is problematic because you're therefore serving only a fraction of the market.
A considerably number of companies have to actually deal with this fragmentation, for example, we have a product that integrates with a device via Blutooth, and we have to deal with this issue. We can't just 'not serve' a bunch of customers.
Well, if you remove all iOS versions with <3.42% penetration, then you should remove the same from the Android table and use 2 decimals for Android like for iOS.
My point being: there ARE other iOS versions in use. I have a backup working iPhone 4 turned on right now. It won't upgrade beyond iOS 5 (I think it'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't fragmented, it just has a bunch of recent enough versions on similar enough devices to run most apps.
Apps don'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.
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're willing to upgrade the ROM yourself.
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).
The only company that is truly consumer hostile is Samsung. And, frankly, I don't know why anyone would buy Samsung or Apple or even Google'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.
What makes Samsung phones consumer hostile? Their ridiculous prices? Because I wouldn't call that hostile, rather simply overpriced. And I would agree that they are.
However, I still have every galaxy note I have ever owned, working, and in great condition (Note 2, 5, and now 8). My dad is actually using the 5. All of them got upgraded at least once to a newer Android OS and they are still solid devices.
Granted, other than Note, I've only owned a Startosphere for the hw keyboard, so I can't compare it to others, but even after I realized that the Note 8 was crazy expensive and made me double think what my next phone will be, I worry if the longevity can be matched.
I buy Samsung, and now a Pixel, because I like their design better. (Much prefer the experience of the Pixel now) The price difference is a non-issue for me because I don't feel the need for the latest model, so I get last year's model at > 50% off the premium price. I'm with you: I'm astounded that so many people pay such a premium for the absolute bleeding edge. It would be like if enormous segments of PC buyers purchased massively high end gaming rigs just because. Marketing, I guess?
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're willing to upgrade the ROM yourself.
The 2012 iPhone 5 is the newest unsupported iPhone. Would you really want to support a phone that old and have to support both a 32 bit and a 64 bit version of your app?
> OnePlus supports Android on their phones ridiculously long times.
I would challenge that. I'm still waiting for Android Pie (August 2018) on my OnePlus 3T (November 2016). That's not even two years, and while OnePlus have promised to eventually bring Pie to this phone, it's already almost 9 months late. By the time the 3T is updated to Pie, Android Q will be out.
Something that doesn'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 (https://dontkillmyapp.com/), but it really is a huge problem.
I can be listening to music on my phone and One+ will just kill Pandora, or Spotify. I have to manually "lock" music apps and workout apps in One+'s task switching UI to keep them from being randomly killed while in use.
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't think it is even malicious, just oddly programmed. I wish my music apps could pull off the same trick though!
I had a similar problem with my OP6T. My hike tracking app would constantly turn off randomly in the middle of a hike. Having used Android for years I went through all the typical battery optimization settings, but nothing worked. I contacted the app developer and they had no idea what was causing it.
Eventually I stumbled on the "Lock" feature, which as far as I know is specific to OP, and that solved everything. I'm pretty annoyed with OP about it to be honest. Android has app-specific battery optimization settings built in but they just completely ignored them.
I don't think a lot of people understand how apps run in the background on Android. I know having worked on one recently, coming from iOS, I had a lot of assumptions about what it would or wouldn't be doing... and they were all wrong (of course).
Turns out Android, at least however this app is setup, maybe by default, leaves the app fully running. Like zero effort to suspend it automatically. A part of the UI crashed and a hunt to find the bug made me realize this... I fixed the bug, but still haven't really looked into how to really suspend it.
You should try disabling deep battery optimization in Settings -> Battery -> Battery optimization -> Advanced optimization. Unfortunately that feature is known to cause these kind of problems on OnePlus devices.
These articles rarely go over what, if any, practical concerns there are. The Wintel market is even more fragmented, but that's not really an issue in practice because the abstractions are more or less in the right place.
You can install stock Win 10 on any machine you buy, or most Linux distros with the same boot image thanks to UEFI and the PC spec. Android ARMs are NOT an architecture. They're random pins soldered to random shit with little upstreamable in their hacked to hell kernels.
Oreo and the /vendor partition may help with this some. Still, it's a far cry from the Linux/PCs days of the 90s. I've written about this before:
Wintel is something that could be taken down a notch, but it seems everything outside of the x86 family is even worse.
If I buy a Dell laptop or a Lenovo laptop, it will come with a bunch of useless junk installed that nobody in their right mind would ever want, like Lenovo's useless gigantic Wi-Fi icon in Windows (last observed by me in a T520). But not only can I uninstall all of that junk software, I am still running real Windows. And that means I can update it normally.
Compare that to an Android device. You get a phone from a company like Samsung and you cannot uninstall the Facebook app no matter what you do. You get a phone from HTC and maybe they decide to push an update from 7.something to 8.0 and 8.0 introduces a new issue. That is fixed in 8.1 but you can never actually upgrade to 8.1 because it's not the real version of Android it's the HTC version of Android and they have ordained that your device shall never go past 8.0 and they pushed some firmware "security" update that prevents you from installing any other OS on your device. Additionally, some software seems to be dictated by your mobile carrier, which would be like allowing Comcast to control what you run on your PC.
So whatever fragmentation there is on Wintel (or LinAmd), it is not nearly as hostile to the user as the Android ecosystem.
The articles states the vast majority of android phones do not receive any updates but Google is able to collect valuable data from these devices. I beleieve this is a practical concern.
> My POV is ... Apple leads the Mobile OS market share ... by a huge margin.
I'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.
Android doesn't brag it has 75% share. Actual data is that 85% of smartphones run Android and that's market share. Fact that they are not updated to the latest version doesn't change the market share.
He’s basically claiming that latest iOS has higher market share than latest Android version (which may be true), and from that concludes that the rest of the android versions in the market somehow don’t count, so iOS is biggest.
Android has its issues, but “math” like this isn’t the answer. This is drivel, really.
Also: See Wintel for fragmentation. Everywhere in nature and tech diversity is good. But somehow not for mobile phone OSes.
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's Android 4.4, which was deprecated in 2015. Who are these phones for? They're not even suitable for computer science students, because trying to learn Android development with a KitKat device is incredibly suboptimal.
A google search on 100$ android phones returned a "best cheap android phones" list. The first entry is the Nokia 2 (never tried one but I heard good things).
For 85$ it ships with Oreo.
That's kind of amazing : for a relatively modest sum, you get a lot of technology.
It makes me wonder why anybody would recommend a costlier device shipping with 4.4
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/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'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.
Fragmentation doesn't bother me. Yes, on some devices the app crashes, on others the sound lag is unbearable. I don'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.
Every time I enter android studio, it wants to update. The studio wants to update. Suddenly it'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'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's resolved by something completely unrelated to error message. Usually it'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.
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't and won't spend time to get the build for 64-bit version working. Google sent me a mail that "All new apps and app updates are required to provide 64-bit versions of any 32-bit native code they provide". So I won't be able to update existing app to existing users ever again, for non-technical reasons.
Fragmentation I can deal with. All web developers deal with it daily. But Google's treatment of development is horrible and I don't want any part of it. Because of this I've transitioned to web as platform. At least I can be safe that anything I build will be runnable in 10 or 20 years.
>Google sent me a mail that "All new apps and app updates are required to provide 64-bit versions of any 32-bit native code they provide". So I won't be able to update existing app to existing users ever again, for non-technical reasons.
Isn't the reason entirely technical? 64-bit apps can use 64-bit only instruction sets, which are newer and usually faster, resulting in a performance improvement. BTW, apple did the same thing years ago on iOS and is planning to kill 32-bit apps on MacOS soon.
> 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't and won't spend time to get the build for 64-bit version working. Google sent me a mail that "All new apps and app updates are required to provide 64-bit versions of any 32-bit native code they provide". So I won't be able to update existing app to existing users ever again, for non-technical reasons.
So the "non-technical" reason here is that you don't want to provide a build for users with 64-bit devices?
Old Android devices that cannot be upgraded is a headache for service that can't afford to lose customers who still use old smartphone.
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's wage). He concluded that it'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.
Well, salaries of employees are a fixed cost, so there wouldn't really be any money saved by giving away devices. At least, there'd be no money saved unless the company also then fired all of the engineers that were no longer needed because time didn't have to be spent diligently supporting old android versions.
We support API versions 19-26 on our Android side, and it'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's incredibly jolting. I mean, I get it. Android started from the opposite end of the spectrum from Apple, and now they're sort of meeting in the middle. But it'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.
Well, that's kind of the point: Despite the age, OS-updates to it shall make it work just like any new device, except for being slower. If features (that are also present in the older device) don't work at all instead of just slow, that's fragmentation.
You should upgrade an old device because you need a new feature or you want more speed a modern device can offer you, but having to abandon the device because it doesn't work properly anymore should not be an option you're forced to consider, and that's the point, the vendors do force this upon you to drive their sales.
From these observations, it seems that Android'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%.
It is hard to understate how MISLEADING these dashboards are. They are so, so, so wrong. I've professionally worked on several apps/libraries which reached millions of Android users and not one of them (not one!) had a distribution that's even close to what those dashboards show.
Any kind of app that's not exclusively targeting emerging markets on 512MB phones will have significantly higher percentage of newer Androids. If you're targeting US, EU, China, Japan, Korea and S. America you'll probably have Androids before 6.x in marginal <10% total figures.
Any kind of app that's being released together with its iOS version will probably have double to triple percentage of new Android versions and pretty much non-existant usage stats on Androids before 5.0.
Those dashboards reflect pretty much no app published on Play store - not even apps like Facebook.
Which is the reason why Google has finally added an update clause to their services contract, as OEMs are starting to not pay attention to their new versions.
In Germany, on consumer stores at shopping malls you can still buy pre-paid devices with Lollipop.
This "device model" 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.
It's probably not worse than that because he makes the totally incorrect assumption that Android version and device are independent, which is obviously not the case.
Most people update their phones to the latest available version for their phone, so it would be 144 OS-device-manufacturer combos (more or less).
>12.X has about 80.5% market share... [of the iOS market] My POV is ... Apple leads the Mobile OS market share ... by a huge margin
That'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'm sure MacOS enjoys market share "dominance" 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's total 75% of mobile install base is still quit a bit more than 80% of iOS's 23% mobile install base.
And even that I don't really care about. iOS is a great OS. What I don't like are sloppy definitions and methodology in something that presents as data analysis.
It'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.
I'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't just target the latest version given that vendors don't push the latest updates to all users. It means older devices can still get many/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'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 "upgrade" to an $80 kindle fire kids version, which plays minecraft quite nicely. That I'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's and various other Android devices.
For the most part it isn't a problem for us - we require Android 6+ and for the phone to have various sensors.
Some of our customers can't afford the latest or greatest Android devices - that's fine - we will do our best to support them.
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....
I don't get the negative sentiment here. When Vulkan was brand new Google didn't want to force it in 7.0 or they might have had even more devices still stuck on 6.0 today.
The fact they made it mandatory and independent of vendor in 9 is laudable. Doing so absolutely costs them adoption of the latest releases but they did it anyway.
When you say "first you need a device with Android 9" that is on the vendors to provide. And the scarcity of 9 can in part be contributed to compulsory Vulkan support. Most of Googles first party phones now run it, even though their general attitude of abandoning 4+ year old products is still egregious.
I understand the frustration in Google not solving this sooner, but from your comment it seems like they have solved it (with Android 9) and you still seem annoyed?
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's compatible with all newer Android OS releases.
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's the difference between Samsung's bluetooth stack and Android's own
I work at a company that distributes an Android SDK specifically for East/West/Southern Africa and South Asia. So far (and we are extremely early stage) we've seen 2,992 unique make/model combinations, and from there the OS ranges from v4.3 - 9.0 and everywhere in between. There'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/costs don't upgrade their OS often, and have secondhand or imported devices with some kind of customized OS.
1) Do this analysis for your own user base, universal stats may not be relevant.
2) It'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.
3) Do test your UX across a couple different phones categories. Samsung & vanilla Android have different button placements and icons.
4) There are plenty of libraries and tools available to handle this problem. I won't say it's not something to think about, but it's usually pretty low on my list.
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'm wondering if letting your app support very old OS versions is a good thing. You get more customers but aren't the ones with the old OS more likely be the ones causing the most problems (= work) because they aren't very tech savvy?
It provides economic opportunities for third party services. Supporting your local IT/Phone-store around the corner in assisting me is preferable to me than to buy a new phone.
> The vast majority of iPhone users update to the latest version quite fast and flawlessly.
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.
Yeah, there's a lot of different Android versions out there. Who cares? Other than security updates, it's pretty much a non-issue. Developers target the version they want to support and publish their app online.
Maybe on one particular major version update. The vast majority of updates are completely painless, as evidenced by such a large percentage of people having no reservation about updating to the latest version.
every article preaches the same absurd fallacy: "users update the OS more in so or so"
Users have absolutely no say! Planed obsolence does.
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.
This is pure greed over consumer rights (or respect).
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)
on_and_off|6 years ago
Android O, P and Q are 88% of our Android devices. By far and large, fragmentation is something I _never_ have to think about.
Jetpack libraries are here to handle it for us, as an abstraction layer between the OS and third party apps.
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.
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.
And at the time, I was already finding these articles deeply ridiculous.
blihp|6 years ago
[1] You say that O/P/Q are 88% of your devices but they only represent 38.7% of devices accessing the market (Q doesn't even show up) per https://developer.android.com/about/dashboards. Likely the solution Google has provided ignores a significant chunk of devices out there. When they announce these new initiatives, they tend to support the most widely-used and recent devices while quietly ignoring the rest. A valid strategy, but hardly comprehensive. (yeah, yeah... this time is different)
[2] Technically, they can still access the market, they just can't download anything. Probably either some web API breakage or no longer supported version of something on the device.
mattlondon|6 years ago
I have no interest AT ALL in the manufacturer of the device.
Fragmentation simply doesn't feel like an issue, at least to me.
throw03172019|6 years ago
I still find iOS to be my preferred platform but the “it just works” feeling is no longer there.
keerthiko|6 years ago
- native UI elements (labels, text fields, images, listviews, etc)
- images in any standard format (png, jpeg, etc)
- network requests that doesn't fetch more than a few 100kb of data at a time
- simple touch interaction (single item tap/drag/swipe/slide)
- read/write to internal storage
- play audio
...then you're fine and fragmentation is most likely a non-issue. OTOH, if you require
- openGL or 3D graphics calls
- read/write to removable storage
- video streaming, HLS streaming, or even local video file playback
- downloads/network fetches of larger amounts of files/data
- multi-touch UX
- rear and/or front or any specific camera access
- actually any hardware sensor/broadcaster/receiver access (gyro, accel, flashlight, bluetooth)
- OS manipulation (custom keyboard, replace default telephony/texting, modify native modals such as share view, register with the OS as a share-target, etc)
...then enjoy lopping off a chunk of your userbase (which you may have to specify manually, although Google helps with this) or struggling to write lots of OS detection switch statements with custom logic for handling each of these things. Working on an app that does 4+ of the things from the latter list, Android fragmentation has been and will continue to be a problem, even if it isn't really at any given point.
If we just want apps which move blobs of text back and forth between views and across the network, then yes fragmentation is not an issue.
orangecat|6 years ago
Yes. The backwards sensors in the Nexus 5x and 6 were particularly amusing/irritating: https://www.theverge.com/2015/11/9/9696774/google-nexus-5x-u....
alkonaut|6 years ago
If you can just code for "The 90% with a reasonably modern browser, at least one working eye and JS enablded" then you are in a different situation.
Fragmentation hurts the people in the first camp that need to support 99% or more, for example if you are coding an app for a government service and not for a startup.
clumsysmurf|6 years ago
The irony, is that Android was originally designed to be a Camera OS. So its still fragmented in the thing it set out to do.
https://www.pcworld.com/article/2034723/android-founder-we-a...
megy|6 years ago
matwood|6 years ago
sonnyblarney|6 years ago
A considerably number of companies have to actually deal with this fragmentation, for example, we have a product that integrates with a device via Blutooth, and we have to deal with this issue. We can't just 'not serve' a bunch of customers.
milleramp|6 years ago
This is a huge exception that suppresses third party innovation.
bluescrn|6 years ago
rarestblog|6 years ago
https://i.imgur.com/0Ar0ta5.png
My point being: there ARE other iOS versions in use. I have a backup working iPhone 4 turned on right now. It won't upgrade beyond iOS 5 (I think it's iOS 5). But somehow the author ignores all those 0.1% iOS versions, yet shows them for Android (with 4 decimals no less).
kevin_thibedeau|6 years ago
stesch|6 years ago
gshdg|6 years ago
stevehb|6 years ago
ehsankia|6 years ago
Yes, I realize that as a developer, fragmentation can be more of a pain on Android, but comparing it directly to iOS is comparing Apples to oranges.
DiabloD3|6 years ago
Apps don'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.
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're willing to upgrade the ROM yourself.
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).
The only company that is truly consumer hostile is Samsung. And, frankly, I don't know why anyone would buy Samsung or Apple or even Google'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.
pekalicious|6 years ago
However, I still have every galaxy note I have ever owned, working, and in great condition (Note 2, 5, and now 8). My dad is actually using the 5. All of them got upgraded at least once to a newer Android OS and they are still solid devices.
Granted, other than Note, I've only owned a Startosphere for the hw keyboard, so I can't compare it to others, but even after I realized that the Note 8 was crazy expensive and made me double think what my next phone will be, I worry if the longevity can be matched.
dmitrygr|6 years ago
ineedasername|6 years ago
scarface74|6 years ago
The 2012 iPhone 5 is the newest unsupported iPhone. Would you really want to support a phone that old and have to support both a 32 bit and a 64 bit version of your app?
Liquid_Fire|6 years ago
I would challenge that. I'm still waiting for Android Pie (August 2018) on my OnePlus 3T (November 2016). That's not even two years, and while OnePlus have promised to eventually bring Pie to this phone, it's already almost 9 months late. By the time the 3T is updated to Pie, Android Q will be out.
com2kid|6 years ago
I can be listening to music on my phone and One+ will just kill Pandora, or Spotify. I have to manually "lock" music apps and workout apps in One+'s task switching UI to keep them from being randomly killed while in use.
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't think it is even malicious, just oddly programmed. I wish my music apps could pull off the same trick though!
noelsusman|6 years ago
Eventually I stumbled on the "Lock" feature, which as far as I know is specific to OP, and that solved everything. I'm pretty annoyed with OP about it to be honest. Android has app-specific battery optimization settings built in but they just completely ignored them.
rubyn00bie|6 years ago
Turns out Android, at least however this app is setup, maybe by default, leaves the app fully running. Like zero effort to suspend it automatically. A part of the UI crashed and a hunt to find the bug made me realize this... I fixed the bug, but still haven't really looked into how to really suspend it.
soohyung|6 years ago
Knufen|6 years ago
snek|6 years ago
monocasa|6 years ago
djsumdog|6 years ago
Oreo and the /vendor partition may help with this some. Still, it's a far cry from the Linux/PCs days of the 90s. I've written about this before:
https://penguindreams.org/blog/android-fragmentation/
MiddleEndian|6 years ago
If I buy a Dell laptop or a Lenovo laptop, it will come with a bunch of useless junk installed that nobody in their right mind would ever want, like Lenovo's useless gigantic Wi-Fi icon in Windows (last observed by me in a T520). But not only can I uninstall all of that junk software, I am still running real Windows. And that means I can update it normally.
Compare that to an Android device. You get a phone from a company like Samsung and you cannot uninstall the Facebook app no matter what you do. You get a phone from HTC and maybe they decide to push an update from 7.something to 8.0 and 8.0 introduces a new issue. That is fixed in 8.1 but you can never actually upgrade to 8.1 because it's not the real version of Android it's the HTC version of Android and they have ordained that your device shall never go past 8.0 and they pushed some firmware "security" update that prevents you from installing any other OS on your device. Additionally, some software seems to be dictated by your mobile carrier, which would be like allowing Comcast to control what you run on your PC.
So whatever fragmentation there is on Wintel (or LinAmd), it is not nearly as hostile to the user as the Android ecosystem.
samdung|6 years ago
jherdman|6 years ago
I'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.
Gudin|6 years ago
Android doesn't brag it has 75% share. Actual data is that 85% of smartphones run Android and that's market share. Fact that they are not updated to the latest version doesn't change the market share.
josteink|6 years ago
Android has its issues, but “math” like this isn’t the answer. This is drivel, really.
Also: See Wintel for fragmentation. Everywhere in nature and tech diversity is good. But somehow not for mobile phone OSes.
sidlls|6 years ago
IloveHN84|6 years ago
unknown|6 years ago
[deleted]
eugeniub|6 years ago
on_and_off|6 years ago
For 85$ it ships with Oreo.
That's kind of amazing : for a relatively modest sum, you get a lot of technology.
It makes me wonder why anybody would recommend a costlier device shipping with 4.4
dmitryminkovsky|6 years ago
robocat|6 years ago
For WebView, Android 4.4 is stuck on Chrome 30/33 and anything older still uses AOSP.
Samsung users often use the Samsung browser, which is often a very obsolete version that came with the phone.
1. https://www.xda-developers.com/google-chrome-android-droppin...
jmiskovic|6 years ago
Fragmentation doesn't bother me. Yes, on some devices the app crashes, on others the sound lag is unbearable. I don'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.
Every time I enter android studio, it wants to update. The studio wants to update. Suddenly it'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'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's resolved by something completely unrelated to error message. Usually it'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.
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't and won't spend time to get the build for 64-bit version working. Google sent me a mail that "All new apps and app updates are required to provide 64-bit versions of any 32-bit native code they provide". So I won't be able to update existing app to existing users ever again, for non-technical reasons.
Fragmentation I can deal with. All web developers deal with it daily. But Google's treatment of development is horrible and I don't want any part of it. Because of this I've transitioned to web as platform. At least I can be safe that anything I build will be runnable in 10 or 20 years.
chipperyman573|6 years ago
Isn't the reason entirely technical? 64-bit apps can use 64-bit only instruction sets, which are newer and usually faster, resulting in a performance improvement. BTW, apple did the same thing years ago on iOS and is planning to kill 32-bit apps on MacOS soon.
izacus|6 years ago
So the "non-technical" reason here is that you don't want to provide a build for users with 64-bit devices?
robocat|6 years ago
Xcode is always bumping versions too.
> The second thing is recent requirement to provide 64-bit version of each app.
iOS had this issue too.
saagarjha|6 years ago
FWIW, Apple did exactly this a while before Google did.
ezoe|6 years ago
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's wage). He concluded that it'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.
Sadly, our company never executed this plan.
ineedasername|6 years ago
twodave|6 years ago
bahmboo|6 years ago
klingonopera|6 years ago
You should upgrade an old device because you need a new feature or you want more speed a modern device can offer you, but having to abandon the device because it doesn't work properly anymore should not be an option you're forced to consider, and that's the point, the vendors do force this upon you to drive their sales.
ajnin|6 years ago
From these observations, it seems that Android'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%.
izacus|6 years ago
Any kind of app that's not exclusively targeting emerging markets on 512MB phones will have significantly higher percentage of newer Androids. If you're targeting US, EU, China, Japan, Korea and S. America you'll probably have Androids before 6.x in marginal <10% total figures.
Any kind of app that's being released together with its iOS version will probably have double to triple percentage of new Android versions and pretty much non-existant usage stats on Androids before 5.0.
Those dashboards reflect pretty much no app published on Play store - not even apps like Facebook.
pjmlp|6 years ago
In Germany, on consumer stores at shopping malls you can still buy pre-paid devices with Lollipop.
PunchTornado|6 years ago
somedudetbh|6 years ago
It's actually _much worse_ than this. Here's a review of the "Samsung Galaxy S10+": https://www.anandtech.com/show/14072/the-samsung-galaxy-s10p...
This "device model" 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.
IshKebab|6 years ago
Most people update their phones to the latest available version for their phone, so it would be 144 OS-device-manufacturer combos (more or less).
ineedasername|6 years ago
That'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'm sure MacOS enjoys market share "dominance" 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's total 75% of mobile install base is still quit a bit more than 80% of iOS's 23% mobile install base.
And even that I don't really care about. iOS is a great OS. What I don't like are sloppy definitions and methodology in something that presents as data analysis.
It'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.
I'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't just target the latest version given that vendors don't push the latest updates to all users. It means older devices can still get many/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'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 "upgrade" to an $80 kindle fire kids version, which plays minecraft quite nicely. That I'll admit is absolutely its own fragment of Android though)
xs83|6 years ago
For the most part it isn't a problem for us - we require Android 6+ and for the phone to have various sensors.
Some of our customers can't afford the latest or greatest Android devices - that's fine - we will do our best to support them.
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....
pjmlp|6 years ago
The reality is that thanks for it being an optional API, introduced in version 7, only flagships have proper support.
And even then, each OEM provides a different version, with their own set of instructions.
Hardly any better than GL ES.
Now they are doing it compulsory on Android 9, upgradable via the store, with GL support being supported via ANGLE.
Guess what, first you need to get a device with Android 9 on it.
This just an example among many others across other API surface areas.
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.
zanny|6 years ago
The fact they made it mandatory and independent of vendor in 9 is laudable. Doing so absolutely costs them adoption of the latest releases but they did it anyway.
When you say "first you need a device with Android 9" that is on the vendors to provide. And the scarcity of 9 can in part be contributed to compulsory Vulkan support. Most of Googles first party phones now run it, even though their general attitude of abandoning 4+ year old products is still egregious.
Andrex|6 years ago
ChrisRR|6 years ago
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's the difference between Samsung's bluetooth stack and Android's own
jessshorland|6 years ago
https://medium.com/use-hover/hover-launches-v1-0-stable-and-...
krschultz|6 years ago
2) It'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.
3) Do test your UX across a couple different phones categories. Samsung & vanilla Android have different button placements and icons.
4) There are plenty of libraries and tools available to handle this problem. I won't say it's not something to think about, but it's usually pretty low on my list.
mymythisisthis|6 years ago
Schnitz|6 years ago
OrgNet|6 years ago
panpanna|6 years ago
I don't understand why this is on HN.
nrjames|6 years ago
stesch|6 years ago
klingonopera|6 years ago
tempodox|6 years ago
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.
8bitrebellion|6 years ago
rocky1138|6 years ago
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.
Yeah, there's a lot of different Android versions out there. Who cares? Other than security updates, it's pretty much a non-issue. Developers target the version they want to support and publish their app online.
mberning|6 years ago
unknown|6 years ago
[deleted]
m-p-3|6 years ago
myko|6 years ago
gonvaled|6 years ago
fopen64|6 years ago
[deleted]
twntee|6 years ago
[deleted]
ggg2|6 years ago
Users have absolutely no say! Planed obsolence does.
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.
This is pure greed over consumer rights (or respect).
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)