
How Fragmented Is Android? - tgp22
https://eggonomy.com/blogs/news/how-fragmented-is-android
======
on_and_off
I work on an Android app aimed at the North American market.

Android O, P and Q are 88% of our Android devices. By far and large,
fragmentation is something I _never_ have to think about.

Jetpack libraries are here to handle it for us, as an abstraction layer
between the OS and third party apps.

I would have mentioned that e.g. camera apps are an exception : here hardware
fragmentation can be a pain. I was half surprised to see that Google is also
working on that one with the camera x library.

There have been cases where the fragmentation bites us; and there might be in
the future (although in all fainess my iOS colleagues sometimes have to create
specific fixes as well) but the last time I had to scratch my head because of
a device specific bug was years ago.

And at the time, I was already finding these articles deeply ridiculous.

~~~
blihp
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](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.

~~~
on_and_off
>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.

~~~
izuchukwu
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.

~~~
on_and_off
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.

------
rarestblog
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](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).

~~~
stesch
By the way: iPhone 4 supports iOS 7.1.2, released 4 years after the iPhone 4.

~~~
Wowfunhappy
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.)

~~~
alkonaut
> 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.

------
DiabloD3
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.

~~~
scarface74
_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?

~~~
pjmlp
May 2019 Windows 10 version runs just fine on this 2009 laptop.

~~~
scarface74
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...](https://www.notebookcheck.net/Review-Dell-
Latitude-E6500-Notebook.11958.0.html)) 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.

------
com2kid
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/](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!

~~~
rubyn00bie
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.

~~~
pjmlp
It helps that each version does it differently, and the OEMs also make their
own set of fine tuning.

------
monocasa
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.

~~~
djsumdog
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/](https://penguindreams.org/blog/android-fragmentation/)

~~~
derefr
> 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.

~~~
pjc50
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.

~~~
djsumdog
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.

------
jherdman
> 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.

~~~
Gudin
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.

~~~
matwood
"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.

~~~
chipperyman573
>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.

------
eugeniub
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.

~~~
on_and_off
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

------
dmitryminkovsky
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.

~~~
robocat
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...](https://www.xda-developers.com/google-chrome-android-dropping-
support-android-4-1-4-3-jelly-bean/)

~~~
oblio
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.

~~~
dmitryminkovsky
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?

~~~
oblio
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...

~~~
dmitryminkovsky
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?

~~~
robocat
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/](https://shoptalkshow.com/episodes/349/)

~~~
dmitryminkovsky
I’m excited to try Svelte. Looks great.

------
jmiskovic
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.

~~~
chipperyman573
>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.

~~~
izacus
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.

~~~
kalleboo
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.

------
ezoe
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.

~~~
ineedasername
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.

------
twodave
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.

------
bahmboo
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.

~~~
klingonopera
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.

------
ajnin
I've been tracking the data from Google's Android dashboards over time :
[https://www.bidouille.org/misc/androidcharts](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%.

~~~
izacus
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.

------
somedudetbh
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...](https://www.anandtech.com/show/14072/the-samsung-
galaxy-s10plus-review)

This "device model" is actually two devices with completely different SoCs.
There is no meaningful sense in which these two phones are one device.
Sometimes the manufacturers document this, sometimes they just start selling a
phone that identifies itself by the same name as an existing phone but with a
GPU that has completely different performance characteristics.

~~~
IshKebab
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).

------
ineedasername
> _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)

------
xs83
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....

------
pjmlp
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.

~~~
zanny
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.

~~~
pjmlp
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...](https://www.amazon.com/PC-98-System-Design-
Guide/dp/1572317167)

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.

------
ChrisRR
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

------
jessshorland
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-
scalable-f65e33731090)

------
krschultz
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.

------
mymythisisthis
Should be more fragmented, until it gets to the point where I don't have to
have ads kicking in my teeth daily.

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

~~~
OrgNet
Why would it be a problem for larger apps that have a bigger budget?

------
nrjames
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.

------
stesch
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?

~~~
klingonopera
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.

------
tempodox
> ...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.

------
8bitrebellion
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

------
rocky1138
> 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.

~~~
mberning
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.

------
m-p-3
I'm surprised to see Marshmallow (6.0) below Ice Cream Sandwich (4.0)

------
myko
This is asinine. Android's support library makes fragmentation a non-issue for
the vast majority of applications.

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

------
ggg2
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)

