Building Android firstDecember 2, 2013
Over the past six months, my business partner Matt and I built an Android app. One side benefit’s been seeing mobile development trends firsthand, and the most important trend we’ve seen is that Android’s become a strong development platform, and it could be worth going “Android first” – but doing so isn’t for everyone.
Android’s billion-plus users come on thousands of devices and several operating systems. Our app, Hoot, has been used on over 1600 device models in the ten weeks it’s been out. If we’d built for iPhone, the app would have been used on fewer than 10 models, but since Android offers decent tools to manage across device sizes and feature sets, we haven’t seen too many problems. 
We’re also supporting five OS versions, whereas if we’d made an iPhone app, we’d support one or two. Google stats suggest there are seven API versions with more than 0.1% market share, which sounds fragmented. We haven’t found that though; instead, we read the chart and think, “28% of the market uses one version (Android 2.x/Gingerbread) and 72% of the market uses another (Android 4.x./Ice Cream Sandwich, Jelly Bean, soon KitKat)” 
Android 2 and Android 4 are pretty different. If you’re a new startup, you can – and, I think, should – ignore Android 2. Devices running Android 2 tend to be older; they might not have hardware features like bluetooth or front-facing cameras; and coercing applications to run on both Android 2 and Android 4 can be hard.  Compatibility between different versions of Android 4, for the most part, isn’t hard because of the backwards-compatibility built into newer OSs and open-source projects that bridge gaps. 
This isn’t to say Android works well all the time, because it doesn’t. The worst breaks happen when hardware manufacturers modify the version of Android they’re using without leaving any documentation. In effect, they’re breaking the Android APIs, and they do so on a device-by-device, sometimes telecom-by-telecom basis.  In our experience, it’s most common when the software tries to control the hardware, as device manufacturers often have to implement those software methods. The undocumented hodgepodge of implementations is hugely discouraging for developers (like us!) who want to use device hardware (the camera, GPS location, accelerometer, etc.) in apps.
Right now, that probably means fewer Android developers use hardware functions in their apps, and some Android apps don’t stack up to their iOS counterparts. Longer term, I suspect Android developers will become savvier about developing for a subset of Android phones. Google already offers good tools to blacklist certain devices, although that requires knowing which devices to blacklist. (How do you figure that out? Crash reports. From real users. It’s painful.) Or, sometimes, the breaks happen in the most popular Gingerbread handset of all time, and you’re a big company, and then you have to slog through it.
Today we talk about “Android versus iPhone,” but I think we’ll soon compare the iPhone to “Google Android,” “Samsung Android,” “Amazon Android,” and “Xiaomi Android,” and we’ll calculate market share between the Androids. There might be an opportunity for a developer-tools company that ports apps between the Androids.
The true test of a platform’s viability is whether startups build on it. On that metric, Android does well. Young startups build on Android, and some startups build on Android first (as Matt and I did.)  Many blog posts have been written about choosing a first mobile platform. My opinion? I’ve come to believe early teams should develop for the platform for which they’re best positioned. For some – especially for consumer products, because most developers know more iPhone users than Android users – that’s iOS; for others – particularly those who have developers with little mobile experience and some Java experience – that’s Android. Being prescriptive about a startup’s first mobile platform isn’t helpful, so long as the team picks the one that’ll help it find product-market fit fastest.
Mobile platforms, like many other things in early-stage startups, come down to a simple rule: building great products is hard enough that startups should give themselves every advantage they can. For some, that’s building on Android; for others, that’s building on iOS.
 Regarding device sizes, the folder suffixes, e.g. layout/, layout-xlarge/ and layout-land/, and the < merge > tag (so layout elements aren’t duplicated across layouts) are quite good. Regarding feature sets, the Play Store hides apps from phones that don’t have what’s required; search for “Hoot” on a phone without a front-facing camera, and you’ll not find our app. It’s well-intentioned, but in our experience, it’s pretty confusing for users.
 Another version of the official Android distribution chart is slide 42 from mobile analyst Ben Evans’ Mobile is Eating the World presentation. I find the chart misleading, and I’d at least put it side-by-side with this chart, arguing the leap to iOS 7 was on par with the leap from Android 2.x to Android 4.x, but the changes between, say, Android 4.0.4 and Android 4.2 were relatively minor and on par with the upgrade from iOS 5 to iOS 6. That said – nothing beats how quickly Apple gets iOS users to upgrade to a new operating system.
 One way to think about the difference between Android 2 and Android 4 is that there were as many API releases between the start of Android (API level 1) and the first Android 2 release (API level 8) as there were between that Android 2 release and the first Android 4 release (API level 15.) Other developers have blogged about supporting only Android 4.0+ if possible.
For example: say you’re making an application that uses the camera. Android already has a method to find “the best” camera size for a device, which you’d use to show the largest, not-distorted viewfinder on the screen. Android has the find-preferred method return the size best suited for that device, and some devices implement it; others return the first possibility, which is rarely the preferred size (it’s often the smallest), and some return the last (often the largest, maybe not the best.) Easier to implement but a disaster to use.
Worse is when hardware manufacturers re-write Android internals, dropping or re-formatting standard values. Our favorite example is the way the Samsung Galaxy S2 Tabs sold in India implement paddingStart and paddingEnd; rather than return ints, (e.g. 8) as the Android docs suggest they do, and as paddingLeft and paddingRight do, paddingStart and paddingEnd are saved and returned as strings (e.g. “8.0dp”.) When Android’s internals fetch paddingStart or paddingEnd, they expect ints, not Strings, and not-so-gracefully explode. Without paddingStart and paddingEnd, you can’t easily internationalize your app for right-to-left languages.
Android’s intent system is another frequent victim. Android activities communicate with one another through Intents and Objects passed back and forth. The objects are typed as such, though the Android docs suggest what type the objects are. Let’s say you start an intent to take a picture; per the official Android docs, you’ll eventually get back the byte array of data that is the photo. On some devices, on some telecoms, in some countries – all undocumented – you might not get a byte array and instead get a string (where the file’s stored), a boolean (whether the photo was saved ... somewhere) or nothing (who knows.) Java, Android’s programming language, is unforgiving: if you have a string, but act like it’s a byte array, everything crashes.
 Matt and I probably would’ve built Hoot, our app, on iOS first or built a different Android app if we’d known what we were getting into, but we didn’t. Hoot uses temporary storage, light and motion sensors, the camera, and network connections – nearly every piece of the hardware – and we’ve played whack-a-mole coercing it to work across (many) devices. A few months ago, we looked at Android and saw a relatively-ignored platform that uses a programming language with which we were both familiar and no app like Hoot in the Play Store. Since, we’ve spoken to more-tenured mobile developers and realized everyone who knew more than we did stayed far away from features like Hoot’s.