Submitted by This is absolutely fascinating. Steven Troughton-Smith has gotten his hands on one of the two early Android prototypes – the Google ‘Sooner’. The Sooner is the BlackBerry-esque Google phone, which was supposed to be released first, followed by the much more advanced Google Dream (yup, what would eventually become the G1). Lots of high-res screenhots to get a good look at early Android. Update: Fascinating comment.
According to Steven Levy’s “In The Plex: How Google Thinks, Works, and Shapes Our Lives”, Google was working on two different phones in 2006 and 2007. The first was the phone Android was working on before it got acquired by Google – a BlackBerry-like device, called the “Sooner”, which is the device Troughton-Smith got his hands on. The other was far more advanced, and was started after Google acquired Android. This one was called the “Dream”, and sported a touch screen interface. This would eventually become the HTC Dream (or T-Mobile G1 in the US), the first commercially available Android device. So, what the heck happened to the Sooner?
The idea was to get the Sooner – which had seen the bulk of development before Android was acquired by Google – out the door first, to be followed later on by the Dream. Then, as we all know, the iPhone happened. The Sooner was dropped like a brick, and all development would focus on the Dream instead. Since Rubin was given quite some freedom in setting up his Android team within Google, he managed to attract a number of employees from Palm, like Dianne Hackborn, who obviously had quite some experience with touch input.
We already know what the Dream looked like round around that time – it supported multitouch, but it was limited, and by far not as advanced as the iPhone’s touch input. Thanks to Troughton-Smith, we now also know quite a lot about the ill-fated Sooner, the dead end that never came to market because the iPhone made it pointless and a relic even before it was well and done.
The Sooner, or HTC EXCA 300, sports an OMAP850 with 64MB RAM, and came in both black and white. It had all the usual stuff (like a camera), but no 3G or wifi (so only 2G). According to Troughton-Smith, the device has a “certain quality to it”. It runs build htc-2065.0.8.0.0, dated May 15, 2007, a few months after the iPhone had been announced.
It had no homescreen like we know today – it was just a clock with a Google search field. Interestingly enough, it did have an early version of the homescreen we know from Android today, but it was a separate application instead of the main launcher (Android still works that way today – multiple launchers on the same device). It came with the usual Google applications, too, like Gmail, Calendar, and as on. There’s a lot of skeuomorphism going on, and thank god The Astonishing Tribe redesigned all that stuff for the Dream project.
All this shows just how much the iPhone’s launch caused the industry to change gears. Sure, Google was working on the Dream before the iPhone, but it was considered a “long-term” project, and they were clearly in no rush to get it done. Then the iPhone came. Google made the right choice – suck it up and ditch the Sooner – while others, like Microsoft, Nokia, and RIM, had no idea what to do. They were simply too set in their ways, and couldn’t, or didn’t want to, see just what the iPhone meant.
Google was leaner, and quickly shifted focus from the Sooner to the Dream. The company was lucky it hadn’t launched the Sooner yet, else it would be in a position more similar to the other players (i.e., having to support and promote/sell what would obviously be a dead end).
I love competition.
So it got killed Sooner than later.
…and so the Android is now living the Dream.
Someone even wrote a book about it:
http://en.m.wikipedia.org/wiki/The_Android%27s_Dream#_
Edited 2012-05-06 15:19 UTC
But (inevitably it seems when it comes to discussing iOS, Android, and such) we also have an old example of prior art…
http://en.wikipedia.org/wiki/Do_Androids_Dream_of_Electric_Sheep~*~…
(I guess it also means that http://en.wikipedia.org/wiki/Electric_Sheep should be ported to Android)
We all know sometimes when a device is acting up you don’t turn if off and on, but keep it off for a few seconds before turning on. I guess during this brief time renegade electrons could cause a dream effect in a complicated artificial brain.
I haven’t read the book, so don’t get upset if I have just given away the plot.
i read do androids dream of electric sheep in college for an english class, but had forgotten about it.
Edited 2012-05-06 15:52 UTC
Well, does “Blade Runner” sound more familiar? (Even though it was based on the book *really* loosely).
http://2.bp.blogspot.com/-iNo0nK2BzhU/T6U18w3Vk6I/AAAAAAAAAsw/hUYkq…
Another good example for the misuse of skeuomorphism. 😉
You should see the animation and sound in the calculator app… it is fully skeuomorphic 😛
looking at it i thought it was an electric razor.
Google recognised immediately the potential of the iPhone and reacted accordingly.
RIM, MS, Nokia simply laughed at it initially, be it its price, the lack of a physical keyboard or its OS. Their ignorance is what lead them to their current situation.
It’s sad that we lost Palm along the way. They had some interesting ideas and with the right support I believe they could have succeeded.
I see this as a classic case of the innovator’s dilemma.
RIM, MS, Nokia, Palm, etc. already had customers and were making money on their product.
Google did not.
Edited 2012-05-07 18:12 UTC
You make it sound like not having to support tons of existing (and expecting certain stuff) customers, not having to support many existing product lines, was not a major advantage of the newcomers.
And you ignore some facts – for example, the “ignorant” Nokia was, for some time already, working on Maemo (a touchscreen OS, with long-term goal of running on mobile phones when the tech will be ready http://www.osnews.com/thread?498055 – its early tablets were a bit too bulky, and with short battery life… but BTW, N770 and N800 didn’t have a keyboard).
Edited 2012-05-14 00:10 UTC
Apple, Steve, thank you for reinventing phone
http://www.youtube.com/watch?v=ftf4riVJyqw&feature=youtube_gdata_pl…
Google, thank you for fast reaction!
I think this gives a somewhat misleading impressions of what happened.
From a software perspective, Sooner and Dream were basically the same — different form-factors, one without a touch screen — but they were not so different as this article indicates and the switch between them was not such a huge upheaval.
The main reason for the differences in schedule was hardware: Sooner was a variation of an existing device that HTC was shipping, while Dream was a completely new device with a lot of things that had never been shipped before, at least by HTC (new Qualcomm chipset, sensors, touch screen, the hinge design, etc). So Sooner was the safe/fast device, and Dream was the risky/long-term device.
However the other factor in this was the software. Work on the Android we know today (which is what is running in that Sooner) basically started around late 2005 / early 2006. I got to Google at the beginning of 2006, and it was around that time we started work on everything from the resource system through the view hierarchy, to the window manager and activity manager that you know today. Some work on stuff we have today (like SurfaceFlinger) was started a bit earlier, but also after Google acquired Android.
Even if there was no iPhone, there is a good chance that Sooner would have been dropped, since while it was a good idea to get Android out quickly from a hardware perspective, the software schedule was much longer. I don’t recall the exact dates, but I believe the decision to drop Sooner was well before the iPhone announcement… though we continued to use it for quite a while internally for development, since it was the only semi-stable hardware platform we had. If nothing else, it helped remove significant risk from the schedule since software development could be done on a relatively stable device while the systems team brought up the new hardware in parallel.
So what you see running on that Sooner is the same Android that would run on Dream. This is one of the reasons we have the -notouch resource qualifier, for the UI select a touch-based or non-touch interface depending on the device. Also at that point most of the widgets you see in the UI (lists and such) are the ListView and GalleryView we have today, and would already be able to react to touch input if they received it. And the software on there was using our layout managers to resize the UI elements to match the screen size.
However that build may not have things in it like actually running apps in multiple processes.
That was one of the lagging implementations in Android, which was increasingly making the hardware schedule for Sooner not match the software schedule for Android. I think almost everyone on the team was relieved when Sooner was dropped, just because it gave some relieve on the core software schedule.
Imagine if Sooner had gone out at a reasonable time before Dream, say a year before. This was when we released the preview SDK. We had a mad dash to get the SDK somewhat cleaned up for that, but did lots of iterations on it in the following months. We had barely gotten multiple processes working (it was so close you still see remnants of our single process environment in the SDK with Application.onTerminate).
During the time from when the SDK came out to when the G1 shipped, we spent many many months working on stabilizing, optimizing, and productizing the platform. This was a platform that had never been shipped before, with a lot of pretty unusual designs — up until near the end, you had to wonder “is this actually going to work?”
We also had a long lead time required in stabilizing the platform before shipping the device. Partly because of uncertainty of how everything would work together, partly because the team hadn’t shipped a device before and didn’t know the tricks we do now for tuning the release schedule. At the time we shipped the device, we even felt like we had to assume that what we shipped on the ROM was it, and we would never be able to deliver an update to it!
So be careful when you look at screen shots. People who aren’t programmers, understandably, see a UI and take that to be all there is to know. We should know however that what is behind the part you can see is actually a lot more complicated, stuff you could never realize just from what you see with your eyes. People throwing up pictures of a UI they have played with and coming to conclusion that explain what is going on behind the scenes may get some things wrong.
Thanks for that – sadly, us peasants have to work with what we have – screenshots, word-of-mouth. From that, we have to try and piece together how things went, and the more information we get, the clearer the picture
.
Any reason in particular for not using then, as a base (at least for early development phones, not necessarily the launched one), the existing Windows Mobile HTC touch handsets?
I think I remember some of them even getting community created Android builds…
Resistive touch screen, for example?
Yeah Dream had a capacitive touch screen, unique keyboard mechanism, 3G data, compass, accelerometer, new chipset, etc. It was intended to be what its name says.
Maybe from earlier on it would have been a better plan to design a device based on a different existing device that was somewhere between Sooner and Dream, and not do Dream at all. Or maybe not — ultimately as I said the software schedule was as much a factor as the hardware schedule, so pulling in the hardware schedule wouldn’t have necessarily gotten a product out earlier.
As it is, I think it worked out well. We got the Dream hardware and Android platform software done around the same time, and Dream gave us something of an “everything and the kitchen sink” device to help guide the platform: supporting both landscape and portrait as primary orientations due to the keyboard, capacitive touch screen and DPAD focus navigation, compass, accelerometer, GPS, etc. Having a platform that worked from the start with that device has I think been really good for us.
There are quite a few Android phones with resistive touch screen out there (I can immediately recall one popular, LG GT540), so it’s not exactly a show-stopper like some1 suggests above.
(though yeah, it’s nice that G1 had capacitive – in all, it’s basically still just as good as any decent entry-level Android that’s currently shipping, my buddy still has G1 with some 2.3 community ROM – I just wondered about not quickly rigging up, available for dev much sooner, something from existing HTC tech …which you just adressed)
I love to read yours posts Dianne regarding Android, somehow it reminds me on blow and whistles while releasing Atari ST
btw did you manage to fix scroll on Android or you still waiting for more powerful hardware to mask this problem?
2009 called, they want your issue back.
it’s more like 2011 issue
https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s so plz stop trolling
I see Dianne that you work hard to resolve all that mess
good job.
Nothing you are writing really has anything to do with my post you are quoting.
This is still an issue on Android? It was my understanding that this kind of thing was fixed for good in Froyo or Gingerbread (I don’t remember which specifically). I know that every device I’ve used with Gingerbread or higher, including my lowly Moto Cliq with CM7 that I just gave to my best friend’s sister, has no scrolling issues.
Oh wait, I forgot you are a huge Apple fan. My apologies, troll on my friend.
last what I read from Dianne is that scroll issue will be fixed with better hardware – this approach remind me a little bit to Microsoft but … who know why this is good
btw I am a fan of god-like optimization
Hey, all I know is switching to CM7 from the official ROM on that Cliq fixed all the UI issues the phone had.
Since we’re on the subject, do you have any suggestions for the terrible UI sluggishness and other performance issues on my girlfriend’s iPad? Since everyone knows you can’t put a different OS build on Apple iDevices, I mean.
Well, you know, that’s not exactly an Android-specific problem.
Symbian smartphones used to last a week of light use on a single charge and deal well with 266 MHz CPUs and 256MB of RAM. I believe Blackberries were also able of similar feats at the time. Nowadays, you’ll have a hard time seeing something running iOS, WP7 or Android achieving something similar.
For an example from Apple, look at the statements that Siri cannot be ported to pre-4S hardware because the hardware is not powerful enough, or that the iPhone 3G couldn’t multitask. I tend to doubt it myself, but if it’s true, it says something about optimization at Cupertino, since they used to be able to do voice recognition and multitasking on hardware that was much weaker than that, without the assistance of external web servers for “cloud” processing.
The reason why smartphones OS manufacturers don’t care about optimization is not a secret either. People switch phones once every two years at most, and are lured into believing that this is a minor expense through carrier subsidizing. In the end, why bother with making optimized software for disposable hardware that will be “powerful enough” pretty soon anyway ?
Edited 2012-05-07 08:28 UTC
Neolander,
“For an example from Apple, look at the statements that Siri cannot be ported to pre-4S hardware because the hardware is not powerful enough, or that the iPhone 3G couldn’t multitask.”
I have no authority on the subject, nor do I much care, but as I understand it siri not only worked on pre-4S hardware, but was actually available to customers in the store prior to apple buying them out and pulling the app.
Trouble is vendors have no incentive to ever add support for older hardware even if possible. In fact the opposite is usually true, they’d prefer the apps not be compatible on existing hardware even if it is trivial.
That’s technically correct, by you actually overdo the 2nd number
~256 MB is only becoming fairly standard in presently shipping Symbian handsets – they used to deal well with amounts close to an order of magnitude smaller.
I had Nokia E50 for a time, nice little entry-level Symbian (though “big” ones weren’t that different). Its CPU speed was quite close to what you say (note though that it was, IIRC, ARM9). But it had ~30 MB of RAM, ~20 of which was free & useful to the user.
And it worked fine.
More than that, they pulled it from being available for older iPhones when 4S premiered.
Yup.
Edited 2012-05-14 00:18 UTC
And What about the htc blue angel? i heard that it was one the first prototype to receive android developpement?
http://www.usatoday.com/money/industries/technology/2008-01-13-andr…
http://news.soft32.com/a-la-mobile-demonstrates-android-platform-on…
http://www.a-la-mobile.com/news/press/pr080114.html
strange photo:
http://openhandsetmagazine.com/2008/01/a-la-mobile-demonstrates-the…
Edited 2012-05-07 13:39 UTC
Would just like to clarify that I am most certainly a programmer (you can Google me if you like) 😉 And even running the M3 SDK version of Android on the touchscreen emulator has the OS looking and acting exactly the same as non-touch – there is no completely different UI for touch, so it’s misleading to suggest that what you see here isn’t representative of Android at the time. Just my 2¢
The early emulator was released with the goal to get feedback on APIs and developers starting on basic application development. A lot of the real UI stuff was not visible in order to avoid it being leaked in an incomplete state.
If you look at the schedule, it would be pretty hard to believe that in the less than a year from the first emulator release until devices are being sold, the entire platform was stabilized *and* the entire UI was changed from being DPAD-based to touch-based. The same people stabilizing the different parts of the platform would also often need to be doing any work on touch — for example the view hierarchy was a big new piece of code that had never been shipped, and would have significant disruptive work to add touch support later on. Even if you had a large number of engineers working on it (which there were not) you couldn’t stabilize it at the same time you were making such changes.
The tail end of this comment reminds me of many moons ago where an overzealous and underdeveloped Director used to come around my dev team office every day to see “progress”.
I’d make sure we stuck a few meaningless buttons on forms or changed a layout a bit before he came around and then we’d carry on as per usual.
The new pretty buttons was the only sign of change he understood. A UI that never changed for weeks was obviously a sign of developers doing nothing in his eyes.
The dock and apps screenshot reminds me on how Google TV GUI home screen and apps works today.