How Android was created
businessinsider.com
businessinsider.com
For an in-depth look into how the original smartphone OS came about, I can recommend David Wood's Smartphones and beyond: Lessons from the remarkable rise and fall of Symbian:
http://www.amazon.com/Smartphones-beyond-Lessons-remarkable-...
David Wood was an R&D executive at Symbian. He's brutally honest about the company's failings... But he also paints a fascinating picture of how the vision for smartphones evolved in the late '90s, when nobody had a clear idea of what the form factor could be and what actual people might want to do with the devices.
(There's a widespread belief that Symbian wasn't a real smartphone OS... Yet it supported 3rd party apps, multitasking and background services, 3G data, touch and keypad UIs, had a mobile WebKit browser before anyone else, GPU-accelerated OpenGL in 2005, and so on. In many ways Android owes a lot to Symbian, IMO -- for example the Activity lifecycle is fairly similar to the base concepts in Symbian.)
I used another more recent HTC device (Blue Angel), second-hand, for a couple of years as my main phone, from 2011 to 2013 IIRC. With WiFi and Bluetooth, decent web browsers available (Opera Mini and Mobile, plus some WebKit forks/wrappers), Google syncing through ActiveSync, for a long time upgrading to a newer phone and OS was not a priority. I only stopped using it for a Android phone two years ago (with the "appification" trend, a web browser is sadly no longer enough).
Coincidentally, the Blue Angel was an early Android target[0], and people have made it run versions up to 2.3 (at which point it's too slow to be usable by today's standards).
I doubt that Android owes much to WM, after all it was a closed-source OS and certainly there wasn't any motivation to do things the "Windows way". It's important to point out that platforms like WM and Symbian existed well before iOS/iPhone OS and Android even had their names decided, and failures apart, the idea of "smart phone" was not the result of solely Apple or Android Inc./Google. Unfortunately, even in many tech circles this is not the idea that prevails.
I also own a Symbian-powered Nokia phone (without touchscreen, forgot the model), and I have no doubt it is a "real" smartphone OS. I can confirm it allows for all that you described and certainly even more in the newer devices with touchscreen.
Say what you will, the IE on my HTC Windows CE-based phone (I forget the model) was actually better than its contemporary IE in supporting standards correctly.
I seem to have misplaced the url, but there used to be a video on Youtube from a mobile tech trade show where Nokia was showing off using one of their phones as a mobile office.
We are talking Symbian, bluetooth keyboard and mouse, and video out to a TV. And this was when Android barely had bluetooth keyboard support (and you needed to use special OSKs to get anything but an American layout), and they had been doing it for years already.
But the Symbian OS itself was terrible; I coded for it and it was a mess. It was quite functional, didn't really crash, but it seemed like it achieved that through sheer effort and will rather than good design.
Really wish i had bought that Motorola Z8 (the Z10 never reached my part of the world).
Frankly it seems the major thing Apple did to the mobile world was to make everything into slabs of glass.
At Orange we had built apps for Symbian S60, UIQ, and windows mobile. We also had seen the limitation of these platforms, especially Symbian which was getting long in the tooth with its baroque memory management architecture. I personally had seen the limitations of trying to get something working on Series 60 working directly with Nokia Engineers and getting held up by the platform limitations (and Nokia's own internal issues).
Another player at that time was Savaje - they had built a completely java based phone OS and were trying to sell it to carriers. Unfortunately they were too early to the market (among other issues).
So Rich had seen all of these issues with early smart phone systems and the European smartphone ecosystem, and presumably applied some of the learnings to Android's development.
But the Android team mostly came from Danger, and Danger used Java. So the Android team had considerable experience designing a Java VM for a device with very limited resources. Although Android never shipped on such a device, the design target was 200Mhz CPU, no GPU, and, IIRC, 128 or 256MB RAM. That's luxurious compared to a Danger Hiptop, which IIRC had only 32MB.
If you look at how many VM instances get started when an Android boots, it's pretty amazing that it doesn't take 15 minutes.
Also it enabled them to piggyback on a very mature toolchain by translating from Java bytecode to Dalvik bytecode as the last thing before packaging an app. At the time, XCode had nothing like the linting and refactoring Eclipse had. If they had a similar toolchain for Danger, that would be another reason to stick to Java.
And not for any actual good reasons.
And we (Android developers) still need to suffer through their poor initial choice of platform; things would be so much better if they exposed a C API as a first-class citizen of the OS, rather than making Java the only first-class way to access Android.
In 2009, I thought the same way as you do - that C API would be better. However, I was wrong - the Java/Dalvik as a first class is actually better, Google got the possibility to be CPU-architecture independent. Today, we have ARM, Intel, MIPS implementations, that are all first class citizens. Compare that to the failure of Windows-on-ARM.
Yes, the Java language is nothing to write home about - but there is a lot of existing code written in it, so replacing that would be difficult. Designing another language that could use the same standard library, API semantics AND be effective on small devices is not that easy (for example, Scala and Clojure both bring their own large standard libraries, Clojure also runtime overhead, making them both unusable on small devices).
Just about anything would have been better than Java. I'm not a big fan of C#, but CLR would have been better. Even JavaScript would have been better. But an intermediate VM language (like the LLVM intermediate representation) would have been the best option, if CPU architecture targeting were the concern.
I do games, primarily. And writing games in Java (which is what Google tells you to do -- though they finally gave in to pressure and added the NDK) just sucks, because you have to ship the JDK when shipping on every other platform -- or you need to write your game twice.
So pretty much every major game uses C/C++ despite it being the ugly stepchild of Android. Google set up the dev environment so that you can add as many target architectures as you want, making your APK "fat", or alternately shipping various APKs with different architectures in them and letting the store pick the appropriate version. Which works, but is ugly.
C and C++ have been CPU-architecture-independent for a long time, and if they DIDN'T want to force the multi-binary approach, using LLVM to build to an intermediate language and compiling for each platform would have been an even better fix.
Intel and MIPS are not first-class citizens, by the way, because the NDK exists, and many developers still only ship ARM binaries. And while other platforms ship with ARM emulators, they're buggy: An app I'm currently working on just fails on MIPS, and there are few enough people with MIPS devices that the client decided to just not support MIPS (our build process uses libraries that aren't build using the Android.mk system, so I can't just add "mips" to the platform list).
I don't think that failure occurred due to anything other than mismanagement.
The Win8 cycle produced many things:
* An OS for desktop PCs
* Under the hood improvements vs. Win7, like faster boot
* A tablet UI
* A tablet
* A port of NT to ARM
* A tablet based on the above which could only run code signed by Microsoft
* An app store with a new set of APIs that nobody cares about
In a weird attempt to distinguish all of these bullet points they muddied the message. What was Windows 8 exactly? They produced oddities like a Windows tablet that won't run Windows programs (not even after a recompile), and a tablet UI that ran on desktops.Imagine a world where they shipped some other combination of these bullet points. Example: A laptop running ARM and recompiled Win32 apps, with a UI that more resembles Windows 7. I'd argue (and argued at the time) that would be more successful than Windows RT.
I want write-once-run-everywhere.
It's more true that GUI-heavy apps can be harder to get right, cross-platform. But it's a no-brainer for game development.
None of this applies to regular app though.
Sadly.. still programming in Java (most of the time).. but one step at a time I guess
is a clickbait site
It really seems like it was the blueprint of what Android became.
I used to play a lot with those devices, we were an small but passionate community wanting to get a full Linux on mobile. I remember people running a full debian desktop distro in a Zaurus... crazy stuff for 2004.
I've always wondered if Android had the same roots as OpenZaurus or similar mobile distros. It looks like Sharp is at least a common denominator...
Danger "v2" is Linux. True?
Microsoft acquired Danger only to eliminate competition. True?
I still remember their advert seeking NetBSD developers after the acquisition. I wonder if they ever found one who was interested?
I'm pretty sure that by the time it belonged to Google, they had the resources for proper marketing.