Unlike some of Ars' other epic history articles, this one didn't really get me too excited. It seemed pretty screenshot-heavy, thin on technical details (especially the 'why's behind version-to-version changes, the 'who's behind the original and ongoing development, etc.).
Most of the information is nice to know, but the story really remains to be told. This article is far from a Sircusa Mac OS X review (which I usually spend at least an hour reading every year).
In the end, the article reminded me more of a journal of someone's spelunking adventure rather than a personal story with an interesting slant, so I felt less inclined to power through the last few pages.
I'm really glad that this article has been put together just to at least have some idea of the way things were.
If they are planning to keep this updated as android evolves I really hope they go back to each of these previous versions and give a bit more context around the industry at the time.
There are certain comments in there generalizing around 'people weren't ready for xxx' but they obviously were as other OSs had the functionality at the time.
I got a massive nostalgy rush out of the 0.5 screenshots.
When I was summer intern at Nokia back in 2007 we installed android beta version into N800 (the small Linux tablet by Nokia). And for maximum amount of trolling we even taped the text "gPhone" in it (iPhone had just been released).
This was absolutely non official but hey. It was fun! The actual port was made by someone at maemo forums so we didn't even waste too much work hours on it.
I really hope Android 5.0 is coming out at I/O. It's a bit overdue. Google usually pushes major .0 revisions every 2 years. 2.0 in 2009. 4.0 in 2011, and 5.0 in 2013...NOT.
It's 2014 and no 5.0 in sight, except for a very weak rumor about the date on a Nexus phone being 5:00. If they wait until fall this year, it would be 3 years for the 5.0 release, just as much as for a typical Windows release, which I find pretty ridiculous considering Android isn't even trying to work on all devices out there before it's released.
Hopefully Google will release it soon, otherwise I'll be very disappointed.
To be honest, there have only been two major relevant Android versions; 2.x and 4.x. Under 4.x, they realised that getting updates to devices (where they had to rely on phone manufacturers) just wasn't dependable, and they overhauled both their OS's architecture (moving most services out of the core OS into Google Play Services) and their release system (allowing for over-the-air updates without the phone manufacturers' intervention).
So unless they've rebuilt Android from the ground up, I doubt they're going to do a 5.0.
From what I've read, the general hypothesis is that Goog will likely stick with 4.x numbering for some time. Imho they'll switch to 5.x when they decide to drop support for ~2012 Nexus devices (Nexus 4, Nexus 7 etc).
I feel the OS has been updated a lot in the last year or two but mostly by app updates as Google is now moving a lot of their stock Android apps to the play store.
Much sought after features like a tighter Hangouts/Voice/Sms integration would 'only' need an app upgrade as opposed to a new OS.
One thing that you have to respect about Google and Android, like a constantly changing (dare we say gentrifying and revitalizing) urban neighborhood - they aren't afraid to try new things, tear down old things, invest, and divest.
John Gruber had a much favorited tweet during WWDC that he revisited in his blog.
"Microsoft: one OS for all devices.
Apple: one continuous experience across all devices.
That tweet was massively popular,1 but I missed a word: across all Apple devices. Microsoft and Google are the ones who are more similarly focused. Microsoft wants you to run Windows on all your devices, from phones to tablets to PCs. Google wants you signed into Google services on all your devices, from phones to tablets to PCs."
The article is much about look and not enough about what makes Android different.
The two biggest changes in Android were the Fragment class and a greater emphasis on multiple layouts to scale UIs across many screen geometries, and Google Play Services.
Outwardly, Android looks much much prettier. But it's the same Home app, with an evolved but fundamentally the same AppWidget architecture under that prettier face.
Android's core features, like AIDL-based IPC, Intent and filters for Intent types, and ContentProvider have been remarkably stable and constant. And they have been under-appreciated and under-exploited, with the exception of ACTION_SEND intents for the "Share" menu. Too few apps expose an API or expose their data through a ContentProvider. Too few apps provide Intent matching for actions other than ACTION_SEND.
Very great article, and yet quite sad and scary. You can grab an old apple ][ and run programs from 30years ago! If you can get access to a PDP computer, you can run programs from 40 years ago on it! Or even the emulator. You are not going to be able to run your favorite andorid programs 10-20years from now.
Just the other day, a link was posted on here about how to get a Lisp machine running in your Linux. I downloaded the binary and some source and got one up and running about 2 years ago. To be able to time travel to the past and explore what has been done without just reading about it is a great experience. With the mobile eco system, we are going to miss out on this. There are going to be great programs that will be written and then rot away with time never to be recovered.
Because many of the apps require connections to deprecated (and usually non-working) Google APIs to even start up. Thus the white screens, crashes, etc., as mentioned in the article.
If you can find a way to emulate Google's infrastructure and services circa 2007, and redirect all your DNS traffic to this local infrastructure setup, then you may be able to run the apps in an emulator. But it's more effort than it's worth :(
Oh I see, well from that perspective quite a lot of things will go away, like I probably won't be able to emulate Gmail, $ing, all kinds of stuff, probably in 50 years. That doesn't seem to be a particularly Android specific issue.
gmail doesn't belong to you. With android, you wouldn't be able to run your own code without much effort/porting to new platforms. If you wrote a game for the amiga or apple, and still have the original machine, you can still run your own code. There are programs being used today that are 30+ years old which serve their purpose. This will be used to force extinction of programs.
I strongly believe Google will replace ChromeOS with Android some day. ChromeOS compared to Android "Just Works™".
I'm usually an iPhone user but I am very curious about Android so often make the switch. Last time I switched to Galaxy Nexus my experience was not so good. Battery life and UI smoothness was far from iPhone. I switched back to iPhone.
This time I switched to Android via a Nexus 5. Battery life is still not acceptable and many times I experienced things not working. Having to kill an app or cleaning their local cache are things I don't want to do on my phone. Specially when I'm trying to get around or find a very urgent information. I'm going to switch to iPhone with next release and wait for an operation system from Google that work as good as Chrome or iPhone.
This time I switched to Android via a Nexus 5. Battery life is still not acceptable
I switched to Moto X after using an iPhone for four and a half years. With the same usage patterns, my Moto X lasts as long as my iPhone 4 before. The Nexus 5 is apparently notorious when it comes to actual battery life.
Having to kill an app or cleaning their local cache are things I don't want to do on my phone. Specially when I'm trying to get around or find a very urgent information.
Never had to that that. In fact, my experience is quite the opposite. Even after all those years, iMessage messages would arrive minutes to ours too late or in the wrong order (very annoying when you have to meet with someone). iTunes Match would often only download albums partially. Calendar sync was not immediate (there was often a delay between adding an appointment and it showing up on the Mac and vise versa).
Since switching to Android I wouldn't want to go back. It has decent keyboards (finally coming in iOS 8), I can actually share data between apps (finally coming in iOS 8), I can attach files from within the e-mail client (rather than only being able to pick a file from an app and then saying that I want to share it via e-mail). Google Now and voice recognition are awfully much better than Siri, especially because it's actually integrated in the Google Now Launcher, and not an island on its own.
Besides that fact that I find Android far more pleasing, I bought my Moto X for half the price of an iPhone 5 and I have a data plan for 10 Euro per month. This means I can upgrade my phone every 8-12 month without spending a dime extra.
I have a friend that has a Moto X. I think I should try a better hardware. Nexus 5's GPS/BT/LTE chip is not working well I guess. I have to kill Google Maps every single day to get it working.
Yeah, that had me puzzled too. I haven't had to mess around with clearing apps or resetting data or even rebooting my phone since 4.1 hit the Gnex - even before that it was very occasional reboot and not much else. Nowadays it just works.
Can't figure out why people keep complaining about battery life as well - probably they've the wrong phone. Head over the Anandtech or any other reputable review site and you will find many Android phones trumping the iPhone in battery life department. My Moto G easily runs for a day+ consistently and I am a pretty heavy user.
"Cleaning local cache" particularly befuddles me. My first smartphone came loaded with Gingerbread and I don't remember ever having to do that, much less having to do it in recent memory.
Android is phenomenal success and needs no messing with. It will spread from tablets and handsets to TVs, cameras, cars, appliances, etc. Android will have a multi-decades dominance like Windows had, but spread across more different touchscreen hardware platforms.
Chrome OS is doing a brilliant job soaking up Windows refugees with a laptop/netbook form factor, where you have a touchpad or other pointing device, so you don't have to make the Web finger-touchable, which it isn't.
People will try to mix the two, but there is no point.
EDIT: Yes I know TV isn't touch, but it is a d-pad/select style of interaction, which Android always supported, even before touch.
Android on TV may be d-pad/select style, but many Android apps aren't. For example, the Australian public broadcaster ABC produces an Android app called iView, but it is almost unusable on an Android set-top box without a mouse.
Sadly, that's correct. Those apps should declare that limitation in their manifests. Which would in the case you cite lead to a TV app not being offered to TV devices.
Botches like that are mostly due to buying cheapass, low-bidder implementations that don't implement the d-pad navigation methods in custom View classes. Actually, it's pretty difficult to avoid inheriting the default method implementations so the deficiency is probably mostly in not handling the highlighting and selection methods. Shoddy!
I think Android benefits from the general Google halo effect, but it just isn't very good. It's OK, in the same way Windows 98 was OK. My Nexus 5 has been buggier than my Lumia 620 or the iPhone 5 or iPhone 4 I had before that. Just little things: messed up text boxes in Chrome, app hangs in Chrome, etc. Some random bad design: if you turn off location services, which I do because of the marginal battery life, Maps will just sit around waiting for a location--it won't tell you to turn it on in the preferences. Its not the reliable appliance I want it to be. I have a regimented weekday schedule, and by midday I could be on my last legs battery wise, or still have half a tank. For some reason, I have a Gallery app as well as a Photos app. Of course, it'll continue to be popular because it's free.
It's fine. It's just not that great. I too am back on the iPhone when they come out with bigger screens.
> Some random bad design: if you turn off location services, which I do because of the marginal battery life, Maps will just sit around waiting for a location--it won't tell you to turn it on in the preferences.
I turn off location services (not because of the impact on battery life[0] but because I don't want to send my location to Google 24/7). Every time I open Google Maps and try to find the current location, I get a popup telling me to turn on location services[1].
[0] Neither GPS nor Google location services has a noticeable impact on battery life - the thing that will have a noticeable impact on battery life is when an app holds a lock on the GPS/location services (which actually has nothing to do with whether location services are on, since they can lock locations services even when they're off - an easy example of a culprit here is Foursquare's main app).
I know this is not an option for a lot of people - it requires root access to the device - but there is an Xposed module which disables the popups for location services [0]. I use it with Tasker to selectively enable and disable location services, but it may help you.
You have turned off location services (coarse location) but not GPS (fine location). As a technology, GPS gives better accuracy and precision, but at the cost of possibly taking longer to provide a reading, and they generally require a clear view of the sky because of how they work[0]. Google's location services have varying accuracy and precision (usually good, but sometimes way off), but return a reading almost immediately.
The reason that the UI is prompting you to wait instead of prompting you to turn on location services is because you don't need to turn on location services - you just need to wait until the GPS gets a solid reading (which could take either seconds or minutes, depending on where you are, whether you're inside or outside, etc.)
By default, Android turns on both together, and the assumption across the OS is that you're using both, because there's very little downside to doing so. I can see why that UI might be confusing to you, but if you're turning off coarse location services while leaving on the GPS, you're not really using the device the way it's intended (nor the way that it defaults to being used), so I can see why the UI isn't tailored for that use case.
For what it's worth, in your case, I'm puzzled by why you would want to leave GPS on but location services off. You mention battery life, but since the former is the one that is a larger draw on the battery (and as I mentioned before, neither one is a major draw on the battery as much as the lock is), you'd probably be much happier leaving both on all the time (or to leave location services on but turn the GPS off[1]).
[1] For most mobile applications, GPS is actually overkill and the coarse location services will probably suffice. The only time I've ever needed the precision that the GPS provides is when I need turn-by-turn directions.
My experience has been the opposite. In fact there were couple of articles with evidence of android apps being more stable than their iOS versions [0]. The difference wasn't large however.
Its the same case with battery life. It seems pretty comparable to the iPhone 5 and 5S [1]
There are huge power-oriented architectural differences.
1) Background an app, it doesn't use power.
2) ObjC doesn't keep gobs of unused memory around
3) Hardware / software integration allows things like spinning up the radios, doing all the updates, shutting the radios down.
4) C code runs lightyears faster (aka. uses less power) than java.
5) iOS uses the GPU rather than the CPU to do most rendering tasks, and provides great tools to let developers know when it's CPU rendered.
6) Instruments tells you exactly what code is using power.
7) Location services, if an app uses too much GPS you ban it from location services.
8) Timer coalescing allows the CPU to sleep more
C code runs lightyears faster (aka. uses less power) than java.
First of all, it's not lightyears, usually only a factor of two. Secondly, iOS apps are usually written in Objective C, which uses dynamic binding, sacrificing part of C's performance.
5) iOS uses the GPU rather than the CPU to do most rendering tasks,
Before quoting performance comparisons it is a good idea to check whether they are up to date. That page compares a very early version of Dalvik (1.6 a.k.a. 'Cupcake') to native C and a server JVM with a smart-ish jit compiler ('hotspot').
The first release of Dalvik which contained a jit compiler was 2.2 ('Froyo'), comparisons for that versions with Java have been performed by Sun/Oracle [1] showing it to be about half as fast as Java SE embedded 1.6.0_21. Both the JVM as well as Dalvik have made speed gains in the intervening 3.5 (!) years. As of Android 4.4 there is an experimental new runtime (prosaically named 'ART' for 'Android RunTime'...) which pre-compiles as much of the code as possible to native code. The speed gains currently are subject of much debate.
1) A backgrounded app on iOS is usually suspended immediately and as such comparable to a cached app on Android, neither uses power. Both platforms allow apps to continue to run code in the background, both platforms reclaim memory from inactive apps. Android is more flexible when it comes to running several tasks in the background, iOS is slowly moving in that direction.
2) What do you mean by 'keep(ing) gobs of unused memory around'? Neither iOS or Android keeps 'gobs of unused memory around', both use inactive memory for caching purposes.
3) The same is true for Android.
4) This has already been debunked in this thread.
5) The same is true for Android.
6) More or less the same in Android.
7) This is where Android runs behind iOS in the default configuration. Alternative distributions (Cyanogenmod, Paranoid Android, etc) do offer more fine-grained control over services, as do extensions like the 'Xposed framework'. The device needs to be rooted to install the latter.
8) as does the Linux kernel...
It does not make sense to portray iOS as superior to Android because it isn't. Both platforms have their idiosyncrasies, both have their strengths and weaknesses. Android is more flexible, iOS offers more fine-grained control over permissions. The latter can be retrofitted to Android, while it is hard - and against the EULA - to add flexibility to iOS. Both platforms show the intentions of their creators: Google wants to know as much as they can about their users, Apple wants to have their 30% cut of anything done on or through their platform.
Yup, it's all the same Android is totally on par with iOS yet somehow the battery life on a typical iOS device with actual real software installed and used frequently results in far higher battery drain than on iOS.
Sure, the GPU is integrated now, but the graphics still chug on a Note 3.
Sure, if you unwrap any two android and iOS devices they will be on par, ask two heavy android/ios users how long their battery lasts and you'll get vastly different answers.
There are plenty of places where just these questions are asked, and answered. For Android I'd suggest looking around the xda forums. For reference, I use an oldish (launched in 2010) Android device (Motorola Defy) running Android 4.4.3. The battery generally lasts for 3-4 days before I get a low battery warning (meaning 14% left). Had I loaded the thing with constantly updating all-singing-and-dancing apps and widgets I'd need to charge the battery every day. Doing absolutely nothing the battery lasts for 28 days (from 100% to 2%). And yes, there are differences between Android devices, just as there are differences between cars and televisions and chainsaws and any other device which is produced in an open market.
For what it's worth, I work in retail, and the average iPhone/iPad-using customer/staff member believes their devices run better when they manually kill apps. I also see quite a few iPhone customers who literally kill every app they use as soon as they finish using it.
I can't think of any Nexus device that had a long battery life. The pressure to deliver a high-spec $350 phone means cuts somewhere. The big beautiful screen uses a lot of juice as well. I think if you want battery like you should not buy into the Nexus platform.
That said, its certainly not bad. There are reviews of long on-screen usage and its certainly usable. It just may not be as long as the tiny-screen iphone.
Things not working on Nexus for me is pretty rare. Usually one bad application that wasn't expecting to be on the newest version of Android and has not been properly tested for it.. Typically, these get patched quickly.
Android has a web browser and if you dont like native apps just dont install any. WebOS only cant be successfull when the competition have all their features + native apps.
Most of the information is nice to know, but the story really remains to be told. This article is far from a Sircusa Mac OS X review (which I usually spend at least an hour reading every year).
In the end, the article reminded me more of a journal of someone's spelunking adventure rather than a personal story with an interesting slant, so I felt less inclined to power through the last few pages.