Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Android is splintering, just not how you think it is... (russellbeattie.com)
43 points by ubernostrum on Nov 22, 2009 | hide | past | favorite | 17 comments


In what other ways is Android splintering?? This post talks about the sort of splintering I thought everyone was talking about when they talked about splintering: multiple devices, different hardware capabilities, different versions, carrier and manufacturer-applied customisations.


There is also splintering in the Linux sense, where the actual software is branched into a number of moderately-compatible versions that include different features, different ways to manage the software, and different interfaces.

Despite its open-source nature, we haven't actually seen any real forks of Android yet. I'm assuming that's the sort of splintering the article refers to.


Tim Bray's post (which this was responding to) seemed to be taking the position that since all Android devices run Dalvik bytecode, they're basically compatible with each other. Russ' point is that this is the wrong way to think about it.


The outlook gets quite a bit brighter when you limit the field to actual phones -- which is where the development is focused.

I understand that the promise of Android is compatibility across many different kinds of devices, but at this stage it's a bit of a strawman to pull out the Archos which is a: not a phone, b: a very early device and c: not Google sanctioned.

In other words, I'm with Tim Bray on this one.


A lot of people talk of splintering as if it doesn't exist on the iPhone.

1. different devices have different hardware capabilities: my 1G doesn't have bluetooth, early iPods don't have a camera, etc. Apps have to deal with that on every platform and it'll only get worse as Apple ads more hardware features.

2. different screen resolutions: Android is simply ahead of the game on this one, the iPhone isn't going to stay at 480x320 forever (I'm willing to bet a lot of money next year's iteration will not have that resolution)


The challenge that Android faces is that multiple versions of software/hardware are available to purchase at the same time. While Apple only has one version of the iPhone in stores.

I hope Android succeeds to keep Apple innovating and honest.


Android's challenge vis-a-vis the iPhone will be that Google doesn't know a lot about consumer electronic devices, and the wireless carriers don't know a lot about consumer software. Apple is among the best at both.


Was your 1G iPhone's bluetooth broken? Bluetooth was included on all the iPhones. The only thing that the first gen can not do is stereo bluetooth.


I recently bought an Archos 5, which I'm very happy with as a gadget. However, it's stuck on v1.5 of the Android OS right now, with a custom GUI extension added to make up for its lack of keys and home/menu/back. Additionally, it's not a Google-sanctioned distribution, so there's no Android Marketplace, nor able to run any of the important Google apps: Mail, IM, Maps, etc.

OK, so everybody can take Android and run it on their device.

Google needs to get control quickly. I had originally suggested using the Android logo and trademark (which they may or may not own) as a way of ensuring compatibility, but it seems the logo is creative commons. So maybe they need to come up with an "Android Approved" logo or something.

Doesn't that give even more confusion to the customers? Companies can change Android in whichever way they want and still call and market it as Android. Adding another method of distinguishing Android devices won't help solidify the brand.

(Also, people will still try to run your app and complain when it doesn't work. It's like your application breaking because of injected code on a jailbroken device -- you shouldn't have to worry about it, but those users will still leave negative feedback, so you'd better fix it quickly).


I don't know if this is the case, but Android should have a set of guidelines specifying the current known hardware variations to test against in terms of screen size, memory and processing power. That devices take into account physical and on-screen keyboard should be a give, however.

The most likely thing is that different manufacturers will have some sort of certification process a la Appstore, but less restrictive in terms of allowed functonality. I know for a fact that Sony and Motorola are pointing that way.

I'm still pretty sure that within a year this situation will be normalized as more specific guidelines come up. Indeed, some devices will be left out. However as long as most devices have access to the important applications I don't think anyone will be too worried.


I had this exact conversation a few days ago with a friend who is just starting to play around with Android. They really should define "capability classes" of some kind - ie, a 'Class A' device has minimum screen resolution of u x v, physical keyboard, GPS, etc. This would allow us to have specific targets to build against, but still allow manus to create a variety of devices. This would allow for building elegant degradation into apps so that people without the latest and greatest phones aren't completely left out (as is currently the case).


Carriers and HW companies may not like making side-by-side comparisons so easy. Alternately there should be names other than A,B,C which are not inherently ranked.


Trying out a bit of Android development is one of those things I want to try over my holiday (just need to get a device...) - how big a deal is testing an app on different devices at this point? At least amongst Google sanctioned ones?


Not a big deal.

Just plug in a device, and press play in Eclipse.


Except you need the actual device. For J2ME development this has become impossible for "small guys".


Someone (nokia?) has/had farms of different devices which you could test on remotely. However this is unlikely to be available to run-of-the-mill developers.


For kicking the tires on Android development, you can use the emulator.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: