Fragmentation or Diversity? It’s a Matter of Perspective

Points of View

It’s hard being a developer that has to support thousands of different devices, with screen sizes ranging from tiny to enormous, running multiple OS versions on all sorts of hardware… said the web developer.

Even if you only have a passing interest in developing for mobile, you’re bound to have heard about Android Fragmentation. In short, fragmentation is the onus placed on Android developers to ensure their apps work on an ever expanding array of devices encompassing variables such as:

  • screen sizes
  • screen resolution
  • device hardware specifications (i.e. RAM, processor, disk space / SD card support)
  • device capabilities (e.g. not all devices have NFC, tablets don’t tend to have phone functionality)
  • different versions of the operating system

As a developer, these variables add overhead to the whole process. Last year, the BBC revealed that their Android development team was three times the size of their iOS team. Fragmentation has often been cited as “The Achilles Heel of Android”. I’ve heard developers say “We didn’t develop an Android version because… fragmentation”. A valid argument?

Taking off my developer hat, I look at this issue from a consumer perspective. The fact that Android caters for the list of variables above means that manufacturers (original equipment manufacturers, or OEMs for short) can produce a wide range of devices to suit a wide variety of customer tastes and budgets – do I really want a phone with 6 inch screen? Do I want to buy a high-res quad core monster, or a budget friendly device for casual use? New devices (and indeed new manufacturers) are appearing every day, with a lot of emphasis being placed on growth within emerging markets such as China, Brazil and India.

Hardware sales aside, a larger audience equals more people to sell apps and services to. Even Nokia are tackling the emerging markets with an Android phone, with the Nokia X reportedly selling out in four minutes at one Chinese retailer. Although an Android phone, the device taps into Microsoft services rather than the equivalents provided by Google, and it is customised with a Windows Phone style launcher.

But how do we keep everyone happy? I thought I’d write this post as I personally believe the issue of fragmentation is largely overblown. The Android SDK is inherently designed to cater for such variety from the design phase onward; it’s not a hacky, post-production fixing exercise. Hopefully I can clear this up.

Fragmentation – How does it happen?

You’ve probably seen horrific patchwork quilt graphs like this one:

Android-fragmentation-brand-2013

But what does this mean?

To start with, we should consider the Android Open Source Project (or AOSP for short). If you didn’t know already, Google makes the source code for Android freely available, hence it’s rapid adoption by new and established OEMs. The manufacturing cost associated of using Android lies in whether the OEM wants to use Google services (such as the Play Store), which must be licensed. In the case of the Nokia X, no such license was required; similarly, Amazon tablets provide their own marketplace.

If an OEM wishes to run Android on their devices, they will download the source and compile it against each device specification they manufacture. In our graph:

  • Manufacturers are represented in different colours, with area reflecting market share (Samsung being the most dominant player here)
  • Manufacturers are further split into different device specification, with area representing device popularity

So many specifications, so many Android binaries, so many problems!

At least, that’s what you may be led to believe. Google sets compatibility standards for manufacturers to ensure a consistent SDK, so that developers don’t write custom code for every possible hardware configuration, making this graph largely irrelevant in my opinion.

But what about different versions of the OS itself?

Like any other OS, incremental improvements of Android are released over time, bringing features such as better memory management (the main focus behind KitKat), a more fluid UI (JellyBean) and other assorted goodies.

Correspondingly, the updated source is pushed to AOSP for OEMs to compile and make available for their devices. Unfortunately, unless you have a Nexus device, you can expect a delay between when the source is released to AOSP and when it becomes available for your device; it may not even become available at all. For me, this is the true measure of fragmentation, and is displayed in more objective (And less scary) graphs such as this one:

Distribution

Delays are straightforward to explain. OEMs need to compile and thoroughly test the source on their device range and this takes time. Although Android is a third party product, it’s still the OEM brand image that will be hurt if the update isn’t seamless. There may be an incentive to be first to market with the latest and greatest, but a hasty release may not be worth it if a rival OEM releases a perfect update a little while later.

