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.
Post a Comment
Member since:
2011-05-12
Member since:2005-07-06
Member since:2011-05-12
Someone even wrote a book about it:
http://en.m.wikipedia.org/wiki/The_Android%27s_Dream#_
Edited 2012-05-06 15:19 UTC
Member since:2005-07-06
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)
Member since:2011-05-12
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.
Member since:2005-07-06
Member since:2006-09-02
Member since:
2009-12-24
http://2.bp.blogspot.com/-iNo0nK2BzhU/T6U18w3Vk6I/AAAAAAAAAsw/hUYkq...
Another good example for the misuse of skeuomorphism. ;-)
Member since:2012-05-06
Member since:2005-07-06
Member since:
2011-10-12
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.
Member since:2011-05-19
Member since:2005-07-06
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
Member since:
2006-02-15
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.
Member since:2005-06-29
Member since:2005-07-06
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...
Member since:2010-10-05
Member since:2006-02-15
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.
Member since:2005-07-06
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)
Member since:2005-06-29
RE[3]: A little misleading
Member since:2006-02-15
Member since:2005-06-29
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.
RE[3]: A little misleading
Member since:2005-06-29
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. 
Member since:2010-03-08
btw I am a fan of god-like optimization
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
Member since:2011-01-28
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.
Member since:2005-07-06
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
Member since:2009-04-28
Member since:2009-04-28
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
Member since:2012-05-06
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¢
Member since:2006-02-15
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.
Member since:2005-07-06
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.
