By 
Yesterday marked an impressive milestone for Android – Google Play Services version 3. For such an important milestone, though, you’ll find no Android statue on the lawn in front of building 42, no dessert themed easter egg in the settings menu, and little more than a general “meh” heard from Android users. So what, exactly, is the big deal?
In September of 2012, the first release of Google Play Services brought oauth 2.0 support to all Android applications, on all devices utilizing Google Play. This allowed application developers to implement a token-based authentication scheme against all of the web services that supported oauth 2, including Twitter, Facebook, Google, Dropbox, and, well, you get the picture. Later on in December, Google Play Services released version 2.0, updating the Google Maps APIs for use inside applications.
Like the first release, this hit all Google Play supported devices. Yesterday, version 3 brought Google Plus features, and revamped the entire Google Account usage concept for authentication inside your apps, and no device was left behind as all Google Play supported devices are seeing this update. I should also make note that the very popular Honeycomb Fragments UI API was even backported to prior versions of Android.
So what, then, is a Google Play supported device? Quite simply, it’s an Android device that has the Google Play store installed on it, running Android 2.2 (Froyo) or higher. Taking a look at the most recent Android OS Distribution Statistics, that means that Google Play Services is enabled for 97.6% of all Android devices captured in that report. While this obviously excludes non-Google Play devices (the Kindle comes to mind), it’s still a very impressive and important milestone.
Why, then, does fragmentation no longer matter? Simple: Android is now designed for it. Google provides tools for developers to write applications, and the capabilities they provide are now mostly version-agnostic. Sure, Ice Cream Sandwich has the new Holo UI, and tablets have a higher display resolution than phones (but for how much longer?), but Android has built frameworks for this. You can specify multiple layouts for your application, if you choose – a tablet layout for larger screens, and a phone layout for smaller screens. A Holo UI for Android 4.0+, and a regular UI for non-Holo devices.
The restriction of apps to specific versions of Android is only necessary in only two viable cases. In the first case, developers might be targeting a specific feature such as Google Now, or the new Lockscreen Widget found in Jelly Bean 4.2. Like applications targeting Siri on the iPhone 4s and 5s, the OS obviously has to support these features for developers to develop against them. In the second case, the developer doesn’t wish to provide an alternative layout for their application.
As a developer myself, I’ll admit that sometimes it’s easier to cut my losses (and my customer base potential) by giving the axe to older devices. They’ll be running Android 4.0+ eventually, so it’s a time-saver to not implement two different UIs in my application. I might not have the debugging capability (the emulator only goes so far) to support legacy UIs as well as Holo UIs, or I might want to break up my app into a tablet and phone variety for other reasons. But those are all developer choices, not technical requirements.
Apple on the other hand, seems to have bigger problems. Between the retina display devices and the non-retina display devices, to get an application truly compatible across all of Apple’s devices, you need to include 4 different UIs, which includes different resolution textures, graphics, and layouts. While the retina display iPhones have the same resolution as the non-retina display iPads, they can’t utilize the same layouts. While this concept makes no sense to me, it’s obvious that Apple thinks different.
For non-static content, such as OpenGL rendered objects, a developer needs to render at retina display density to support those devices (even if it isn’t necessary, in which case the resulting render gets scaled back, causing it to lose detail), or render at lower density, and have your renders look blocky on the retina display devices. Or double your code, one renderer for each device, and double your fun!
Both implementations of mobile operating systems have their drawbacks with support for multiple devices, but both custodians of those operating systems have provided plenty of tools to tackle the problems at hand, and they’re beyond sufficient for most apps. While Google and Apple will both continue to release more devices and newer versions of their operating systems on them, we’re finally beyond the days where apps have to be dependent on those versions.
It’s always harder to support two layouts inside an app than one, but it’s a necessary evil if you want your application to run on the latest and greatest innovations out of Silicon Valley, and it’s a trend that is only going to continue. So maybe that F-word isn’t so scary now after all. Does it still have you trembling in your boots?
LOL Apple was the first to accuse Android of fragmentation, and now look at how fragmented they are. Certain apps work only on certain iPads, Not all OS versions work on all iPhones :D
The irony! It burrrrnnnnsss!
Don’t forget about the iPhone 5 and the apps with black bars at the top and bottom!
The contrast of the black bars, helps you see the app content more vividly :D
But every single one of the apps that don’t officially support the iPhone 5 because they still have the lower resolution, still WORK on the iPhone 5…go figure.
Completely incorrect. Show me ONE instance of an app that works on a later ipad but not an earlier one.
Great article.
I second that. This really gave me some good insight into app development on both ends. Now I can argue a little more intelligently with itards on other sites
Very good read…
It’s about time. Compatibility is whats needed in android, and if peeps find out their left out , may not return. People have these smartphones, and I’d say that most, have no clue about how to really use it(my sister just found out she could get the pics off her phone from two years ago, after I showed her how, and she develops software). Some phones, even made today, may never see upgrades to ice cream sandwich, or jellybean. Good move.
Stellar first article, hope to see more like this in the futre
Wow.. Actually learned a bit here. Great article! And it makes me smile much that apple is fragmented this way, I actually had no idea
As stated by others great article one the best ive read on this site
One area where Apple has a distinct advantage over Android is that it gets its devices updated to the latest OS promptly. About 87% of currently active iOS devices are running iOS 6.x just a few months after its release. Android still hasn’t hit 50% of users running 4.x after nearly a year and a half. You say that “They’ll be running Android 4.0+ eventually” but thanks to the lack of interest from manufacturers and carriers, any Android device that isn’t running 4.x today is unlikely to ever get it (unofficial ROMs aside). The only way those users will get 4.x is when they upgrade to a new device.
Also, it’s not really accurate to say that you need to develop 4 UIs for an iOS app. The Retina and non-Retina versions use exactly the same layouts and code. The only difference is that you need to provide two sizes of any image resources. You need an iPad layout and an iPhone layout and that’s it (although since the iPhone 5 your iPhone layout needs to take into account the possibility that the screen is slightly taller).
That said, it’s certainly true that Android is better prepared for future devices with new screen sizes than iOS is. I think that’s why Apple stuck with the same screen ratios for each version of the iPhone and iPad until the iPhone 5 and why they made sure that Retina screens were exactly 2x the size in each dimension. It made developers lives a lot easier but you could argue that it was the tail wagging the dog with software constraints dictating hardware choices.
One final point, the Retina iPhone screen is not the same resolution as the non-Retina iPad. The iPhone is 640×960 and the iPad is 768×1024.
My Nexus 4 will get updates for years to come.
The carrier restrictions are the problem, as far as updates go.
My VZW Galaxy Nexus doesn’t get updates, but at least i can route around that :)
Yeah, my Galaxy Nexus is getting the updates too.
The problem is, while 4.1 was perfect, 4.2 is clearly optimized for Nexus 4 – on Galaxy Nexus, the performance went dooooown. It is no longer a pleasure to use, it doesn’t feel like premium Nexus experience. I guess that’s what will happen to Nexus 4 when the new one will come out.
So, it seems that the Nexus line is not the ultimate solution either.
“One area where Apple has a distinct advantage over Android is that it gets its devices updated to the latest OS promptly.” – But when the most important features of the OS updates are purposefully disabled on older phones, does it really matter what the version number says?
Also don’t forget that older devices completely are unsupported after 2 years. The 3G and 3GS can’t be updated past iOS 5 if I’m not mistaken. And I think iOS 6 is the last for the iPhone 4?
Exactly. Not even important features too. The devil is in the details. Even with WP. Look how WP 7 went to WP 7.8.. Its not exactly WP 8…..but its close enough.
I applaud companies for that….but fragmentation exists on iOS and WP. Google just chooses not to do the half update. Its all or nothing. Both ways of updating have pros n cons. And sometimes its hardware based. At one time the LG Ally officially couldnt run 2.2 because of hardware issues with Flash. I dont think it ever got updated past 2.1 I think thats the only time a feature of the OS was left out in Android for an update. And that might have been LG’s doing.
One of those prompt OS updates made the older device almost useless. I think it may have been iOS 4 on an iPhone 3. My friend had iPhone, and liked it at the time, until this happened. Fortunately, by complaining enough to AT&T (but hey what other type of communication do AT&T customers do with AT&T) he was able to get back to a plain iPhone 3. Eventually he upgraded to a Samsung Galaxy Note.
Nicely done Google this is the last time I have to hear complaints from Apple users :D
Apple still comes out ahead because more people prefer to develop for iOS products. Better ROI and exposure.
What does that have to do with it? People prefer to develop for it, therefore, it’s better? Appeal to the people.
I love developing for Android. One you’ve figured out all the UI scaling, it’s simple!
>So maybe that F-word isn’t so scary now after all. Does it still have you trembling in your boots?
From a user perspective it’s great that Google Play is getting updated to all devices.
Having used Android since v1.0 and every API level here is my developers perspective… Trembling, no… Aware that it will never go away… yes… And here is why and what real fragmentation is from a developers perspective:
(granted it gets more technical now)
At the core real or hard fragmentation are the bugs / flaws that are inherent at each API / OS level of Android that require explicit workarounds. There are arguably worse flaws in the past and things are getting better in general, but not everything is caught all the time before a new OS / API level ships.
In a nutshell:
People are fallible -> people write software > deadlines loom -> the SDK is hard locked to firmware / OS versions -> there is always potential for hard fragmentation.
Examples of major flaws that affected my world:
1. Deficiencies & incomplete testing of the OpenGL ES 2.x Java API in 2.2 due to code generation and improper follow up testing.
2. Major regression in 3.0 / 3.1 for the Java NIO API for some methods which cause an _endian swap_ condition. The duplicate() method was changed / flawed; asCharBuffer() is always going to be flawed because internally it calls duplicate(). It took me 50 hours to find the root cause to why my OpenGL apps failed due to the use of NIO / duplicate() when I got the G-Slate / 3.0. I’ve never seen the Android team fix a bug quicker once the source was identified (~2 hours), unfortunately those changes didn’t make 3.1
Workarounds.. For the first one if one wants to support 2.2+ from one unified OpenGL ES 2.x API one has to use a 3rd party wrapper and never use the official API. For the second if you have access to source code using NIO and need a duplicate view of a buffer then there is a way to do it without the forced endian swap. If you don’t have access to the source code say using a 3rd party library for networking or whatever you are out of luck. This NIO flaw is only in 3.0 / 3.1 and doesn’t affect the API from version 1.0 of Android or any others. Unfortunately “asCharBuffer()” will always be flawed and there is no workaround on Android 3.0 / 3.1.
Luckily, I can’t point to major / hard fragmentation bugs 4.0+. In fact 4.x was the first major version of Android that didn’t have “show stoppers”. Some minor quibbles / bugs here and there.
—————–
From a more fundamental direction there are always aspects of soft fragmentation with the Android SDK since it is constructed in a very traditional OOP (Object Oriented Programming) manner where the API expands additively over each API level / OS version. This regards small / slow tweaks + extra functionality that isn’t going to be back ported. There will _always_ be this kind of soft fragmentation with Android requiring developers to conditionally target API versions with different paths if new functionality is desired to be used. Case in point.. Just check out the View documentation and play with the API level selector which shows which new methods are added at each API level:
http://developer.android.com/reference/android/view/View.html
New functionality at API levels: 1, 2, 3, 4, 5, 7, 8, 9, 11, 12, 14, 15, 16, 17
17 is the latest / Android 4.2.x and there was significant handy new functionality added since API 16 / 4.1.x at least for optimizing animation in certain situations. I like to highlight the View class because it is central to writing standard Android apps. In this case for the most part new methods / functionality is additively added with each API level. Luckily there are only minor deprecations at API level 14 & 16.
For soft fragmentation developers usually just pick a minimum API level and stick to it. New apps may choose a new minimum API to use the latest features. At least this is the common case for app development. The worst situation is embedding conditional logic in an apps code to branch and do different things at API levels as maintainability suffers greatly.
————————
>”Why, then, does fragmentation no longer matter? Simple: Android is now designed for it.”
This is simply not true. Nothing has changed in the core ways Android is being developed and hard and soft fragmentation for developers is not going away anytime soon. Hard fragmentation can be reduced, but that really comes down to managing better testing / quality assurance with new OS releases; the track record has been spotty in the past, but seemingly is on a better course presently. Soft fragmentation is just inherent to the engineering methodology / approach taken to extending Android. OOP / additive SDK development is what it is; not everything gets back ported.
The author mentions about the Holo UI, “A Holo UI for Android 4.0+, and a regular UI for non-Holo devices.”
I do want to provide some info on a neat effort out there that back ports the Holo UI to Android 2.1+.
https://github.com/ChristopheVersieux/HoloEverywhere
Combine the above effort with either the stock ActionBar back port or ActionBarSherlock and one can create apps that look / run uniform across Android 2.1+ for the most part.
—-
Ultimately, for fragmentation to be significantly minimized for developers the SDK needs to be separated from the firmware & OS / hard release cycles such that the SDK can be updated without bumping the firmware in a similar manner that the Google Play store can be updated to all applicable devices. I’ve been chanting this war cry from the get go…
There are more modern engineering approaches that allow this.. I’ve been working on cracking that nut for a while.
As a dev working in a low level hardware dependent area, I agree.
Fragmentation is a real problem for small devs, even when not working low level.
Over 60% of my app sales are to a handful of the most popular Galaxy S class devices. These, and a few HTCs are my main target going forward.
I’m not supporting the thousands of different phone variants out there, especially the Huawei and ZTE devices that are 99% likely to be using my app pirated.
I’m sorry to see you get voted down because what you say is true whether we like it or not.
Of course, this cost and effort is the flip side of a huge benefit of Android — that Android devices come in every imaginable size, shape, style and feature combination, unlike Apple’s “one true way” which is now ironically, fragmented.
this is about 40000 words too long for me to bother reading…
Hmm… I thought this was about the word derogatory F-word and how Android can censor it out and Apple couldn’t or something. I was completely taken off guard.
iPhone 4 / 4s Resolution is 640×960 and iPhone 5 resolution is 640×1136….iPad 1 and 2 resolution is 1024×768….how are those numbers the same to you?
On top of that, you mention applications that “target siri”…what applications are you referring to here? Yelp, Yahoo Sports, and Wolfram Alpha have functionality baked into Siri, but no application that I know of cannot function across devices due to this. Those with an iPhone 4s or above, or iPad 3 and above can use Siri, those without those devices cannot…but the respective applications work just fine and every one of those devices.
The fact of the matter is, fragmentation is a very large issue within the android ecosystem. A small developer has to make the choice of devices they wish to support, and either spend their time/money trying to increase their customer base or save their time/money by decreasing their customer base…from where I’m standing that sounds like a lose/lose situation.