Why then would an OEM choose not to release an update at all? Again, relatively straightforward – doing so could take the shine off new hardware they plan to release. This is especially true for smartphones which are generally replaced every 2 years. The choice is simple for an OEM – spend time and money creating a free update for a 2 year old device, or make it exclusive to newer hardware, providing the consumer with the incentive to spend money. This is further complicated in the US, where telecoms carriers hold sway on what updates OEMs can release for their devices, again for the same reasoning – making money.

How does Google address version fragmentation?

Google have taken a number of steps to address this issue:

  • Most new APIs are not version specific
  • The Support Library
  • All new devices that wish to use Google services must run KitKat

The first point is really rather clever. Think about the release of any new operating system. The parent company release promotional material of the new features. Again, it’s an incentive to upgrade, and so we associate new features with new versions of an OS.

In Android’s case, this model is flawed – for reasons given above, a large chunk of consumers do not have the latest version of the OS, and some run so called “legacy versions” of the OS (i.e. Android 2.3; Gingerbread). Developers would have little or no incentive to work with new features if they aren’t widely available.

Consequently, Google release most new APIs as part of the Google Services package; a service that runs on all Android devices and is updated automatically. Developers who wish to integrate features such as Google Drive, Cast, Cloud Messaging, Game services… etc. can do so knowing that all devices can handle the new APIs, regardless of OS version.

play-services-diagram

The second point mostly caters for devices running anything less than Honeycomb (Android 3.0). Honeycomb was designed for Android tablets only, and had a very different look and feel to the Android that ran on phones at the time (mostly Gingerbread 2.3 and Froyo 2.2). It introduced ActionBars, Fragments and swipeable views among other things.

The main focus of Android 4.0 (Ice Cream Sandwich) was to create a unified experience across tablets and phones, and thus a lot of the design introduced concepts in Honeycomb became the new standard for phones as well. These design libraries are not APIs, so do not ship with the Google Services package; they are tied to the OS version.

However, developers can simply import the Android Support Library jar into their projects and start using the new designs for older versions of the OS. Code written using the support library is not specific to older versions of the OS either – that is, your Gingerbread compatible app with fragments looks and behaves exactly the same on an Android 4.0+ device. Thus the need for version specific code is largely avoided.

Of course, Google do provide monthly statistics on the adoption rates of each OS version (as shown above), and it’s the developers choice to ignore older OS versions if they wish. If a user wishes to download an app that is not supported on their device, they will have to know the URL of the app as it will not appear in any search results. Furthermore, they will be prohibited from installing the app as the Play Store will display a “Not compatible for your device” message instead of an Install button. Even side loading the package won’t work.

The last point is based on “a leaked internal memo“, although it has been reported in a few places. Apparently Google is insisting that all devices released from February 2014 onwards must run KitKat. The main focus of KitKat was to radically improve memory management, allowing low-cost, low-spec devices with as little as 512Mb of RAM to run the latest version of the OS (so called “project svelte“). I’m interested to see how this one pans out.

How do developers cater for different screen sizes and resolutions?

This has been a feature of the SDK for a long time. It’s really nothing new.

Here’s a quick primer on how screen layouts work in Android – basically, each screen will have an XML file that defines the position and styling of screen components (such as buttons, labels, images…etc), much in the same way as HTML is used. Let’s say we have a screen that uses the layout “activity_main.xml”. The directory structure looks like this:

TreeLayout1

If I wanted to alter the layout for a large screen somehow (change the styling / margins, show more controls), I create a new folder “layout-large”, and add a new layout with the same name as before to it. So my directory structure looks like this:

TreeLayout2

At runtime, Android will load in the correct layout depending on device screen size.

Images work in a similar way. Let’s say I have the image “ic_launcher.png” – the directory structure looks like this:

TreeDrawable1

If I wanted to use a high resolution version of the icon on higher resolution screens, I create a folder “drawable-hdpi” and store my higher res graphic there:

TreeDrawable2

