The Android Screen Fragmentation Myth

http://rustyshelf.org/2014/07/08/the-android-screen-fragmentation-myth

by chanux • 12 years ago

146 72 12 years ago

barbs• 12 years ago

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

coldtea2• 12 years 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).

veeti2• 12 years 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.

coldtea2• 12 years 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.

justinpaulson• 12 years 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• 12 years 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• 12 years 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-...

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.

chrisrhoden2• 12 years 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.

sujal992• 12 years ago

Reporting wrong dpi is the real issue.

stusmall2• 12 years 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?

sujal992• 12 years ago

Don't have the answer. I tried with i-Ball tablet (India made), noticed that.

ulfw• 12 years 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

weavie• 12 years 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.

mattdonders• 12 years 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.

pilsetnieks• 12 years 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.

Argorak• 12 years 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• 12 years 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.

Zigurd2• 12 years 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.

jaxytee2• 12 years 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.

adl2• 12 years 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.

esolyt• 12 years 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.

smackfu• 12 years 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• 12 years 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...

chrisrhoden2• 12 years 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).

fpgeek2• 12 years 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• 12 years ago

Designers don't like AutoLayout - developers (often) need to be involved in the design process again. This is a significant loss for my team.

antimagic• 12 years ago

No, on those early devices, which were at least an order of magnitude slower than current devices, pixel-perfect layout was the only way to achieve fluid animations. It's not an accident that iOS devices were so much better at animations compared to Android devices in the early days, despite not necessarily having the best hardware.

But this is no longer true, or at least true to a much lesser extent. With current hardware you can achieve 60fps reliably even with a layout engine running constraint evaluations for every frame. It makes sense to make it easier to target variable screen geometries now, which was not the case 7 years ago.

kllrnohj2• 12 years ago

It's not an accident that iOS devices were so much better at animations compared to Android devices in the early days, despite not necessarily having the best hardware.

Pixel perfect layouts had NOTHING to do with that performance gap, and iOS devices have far and away the best GPUs of each generation. iOS devices consistenly push fewer pixels (lower resolution screens) with faster GPUs than Android does.

The only reason people think Android devices are such power houses is because everyone still just looks at the CPU core count and clock speed. Which has almost no impact on scrolling and animation performance.

EDIT: For example compare the Galaxy Nexus to the iPhone 4S. Both shipped Nov 2011, both use PowerVR GPUs. The GN is rendering 920k pixels, the 4S is only 615k pixels! The GN is making due with the SGX540 at 307MHz, whereas the 4S has the SGX543MP2 at 266mhz or so - literally double the GPU power of the GN, and for a lower resolution screen.

The_Double• 12 years ago

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

fpgeek2• 12 years ago

Well there was that generation of web designers that believed the world was 1024x768 (or 800x600).

taeric4• 12 years 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.

brendan_gill• 12 years 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• 12 years 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.

thathonkey3• 12 years 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.

kllrnohj2• 12 years 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.

thathonkey3• 12 years 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/

GBKS• 12 years 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...).

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• 12 years 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• 12 years 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./) 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

npsimons2• 12 years 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.

Aldo_MX• 12 years ago

the problem is all the handset manufacturers and carriers fucking things up

A thousand times this! It seems that carriers exist for the solely purpose of fucking things up.

gue5t• 12 years ago

Thank you for calling out Ubuntu (a wolf in sheep's clothing in many ways, despite the significant role Ubuntu has played in bringing great people to the Linux community and the fact that they do a lot of good too) and fronting open-source drivers. HN seems mostly ignorant of how critical free drivers are while it continues to flock around diatribes against far-downstream effects of relying on closed blobs. User freedom stems fundamentally from the ability to make use of the components in devices they own. For the uninitiated: that's exactly what drivers do.

saurik• 12 years ago

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.

I was looking into this a few days ago (for a much more off-the-wall reason I won't go into) and it turns out that Samsung actually will ship devices under the same brand (such as "Galaxy S5") that use entirely unrelated SoCs depending on the radios the device is intending to support: some devices use Qualcomm's Snapdragon, and some use Samsung's own Exynos, so there are tons of possibilities open for these kinds of "Sprint-specific" issues :(.

http://www.cnet.com/news/the-chips-of-samsungs-galaxy-s5-exy...

jinushaun• 12 years ago

The problem with Android is that the API offers no guarantee that your call will work correctly on all devices. This is especially true for anything related to sensors like the camera. It is up to the manufacturers and carriers to honor that contract and they simply don't do a good job of it.

gabemart• 12 years 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.

adl2• 12 years 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• 12 years 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• 12 years 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?

The Android Screen Fragmentation Myth

Related Stories