If you’re running the latest Android OS on a newer phone (Nexus 5, 5X, 6, 6P) you’ll notice how smooth and buttery Android now feels. The standard Android OS has lots of bells and whistles that make iOS look like a phone made in the 90’s. The problem is, everyone else on Android is stuck in the 90’s too, and we can’t get them out.
Recently I was helping a friend find an Android developer to port an existing iOS app to the Android platform. It was a memory intensive multi-media based application, and they were having a hell of a hard time finding qualified and willing Android developers.
The reason is actually quite simple - there are a couple of areas of development that Android developers will shy away from because of the complexity and frustration involved. In this particular instance it had to do with complex memory management - in Android that’s a challenging beast. The real root of the problem boils down to the vast landscape of Android devices, hardware implementations and problems that surface from the Cartesian Product of configurations that arise - also known as - Fragmentation.
iOS Devs Have it Easy
Managing memory is nothing new, but when there is a substantial set of devices that are consistently being released it’s hard to even wrap your head round the possible memory problems you can have (among other things). Hell, Facebook created Fresco out of frustration from dealing with Android memory problems in regards to images. This isn’t just about memory though, it’s merely tip of the iceberg.
In Android we don’t have a small subset of devices like iOS devs. This is where iOS devs have it easy. iOS developers have a known set of hardware specs that they can depend on while also running a known small set of operating systems. All devices are built with the same hardware components (for the most part) so you know what you’re getting into. This makes developing for iOS much easier than for Android.
Android devs have thousands upon thousands of different devices along with an insane number of various hardware components to deal with. For a device to be considered Android compatible it must meet or exceed the Android Compatibility Definition (Android CD) as outlined by the Android Compatibility Definition Document. The Android CD is meant to foster an ecosystem that builds growth and user adoption but does not deter manufacturers and carriers from fragmentation.
Get more development news like this
Usually at this point someone says something to the nature of:
“... But Donn, that’s why Android is so successful …”
I know, I get it and they’re right. That is why Android is successful - it has been able to grow unbounded. I believe it so much that when I started the Android Developer Podcast with Kaushik we decided to name it the “Fragmented Podcast”.
I love Android but I do feel that Android is the Windows of the mobile revolution. We have a ton of devices, a ton of hardware vendors and this creates a world of hurt in a lot of areas of Android development.
The Carrier Oligarchy
Ok, developing in a fragmented environment is hard, we get it. But why does fragmentation exist in the first place? There are various ideologies and concrete examples, but I’ve had my own theory for a long time and it boils down to this -
Carriers make money selling phones and upgrading usage plans, not upgrading operating systems.
With Apple, carriers are not allowed to modify the OS other than a couple of configuration settings for the mobile network/etc. Everything else is off limits. This is where the true power of iOS lives - Apple controls the release cycle of iOS. I’m fairly certain that Carriers make far less money from iOS users than from Android users in the long run because of the long term support for iOS devices (see iOS Support Matrix for more info). For example - Last year my wife upgraded to an iPhone 6 and her old iPhone4S was still getting updates. We bought that phone in 2011. That was over 4 years ago! Tell me an Android carrier device that still gets updates after a year or two - they’re hard to find if not near impossible.
Carriers do not make money upgrading their existing Android users to the latest and greatest - it actually costs them more money. What most people don’t think about is why this is the case, but again it’s very simple - upgrading software costs money, and lots of it. Carriers have such vast user bases that their code has to be flawless and bulletproof. Well, updating a customized operating system is no quick task that you bang out in a few days.
Why Updates are Slow or Non-Existent
The traditional carrier/manufacturer phone will ship with a custom operating system that they created. This operating system will have a custom theme and various custom applications such as: custom phone dialer, custom SMS messenger, custom voicemail app, custom calendar and custom calculator - just to name a few. When a new major Android release drops usually there are a fair number of UI changes (such as going from Holo to ICS and then to Marshmallow/Material Design). Carriers are responsible for passing an OEM test after an upgrade and at that point the update can be pushed out via OTA.
Therein lies the rub - they have to update their software. A little background info - Most carriers have some sort of consumer agreed upon release cycle. For example, I’ve seen such claims as “Your phone is guaranteed to get updates for 2 years”. The problem is that the fine print states that if the release is ready in that two year time they will release it. What if your two year update period is over on December 31st and a new version of Android is released in August? In that case you’re never going to get that update because they won’t be able to update the software in time, so they just leave it. Aha! Gotcha.
Carriers are in this for the long haul. They can lock you out of the updates and eventually force you to buy a new phone if your device is no longer supported. They expect you to buy another phone every year or two at most. Each time you do this your contract length is extended and it ties you to the carrier for longer. When you think about it from a business perspective, it’s not a bad gig - they make more money this way … but for consumers this sucks, bad.
There is hope for Android though and one avenue is the Nexus program. Nexus devices are stock Android devices with no carrier or manufacturer customization and no carrier lock in. For example I have a Nexus 5 (still waiting for my 5X) and I can run on T-Mobile, AT&T and many more. I recently moved across the country to New Jersey and my T-Mobile service was non-existent. I went to AT&T, signed up for a monthly plan and got a SIM card, walked out 20 minutes later with the same phone, on a different network. Lovely. Seems like the way it should be, right?
Here’s the awesome part about the Nexus program - Nexus devices are notorious for getting OTA core Android OS updates far before the carrier phones. I’ve been running Android Marshmallow for a few weeks already. I tweeted about this on Oct 14th, a mere 9 days after Marshmallow was officially released.
Just got the marshmallow update on my nexus 5. Love the nexus program. All Android devices should be rqrd to run stock Android. #androiddev— Donn Felker (@donnfelker) October 15, 2015
I received the OTA update 9 days after the release! This is very reminiscent of how Apple pushes iOS updates: Fast, VERY fast. As a consumer I LOVE this type of update frequency, and I’m not alone, everyone wants this experience.
Nexus Devices are the real Android Devices.
When folks ask me “Donn, what Android phone should I get next?” My answer is always “Get a Nexus phone. I don’t buy any other phone - they’re all junk.” I truly believe that. I buy 3-5 carrier phones a year for development testing. I try to use each one and every single time I feel like throwing the damn thing out the window while I’m driving down the freeway - that’s how frustrating the carrier/manufacturer-modified devices are to me.
The Nexus program also has some new life breathed into it via the - the Google Fi and Android One projects. With Google Fi, Google is attempting to change the way you consume mobile services. But here’s the great thing - as of writing it’s restricted to newer Nexus phones. This could also be seen as a negative if you don’t have access to Nexus phones, but that’s what I would advocate - a less device-fragmented approach for Android. Android One is a bit different but they share one important take away - they both run on the latest versions of Android.
Why can’t I buy a Nexus phone down the street at my carrier’s local store?
I have my own theory on this and it’s the same one as before - Carriers make money off of selling devices and upgrades. They don’t make money from a phone that gets constant upgrades and has a long lifespan compared to existing carrier models. So then why do carriers stock iPhones if iOS basically gets the same treatment we’re after? Well, the market demanded it. People wanted iPhones and carriers realized AT&T was killing it in the sales department and wanted a piece of it. Basic business.
Unfortunately the vast Android consumer market is not that keen on how the Nexus product line works just yet and most probably don’t care. Sure, us power users care and are aware, but my father has no idea what the hell a Nexus device is and why it’s better. He just knows his friend’s iPhone gets updated all the time and his Android device is old and laggy.
So … Android Sucks, Right?
Unfortunately, many people feel this way, but it shouldn’t be like that.
This is usually the point in the conversation where someone states “Google did this so we have to buy new phones all the time and they are the ones who created the problem! Google is Evil!!”
In my opinion, it’s not entirely Google’s fault. I feel that when they embarked on this journey they were not entirely aware of how big mobile would get, the potential for vast fragmentation problems, and that carriers would be the source of much of the pain. Hindsight is 20-20 and I’m sure Google would prefer if the carriers updated their consumers’ phones more often, but that’s not the world we live in.
How could the market go about fixing this?
I’m not exactly sure there is a single way to fix this. However, there are a few things that Google can do in order to push the carriers in that direction. In a perfect world we’d all adopt the Nexus style of devices and/or Project Fi, but let’s be real - that’s not going to happen.
Option 1: Get rid of OS Customization This would be a hard sell, because it cuts off an arm of a carrier’s revenue. They depend on the phone update cycles that consumers typically have. This type of requirement will lengthen the release cycle and cut revenues significantly.
Option 2: Implement OS Customization via a Plugin Model If a carrier/manufacturer wants to make customizations they should be required to do it in a plug-in style model. This means the core OS would stay intact but would provide plugin hooks to the OS to provide some customization. That way the core Android OS could be updated with minimal effort and would also give the users some flexibility if for some reason the stuff that shipped with the core OS was not to their liking. This is a hard sell too though, and there are some issues around OS updating and the related apps that are built on top of it. For example if an OTA occurred and the carrier theme crashed, the Android OS could take over and use the default launcher and theme so the end user could still use the device with the new OS. Not perfect, but it’s a step in the right direction.
Option 3: Institute a Strict Update Policy Google could tighten down the requirements of what can be updated and how often. They might also want to include a clause that states the device must be updated within a month or two of the latest ASOP release. This will put pressure on the carriers to decide if a) they want to do that or b) should they just go stock android. If Google did enforce this, my assumption is that a couple of carriers will start offering stock Android devices and folks will start immediately flooding to those because of the longevity and reliability of those devices (assuming the devices are of quality). This will also ensure that the core OS software works on their hardware as expected.
Problems with Hardware Compatibility
Ancillary to the software updates is the hardware - we need more stringent requirements on the hardware. A vast test suite needs to be developed that abuses the hardware to ensure it passes all of the edge cases that developers might encounter with the core, unmodified OS. The same test needs to be run after the Android OS modifications have been made (if that trend continues).
The hardware side is interesting because some manufacturers and carriers have to modify the Android OS simply to get the Android OS to work with the hardware they’re using. That’s kind of a problem - if they have run into problems, us application developers are also going to run into problems. The Android CCD should shield us from that, but so far it has not done a great job of it. Tests will help.
Better yet - the test suite should be open to the community so that the community can help build it. With its sheer number of developers the community can help find areas that need to be tested and they can all provide feedback to ensure the manufacturers devices are top notch, not some knock off hardware. There are tons of software hacks made everyday in order to fix a hardware issue in Android, it’s time to fix that.
Android Has Grown Up
Everyone thinks Android is a crappy OS that is old and buggy, but that’s not the case - Android is a well oiled machine at this point. However, having this many users on older devices and OS’s fragments the ecosystem more and more everyday. This complicates things for everyone - consumers, developers, carriers, and even Google. We need to get manufacturers and carriers to hop aboard the new operating system with reliable hardware. Doing so will help stabilize the platform, increase brand loyalty to Android, make developers lives easier and will make apps much better in turn. When that happens maybe then we can have those really nice multimedia apps I originally spoke of. :)
About the content
This content has been published here with the express permission of the author.