At runtime, Android will load in the highest resolution images that the device screen can support.

These folder suffixes are known as “qualifiers”, and the documentation on them can be found here.

Further Restrictions

If you want to take a very narrow view of supporting only specific devices, Google allows you to do this as well – you may specify which devices may download your app when uploading it to the Play Store thus:

DeviceSupport

I know that the SkyGo app is restricted in this fashion, causing some consternation among customers who don’t own one of their allowed devices (for a time the Nexus 5 was not compatible, even though the Nexus 4 was). This may be that they only release their app for devices they have tested it on, but the cynical side of me thinks they are being lazy here.

A Rich, Ever-Expanding Ecosystem

Here’s a list of Android devices I own:

And some I’d like to get my hands on:

A wide range of devices and form factors, all running Android, all ready to consume services. Fragmented? Maybe. Diverse? Definitely.

 

Advertisements

Make your own Android Laptop – Part 2

Intro

This is the second part of a two part blog on running Android on a laptop / desktop computer. This post focuses on my experience of running Android in a desktop environment; please take a look at the previous post of you’d like to try it out for yourself.

Setup / Boot time

Android will boot up in a time comparable to any tablet I’ve used, although this is hardware dependent (a few minutes on my laptop). There’s a standard setup process for the first time you run the OS, just like when you start a new phone or tablet:

android-setup

Home Screen

Your home screen is fairly blank on first install, so I quickly got to work customising it with my own wallpaper, preferred apps on front (Google Play store works) and some  widgets. My homescreen looks like this:

homescreen

So what have I got here?

  • Google Music widget (currently listening to the Rush soundtrack)
  • Google Now widget (how are my teams doing, what news stories interest me)
  • News and Weather widget
  • Google Newsstand widget (randomiser of articles for sites / magazines I subscribe to).
  • Google+ Widget (randomiser of stories from my G+ feed)
  • Links for my regular apps, including some folders on the bottom dock row

If I click on the app drawer icon (bottom row in the middle of screen), I can view all my apps:

appdrawer

One quirky thing – a bigger screen doesn’t necessarily give you more icons on screen. A higher resolution screen will use higher resolution icons. In short, the icons occupy the same physical size, but will be of greater image density. It’s like comparing a high res tablet with a medium res tablet – the icons are the same size, but they look nicer.

Storage

I installed Android on a 16Gb USB disk. On first impression, that’s not a huge amount of space (bear in mind that the OS will take up part of this). However, what we have is a cloud centric machine. Take a look at the following free cloud storage providers:

storage

  • Google Drive gives me 15Gb of storage for free, and an extra 10Gb if I install Quickoffice
  • Box gives me 10Gb of storage for free
  • Dropbox gives me 2Gb of storage for free, up to a  maxmium of 16Gb through their “refer a friend” scheme
  • OneDrive gives me 7Gb of storage for free

Although I haven’t installed it (yet), Amazon cloud locker will give me another 5Gb of free storage. So that’s anywhere between 37Gb and 63Gb of storage for free.

It’s also worth noting that Google have slashed their cloud storage prices recently, with 100Gb storage costing less than $2 a month. This will trigger an inevitable price war, giving your cloud-centric machine a lot more for a lot less.

That said, if cloud storage isn’t your thing, the OS will pick up any USB drive or external hard disk plugged into the computer automatically. I believe SD cards are also supported, though you may need to manually mount these.

The Office Experience

The standard list of applications we’d expect from any computer for work use would include:

  • An Email client
  • Word processor / spreadshseet / presentation software
  • A browser
  • A calendar

To cover this, I have installed:

GMail (on top of the default mail client)

email1

Quickoffice

office

Chrome

browser

Google Calendar

calendar

I may also need instant messaging / video conferencing abilities. So I installed Skype (I had some camera discolouration issues with Hangouts):

skype

I’ve also got remote desktop capabilities, using the official Microsoft Remote Desktop Client app:

remotedesktop

