
The Android Screen Fragmentation Myth - chanux
http://rustyshelf.org/2014/07/08/the-android-screen-fragmentation-myth
======
joeblau
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
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.

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

~~~
ewzimm
Free drivers are the way to go, but pushing proprietary drivers was never
really Ubuntu's fault. It has been a lack of development of free software
drivers because of non-cooperation by hardware vendors. But the community has
stepped up with better support for historically unsupported things like
accelerated video. If you install 14.04, it does not recommend proprietary
drivers except in cases where there is still a lack of options.

I'm not saying Canonical is entirely innocent, but they do employ a lot of
fervent free software advocates and developers. What we need to fix the
situation is more pressure on hardware vendors to release specifications and
free software. Perhaps if Ubuntu Touch takes off, Canonical will be in a
better position to provide that pressure.

~~~
npsimons
_What we need to fix the situation is more pressure on hardware vendors to
release specifications and free software._

Very much this. Even with the vast power that kernel developers wield, even
with offers to write (for free!) and integrate drivers into mainline[1], the
biggest pull is still consumers. Push your hardware vendors to (at a minimum)
release specs; it's the right thing to do.

[1] - For seven freaking years this offer has stood:
[http://article.gmane.org/gmane.linux.kernel/487536](http://article.gmane.org/gmane.linux.kernel/487536)
And yet we still have retarded fucking hardware companies who won't release
specs. Fuck 'em - don't buy from them.

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

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

~~~
jaxytee
I think iOS' HTML5 issues (webview throttling) are self induced though. Apple
has a vested interest in developers learning, and being locked into their
proprietary ecosystem.

A bunch of devs building slick HTML5 apps would go against this.

~~~
chrisdevereux
It was pretty stupid of them to use the new llvm-based javascript JIT for
webviews in iOS 8, then...

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

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

------
GBKS
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...](http://developer.android.com/guide/practices/screens_support.html)).

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

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

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

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

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

~~~
stan_rogers
Poor training? Or could it, perhaps, be a conscious desire to be at least
semi-modal? Unless I have physically separate screens, I much prefer to have a
single, maximized application going on onscreen almost all of the time. That
doesn't mean I want only one application running, but that I generally only
want one occupying my attention at any given moment. (The very existence of
"distraction-free writing" applications makes me believe I'm not alone here.)

~~~
dllthomas
Do you use a tiling WM?

~~~
stan_rogers
Name it, I've used it. I _prefer_ full-screen, one-task-at-a-time if I can
have it, no matter what _you_ may like. Neither side is wrong (or doing it
wrong). I just don't want the stuff I'm not using right now to be there.
Period.

~~~
dllthomas
Well, you're wrong in that you seem to think I was trying to convince you of
something. I was just curious as to your setup, since my habits run similar.

Personally, I use ratpoison, typically with one window full-screen.

~~~
stan_rogers
Many, many years (just about 30 of them, in fact) of people telling me I
really, really want tiled or overlapping windows despite my protestations have
conditioned me to expect it.

~~~
dllthomas
Understood - but you've still not addressed my question :-P

What's your setup like?

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

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

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

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

------
Argorak
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._

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

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

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

------
coldtea
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
> 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
> _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.

~~~
GrinningFool

        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]

------
sujal99
Reporting wrong dpi is the real issue.

~~~
stusmall
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
Don't have the answer. I tried with i-Ball tablet (India made), noticed that.

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

~~~
babuskov
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-...](http://blog.gemserk.com/wp-
content/uploads/2013/01/mainmenu-areas-example2-300x210.png)

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.

------
thathonkey
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
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
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
In that link he mentions it but it bears a little breaking down. His chart is
showing the versions of the rendering engine that is used to back a WebView.
It isn't for the browser included with the phone. Google has requirements how
WebViews are implemented but the requirements for the default browser are
pretty light. Even if the user doesn't swap out their browser you don't know
what you might get. See section 3.4 of the CDD for the requirements.

~~~
thathonkey
"Even if the user doesn't swap out their browser you don't know what you might
get."

My point exactly.

