How Fragmented Is Android?(eggonomy.com)
eggonomy.com
How Fragmented Is Android?
https://eggonomy.com/blogs/news/how-fragmented-is-android
188 comments
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] 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.
> but they only represent 38.7% of devices accessing the market
He said he targets North America. Those stats you referenced are global.
If he was supporting parts of Asia, Latin America, etc then I have a feeling his team would have to be more careful.
He said he targets North America. Those stats you referenced are global.
If he was supporting parts of Asia, Latin America, etc then I have a feeling his team would have to be more careful.
Point taken that the U.S./Canada stats likely skew to more recent versions. However, I'm in the U.S. and several of my devices couldn't possibly even download his company's app. Granted, I'm an outlier and tend to use my devices until they die. (they are actually still pretty useful around-the-house devices and can browse the web, watch videos, play some older games etc. Maybe I'll fire up a couple of them and open the Play app just to nudge the stats by a few millionths of a percent. ;-)
That's not unique to Android. I still use an old iPad 3 (stuck on iOS 9) for movies & audiobooks in bed. I can still use Netflix, Plex, & Audible because I downloaded them a long time ago. But I recently switched to 1Password and I can't install it on that iPad.
According to 1Password's support forum, "1Password 6 supports 1Password.com accounts, and that will run on iOS 9 and 10"[1].
The iPad 3 was quite problematic as a device in that it was very RAM- and CPU-limited. With a 1GHz dual-core A9 and 1GB RAM, it was not going to handle future iOS updates well.
The next version, the 2012 iPad, runs iOS 10 and is still useful -- I still have one lying around for when I need an iPad (and I do have 1Password on it). And the 2013 iPad Air runs the latest iOS and I expect this to continue as iPad tech plateaus.
Lack of OS updates isn't unique to Android, but Android manufacturers collectively have a very blasé attitude to updates, much worse than Apple and Microsoft.
[1] https://discussions.agilebits.com/discussion/comment/408090/...
The iPad 3 was quite problematic as a device in that it was very RAM- and CPU-limited. With a 1GHz dual-core A9 and 1GB RAM, it was not going to handle future iOS updates well.
The next version, the 2012 iPad, runs iOS 10 and is still useful -- I still have one lying around for when I need an iPad (and I do have 1Password on it). And the 2013 iPad Air runs the latest iOS and I expect this to continue as iPad tech plateaus.
Lack of OS updates isn't unique to Android, but Android manufacturers collectively have a very blasé attitude to updates, much worse than Apple and Microsoft.
[1] https://discussions.agilebits.com/discussion/comment/408090/...
Same here.
I don’t think iPad 3 is even “old”. I have an original iPad 1, and the situation is even worse: I’m frozen in time on iOS 5, and the device has been losing app availability for years. Without jail breaking, it can basically only do what was installed with it from the factory. The hardware itself outlasts most companies’ software support by 2-4X. I see a bleak future of millions of perfectly usable devices that are only unusable because developers decided to stop keeping their software compatible.
Contrast that with the world of PCs where I can still run recent versions of Linux on devices 10-20 years old.
Contrast that with the world of PCs where I can still run recent versions of Linux on devices 10-20 years old.
> where I can still run recent versions of Linux on devices 10-20 years old.
10 sure, but not 20. 20 years ago the devices had 32 bit CPUs, the support for them is being phased out. The last 32-bit Ubuntu LTS is 16.04.6, from 2016.
10 sure, but not 20. 20 years ago the devices had 32 bit CPUs, the support for them is being phased out. The last 32-bit Ubuntu LTS is 16.04.6, from 2016.
Ubuntu 16.04 is still receiving updates - unlike typical Android phones from the same era.
While you might not get the latest kernel with it, as far as I can tell, there is nothing in its package manager that doesn't run on hardware from 2016. Unkike typical Android devices from the same era.
While you might not get the latest kernel with it, as far as I can tell, there is nothing in its package manager that doesn't run on hardware from 2016. Unkike typical Android devices from the same era.
> as I can tell, there is nothing in its package manager that doesn't run on hardware from 2016.
Right, but 20 years ago was 1999. I won’t be surprised to find out many packages won’t work: that CPU doesn’t have SSE2, the RAM limit is 512 MB, and typical systems usually had 64 or 128 MB.
The official page says recommended minimum requirements for Ubuntu 16.04 are 2 GHz dual core processor with 2GB RAM. 20 years old PCs don’t fit.
Right, but 20 years ago was 1999. I won’t be surprised to find out many packages won’t work: that CPU doesn’t have SSE2, the RAM limit is 512 MB, and typical systems usually had 64 or 128 MB.
The official page says recommended minimum requirements for Ubuntu 16.04 are 2 GHz dual core processor with 2GB RAM. 20 years old PCs don’t fit.
Ubuntu is heavy though. You can install the latest Slackware on a 486 with 64 MB of RAM.
Doesn't Debian support 32-bit systems? Also, using 64-bit has little value if you have less than 8 Gb of RAM.
> Doesn't Debian support 32-bit systems?
Yes. But I think it’ll only a matter of time before they stop, too.
> using 64-bit has little value if you have less than 8 Gb of RAM.
Address space brings much value. No need to worry about address space fragmentation, also you can safely use memory mapping, even for large files.
Extra registers also very nice performance-wise, both general purpose r8-r15 and vector xmm8-xmm15.
Finally, when you code AMD64 you can rely on having at least SSE1 and SSE2 SIMD, their support is a requirement.
Yes. But I think it’ll only a matter of time before they stop, too.
> using 64-bit has little value if you have less than 8 Gb of RAM.
Address space brings much value. No need to worry about address space fragmentation, also you can safely use memory mapping, even for large files.
Extra registers also very nice performance-wise, both general purpose r8-r15 and vector xmm8-xmm15.
Finally, when you code AMD64 you can rely on having at least SSE1 and SSE2 SIMD, their support is a requirement.
Yes. But I think it’ll only a matter of time before they stop, too.
It will probably take at least 5-10 years before all major distributions will stop and their support periods will be over.
Once we are there, there is still NetBSD and OpenBSD. Heck, NetBSD still supports VAX.
It will probably take at least 5-10 years before all major distributions will stop and their support periods will be over.
Once we are there, there is still NetBSD and OpenBSD. Heck, NetBSD still supports VAX.
> Heck, NetBSD still supports VAX.
I wonder about the level of VAX support. Do they just have old code lying in the repository, do they build it, or do the devs actually have a working VAX machine and they test new builds?
I wonder about the level of VAX support. Do they just have old code lying in the repository, do they build it, or do the devs actually have a working VAX machine and they test new builds?
Not a dev, but as i understand it as a Vaxstation 4000 owner who boots up from time to time to enjoy the beeps:
a) build.sh allows cross compilation, which helps with build validation (although openbsd built native until they dropped vax ~3y ago)
b) there are a few dedicated devs on vax. these pretty much do the work as a hobby, and things are best effort, but generally in sync with the rest of the tree. most of these own a vax or three, but you can also run on SimH and probably other vax emulators.
c) really, the system source is modular enough that adjusting device drivers for well documented hardware which has existed for years, and tweaking a few already-implemented since the 80s macro primitives is most of what is needed to keep things running -most of the adjustments to the system itself happen higher up the stack (e.g in the generic c portion of the kernel, or in the c library). Granted, this does mean knowing the ISA and HW in and out, and having skills to debug/reason about low-level instruction/hardware sorts of issues, but, hey, that's who codes open source os'es anyway.. Besides, if you are a true VAX BSD UNIX hacker, you've been tweaking your kernel sources since you manually toggled in the 3BSD bootstrap in 1979 :b
a) build.sh allows cross compilation, which helps with build validation (although openbsd built native until they dropped vax ~3y ago)
b) there are a few dedicated devs on vax. these pretty much do the work as a hobby, and things are best effort, but generally in sync with the rest of the tree. most of these own a vax or three, but you can also run on SimH and probably other vax emulators.
c) really, the system source is modular enough that adjusting device drivers for well documented hardware which has existed for years, and tweaking a few already-implemented since the 80s macro primitives is most of what is needed to keep things running -most of the adjustments to the system itself happen higher up the stack (e.g in the generic c portion of the kernel, or in the c library). Granted, this does mean knowing the ISA and HW in and out, and having skills to debug/reason about low-level instruction/hardware sorts of issues, but, hey, that's who codes open source os'es anyway.. Besides, if you are a true VAX BSD UNIX hacker, you've been tweaking your kernel sources since you manually toggled in the 3BSD bootstrap in 1979 :b
At what stage does it become an endorsement to use insecure architecture?
That’s what happened with desktop PCs when design progress (or deliberate gradualism some would say) obsoleted machines over the course of several months.
Same happened with mobile devices, where designers and manufacturers were looking for the ideal recipe of a mobile phone.
Same happened with mobile devices, where designers and manufacturers were looking for the ideal recipe of a mobile phone.
Can you still access the App Store? A few years ago in 2017 I found my old iPhone 3GS in a drawer. I fired it up and it still connected to the App Store, and I was able to download some apps I'd bought back in the day. Even some apps that hadn't been updated or available for newer devices for years, including Lemonade Stand, an old favourite. It was great seeing my kinds play that on my old Phone.
I got my daughter a newer device later that year, so don't know if it still works. I've lost track of it again.
I got my daughter a newer device later that year, so don't know if it still works. I've lost track of it again.
>It sounds like you're rolling with whatever Google's latest 'solution' to fragmentation
> You say that O/P/Q are 88% of your devices but they only represent 38.7% of devices accessing the market
NO !!
That's the issue with these articles. They just read the android dashboard and pretend that:
- it applies everywhere
- many different devices = difficulty for the devs or users
The dashboard reports the global figures. These figures are heavily skewed by third world countries where old versions of Android are still shipping.
"The market" ... this is absolutely meaningless. If you work for let's say Lyft, the market is wherever lyft can operate, that's not the whole world, so whatever the Android version dashboard tells is meaningless for you or your users.
For our market 88% of the users are O or superior. 6 months ago we stopped supporting devices older than lollipop for this particular app (IIRC it was because they don't support TLS 1.3 and it was giving us some security concerns). For the app I worked on before, we had legacy apks : apks that are still distributed on the play store but that we don't maintain. Basically when we decided to stop "supporting" an old Android version. And by old; I mean Android Eclair; this was a pretty popular app with tons of users on various devices. So we take our current app that still support that old API level. We make sure that it is as stable as we can get it (since we always launch new features, we always have new corner cases, we make sure these are handled). And when it is ok; we set this apk as a legacy one on the play store : if you have one of these old Android versions, you are going to be able to continue using or even installing that older apk. Technically we can update it if we want to, but unless there is suddenly a wave of crashes or complaints we just leave it be.
Even for that app, the figures were roughly the same (and that's while being available in 150 countries, that was for a pretty popular app). For these legacy apks, we often had something like 10k installs, while the main app is in the dozens of millions (but since that app had a paid subscription, make the service work even for old device was a must do).
And yeah, even for that job where we had an app available on API 7+ (Android 2.3 eclair IIRC), the figures were still pretty similar and fragmentation was something I read about in stupid articles, not a part of my daily job. I am not working for Google, if I had to solve fragmentation issues everyday, I would be the first to complain about it. I am here to build an app, not maintain random OEMs hacks.
> You say that O/P/Q are 88% of your devices but they only represent 38.7% of devices accessing the market
NO !!
That's the issue with these articles. They just read the android dashboard and pretend that:
- it applies everywhere
- many different devices = difficulty for the devs or users
The dashboard reports the global figures. These figures are heavily skewed by third world countries where old versions of Android are still shipping.
"The market" ... this is absolutely meaningless. If you work for let's say Lyft, the market is wherever lyft can operate, that's not the whole world, so whatever the Android version dashboard tells is meaningless for you or your users.
For our market 88% of the users are O or superior. 6 months ago we stopped supporting devices older than lollipop for this particular app (IIRC it was because they don't support TLS 1.3 and it was giving us some security concerns). For the app I worked on before, we had legacy apks : apks that are still distributed on the play store but that we don't maintain. Basically when we decided to stop "supporting" an old Android version. And by old; I mean Android Eclair; this was a pretty popular app with tons of users on various devices. So we take our current app that still support that old API level. We make sure that it is as stable as we can get it (since we always launch new features, we always have new corner cases, we make sure these are handled). And when it is ok; we set this apk as a legacy one on the play store : if you have one of these old Android versions, you are going to be able to continue using or even installing that older apk. Technically we can update it if we want to, but unless there is suddenly a wave of crashes or complaints we just leave it be.
Even for that app, the figures were roughly the same (and that's while being available in 150 countries, that was for a pretty popular app). For these legacy apks, we often had something like 10k installs, while the main app is in the dozens of millions (but since that app had a paid subscription, make the service work even for old device was a must do).
And yeah, even for that job where we had an app available on API 7+ (Android 2.3 eclair IIRC), the figures were still pretty similar and fragmentation was something I read about in stupid articles, not a part of my daily job. I am not working for Google, if I had to solve fragmentation issues everyday, I would be the first to complain about it. I am here to build an app, not maintain random OEMs hacks.
This reminds me of browser usage stats showing that x% of people are still using IE 6 or whatever. In reality a huge number of those are probably web crawlers or malware or something spoofing it's browser id.
I believe in the comment you’re replying to, “the market” is actually referring to the Android Market, the original name of the Google Play Store, rather than the economic market of serviceable users.
ah, I see.
It still misses the whole point though.
Again, the global numbers are pretty meaningless for app developers.
Even if your app is called gmail, at some point you will see that you have 0.01% of your users on a very old version of Android. And you are not going to cut them off, just freeze an apk that will be their last version.
And for almost all apps, your useage stats won't look like these global numbers.
We are doing everything we can to increase our user numbers .. if it meant lowering the min supported version, we would do it but it is just not something that would help us.
It still misses the whole point though.
Again, the global numbers are pretty meaningless for app developers.
Even if your app is called gmail, at some point you will see that you have 0.01% of your users on a very old version of Android. And you are not going to cut them off, just freeze an apk that will be their last version.
And for almost all apps, your useage stats won't look like these global numbers.
We are doing everything we can to increase our user numbers .. if it meant lowering the min supported version, we would do it but it is just not something that would help us.
> I've got several still functional 4.x-5.x devices [...] that can't even use the market anymore
4.4.x and 5.x can certainly use the Play Store. I use both of those versions regularly, and they still works well (in fact, I keep 4.4.x support, and do not plan on stopping soon).
In Europe, a few manufacturers still sell 5.x devices. In particular, my manufacturer of choice only recently decided to finally upgrade the small tablet / low cost option to give us the chance of having an OS that's not 5 years old on purchase /sarcasm.
May I mention that contrary to iPads, older devices allow to side-load older app versions (that you can easily find online). I recently re-used a 4.0.2 device and installed VLC and Firefox on it (all it will ever need). And for 4.2+, you can just use F-Droid, most apps are going to be compatible.
4.4.x and 5.x can certainly use the Play Store. I use both of those versions regularly, and they still works well (in fact, I keep 4.4.x support, and do not plan on stopping soon).
In Europe, a few manufacturers still sell 5.x devices. In particular, my manufacturer of choice only recently decided to finally upgrade the small tablet / low cost option to give us the chance of having an OS that's not 5 years old on purchase /sarcasm.
May I mention that contrary to iPads, older devices allow to side-load older app versions (that you can easily find online). I recently re-used a 4.0.2 device and installed VLC and Firefox on it (all it will ever need). And for 4.2+, you can just use F-Droid, most apps are going to be compatible.
My Asus Lolipop Tablet (Aka Android 5.x) can certainly use the market.
Just like the "deal of the day" ones that are still being sold across German consumer stores at shopping malls.
Just like the "deal of the day" ones that are still being sold across German consumer stores at shopping malls.
Out of curiosity: did you ever tried using Yalp store for downloading the apk from the store? Would it be useful for you?
No and probably not. I have newer devices too, I was just using my older devices to make the point that the fragmentation problem hasn't been solved as much as it's been swept under the carpet.
+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 have no interest AT ALL in the manufacturer of the device.
Fragmentation simply doesn't feel like an issue, at least to me.
Fragmentation becomes an issue when you're either building services that run in the background or interact with hardware (BT, WiFi, WiFi-direct, Camera, GNSS, Gyro/Accel). I feel fragmentation hard with my app.
For the background WorkManager has done wonders.
For hardware, I believe that 100%. I am talking about "regular" android apps that don't need deep access to the hardware. By deep I mean something harder than recording something (e.g. taking/picking a picture is delegated to the default system app, not the one you build) or displaying the current position with a mapping sdk.
Bluetooth in particular I can believe. It is amazingly complex and adding the OEMs customizations on top must be a total pain.
For hardware, I believe that 100%. I am talking about "regular" android apps that don't need deep access to the hardware. By deep I mean something harder than recording something (e.g. taking/picking a picture is delegated to the default system app, not the one you build) or displaying the current position with a mapping sdk.
Bluetooth in particular I can believe. It is amazingly complex and adding the OEMs customizations on top must be a total pain.
On ADB Podcast about Bluetooth, they referred that certain models would just crash if someone tries to talk with specific protocol versions.
I mean, what? You are like a local store with foot traffic complaining about the global internet restrictions. Of course it doesn't affect you.
Fragmentation is an issue if you're at an enterprise or building a mass market product however.
Then you can't just ignore large percentages of the market.
Then you can't just ignore large percentages of the market.
One of my previous job was for one of the big music streaming services.
So very much a mass market product :)
As stated above, what we did was that when we decided to "drop support" for an API level, what it meant was that we would freeze an apk that would be delivered to these older devices and have a higher min api level for the new app versions.
The burden might higher on the backend people not to break the old endpoints than for us.. these old apks need to continue working. Technically we were supporting these frozen legacy apks, but since we have chosen particularly stable app releases for this, in practice we never touched them.
Weird corner cases/devices were indeed a bit more of a concern. And to be explicit, that was never a significant amount of our time. I was part of the more senior team that had to (among many other things) deal with that, and I don't think it has been more than 5% of my time (and 5% of the time of 2 other colleagues, whereas the 20 others not in our team did not have to deal with it at all).
As far as I can tell it is the result of :
- at this scale, if something can break, it will break. when you have millions of daily users, all of your app issues will be uncovered (and to be honest, there was a ton of these... we inherited some very awful code in some crucial areas)
- mass market means that you will see all kind of devices connecting to your service, including weird no names chinese devices that have not been certified by google. So they did not have to pass the compatibility test suite that devices shipping with the play store have to satisfy. This has been getting better and better year after year but at first you could see some "exotic" behaviors.
- mass market also means that people will try everything in order to use your product for free. Although to be honest 99% are refreshingly naive. Like somebody distributing a "cracked" apk letting you get one month of premium for free. We decompiled that version and could not figure out what had changed .... until we tried it and.. oh man, so that "hack" is just that we we offering a one month free trial at that time .. Nothing nefarious here, just the same free month you would have gotten for a new account by downloading the official apk from the play store.
So very much a mass market product :)
As stated above, what we did was that when we decided to "drop support" for an API level, what it meant was that we would freeze an apk that would be delivered to these older devices and have a higher min api level for the new app versions.
The burden might higher on the backend people not to break the old endpoints than for us.. these old apks need to continue working. Technically we were supporting these frozen legacy apks, but since we have chosen particularly stable app releases for this, in practice we never touched them.
Weird corner cases/devices were indeed a bit more of a concern. And to be explicit, that was never a significant amount of our time. I was part of the more senior team that had to (among many other things) deal with that, and I don't think it has been more than 5% of my time (and 5% of the time of 2 other colleagues, whereas the 20 others not in our team did not have to deal with it at all).
As far as I can tell it is the result of :
- at this scale, if something can break, it will break. when you have millions of daily users, all of your app issues will be uncovered (and to be honest, there was a ton of these... we inherited some very awful code in some crucial areas)
- mass market means that you will see all kind of devices connecting to your service, including weird no names chinese devices that have not been certified by google. So they did not have to pass the compatibility test suite that devices shipping with the play store have to satisfy. This has been getting better and better year after year but at first you could see some "exotic" behaviors.
- mass market also means that people will try everything in order to use your product for free. Although to be honest 99% are refreshingly naive. Like somebody distributing a "cracked" apk letting you get one month of premium for free. We decompiled that version and could not figure out what had changed .... until we tried it and.. oh man, so that "hack" is just that we we offering a one month free trial at that time .. Nothing nefarious here, just the same free month you would have gotten for a new account by downloading the official apk from the play store.
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.
I still find iOS to be my preferred platform but the “it just works” feeling is no longer there.
In my experience, iOS is still pretty close to, “it just works” if one sticks to recommended practices (autolayout, etc). Not perfect, but not bad either.
Of course if you’re writing manual frame code or using some third party UI library, that’s a very different story…
Of course if you’re writing manual frame code or using some third party UI library, that’s a very different story…
If your app primarily requires:
- 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.
- 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.
camera apps are an exception : here hardware fragmentation can be a pain
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....
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....
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.
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.
https://www.pcworld.com/article/2034723/android-founder-we-a...
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...
That's taken way out of context - according to your linked article, Android was pitched as a Camera OS in 2004, but almost immediately changed gears to an "open-source handset solution" a few months later that year. This was still years before iPhone was announced.
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.
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.
“e.g. camera apps are an exception”
This is a huge exception that suppresses third party innovation.
This is a huge exception that suppresses third party innovation.
Try doing anything vaguely graphical (games being the obvious example) and you’ll realise that a large percentage of Android devices are potatoes
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.
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).
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).
The other point is that most Apple store apps become uninstallable on anything older than three iOS versions.
This. I'm happily using JuiceSSH in Android Q beta even though it was last updated in 2017 and was targeting Android L. Android maintained reasonably good backward compatibility just like Windows did.
So many iOS app developers would use new SDK as soon as newer iOS is out, and abandon existing users who chose to use old iOS. Worse, those app developers would choose to drop old version, release a new version that requires you to purchase again.
So many iOS app developers would use new SDK as soon as newer iOS is out, and abandon existing users who chose to use old iOS. Worse, those app developers would choose to drop old version, release a new version that requires you to purchase again.
>>Worse, those app developers would choose to drop old version, release a new version that requires you to purchase again.
To be fair, one is not entitled to free upgrades forever.
To be fair, one is not entitled to free upgrades forever.
If apps ever had a version that worked as of iOS 5, you can still download “the last compatible version”. I’ve downloaded older streaming apps recently on a first generation iPad running iOS 5.
Any iPhone released since 2013 - with the exception of the 5C can run the latest OS.
Any iPhone released since 2013 - with the exception of the 5C can run the latest OS.
By the way: iPhone 4 supports iOS 7.1.2, released 4 years after the iPhone 4.
I'm not sure why the GP said his iPhone 4 won't upgrade past iOS 5, but it's worth noting: while an iPhone 4 can be upgraded to iOS 7, actually doing so is a bad idea unless you want your phone to run slow as molasses. You'll be much better off on iOS 6 or 5.
(I suppose there may be a security argument for upgrading as far as possible, but it's not like iOS 7 is up-to-date either. If you're concerned about security, you shouldn't be using an iPhone 4.)
(I suppose there may be a security argument for upgrading as far as possible, but it's not like iOS 7 is up-to-date either. If you're concerned about security, you shouldn't be using an iPhone 4.)
> You'll be much better off on iOS 6 or 5.
Sure. But if you are making an app for say a government service that has as a requirement to reach 98% of mobile users, and you reach the goal if you count compatible devices (not people who choise not to upgrade) then it helps.
Sure. But if you are making an app for say a government service that has as a requirement to reach 98% of mobile users, and you reach the goal if you count compatible devices (not people who choise not to upgrade) then it helps.
Correct. It won't upgrade past 7.1.2 not 5. My mistake.
Correct, sorry, didn't bother to look at the time. It is 7.1.2. The point still stands, it's old and I'm probably in 0.1% that the article left out in iOS markets.
Wouldn't it be better to say that iOS 7.1.2 supports the iPhone 4?
That's a good point. The list for Android fragmentation even includes 2.0 Eclair, which has 0% across the whole row!
Also, if you want a fair comparison, compare fragmentation between iPhone's and Pixel phones.
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.
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.
Very few people buy Pixel phones.
That's beside the point, as we are talking about fragmentation percentages. The point is, Apple has full control over their hardware, so obviously they will have less fragmentation. To have a fair comparison, we should compare to Pixel where Google has full control over.
That's not really fair still because it's about OS fragmentation, not hardware. Whether Google or Apple has full control is beside the point, isn't it?
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.
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.
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.
Samsung phones ship with ROMs that try to remove as much of the native Android experience as possible, and tend to eat battery life for no good reason. Swapping ROMs to AOSP-like experiences vastly improves battery life and performance on many Samsung phones.
Several Galaxy and Note devices also cannot ROM swap at all due to locked bootloaders, which makes that the most consumer hostile thing of all. I'm not sure which models this effects, but it is enough to put Samsung on my forever shitlist.
Several Galaxy and Note devices also cannot ROM swap at all due to locked bootloaders, which makes that the most consumer hostile thing of all. I'm not sure which models this effects, but it is enough to put Samsung on my forever shitlist.
Does the whole Huawei story not show that it is an extremely smart decision to "remove as much of the native Android experience as possible"?
The bootloader, knox, e-fuse thing I agree is consumer hostile. They are free to ship them locked but should include an override option for supposed owner of the device.
The bootloader, knox, e-fuse thing I agree is consumer hostile. They are free to ship them locked but should include an override option for supposed owner of the device.
Under your definition, Samsung is by far not the only "consumer hostile" company–your definition is par for the course for most large OEMs.
Well, in that case, I agree. I've only unlocked my Note 2 for a specific reason, and never had to do it again in any device since. Battery life on Notes are nothing to rave about, but neither a huge issue. But yeah, it does have many issue with bloatware, locking, non-native UI, etc. Even if they don't personally bother me, I will acknowledge that.
> What makes Samsung phones consumer hostile?
The upgrades that make the phone slower and slower and remove pre-existing functionality. The removal of Android native features, with replacements that stop working after some time. The severe locking of the phone.
But then, Samsung is far from the only ones doing this. I've personally stopped buying their phones because it's better to buy cheaper stuff and just switch after the manufacturer starts with the shenanigans.
The upgrades that make the phone slower and slower and remove pre-existing functionality. The removal of Android native features, with replacements that stop working after some time. The severe locking of the phone.
But then, Samsung is far from the only ones doing this. I've personally stopped buying their phones because it's better to buy cheaper stuff and just switch after the manufacturer starts with the shenanigans.
How about physical buttons that can't be remapped to anything other than their proprietary Bixby service? If you don't like it you can turn it off and have a useless button.
Your one plus has a terrible camera in low light. That is why people pay for pixel. Don't know why they do for Samsung or apple though.
Nope. 6T's low light performance is on par with the Pixel 3's, and Apple's gen equivalent of the Xs doesn't seem to perform as well, and the S9 also had slightly worse night performance.
The only way people can beat the 6T and Pixel 3's camera is with the newer phones: the 7 Pro, S10, Honor 20, Mi 9, the Pixel 4 (when it finally comes out) all use the same sensor: the Sony IMX586.
You may be just simply stating you don't like the 6T's camera app... it does low light differently. Not worse, but different, and in my opinion, more accurately. People have put a copy of Google Camera on their 6Ts and enabled the Pixel 3 low light mode (it's entirely in software and not a function of the hardware; change a prop, and any phone gets the Pixel 3 enhancements), and the 6T either performed essentially identically, or slightly better.
The only way people can beat the 6T and Pixel 3's camera is with the newer phones: the 7 Pro, S10, Honor 20, Mi 9, the Pixel 4 (when it finally comes out) all use the same sensor: the Sony IMX586.
You may be just simply stating you don't like the 6T's camera app... it does low light differently. Not worse, but different, and in my opinion, more accurately. People have put a copy of Google Camera on their 6Ts and enabled the Pixel 3 low light mode (it's entirely in software and not a function of the hardware; change a prop, and any phone gets the Pixel 3 enhancements), and the 6T either performed essentially identically, or slightly better.
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?
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?
May 2019 Windows 10 version runs just fine on this 2009 laptop.
The smart phone market and the related chipset is seeing the same jump in performance that personal computers saw in their first decade.
Could Windows 95 run on a computer from 1985?
My 2009 era Core 2 Duo Dell E6500 - that I still own (https://www.notebookcheck.net/Review-Dell-Latitude-E6500-Not...) had 8 GB of RAM, gigabit Ethernet, a 1920x1200 display, 160GB hard drive, etc. Besides the processor, those are still decent specs for today and even the processor is good enough
The iPhone of 2009 was a 3GS - 320x480 display, 256MB of RAM,802.11G, with a single core 400Mhz processor and slow video graphics by today’s standards.
Compare that to the specs of even the low end $475 iPhone 7.
The Core 2 Duo was already a 64 bit processor. The iPhone didn’t ship with a 64 bit processor until four years later.
Could Windows 95 run on a computer from 1985?
My 2009 era Core 2 Duo Dell E6500 - that I still own (https://www.notebookcheck.net/Review-Dell-Latitude-E6500-Not...) had 8 GB of RAM, gigabit Ethernet, a 1920x1200 display, 160GB hard drive, etc. Besides the processor, those are still decent specs for today and even the processor is good enough
The iPhone of 2009 was a 3GS - 320x480 display, 256MB of RAM,802.11G, with a single core 400Mhz processor and slow video graphics by today’s standards.
Compare that to the specs of even the low end $475 iPhone 7.
The Core 2 Duo was already a 64 bit processor. The iPhone didn’t ship with a 64 bit processor until four years later.
[deleted]
iPhone 5C is "newer" than iPhone 5, technically, since it was released in 2013.
> 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.
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 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.
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.
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.
It helps that each version does it differently, and the OEMs also make their own set of fine tuning.
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.
I have a One+ and I can't really recommend Greenify (App) enough. Forces all apps to shutdown, even those running in the background.
I have plenty of memory, I don't want apps force closed.
If I switch from a game to a browser to look something up, being able to switch back to the (paused) game 5 minutes later is a feature, not a bug.
Apps that obey backgrounding and stop doing work (e.g. burning CPU/Power) are fine.
If I switch from a game to a browser to look something up, being able to switch back to the (paused) game 5 minutes later is a feature, not a bug.
Apps that obey backgrounding and stop doing work (e.g. burning CPU/Power) are fine.
I've had a 1+1, 1+3, and 1+5, and I never had this issue on any of them.
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:
https://penguindreams.org/blog/android-fragmentation/
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/
> They're random pins soldered to random shit with little upstreamable in their hacked to hell kernels.
Sounds like arcade cabinets. Maybe we need something that does for Android ARM devices what MAME does for those: specifies each device as an abstract wiring diagram of pins to bits of patched kernel acting as ROMs. And then make that whole thing into a kernel virtualization-provider module, which uses the stock kernel for anything not masked over by ROMs.
Sounds like arcade cabinets. Maybe we need something that does for Android ARM devices what MAME does for those: specifies each device as an abstract wiring diagram of pins to bits of patched kernel acting as ROMs. And then make that whole thing into a kernel virtualization-provider module, which uses the stock kernel for anything not masked over by ROMs.
This is what devicetree is supposed to be.
However, as with the arctic machine, the incentives are misaligned - they actively don't want to be commoditized.
However, as with the arctic machine, the incentives are misaligned - they actively don't want to be commoditized.
Windows phones did at least have UEFI + arm. You can unlock the bootloaders of many of them now. But there's still no driver support for mobile data and several other critical hardware components.
But none of that matters for app developers.
(Also, Wintel machines are very much random pins soldered to random crap, they just do a better job papering over it with ACPI AML bytecode)
(Also, Wintel machines are very much random pins soldered to random crap, they just do a better job papering over it with ACPI AML bytecode)
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.
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.
That's a good point. Imagine Microsoft allowed third-party computer manufacturers to ship custom-built versions of Windows with modifications and third-party drivers that didn't have to be released in any publicly usable format. We'd have a real mess!
To be clear, I don't think this is a failing of open source. The problem is that Google allowed phone manufacturers to release practically anything they wanted based on the Android code base under the name "Android" and to ship with the common market (Google Play).
Frankly I don't think they should have allowed any modifications, making Android closer to how Firefox is distributed. (Anyone can edit the source code of Firefox, and even release a fully built binary based on that edited code, but you can't call it Firefox.) Maybe fewer manufacturers would have bought in at the outset, or maybe some would have tried to fork Android, but it's easy to forget what a desperate situation they were in. Outside of Apple and maybe Blackberry, the mobile OS market was in shambles because nobody was ready with high quality smartphone software. Android was a huge win and probably saved multiple companies from bankruptcy, and I think they would have eventually bought in to a more strictly defined OS out of necessity.
To be clear, I don't think this is a failing of open source. The problem is that Google allowed phone manufacturers to release practically anything they wanted based on the Android code base under the name "Android" and to ship with the common market (Google Play).
Frankly I don't think they should have allowed any modifications, making Android closer to how Firefox is distributed. (Anyone can edit the source code of Firefox, and even release a fully built binary based on that edited code, but you can't call it Firefox.) Maybe fewer manufacturers would have bought in at the outset, or maybe some would have tried to fork Android, but it's easy to forget what a desperate situation they were in. Outside of Apple and maybe Blackberry, the mobile OS market was in shambles because nobody was ready with high quality smartphone software. Android was a huge win and probably saved multiple companies from bankruptcy, and I think they would have eventually bought in to a more strictly defined OS out of necessity.
Welcome to PC-DOS, MS-DOS, DR-DOS, XX-DOS experience, with each OEM having their own BIOS idea.
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.
Why is this a concern? They never paid for Android to begin with and still get to use Google services like Maps, Play, GMail, etc.
> 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.
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.
The conclusion is unexpected and stupid.
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.
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.
"Addressable" market share maybe? A developer can target iOS current version and current version-1, and cover the large majority of iOS devices. How far back does an Android developer have to target? Maybe it doesn't matter since the Android marketshare is so much larger that targeting current - 1 stills gets more devices than iOS.
>Maybe it doesn't matter since the Android marketshare is so much larger that targeting current - 1 stills gets more devices than iOS.
That's an interesting way of thinking about it, getting 20% of 100 is more than getting 80% of 10. I think the problem you'd run into is that some users with androids would be upset they can't install your app when their friend that has an android can install it just fine.
That's an interesting way of thinking about it, getting 20% of 100 is more than getting 80% of 10. I think the problem you'd run into is that some users with androids would be upset they can't install your app when their friend that has an android can install it just fine.
One set of figures that I saw suggested that iOS 12.1 had a small lead over Android 8.1 in March 2019. (These were the most common versions at the time.) Consider all of the versions of iOS 12 and Android Oreo, then Android had a major lead. That is before considering Nought and Pie, which I suspect is the range of releases that most developers would target.
And if you want to compare "updating to the latest version", we should be comparing Pixel phones to iPhones. I'm sure Pixel's have a very similar rate of conversion, if not better.
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.
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.
> diversity is good
It depends on what the cause is. If I have no option to update to a recent version and causing diversity that way, it is bad. If I can choose to install a custom version, it is good. So in Android's case, the diversity is just a symptom of the underlying fragmentation of responsibility for updates.
However, phone manufacturers might see this a bit differently.
It depends on what the cause is. If I have no option to update to a recent version and causing diversity that way, it is bad. If I can choose to install a custom version, it is good. So in Android's case, the diversity is just a symptom of the underlying fragmentation of responsibility for updates.
However, phone manufacturers might see this a bit differently.
What are the numbers in terms of revenue? Share of installations doesn't mean quite as much if that ratio is in Apple's favor.
Wait, what? We are comparing really the 90% of Android Global Market Share vs 9% of iOS?
[deleted]
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
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.
FYI: Android 4.1, 4.2 and 4.3 will soon get no more updates to Chrome[1]. Android 4.0 is stuck on an old version of Chrome.
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...
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...
Android 4.1-3 are from 2012, early 2013. So 6-7 years old. Those old devices are barely functional to view modern webpages, anyway.
That’s the assumption I made but is that actually true you think? This is true of iOS devices after OS upgrades, I’ve experienced this myself: Apple ruins old devices with software updates. But I somehow doubt that a phone from 2012 must be ruined with bad software. Any idea?
Not bad software, underpowered mobile device CPUs. Mobile CPUs have only started stabilizing around "good enough" around late 2016 and that was for flagships (with Snapdragon 820, basically).
A mid range Android phone CPU will choke quite hard on modern Javascript-heavy web pages. Now think about a low range phone...
A mid range Android phone CPU will choke quite hard on modern Javascript-heavy web pages. Now think about a low range phone...
I don’t know, older Androids take 4-5 seconds to parse my webpack bundle. That’s not too bad for these devices, given that once it’s all parsed and evaluated, the app seems to work fine. I do want to buy some even older devices to see how they run. With webpack and a little effort, ares these older phones really bricks?
We still support Android 4.1, iOS7, and IE9 because our users don't choose to use our web app (their company does). There are low income users in our demographic for whom spending money to upgrade their phone is not their priority.
With care it is possible to make mobile web apps run at a reasonable speed even on low end devices. I personally like to aim to make things work OK on shitty old devices, that way I know it works well on newer devices. Also our code (custom) was originally written for IE6 so we started light, which helped.
A framework that appears to be good on low end devices is svelte.dev: "Last month, a developer in Brazil shared that [Svelte is] being used for point of sale systems in Brazil. There are like 200,000 of these devices in the wild. His job is to build this interface for the point of sale system. They're working with a very outdated version of WebKit on extremely memory constrained and performance constrained hardware. They tried a dozen different frameworks and none of them were up to the task. You would press a button on this interface and, half a second later, it would respond, which is kind of an awful user experience because you're more likely to press that button twice and end up overcharging your customers or something like that. They tried it with Svelte and it worked smoothly, so that is an example of what you can do when you have a framework that has a very, very low memory footprint and very good performance. Another example, we have a guy using it in the context of smart televisions, which also tend to be quite constrained devices." From: https://shoptalkshow.com/episodes/349/
With care it is possible to make mobile web apps run at a reasonable speed even on low end devices. I personally like to aim to make things work OK on shitty old devices, that way I know it works well on newer devices. Also our code (custom) was originally written for IE6 so we started light, which helped.
A framework that appears to be good on low end devices is svelte.dev: "Last month, a developer in Brazil shared that [Svelte is] being used for point of sale systems in Brazil. There are like 200,000 of these devices in the wild. His job is to build this interface for the point of sale system. They're working with a very outdated version of WebKit on extremely memory constrained and performance constrained hardware. They tried a dozen different frameworks and none of them were up to the task. You would press a button on this interface and, half a second later, it would respond, which is kind of an awful user experience because you're more likely to press that button twice and end up overcharging your customers or something like that. They tried it with Svelte and it worked smoothly, so that is an example of what you can do when you have a framework that has a very, very low memory footprint and very good performance. Another example, we have a guy using it in the context of smart televisions, which also tend to be quite constrained devices." From: https://shoptalkshow.com/episodes/349/
I’m excited to try Svelte. Looks great.
hopefully firefox will continue to run fine on those (and get faster over time)
chrome on android is dead to me. so many antifeatures it's maddening.
chrome on android is dead to me. so many antifeatures it's maddening.
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.
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.
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.
I think Google wants to allow OEMs to build devices that only support arm64-v8a arch - this will make the OS image significantly smaller because now they need to ship several components in duplicate - 32 and 64-bit versions. This is beneficial to total size of OS on the flash.
Apple did this years ago.
Apple did this years ago.
RAM usage as well as you no longer need to keep both 32-bit and 64-bit versions of OS libraries in memory at the same time.
Android was written for 32 bit. It couldn't run 64-bit before Lollipop. Currently there's about 2% of 64-bit Android devices (https://web.archive.org/web/20170808222202/http://hwstats.un...). I agree with performance argument, especially on battery-powered devices. But in this case there's nothing to be gained because LuaJIT is written for 32-bit CPU. Compiling for 64 bits won't do anything. Besides, hardly anything can squeeze more performance out of CPU than LuaJIT.
I'm complaining different issue, though. I researched the platform requirements before investing time into android development. I shared my work for free because Google doesn't allow developers in my country to charge money for their work. I kept updating the app following the user feedback. I will lose the product because of this. This feels like rug being swept under my feet :(
I'm complaining different issue, though. I researched the platform requirements before investing time into android development. I shared my work for free because Google doesn't allow developers in my country to charge money for their work. I kept updating the app following the user feedback. I will lose the product because of this. This feels like rug being swept under my feet :(
Why are you using an internet archive link from 2 years ago to support a claim about "currently"? It also seems to be misclassifying everything ARM into one bucket (probably because the stats were being collected from 32-bit code...).
It looks to me like for the past 3 years every single mobile ARM CPU released has been 64-bit, and even for 2 years before that roughly half of them, the market share of these must be much larger https://dev1.notebook-check.com/index.php?id=149513&sort=&ty...
It looks to me like for the past 3 years every single mobile ARM CPU released has been 64-bit, and even for 2 years before that roughly half of them, the market share of these must be much larger https://dev1.notebook-check.com/index.php?id=149513&sort=&ty...
This is the best data I could dig up. I would love to see newer statistics of market share, if anyone has a link.
> 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?
So the "non-technical" reason here is that you don't want to provide a build for users with 64-bit devices?
I'm not against 64-bit build, but it's too big effort. This feels like blackmail: "Either invest 40ish hours of your time to compile the framework and all dependencies to 64-bit, or you won't be able to update the app for existing users anymore"
I don't care about 64-bit devices. I'm fine with them not being able to install or run the app, if that's how it is. People with 64-bit devices can easily afford better products that my app tries to replace. I don't own device to test the 64-bit version, and I don't know anyone who does.
I care about existing users. I kept minimum SDK version as low as possible so that my app might reach all the cheap phones in poorer parts of world. It actually works today across many different devices, so what has changed?
I don't care about 64-bit devices. I'm fine with them not being able to install or run the app, if that's how it is. People with 64-bit devices can easily afford better products that my app tries to replace. I don't own device to test the 64-bit version, and I don't know anyone who does.
I care about existing users. I kept minimum SDK version as low as possible so that my app might reach all the cheap phones in poorer parts of world. It actually works today across many different devices, so what has changed?
For all but the most complex, or assembly-optimized, or just poorly written software, supporting 64-bit should be no more than a recompile. When I started producing 64-bit versions of my iOS apps, at first I didn’t even know it happened because Xcode just did it for me. Any yes, they included C and C++, and 3rd party code. It took zero hours to support. It was almost too automatic for comfort.
You might not always have access to the source of something you ship with your app.
> 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".
FWIW, Apple did exactly this a while before Google did.
FWIW, Apple did exactly this a while before Google did.
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.
Sadly, our company never executed this plan.
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.
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.
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.
I've been tracking the data from Google's Android dashboards over time : https://www.bidouille.org/misc/androidcharts
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%.
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.
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.
In Germany, on consumer stores at shopping malls you can still buy pre-paid devices with Lollipop.
dashboards like that are a bit pointless without region filtering. what is your target? eu? usa? china?
From the article: "So the Android ecosystem is split between at least 1,728 combinations of OS - Brand - Device Model"
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.
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.
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).
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)
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....
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....
Khronos likes to talk about Vulkan support on Android.
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.
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.
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.
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.
If Google was anything like Microsoft, they would produce stuff like Android 2019 OEM requirements, and provide the OS directly from them.
Like for example, the "PC 98 System Design Guide":
https://www.amazon.com/PC-98-System-Design-Guide/dp/15723171...
Fact is, just get a new phone is not an answer that consumers likes to hear.
Not every country is like US with everyone on contracts getting free replacements every two years.
Many of us enjoy the freedom of pre-paid replacable SIM cards, and use our phones until they either die or get stolen.
In any case, I only used Vulkan as the most recent example, I can give plenty of other ones, and I develop native Android as hobby.
Other Android developers with more in depth knowledge have plenty of war stories.
Like for example, the "PC 98 System Design Guide":
https://www.amazon.com/PC-98-System-Design-Guide/dp/15723171...
Fact is, just get a new phone is not an answer that consumers likes to hear.
Not every country is like US with everyone on contracts getting free replacements every two years.
Many of us enjoy the freedom of pre-paid replacable SIM cards, and use our phones until they either die or get stolen.
In any case, I only used Vulkan as the most recent example, I can give plenty of other ones, and I develop native Android as hobby.
Other Android developers with more in depth knowledge have plenty of war stories.
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?
My wallet is annoyed.
And as I replied to another comment, that is only one example among many.
I could write about Java 12 support, audio API, the constant changes in background processes, the multiple reboots on the UI framework, how NDK is handled and plenty others.
And as I replied to another comment, that is only one example among many.
I could write about Java 12 support, audio API, the constant changes in background processes, the multiple reboots on the UI framework, how NDK is handled and plenty others.
So how would you "fix" the issue? E.g. how would you add Vulcan on devices that do not have GPUs capable of Vulkan requirements and no proper drivers?
Have made it compulsory on Android 7, and like Microsoft has done multiple times, specify what the hardware requirements for any device should be.
And since Android 1, have made OS updates a requirement of the Android licence contract for Google services.
And since Android 1, have made OS updates a requirement of the Android licence contract for Google services.
And if they did that, instead you would have just bought a phone that was stuck on Android 6
> made OS updates a requirement of the Android licence contract
Now you're being contradictory. You want to force manufacturers to always update to the new Android versions. But you ALSO want to make Android 7 require specific hardware features. How could these requirements work together?
> made OS updates a requirement of the Android licence contract
Now you're being contradictory. You want to force manufacturers to always update to the new Android versions. But you ALSO want to make Android 7 require specific hardware features. How could these requirements work together?
The same way they have worked forever on the PC world.
OS updates always work with fallbacks, and minimum hardware specifications get revised every few years.
Google can ask Microsoft how to do it.
OS updates always work with fallbacks, and minimum hardware specifications get revised every few years.
Google can ask Microsoft how to do it.
That is something Google could do to actually solve things - make the OS binary compatible (rather than requiring device manufacturers to recompile) with driver blob plug-ins. It would require a change to the Linux driver ABI model but without know anything about Android I kind of assume they've already done that.
That is the point of Project Treble, where drivers run as user space processes and use Android IPC to talk with the kernel.
But, big but, the OEMs are free to decide when and how those updates are made available to users.
But, big but, the OEMs are free to decide when and how those updates are made available to users.
The first part of your solution conflicts with the second. You cannot both require new hardware for an OS version and require OS updates for old hardware.
It works for the PC market, as incredible as it may sound.
Those minimum requirements aren't set in stone, and OEMs seem to comply with them, strangely.
Those minimum requirements aren't set in stone, and OEMs seem to comply with them, strangely.
> Those minimum requirements aren't set in stone
is in direct disagreement with
> Have made it compulsory on Android 7
which is my point.
is in direct disagreement with
> Have made it compulsory on Android 7
which is my point.
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 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.
https://medium.com/use-hover/hover-launches-v1-0-stable-and-...
https://medium.com/use-hover/hover-launches-v1-0-stable-and-...
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.
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.
Should be more fragmented, until it gets to the point where I don't have to have ads kicking in my teeth daily.
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.
> ...owners (hopefully) buy a new Android device which offers latest updates.
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.
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't take into account is that Android is obviously split over tons of devices while iOS is, of course, set for Apple devices
> 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.
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.
[deleted]
I'm surprised to see Marshmallow (6.0) below Ice Cream Sandwich (4.0)
This is asinine. Android'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: "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)
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)
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.