Bonus! MightyText is fantastic. It allows me to sync up with my phone and read and send SMS from my desktop. Pretty swish.

mightytext

Media

If I was writing this post two days ago, I’d be reporting that YouTube didn’t work for me. Happily, the most recent update seems to have solved this issue:

youtube

Google Music stores all my music in the cloud, so it doesn’t take up space on device (unless cached). Also, my Google Music allowance of 20,000 songs does not count against my Google Drive storage allowance, so some more free storage there. I’ve also got Google Play All Access, so I can listen to pretty much anything they have in store:

music

Social Media is a bit hit and miss though. Facebook doesn’t have a tablet optimised app yet; Twitter does, but it’s not great from what i can see:

twitter

However, the WordPress app is pretty neat:

wordpress

Google+ is fantastic:

plus

Snapseed is a nice app that can read and edit photos from any of my cloud storage lockers, as well as from my Google+ profile. I can take photos with my phone while out and about and G+ autobackup will save them to the cloud. When I get home, they are already available on my machine to edit (no more USB cables!):

snapseed

And of course, there are a host of emulation apps available. Here’s a PlayStation Portable emulator (PPSSPP) in action:

psp

Outro

I really enjoy using my Android laptop. The OS would be perfect for an old XP Netbook, especially as KitKat is designed to run on machines with as little as 512Mb of RAM. A lot of the windows shortcuts work too (copy/paste, printscreen, windows home, alt+tab). The touch interface is a bit clunky in parts (swipe left / right is awkward with a touchpad), but I’ve been reading up on how to map these gestures to mouse buttons.

How does it compare with ChromeOS? I did try ChromeOS (well, Chromium) on a bootable USB stick a few months ago using a similar method to that in part 1. To be honest, I saw little difference between ChromeOS and just running Chrome browser in fullscreen mode. Furthermore, Android seems to have a greater range of apps. Personally, I prefer my Android setup even though it’s not optimised for the desktop experience…yet.

How to conclude? Give this a go for yourself and drop me a line on twitter @redhandknight and let me know how you got on.

Make your own Android Laptop – Part 1

Intro

This is the first part of a two part blog on running Android on a laptop / desktop computer. This first post will focus on the “how to” and the next post will concentrate on the actual experience itself.

A History Lesson

A few years ago, Forbes published an article announcing Microsoft’s Market Share Drops From 97% to 20% In Just Over A Decade. What was the cause of such a downfall?

Personally, I agree with the author of the article – I think it’s an unfair comparison that relies on the definition of an “internet connected device”. In 2000, an “internet connected device” was a desktop or laptop computer; today the definition has been expanded to include smartphones, tablets, watches, televisions… the list is growing.

In a nutshell, Microsoft focused on the desktop / laptop market and missed the boat on mobile technology, allowing the public to become familiar with mobile operating systems like iOS and Android. Microsoft are still the main player in this “traditional computing” market (over 90% according to NetMarketshare), but statistics are showing a decline in this market at the expense of the rise of the tablet (according to Canalys).

As an IT professional, I don’t believe that a tablet can provide me with everything I need to do my job in the way a desktop computer can. I need a physical keyboard. I need a mouse. I need a big screen.

That said, a number of manufacturers are now shipping computers that run on Android rather than Windows – you can see efforts from Lenovo, Acer and HP here. It’s not a bad idea from a business perspective – it’s an operating system that millions of people are already familiar with (reaching 1 billion activations last year); and as it’s free, there is no OS license fee to pay allowing the manufacturer to sell devices for less or just get a bigger profit margin.

But is Android ready for the “traditional” computer yet? I decided to give it a try. Step forward Android x86.

Android x86

For those not in the know, Android x86 is an open source project aimed at bringing Android to the “traditional computer”. The team download the source code for Android versions as they are released, compile it to run on x86 architecture, and then publish the OS image for public download. It’s very much a community effort with users installing the OS on home computers and submitting any issues / patches as they are found / developed in the spirit of open source software.

