8 ms·

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

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.

orangecat 7y ago
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-upside-down-camera https://www.theverge.com/2015/11/9/9696774/google-nexus-5x-u....
mattlondon 7y ago
+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.
- Avamander 7y ago
  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.
  - on_and_off 7y ago
    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.
    - pjmlp 7y ago
      On ADB Podcast about Bluetooth, they referred that certain models would just crash if someone tries to talk with specific protocol versions.
- threeseed 7y ago
  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.
  - on_and_off 7y ago
    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.
- megy 7y ago
  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.
clumsysmurf 7y ago
> 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-aimed-to-make-a-camera-os.html https://www.pcworld.com/article/2034723/android-founder-we-a...
- ac29 7y ago
  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.
matwood 7y ago
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.
throw03172019 7y ago
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.
- kitsunesoba 7y ago
  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…
blihp 7y ago
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.
- dmix 7y ago
  > 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.
  - blihp 7y ago
    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. ;-)
bluescrn 7y ago
Try doing anything vaguely graphical (games being the obvious example) and you’ll realise that a large percentage of Android devices are potatoes
megy 7y ago
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.
sonnyblarney 7y ago
"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.
milleramp 7y ago
“e.g. camera apps are an exception” This is a huge exception that suppresses third party innovation.
keerthiko 7y ago
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.
alkonaut 7y ago
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.

orangecat 7y ago

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-upside-down-camera https://www.theverge.com/2015/11/9/9696774/google-nexus-5x-u....

mattlondon 7y ago

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

Avamander 7y ago
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.
- on_and_off 7y ago
  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.
  - pjmlp 7y ago
    On ADB Podcast about Bluetooth, they referred that certain models would just crash if someone tries to talk with specific protocol versions.
threeseed 7y ago
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.
- on_and_off 7y ago
  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.
megy 7y ago
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.

clumsysmurf 7y ago

> 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-aimed-to-make-a-camera-os.html https://www.pcworld.com/article/2034723/android-founder-we-a...

ac29 7y ago
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.

matwood 7y ago

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.

throw03172019 7y ago

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.

kitsunesoba 7y ago
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…

blihp 7y ago

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.

dmix 7y ago
> 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.
- blihp 7y ago
  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. ;-)

bluescrn 7y ago

Try doing anything vaguely graphical (games being the obvious example) and you’ll realise that a large percentage of Android devices are potatoes

megy 7y ago

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.

sonnyblarney 7y ago

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

milleramp 7y ago

“e.g. camera apps are an exception” This is a huge exception that suppresses third party innovation.

keerthiko 7y ago

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.

alkonaut 7y ago

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.