8 ms·

The Android Screen Fragmentation Myth

146 points by chanux 12y ago

barbs 12y ago
I think that OS fragmentation/backwards-compatibility is more of a problem than screen fragmentation, definitely more so than iOS.
coldtea 12y ago
Hmm, the whole write-up doesn't really disprove the screen fragmentation issue. Mostly downplays it. That there are layout tools to help you cater for multiple screens for example, doesn't mean they do that work for you. Or that the "slight variation in width" he mentions should not also be taken care of. (Which is just part of the whole problem -- there's also the hardware features and OS version issues which are even more important).
- veeti 12y ago
  > Or that the "slight variation in width" he mentions should not also be taken care of. What exactly is the issue with this? Just like with any other sane widget toolkit designed since the 80's for varying screen or window sizes, Android's layouts and widgets work perfectly fluid to occupy more or less space. One layout works just as well on a 4-inch phone as it does on a 5.5-inch phone, and it will naturally fit more content on the bigger screen. The only problem is with tablet screens where blowing up a user interface designed for a small phone screen technically works but is pretty terrible to use. This is no different from another unnamed mobile platform where you also need to design a separate tablet layout.
  - coldtea 12y ago
    >What exactly is the issue with this? Just like with any other sane widget toolkit designed since the 80's for varying screen or window sizes, Android's layouts and widgets work perfectly fluid to occupy more or less space. It becomes an issue if you're not a sloppy kind of designer/programmer, who just lets the widget flow to occupy more available space. It's not like design only use things like a text entry boxes or a web-views (widgets that just letting them get more space is usually fine and natural). Second, it becomes an issue for every app where you want to have a custom interface -- so the built-in Android widget and layout are of no use to you. This holds for most games, customly designed apps, etc.
    - veeti 12y ago
      > It becomes an issue if you're not a sloppy kind of designer/programmer, who just lets the widget flow to occupy more available space. What? In most cases, that is exactly the right thing to do. Your content should be the center of the app in the first place. > It's not like design only use things like a text entry boxes or a web-views (widgets that just letting them get more space is usually fine and natural). Why don't you name some actual, concrete examples instead of making vague statements like this? Where do you think that this is an issue? > Second, it becomes an issue for every app where you want to have a custom interface -- so the built-in Android widget and layout are of no use to you. This holds for most games, customly designed apps, etc. What does a "customly designed app" even mean? There are countless examples of Android applications designed beyond the norm (http://androidniceties.tumblr.com/ http://androidniceties.tumblr.com/) and they don't seem to have any problem doing so - and guess what: they're using the Android frameworks just like everybody else. And just like application developers, game developers have been working with a myriad of different screen resolutions for ages now. The only people having a problem with this are those exclusively developing for a certain fruit device that has shot itself in the foot by not designing for varying resolutions in the first place. It's not rocket surgery.
    - GrinningFool 12y ago
      It becomes an issue if you're not a sloppy kind of designer/programmer, who just lets the widget flow to occupy more available space. So it's sloppy to build your UI in the exact way it was intended to be built? Not hard-coding every widget sizes is somehow... sloppy? Because the impression I get is that if you can make your app handle different screen sizes appropriately without having to meticulously hand code for every resolution, you're coming out way ahead of the game. That way you present a nice, consistent UX across all devices, and don't have to scramble every time a new resolution or device size comes out. It's also possible to do this with custom interfaces - a little extra attention to your layout engine will net huge benefits in terms of time saved in designing layouts for each of the possible resolutions. Hardware variations, vendor customizations, capabilities variance - these are real issues. Building a UI that flows well across most resolutions and sizes? Not so much. [edit for grammar]
    - pmontra 12y ago
justinpaulson 12y ago
So if you ignore all the weird screen sizes it is only fragmented into 4 different sizes? And you still have to create layouts for each of those sizes? I wouldn't say the point was very strongly made.
- Phoshi 12y ago
  You could build one layout using relative positioning and have it scale to each of those easily. If you want different layouts for different devices, this is an option, but by default things won't break unless you're explicitly positioning things absolutely instead of relatively.
- babuskov 12y ago
  I can confirm this, at least for games. For the last game I made, I had to have all assets in 4 sizes, which makes it look nice in all resolutions ranging from 800x450 to Nexus10 2560x1600. I maintain the aspect ratio and have background that is larger (both wider and taller) than "playing field", so that I can fill up that space on devices with different aspect ratio. What article fails to mention that all Android devices have aspect ratio between 4:3 and 16:9, and you should design around that. The background image looks like this (not my game): http://blog.gemserk.com/wp-content/uploads/2013/01/mainmenu-areas-example2-300x210.png http://blog.gemserk.com/wp-content/uploads/2013/01/mainmenu-... the area inside red rectangle is guaranteed to be shown on all devices, and area outside that is the filler. Now, to make sure your "action area": - uses device native resolution for crisp image and - is not too small ...you have to have all the assets in different sizes. I found that having 4 different sizes does this nicely: 1. targeting 800x450 action area 2. targeting 1280x720 3. targeting 1920x1080 4. targeting 2560x1440 Now, you could pick different boundaries, but a lot of devices use 800, 1280 or 1920 as their base width. The only drawback to this is that some tablets with 1024px width would have a lot of filler area because they would use 800x450 assets. So, having: 5. targeting 1024x576 would make it complete. But I'm not sure there are many 1024px devices out there, so I skipped that one.
- chrisrhoden 12y ago
  No, if you ignore a tiny segment of the market the changes in screen sizes are tiny. And you have been able to create scalable views (and really have only had the option of doing so) since day one, so mostly you just create a single layout. The tools on Android are very similar to the ones on the web - they are designed to scale and stretch because they need to.
sujal99 12y ago
Reporting wrong dpi is the real issue.
- stusmall 12y ago
  How many phone out there do that? I'm really curious on this and who I should watch out for. Also how do you detect and deal with it?
  - sujal99 12y ago
    Don't have the answer. I tried with i-Ball tablet (India made), noticed that.
CommitPull 12y ago
It is really a myth. I've developed over 30 apps so far and everything is handled by Relative Layouts. So instead of saying that you want that button 220px to the right of the top-left corner and 100px to the bottom like on iPhone, you simply say that you want that button 20px to the right of the button on the left and 20px further down. That's it and this way, you will have everything perfectly layed out on 95% of Android devices and it just takes the same time as on iPhone. If you want to get the last 5%, so that your design also looks perfectly on all the weird screen sizes, then you have to put in some extra effort, but otherwise it's just the same effort as for iPhone apps.
ulfw 12y ago
"That’s the beauty of Android’s massive market share, we can ignore all the people with phones running Android 2.3, those with odd and rare screen sizes, and target only 4.0 and above" Well duh. If you ignore all the things that give you trouble/fragmentation you automagically get a trouble-free/fragmentation-free environment. Silly
- mattdonders 12y ago
  Gingerbread is down to 13.5% which is really great and with Google's new Android One program, I think you will see that number drop significantly.
- weavie 12y ago
  I think he is trying to say that because there are so many Android devices out there, you can afford to ignore the troublesome ones and still have a huge market to cater to.
- pilsetnieks 12y ago
  You have to ask, though, if those with the old, weird and outdated devices are the users you want to target at the cost of doing more productive development for users with more recent and capable devices who obviously can afford and/or care more about their mobile experience.
- deleted 12y ago
  [deleted]
Argorak 12y ago
This post pulls a neat trick: the diagram they criticise is all android devices while their diagram is only phones. And suddenly: > The above diagram and analysis also only take into account phones, not tablets, _where designing for physical screen size becomes more important than resolution._
svdree 12y ago
Android fragmentation is real, but screen sizes are not part of the issue. The whole system is built around the idea of supporting different screen sizes, and provides you with the tools you need to handle them. The real fragmentation is in hardware support (don't get me started on OpenGL-ES drivers) and manufacturers that modify the OS in crazy ways. It's quite frustrating to receive crash reports with stack traces showing a crash originating in some manufacturers custom code, with no way of knowing what went wrong.
- esolyt 12y ago
  My favorite Android app is Moves. Moves does not work on Samsung Galaxy Note II, thanks to one of many tweaks Samsung has done to Android. This phone is one of the most popular Android phones in the world and it's running a very recent version of Android. I find this completely unacceptable. A lot of games and certain apps also list "compatible devices" in their Play Store description area. Some developers even warn users not to pay for and download the app if their phone is not supported. Android fragmentation is unfortunately very real.
- Zigurd 12y ago
  This is true but mostly an issue for games. With multiple OEMs and multiple sources of GPUs and drivers - significantly more than for PCs, the only solution is for driver quality to improve. History suggests not holding one's breath.
- jaxytee 12y ago
  For the wild west of Android html5 hybrid development, fragmentation is a huge problem. Different manufacturers roll different implementations that behave differently. Javascript event propagation varied and broke my app on my last HTML5 project. Luckily, the chrome view will be the default webview from KitKat onwards, but it will take at least two years for 4.4+ to become ubiquitous.
  - adl 12y ago
    This! I feel your pain. I'm on the same boat, trying to support mobile HTML5 on Android. To be fair, iOS has it's own issues with HTML5 development.
smackfu 12y ago
At the same time, Apple is strongly pushing developers to not use pixel perfect layouts anymore that are dependent on particular screen sizes, and to use auto layout everywhere. If you follow Apple's iOS 8 guidance, you really shouldn't have any problem dealing with even the original graph of "terrible" fragmentation. Which prompts the question whether it was really that bad after all, or just a gut reaction to something that was different.
- mitchty 12y ago
  So I'm just a old town country ios programmer for fun, so please correct me if I'm wrong. But wasn't the original issue that there wasn't a great way to deal with the multiple layouts/issues on the early 2.3 and below android models? ios8 makes it plainly obvious that "something" is coming that will throw out the "the size of the screen shall be 5 and 5 shall be the size of counting, not 3 nor 4 but 5" paradigm. That or multitasking similar to windows 8 maybe. But this shouldn't be all that crazy hard, we had how many years to deal with 800x600/1024x768/etc...
  - chrisrhoden 12y ago
    Nope, there have been no substantive changes to the way one handles these layouts since android 1.0, with the exception of some additional targeting for LTR and changes to the way you address physically larger or smaller screens (as opposed to screens with fewer or more pixels).
  - fpgeek 12y ago
    The core infrastructure for variable screen sizes and densities was introduced in Android 1.6 Donut (September 2009). There have been improvements with newer versions (e.g. more sizes and densities), but that's straightforward to deal with. The other big improvement was the Fragments API that came with Android 3.0 Honeycomb (February 2011), but that came with a compatibility library that worked all the way back to Donut. And it was more about decomposing your UI into components that could be arranged differently for phones and tablets, not about adjusting a single UI within a device class.
- nb1981 12y ago
deleted 12y ago
[deleted]
The_Double 12y ago
I never got the problem anyway. What magic one resolution devices did you use to develop on before the iPhone?
- fpgeek 12y ago
  Well there was that generation of web designers that believed the world was 1024x768 (or 800x600).
  - taeric 12y ago
    To be fair, the belief is a little more that anything wider than 1024 is typically too wide. Find me a site that lets text run for even that long. Typically you box things in much more heavily.
    - jayd16 12y ago
      >Find me a site that lets text run for even that long. Hacker News
      - taeric 12y ago
        :) I meant to say that you let run for longer than 1024 and can actually read. Also, my ultimate point is that reading text at a normal size that goes longer than 1024 pixels before wrapping isn't exactly pleasant.
    - nitrogen 12y ago
      That should really be the decision of the browser user, but sadly years of poor training has led far too many people to just maximize every window, no matter how big their screen is.
      - taeric 12y ago
        To an extent. Sites like bostonglobe (and google plus) take it to give more columns the wider you are. This is no different than how newspapers are done. Just because you have a giant piece of paper doesn't mean you should let the text flow completely across it.
brendan_gill 12y ago
One thing that the op doesn't address is that the top 10 devices they have selected account for only a fraction of android market. I think there is an implicit assumption that if you cover the top 10 device models you can consider that a proxy for the overall android market but the original fragmentation report shows that to even cover 50% of the market you need to consider around 60-70 device models.
- 21echoes 12y ago
  i think his larger point is that it's not screen size that causes layout fragmentation, it's screen aspect ratio, which is (basically definitionally) more consistent across devices.
thathonkey 12y ago
Don't think there's any fragmentation problems on Android OS? Just try creating a mobile website that supports common "modern" devices. Have fun trying to wrap your brain around all the idiosyncrasies across various versions and browser implementations (Android Stock vs Chrome etc) that will endlessly dirty your code if you want the site to look at all correct in a majority of Android devices. The Android emulator is pretty nice... once you figure out how to set it up for whatever device you're trying to test. It's a ridiculous resource hog though by default (there are ways to mitigate this if you're on an Intel chip). Say what you will about simulation vs. emulation but the iOS Simulator is a dream to work with (again, for web development) and I've never had it mislead me even though it isn't truly emulated. But then you realize there is no way to install the Chrome browser unless you are hooked up to the Android Marketplace (even if you're on the latest version of OS). The best you can get is Chromium, which is a pain to install and doesn't work on some AVDs. All that ranting aside, I've never had a problem with screen sizes, even when working on responsive stuff. But, yeah, Android is basically the Internet Explorer of the mobile space. You'll keep hearing "oh the next version will fix that!" and it may... but you'll be stuck supporting the versions that are broken for years to come.
- kllrnohj 12y ago
  That's fragmentation in web browsers, that has fuck-all to do with the OS or Android's SDK or anything the author is talking about.
  - thathonkey 12y ago
    Oh thanks for breaking it down for me. When it comes to web development, for all intents and purposes, they can be thought of as one in the same since the browser version issued with a device is tied to OS version[1]. Of course some users will upgrade OS and/or browser, independently in some cases, which complicates things further. [1] http://jimbergman.net/webkit-version-in-android-version/ http://jimbergman.net/webkit-version-in-android-version/
    - stusmall 12y ago
GBKS 12y ago
I think Android is shooting itself in the foot here by making things look more complicated than they might be. Take a look at the documentation for screen support (http://developer.android.com/guide/practices/screens_support.html http://developer.android.com/guide/practices/screens_support...). They split phone sizes (2-10") into four generalized sizes (small, normal, large, xlarge). Then they split screen density into generalized densities (ldpi, mdpi, hdpi, xhdpi) based on 3:4:6:8 ratios. The example on the page lists 5 different layout XML files (the 4 previously mentioned + extra large landscape orientation) for different sizes, and three folders for image assets in different densities. But, there are tablet layouts for Android 3.2+, which use a completely different system based on size qualifiers where you can provide minimum/maximum pixel sizes for layouts. The logic for iOS seems super simple in comparison. With a few Android projects under your belt, you have probably internalized how everything works, and which parts are fringe cases you can ignore. But if you're new to this (or a journalist/analyst with limited technical depth), it seems like an absolute mess. Simply rewriting this documentation and providing better tutorials and resources could go very far to clarify the situation.
- ZoFreX 12y ago
  Generalised sizes are a deprecated way of handling screen sizes on Android, from version 3.2 onward we use far more traditional dividers such as minimum width. For many developers it's viable to support only 4+, which lets you avoid a lot of the trickiness. Also, even if you are supporting 2.x, you don't HAVE to have a separate layout file for each generalized size. If you make a flexible layout that works on all sizes, you can just declare it once (and doing so is not difficult in most cases). I totally agree the documentation needs work. Some areas have not been updated in a very long time.
joeblau 12y ago
As a developer, layout and screen size is not the main problem with Android. To be honest, Android isn't even the problem. It's hardware that Android is built on that is the problem. If a handset is broken down into all of it's sensors [Speaker, Camera, Light Sensor, Microphone, Compass, Accelerometer, Clock, NFC, GPS, Screen, BLE, Wifi, Altimeter, Speedometer, CPU] that's where the fragmentation problem is. It's hard to say which devices contain certain sensors (CPU, Screen, Camera, Mic, and Speakers are pretty standard). Of the devices that have most of those sensors, it's hard to say say which devices have those sensors working correctly. I attended a Facebook/Parse hackathon where FB detailed issues about a certain bug in specific CPU's with respect to a C++ based photo processing library. Certain Android phones would randomly crash. There is also the infamous compass video [1] where multiple devices all with different hardware report different readings. As a developer, the Android Emulator makes me think I'm going to have a consistent user experience, but based on hardware, I may not. In my personal experience, I built this game (http://joeblau.com/orb./ http://joeblau.com/orb./) which runs on iOS and Android and I noticed a crazy bug where it would only crash on S4's from Sprint, not from Verizon or AT&T. I re-worked some code to get the application working eventually, but the fact that something would only break on a specific carrier's version of the hardware was crazy to me. The problem is not Android; Android as an OS is actually very good. The problem is HTC, Samsung, Motorola and all of the other hardware manufacturers that build the handsets. Thankfully Google is doing what it can to address the hardware issue by announcing their Android One program, but that hurts other hardware competitors. [1] - https://vine.co/v/MgWLMmmwUQQ https://vine.co/v/MgWLMmmwUQQ
- npsimons 12y ago
  This was addressed at the Linux Plumbers Conference and the Linux kernel mailing list a few years ago. The problem is not just hardware manufacturers trying to differentiate themselves, but carriers fucking around with software loads trying to differentiate themselves. On the hardware side at least, this resulted in virtually a brand new port to every new SBC that came out, even though they were almost all ARM. It used to be you could run Linux on MIPS, SPARC, Alpha, PowerPC, Intel, etc, and not be able to tell the difference from an end user perspective. Then everyone got dollar signs in their eyes, and Google managed to fudge the whole "open" thing so that people were okay with binary drivers (I also blame Ubuntu for acceptance of this), and now you see the mess it's resulted in. Don't get me wrong, I'll take the Android bazaar with its wide variety of choice every day (and twice on Sunday) over the one-size-fits-all-we'll-tell-you-what-you-need style of iOS, but the insanity with differentiating things via closed methods needs to stop. And the Android/Linux developers are aware of the problem and dealing with it the best they can; the problem is all the handset manufacturers and carriers fucking things up.
gabemart 12y ago
I'm developing my first Android application and am beginning to work on the interface in earnest. Can anyone recommend some good tutorials or guides for producing elegant layouts that respond well to different screen sizes? I understand the basic mechanics and laid out in the dev guides, but I'm a bit lots when it comes to putting it all together elegantly.
adl 12y ago
my main issue with Android fragmentation is trying to support HTML5 Apps with PhoneGap/Cordova and various JS toolkits (Sencha Touch, JQueryMobile, Dojo). Each version(4.0, 4.1, 4.2, 4.3) has a slightly different version of the default browser and WebViewUI component(and don't get me started on Samsung devices which have their own issues regarding the default browser) with it's own quirks and rendering issues. They kinda fixed that in KitKat 4.4, using Chromium 30 as the basis of the WebViewUI component, but KitKat deployments in the wild are in the single digits.
cyorir 12y ago
Screen fragmentation was a large problem even before Android. When I was first learning to program, one of the platforms I initially targeted was Windows Mobile, version 6.0. On this platform fragmentation was limited because there were only so many devices developed for Windows Mobile (although screen resolutions were generally different for QVGA vs non-QVGA screens, and smartphones with keyboards had smaller resolutions). Nevertheless, fragmentation was still a problem. Without an api adequate for handling different screen sizes and resolutions, it was hard to develop an application for one device then port it to other devices. I use the term "port" because usually this was actual porting; in some cases it would have been better to have a separate binary for each target device than to have a single binary for all devices. I think the reason Windows Mobile developers were so rare compared to developers for emerging platforms like iOS and Android despite Windows Mobile having been around longer is that the alternatives learned from WM's poor example to create better apis. When I switched from Windows Mobile to playing around with Android 2.1, there was so much more I could do with layouts and the simulator in the IDE to target more devices. Newer versions of iOS, Android 4, Windows Phone, and others have all been improved in this regards even more, to the point that I now think of screen fragmentation as something of a non-issue when I tinker with mobile apps.
jbk 12y ago
What I don't get and frustrates me, as a developer, is the impossibility to use SVG in Android. We need to handle a lot of PNGs, in result. Android is re-compiling/re-optimizing for ART, so why not re-export the SVG in PNG format, at the right screen size, at first run?

146 points by chanux 12y ago

barbs 12y ago

I think that OS fragmentation/backwards-compatibility is more of a problem than screen fragmentation, definitely more so than iOS.

coldtea 12y ago

Hmm, the whole write-up doesn't really disprove the screen fragmentation issue. Mostly downplays it. That there are layout tools to help you cater for multiple screens for example, doesn't mean they do that work for you. Or that the "slight variation in width" he mentions should not also be taken care of. (Which is just part of the whole problem -- there's also the hardware features and OS version issues which are even more important).

veeti 12y ago
> Or that the "slight variation in width" he mentions should not also be taken care of. What exactly is the issue with this? Just like with any other sane widget toolkit designed since the 80's for varying screen or window sizes, Android's layouts and widgets work perfectly fluid to occupy more or less space. One layout works just as well on a 4-inch phone as it does on a 5.5-inch phone, and it will naturally fit more content on the bigger screen. The only problem is with tablet screens where blowing up a user interface designed for a small phone screen technically works but is pretty terrible to use. This is no different from another unnamed mobile platform where you also need to design a separate tablet layout.
- coldtea 12y ago
  >What exactly is the issue with this? Just like with any other sane widget toolkit designed since the 80's for varying screen or window sizes, Android's layouts and widgets work perfectly fluid to occupy more or less space. It becomes an issue if you're not a sloppy kind of designer/programmer, who just lets the widget flow to occupy more available space. It's not like design only use things like a text entry boxes or a web-views (widgets that just letting them get more space is usually fine and natural). Second, it becomes an issue for every app where you want to have a custom interface -- so the built-in Android widget and layout are of no use to you. This holds for most games, customly designed apps, etc.
  - veeti 12y ago
    > It becomes an issue if you're not a sloppy kind of designer/programmer, who just lets the widget flow to occupy more available space. What? In most cases, that is exactly the right thing to do. Your content should be the center of the app in the first place. > It's not like design only use things like a text entry boxes or a web-views (widgets that just letting them get more space is usually fine and natural). Why don't you name some actual, concrete examples instead of making vague statements like this? Where do you think that this is an issue? > Second, it becomes an issue for every app where you want to have a custom interface -- so the built-in Android widget and layout are of no use to you. This holds for most games, customly designed apps, etc. What does a "customly designed app" even mean? There are countless examples of Android applications designed beyond the norm (http://androidniceties.tumblr.com/ http://androidniceties.tumblr.com/) and they don't seem to have any problem doing so - and guess what: they're using the Android frameworks just like everybody else. And just like application developers, game developers have been working with a myriad of different screen resolutions for ages now. The only people having a problem with this are those exclusively developing for a certain fruit device that has shot itself in the foot by not designing for varying resolutions in the first place. It's not rocket surgery.
  - GrinningFool 12y ago
    It becomes an issue if you're not a sloppy kind of designer/programmer, who just lets the widget flow to occupy more available space. So it's sloppy to build your UI in the exact way it was intended to be built? Not hard-coding every widget sizes is somehow... sloppy? Because the impression I get is that if you can make your app handle different screen sizes appropriately without having to meticulously hand code for every resolution, you're coming out way ahead of the game. That way you present a nice, consistent UX across all devices, and don't have to scramble every time a new resolution or device size comes out. It's also possible to do this with custom interfaces - a little extra attention to your layout engine will net huge benefits in terms of time saved in designing layouts for each of the possible resolutions. Hardware variations, vendor customizations, capabilities variance - these are real issues. Building a UI that flows well across most resolutions and sizes? Not so much. [edit for grammar]
  - pmontra 12y ago

justinpaulson 12y ago

So if you ignore all the weird screen sizes it is only fragmented into 4 different sizes? And you still have to create layouts for each of those sizes? I wouldn't say the point was very strongly made.

Phoshi 12y ago
You could build one layout using relative positioning and have it scale to each of those easily. If you want different layouts for different devices, this is an option, but by default things won't break unless you're explicitly positioning things absolutely instead of relatively.
babuskov 12y ago
I can confirm this, at least for games. For the last game I made, I had to have all assets in 4 sizes, which makes it look nice in all resolutions ranging from 800x450 to Nexus10 2560x1600. I maintain the aspect ratio and have background that is larger (both wider and taller) than "playing field", so that I can fill up that space on devices with different aspect ratio. What article fails to mention that all Android devices have aspect ratio between 4:3 and 16:9, and you should design around that. The background image looks like this (not my game): http://blog.gemserk.com/wp-content/uploads/2013/01/mainmenu-areas-example2-300x210.png http://blog.gemserk.com/wp-content/uploads/2013/01/mainmenu-... the area inside red rectangle is guaranteed to be shown on all devices, and area outside that is the filler. Now, to make sure your "action area": - uses device native resolution for crisp image and - is not too small ...you have to have all the assets in different sizes. I found that having 4 different sizes does this nicely: 1. targeting 800x450 action area 2. targeting 1280x720 3. targeting 1920x1080 4. targeting 2560x1440 Now, you could pick different boundaries, but a lot of devices use 800, 1280 or 1920 as their base width. The only drawback to this is that some tablets with 1024px width would have a lot of filler area because they would use 800x450 assets. So, having: 5. targeting 1024x576 would make it complete. But I'm not sure there are many 1024px devices out there, so I skipped that one.
chrisrhoden 12y ago
No, if you ignore a tiny segment of the market the changes in screen sizes are tiny. And you have been able to create scalable views (and really have only had the option of doing so) since day one, so mostly you just create a single layout. The tools on Android are very similar to the ones on the web - they are designed to scale and stretch because they need to.

sujal99 12y ago

Reporting wrong dpi is the real issue.

stusmall 12y ago
How many phone out there do that? I'm really curious on this and who I should watch out for. Also how do you detect and deal with it?
- sujal99 12y ago
  Don't have the answer. I tried with i-Ball tablet (India made), noticed that.

CommitPull 12y ago

It is really a myth. I've developed over 30 apps so far and everything is handled by Relative Layouts. So instead of saying that you want that button 220px to the right of the top-left corner and 100px to the bottom like on iPhone, you simply say that you want that button 20px to the right of the button on the left and 20px further down. That's it and this way, you will have everything perfectly layed out on 95% of Android devices and it just takes the same time as on iPhone. If you want to get the last 5%, so that your design also looks perfectly on all the weird screen sizes, then you have to put in some extra effort, but otherwise it's just the same effort as for iPhone apps.

ulfw 12y ago

"That’s the beauty of Android’s massive market share, we can ignore all the people with phones running Android 2.3, those with odd and rare screen sizes, and target only 4.0 and above" Well duh. If you ignore all the things that give you trouble/fragmentation you automagically get a trouble-free/fragmentation-free environment. Silly

mattdonders 12y ago
Gingerbread is down to 13.5% which is really great and with Google's new Android One program, I think you will see that number drop significantly.
weavie 12y ago
I think he is trying to say that because there are so many Android devices out there, you can afford to ignore the troublesome ones and still have a huge market to cater to.
pilsetnieks 12y ago
You have to ask, though, if those with the old, weird and outdated devices are the users you want to target at the cost of doing more productive development for users with more recent and capable devices who obviously can afford and/or care more about their mobile experience.
deleted 12y ago
[deleted]

Argorak 12y ago

This post pulls a neat trick: the diagram they criticise is all android devices while their diagram is only phones. And suddenly: > The above diagram and analysis also only take into account phones, not tablets, _where designing for physical screen size becomes more important than resolution._

svdree 12y ago

Android fragmentation is real, but screen sizes are not part of the issue. The whole system is built around the idea of supporting different screen sizes, and provides you with the tools you need to handle them. The real fragmentation is in hardware support (don't get me started on OpenGL-ES drivers) and manufacturers that modify the OS in crazy ways. It's quite frustrating to receive crash reports with stack traces showing a crash originating in some manufacturers custom code, with no way of knowing what went wrong.

esolyt 12y ago
My favorite Android app is Moves. Moves does not work on Samsung Galaxy Note II, thanks to one of many tweaks Samsung has done to Android. This phone is one of the most popular Android phones in the world and it's running a very recent version of Android. I find this completely unacceptable. A lot of games and certain apps also list "compatible devices" in their Play Store description area. Some developers even warn users not to pay for and download the app if their phone is not supported. Android fragmentation is unfortunately very real.
Zigurd 12y ago
This is true but mostly an issue for games. With multiple OEMs and multiple sources of GPUs and drivers - significantly more than for PCs, the only solution is for driver quality to improve. History suggests not holding one's breath.
jaxytee 12y ago
For the wild west of Android html5 hybrid development, fragmentation is a huge problem. Different manufacturers roll different implementations that behave differently. Javascript event propagation varied and broke my app on my last HTML5 project. Luckily, the chrome view will be the default webview from KitKat onwards, but it will take at least two years for 4.4+ to become ubiquitous.
- adl 12y ago
  This! I feel your pain. I'm on the same boat, trying to support mobile HTML5 on Android. To be fair, iOS has it's own issues with HTML5 development.

smackfu 12y ago

At the same time, Apple is strongly pushing developers to not use pixel perfect layouts anymore that are dependent on particular screen sizes, and to use auto layout everywhere. If you follow Apple's iOS 8 guidance, you really shouldn't have any problem dealing with even the original graph of "terrible" fragmentation. Which prompts the question whether it was really that bad after all, or just a gut reaction to something that was different.

mitchty 12y ago
So I'm just a old town country ios programmer for fun, so please correct me if I'm wrong. But wasn't the original issue that there wasn't a great way to deal with the multiple layouts/issues on the early 2.3 and below android models? ios8 makes it plainly obvious that "something" is coming that will throw out the "the size of the screen shall be 5 and 5 shall be the size of counting, not 3 nor 4 but 5" paradigm. That or multitasking similar to windows 8 maybe. But this shouldn't be all that crazy hard, we had how many years to deal with 800x600/1024x768/etc...
- chrisrhoden 12y ago
  Nope, there have been no substantive changes to the way one handles these layouts since android 1.0, with the exception of some additional targeting for LTR and changes to the way you address physically larger or smaller screens (as opposed to screens with fewer or more pixels).
- fpgeek 12y ago
  The core infrastructure for variable screen sizes and densities was introduced in Android 1.6 Donut (September 2009). There have been improvements with newer versions (e.g. more sizes and densities), but that's straightforward to deal with. The other big improvement was the Fragments API that came with Android 3.0 Honeycomb (February 2011), but that came with a compatibility library that worked all the way back to Donut. And it was more about decomposing your UI into components that could be arranged differently for phones and tablets, not about adjusting a single UI within a device class.
nb1981 12y ago

deleted 12y ago

[deleted]

The_Double 12y ago

I never got the problem anyway. What magic one resolution devices did you use to develop on before the iPhone?

fpgeek 12y ago
Well there was that generation of web designers that believed the world was 1024x768 (or 800x600).
- taeric 12y ago
  To be fair, the belief is a little more that anything wider than 1024 is typically too wide. Find me a site that lets text run for even that long. Typically you box things in much more heavily.
  - jayd16 12y ago
    >Find me a site that lets text run for even that long. Hacker News
    - taeric 12y ago
      :) I meant to say that you let run for longer than 1024 and can actually read. Also, my ultimate point is that reading text at a normal size that goes longer than 1024 pixels before wrapping isn't exactly pleasant.
  - nitrogen 12y ago
    That should really be the decision of the browser user, but sadly years of poor training has led far too many people to just maximize every window, no matter how big their screen is.
    - taeric 12y ago
      To an extent. Sites like bostonglobe (and google plus) take it to give more columns the wider you are. This is no different than how newspapers are done. Just because you have a giant piece of paper doesn't mean you should let the text flow completely across it.

brendan_gill 12y ago

One thing that the op doesn't address is that the top 10 devices they have selected account for only a fraction of android market. I think there is an implicit assumption that if you cover the top 10 device models you can consider that a proxy for the overall android market but the original fragmentation report shows that to even cover 50% of the market you need to consider around 60-70 device models.

21echoes 12y ago
i think his larger point is that it's not screen size that causes layout fragmentation, it's screen aspect ratio, which is (basically definitionally) more consistent across devices.

thathonkey 12y ago

Don't think there's any fragmentation problems on Android OS? Just try creating a mobile website that supports common "modern" devices. Have fun trying to wrap your brain around all the idiosyncrasies across various versions and browser implementations (Android Stock vs Chrome etc) that will endlessly dirty your code if you want the site to look at all correct in a majority of Android devices. The Android emulator is pretty nice... once you figure out how to set it up for whatever device you're trying to test. It's a ridiculous resource hog though by default (there are ways to mitigate this if you're on an Intel chip). Say what you will about simulation vs. emulation but the iOS Simulator is a dream to work with (again, for web development) and I've never had it mislead me even though it isn't truly emulated. But then you realize there is no way to install the Chrome browser unless you are hooked up to the Android Marketplace (even if you're on the latest version of OS). The best you can get is Chromium, which is a pain to install and doesn't work on some AVDs. All that ranting aside, I've never had a problem with screen sizes, even when working on responsive stuff. But, yeah, Android is basically the Internet Explorer of the mobile space. You'll keep hearing "oh the next version will fix that!" and it may... but you'll be stuck supporting the versions that are broken for years to come.

kllrnohj 12y ago
That's fragmentation in web browsers, that has fuck-all to do with the OS or Android's SDK or anything the author is talking about.
- thathonkey 12y ago
  Oh thanks for breaking it down for me. When it comes to web development, for all intents and purposes, they can be thought of as one in the same since the browser version issued with a device is tied to OS version[1]. Of course some users will upgrade OS and/or browser, independently in some cases, which complicates things further. [1] http://jimbergman.net/webkit-version-in-android-version/ http://jimbergman.net/webkit-version-in-android-version/
  - stusmall 12y ago

GBKS 12y ago

I think Android is shooting itself in the foot here by making things look more complicated than they might be. Take a look at the documentation for screen support (http://developer.android.com/guide/practices/screens_support.html http://developer.android.com/guide/practices/screens_support...). They split phone sizes (2-10") into four generalized sizes (small, normal, large, xlarge). Then they split screen density into generalized densities (ldpi, mdpi, hdpi, xhdpi) based on 3:4:6:8 ratios. The example on the page lists 5 different layout XML files (the 4 previously mentioned + extra large landscape orientation) for different sizes, and three folders for image assets in different densities. But, there are tablet layouts for Android 3.2+, which use a completely different system based on size qualifiers where you can provide minimum/maximum pixel sizes for layouts. The logic for iOS seems super simple in comparison. With a few Android projects under your belt, you have probably internalized how everything works, and which parts are fringe cases you can ignore. But if you're new to this (or a journalist/analyst with limited technical depth), it seems like an absolute mess. Simply rewriting this documentation and providing better tutorials and resources could go very far to clarify the situation.

ZoFreX 12y ago
Generalised sizes are a deprecated way of handling screen sizes on Android, from version 3.2 onward we use far more traditional dividers such as minimum width. For many developers it's viable to support only 4+, which lets you avoid a lot of the trickiness. Also, even if you are supporting 2.x, you don't HAVE to have a separate layout file for each generalized size. If you make a flexible layout that works on all sizes, you can just declare it once (and doing so is not difficult in most cases). I totally agree the documentation needs work. Some areas have not been updated in a very long time.

joeblau 12y ago

As a developer, layout and screen size is not the main problem with Android. To be honest, Android isn't even the problem. It's hardware that Android is built on that is the problem. If a handset is broken down into all of it's sensors [Speaker, Camera, Light Sensor, Microphone, Compass, Accelerometer, Clock, NFC, GPS, Screen, BLE, Wifi, Altimeter, Speedometer, CPU] that's where the fragmentation problem is. It's hard to say which devices contain certain sensors (CPU, Screen, Camera, Mic, and Speakers are pretty standard). Of the devices that have most of those sensors, it's hard to say say which devices have those sensors working correctly. I attended a Facebook/Parse hackathon where FB detailed issues about a certain bug in specific CPU's with respect to a C++ based photo processing library. Certain Android phones would randomly crash. There is also the infamous compass video [1] where multiple devices all with different hardware report different readings. As a developer, the Android Emulator makes me think I'm going to have a consistent user experience, but based on hardware, I may not. In my personal experience, I built this game (http://joeblau.com/orb./ http://joeblau.com/orb./) which runs on iOS and Android and I noticed a crazy bug where it would only crash on S4's from Sprint, not from Verizon or AT&T. I re-worked some code to get the application working eventually, but the fact that something would only break on a specific carrier's version of the hardware was crazy to me. The problem is not Android; Android as an OS is actually very good. The problem is HTC, Samsung, Motorola and all of the other hardware manufacturers that build the handsets. Thankfully Google is doing what it can to address the hardware issue by announcing their Android One program, but that hurts other hardware competitors. [1] - https://vine.co/v/MgWLMmmwUQQ https://vine.co/v/MgWLMmmwUQQ

npsimons 12y ago
This was addressed at the Linux Plumbers Conference and the Linux kernel mailing list a few years ago. The problem is not just hardware manufacturers trying to differentiate themselves, but carriers fucking around with software loads trying to differentiate themselves. On the hardware side at least, this resulted in virtually a brand new port to every new SBC that came out, even though they were almost all ARM. It used to be you could run Linux on MIPS, SPARC, Alpha, PowerPC, Intel, etc, and not be able to tell the difference from an end user perspective. Then everyone got dollar signs in their eyes, and Google managed to fudge the whole "open" thing so that people were okay with binary drivers (I also blame Ubuntu for acceptance of this), and now you see the mess it's resulted in. Don't get me wrong, I'll take the Android bazaar with its wide variety of choice every day (and twice on Sunday) over the one-size-fits-all-we'll-tell-you-what-you-need style of iOS, but the insanity with differentiating things via closed methods needs to stop. And the Android/Linux developers are aware of the problem and dealing with it the best they can; the problem is all the handset manufacturers and carriers fucking things up.

gabemart 12y ago

I'm developing my first Android application and am beginning to work on the interface in earnest. Can anyone recommend some good tutorials or guides for producing elegant layouts that respond well to different screen sizes? I understand the basic mechanics and laid out in the dev guides, but I'm a bit lots when it comes to putting it all together elegantly.

adl 12y ago

my main issue with Android fragmentation is trying to support HTML5 Apps with PhoneGap/Cordova and various JS toolkits (Sencha Touch, JQueryMobile, Dojo). Each version(4.0, 4.1, 4.2, 4.3) has a slightly different version of the default browser and WebViewUI component(and don't get me started on Samsung devices which have their own issues regarding the default browser) with it's own quirks and rendering issues. They kinda fixed that in KitKat 4.4, using Chromium 30 as the basis of the WebViewUI component, but KitKat deployments in the wild are in the single digits.

cyorir 12y ago

Screen fragmentation was a large problem even before Android. When I was first learning to program, one of the platforms I initially targeted was Windows Mobile, version 6.0. On this platform fragmentation was limited because there were only so many devices developed for Windows Mobile (although screen resolutions were generally different for QVGA vs non-QVGA screens, and smartphones with keyboards had smaller resolutions). Nevertheless, fragmentation was still a problem. Without an api adequate for handling different screen sizes and resolutions, it was hard to develop an application for one device then port it to other devices. I use the term "port" because usually this was actual porting; in some cases it would have been better to have a separate binary for each target device than to have a single binary for all devices. I think the reason Windows Mobile developers were so rare compared to developers for emerging platforms like iOS and Android despite Windows Mobile having been around longer is that the alternatives learned from WM's poor example to create better apis. When I switched from Windows Mobile to playing around with Android 2.1, there was so much more I could do with layouts and the simulator in the IDE to target more devices. Newer versions of iOS, Android 4, Windows Phone, and others have all been improved in this regards even more, to the point that I now think of screen fragmentation as something of a non-issue when I tinker with mobile apps.

jbk 12y ago

What I don't get and frustrates me, as a developer, is the impossibility to use SVG in Android. We need to handle a lot of PNGs, in result. Android is re-compiling/re-optimizing for ART, so why not re-export the SVG in PNG format, at the right screen size, at first run?