I found the latest release of Android 4.4 to be quite stable, although not without issues (mostly minor). This post will outline how to safely install the OS onto a bootable USB stick if you fancy giving it a go. If you don’t like it, just reformat your USB stick and you have lost nothing.

Installing Android on your Computer – Preparations

First things first. You will need the following:

  • 2 USB ports
  • 1 USB stick to create an Installer disk (4Gb should be fine)
  • 1 USB stick to install Android onto (as big as you like – this will be your system disk. I used 16Gb)
  • Install a partition manager tool that will allow your to format your USB drive as EXT3 (I used EaseUS Partition Master Free)
  • Install software to write an ISO to bootable USB (I used Win32 Disk Imager)

Step 1: Creating an Installer Disk

Go to the Android x86 download page and download the ISO:

x86_kitkat

Insert your would be “Installer disk” USB stick and run Win32 Disk Imager.

Change the extension of the file from ISO to IMG before selecting the image file, and select your USB drive to write the image to.

windisk32manager

Step 2: Formatting the System disk

Run your partition manager tool and format your second USB stick as EXT3.

easeUS

Note, NTFS will not work, and other formats will limit you to having a maximum disk size of 2Gb.

Info: BIOS – a Primer

As part of the install, we need to change some BIOS settings. If you know what BIOS is, feel free to skip this part.

Simply put, BIOS is the software that tells your computer to start Windows (or whatever OS you use) when the computer is switched on.

It’s often invisible to the common user. You switch on the computer, BIOS searches any attached disks for an OS and then runs what it finds.

By default, most computers have a single operating system already installed on the computer hard disk.

If nothing is found on the hard disk, all other attached media (CD drive, USB) are checked in order until an OS is found.

It is possible to have multiple operating systems installed, but that’s a story for another day.

Step 3: BIOS Settings

We need to change the BIOS boot order to read from our USB stick before the computer hard disk.

Restart your computer. As soon as you see the manufacturer’s logo (Dell, HP, Acer…whatever), note where it says “Press [key] to enter setup” and press the named key.

The most common keys are F2, F10, and Del.

Once you have loaded the BIOS, you can use your keyboard to navigate to the boot menu.

biosBoot

Change the boot order so that USB is ahead of your hard disk.

Plug in your “Installer disk” USB stick and exit BIOS.

Step 4: Installing Android to USB

After exiting BIOS, the following screen should appear:

InstallBootSelect

The first option – “Run Android without installation” – will allow you to try out Android, but you will lose all data on reboot. Try it if you like, but follow on for the proper install.

  1. Select “Install Android to harddisk”.
  2. At this point, plug in your “system disk” USB stick and chose “Detect Devices”.
  3. Select the newly plugged in USB stick as your target install directory.
  4. The next screen will ask you what format the USB stick will be. Select “Do not format” (the disk is already formatted).
  5. Select “Yes” for “Do you want to install boot loader GRUB”.
  6. Select “Yes” for “Do you want install / system directory as read / write”.
  7. Once completed, you are prompted “Run Android x86” or “Reboot”. Select neither; instead, switch off your computer.

Step 5: Booting into Android

Before powering on, unplug your “installer disk” USB stick. All being well, you won’t need this again (although your could lend it to a friend to save him doing Step 1 here).

Plug your “system disk” USB stick into the port the “installer disk” USB stick was just removed from. (If you don’t, you get “Error 17” on boot. Simply reboot with the stick in the right port).

Switch your computer on.

Very shortly, a screen like the following appears:

grubKitKat

Select the first option to boot into Android. There’s an initial setup process just like when you switch on a tablet for the first time.

As long as your Android USB remains in the USB port, you will boot into Android (reboot and remove to boot into your normal OS).

Outro

That’s it. You now have an Android PC.

Part 2 of this post will be a summary of my experience in using my Android laptop, covering the apps I use, what works well, what doesn’t work well, and what doesn’t work at all.

If you don’t like what you see, remove the USB stick and reboot. You will boot into your normal OS as if nothing ever happened. Reformat the USB stick if you want it back.