1) Linux, from Torvalds onward. Android used Linux as the hardware abstraction layer and still does. How many developers there?
1B) The ARM Linux developers, especially. Russell King is an unsung hero in this space.
2) The sea of subcontractors that helped with device drivers, subcomponents, integration, and manufacturing. Remember that whole "Open Handset Alliance"[1] thing? Those were all companies doing work for the Google/Android either under contract or gratis in the hopes of getting future work thrown their way or increasing their handset sales with the Google monolith behind them. I was one of them.
3) Webkit. How many developers worked on that (including Apple engineers)? OpenBinder (started at Be)? OpenGL?
They executed so extraordinarily well that Google spent lots of time in practically every version of android to rewrite core components. They finally killed the horrible DalvikVM recently.
A good proof that "Worse is better". By using a worse implementation, then gaining market share, then fixing the core architectural problems bit by bit, Android was a success. Plus it had some really good ideas in there from the beginning.
What about the underlying architecture of the OS though? Linux with a Java runtime and a new windowing layer that stops "normal" Linux apps running? Running each dalvik process in its own confined user process? What about the design for background services and foreground activities that can be switched to/from (multitasking) right from the beginning, with AIDL for implementing service definitions? What about Intents and the ability to pass messages between processes? What about access to the filesystem in a "normal" way?
What about the "desktop" on Android? Where did they copy that from?
iOS didn't have multitasking until a lot later, and the concept of background services is more aggressively policed (that is, processes killed often) on iOS, as far as I know?
Sure, the superficial layer on top (look! icons! rows of icons!) that children in a sweet shop would notice may look familiar, but underneath it is not anything alike is it?
> iOS didn't have multitasking until a lot later, and the
> concept of background services is more aggressively
> policed (that is, processes killed often) on iOS, as far
> as I know?
Ugh, of course iOS had multitasking from the very beginning as you would expect from unix kernel. The access to it from third party apps is entirely different question.
iOS had restricted multitasking exposed to apps for awhile (definitely by iOS 5) but it was restricted to certain kinds of apps: VOIP, background audio, newsstand, ___location awareness, or to a restricted period of time after the app is backgrounded.
They expanded it quite a bit in iOS 7? to all apps with background fetch, background url upload and download tasks, silent push notifications, and background tasks.
All of these approaches do not work if a user forcibly shuts down the app (I am not quite sure of every case). All these mechanisms are controlled by the OS: we'll call you, don't call us sort of thing and if you don't return in a certain period of time or if we need to, we will shut you down.
In iOS 8 you have extension support which launches mini apps. Extensions are somewhat equivalent to services but they are about integration with multitasking an implementation detail for security purposes.
>What about the underlying architecture of the OS though? Linux with a Java runtime and a new windowing layer that stops "normal" Linux apps running?
What's impressive about that? Tons of companies did something similar. Heck, OS X/iOS is Mach+BSD based hybrid kernel with a UNIX (FreeBSD/GNU) userland and a new windowing layer that "stops normal UNIX apps running".
>iOS didn't have multitasking until a lot later
Actually it did. It just wasn't enabled for third party apps because Apple is not the company to give users some non-essential feature by sacrificing something more precious at the time (battery life). Android just went for the "whatever" option, and let users deal with that.
>What about access to the filesystem in a "normal" way?
What about it? If anything its worse that it being something copied from iOS: it is the standard way of doing things carried over from 40+ years of computing.
>Sure, the superficial layer on top (look! icons! rows of icons!) that children in a sweet shop would notice may look familiar, but underneath it is not anything alike is it?
No, underneeth it's worse. More battery draining, worse responsiveness, a Java runtime they had to axe, audio latency issues, 2-3 releases to get a anywhere near decent UI, bad malware issues, etc.
But I was mainly pointing out the comment that stated that Android was a rip-off entirely of iOS at the time; it wasn't - the ability to have (battery-draining) multitasking for 'common' apps was missing on iOS. Android also introduced features not found on iOS (intents, notifications at the top, stuttering scrolling haha etc.) so it wasn't a "coat-tail-riding" exercise entirely.
I do recall the bad UI from early on; even 2.3 was pretty ugly, and every release said "now with smooth scrolling!" which sadly was lacking. The Java runtime axing is the funny one. One day Java will be as fast as C, right?
I am aware that many of the features could probably be found on Windows Mobile 6.3 or 5.0 or whatever was available at the time, but Android appears to have displaced the Windows phone market to a large extent.
This is coming from a hobbyist mobile developer, so take the following responses with the appropriate perspective:
"Actually it did. It just wasn't enabled for third party apps...."
This is, to my mind, the worst continuing failing of iOS, so bad that we see a front page HN post related to it at least once per month. Apple builds its apps on private APIs, while third parties must build their apps on inferior public APIs. Apple gets to create and use new UX, while third parties must wait until Apple uses it first. On Android, Google's apps use the same APIs my own apps use.
"Android just went for the "whatever" option, and let users deal with that."
That's funny. Apple copied wholesale the Android save and restore data bundles model that was in Android from the beginning, and said, "Look at our battery-saving multitasking."
"What about [normal filesystem access]?"
It simplifies porting. What does Apple's system gain that you can't get by alternate APIs on top of the filesystem? Nothing, as far as I can tell.
"Worse responsiveness"
https://www.youtube.com/watch?v=hPhkPXVxISY
The Android apps are running on Dalvik on year-old budget hardware pushing more pixels. In a same-generation test, I would expect the outcome to be even more lopsided.
"A Java runtime that they had to axe"
How does this matter? It's as transparent to the developer as switching from Sun's client JVM to server JVM. It doesn't require so much as a recompile, unlike on iOS.
"Audio latency issues"
This is true, but it doesn't affect 99.9% of apps, unlike the first issue I pointed out. If you're developing an app for DJs, you already know about it.
"2-3 releases to get a [sic] anywhere decent UI"
It was many more releases than that.
"Bad malware issues"
Not by default -- only if you install apps from websites (requires users to click through a dialog that tellls them it's dangerous) or use a phone with a Chinese app store. You're buying Tim Cook's lazy marketing. None of the manual testing that Apple does before allowing an app on the App Store stops malware any better than the automated testing that gates publishing on the Play Store.
Looking at allowing installation of apps from unknown sources from the other side, this lets me develop apps for my own phone for free, without paying a $99 / year tax. Even more than the private APIs issue, this is what made me jump on the Android bandwagon early on and makes it hard for me to understand why a person who enjoys software development would choose the iOS ecosystem.
>This is, to my mind, the worst continuing failing of iOS, so bad that we see a front page HN post related to it at least once per month. Apple builds its apps on private APIs, while third parties must build their apps on inferior public APIs. Apple gets to create and use new UX, while third parties must wait until Apple uses it first. On Android, Google's apps use the same APIs my own apps use.
Yeah, it's called building a stable API. Not all APIs are ready for external consumption. Apple, since it controls the APIs and their internal apps can safely build on early APIs, since they can release in sync with any changes. Third party developers not so much. This is not some conspiracy or Apple "advantage", this is software development 101.
In fact, instead of third parties "having to build their apps on inferior public APIs", iOS's public APIs are way better, and offering more than Android APIs.
>That's funny. Apple copied wholesale the Android save and restore data bundles model that was in Android from the beginning, and said, "Look at our battery-saving multitasking."
After Android emerged a full year later than the iPhone, and with the same UI and interaction model (while just days prior to the iPhone's introduction Google only had keyboard sporting, classical-looking smartphone models as their Android mockups), there's nothing that can be said that iOS "copied" from Android with a straight face. iOS/iPhone was there first, and it set the way for all the major features. Heck, Android lead members even admitted so.
That Android, years after coming into life as an iOS clone, pioneered a few things here and there (most of which Apple worked on in secret anyway for years, like battery saving techniques) is not that impressive.
>Even more than the private APIs issue, this is what made me jump on the Android bandwagon early on and makes it hard for me to understand why a person who enjoys software development would choose the iOS ecosystem.
Because there are more things to enjoying software development than "hating closed systems" or not wanting to part with $100.
I was hesitant to reply because your response (especially the unrelated copying rant) looked fanboy-ish instead of technical, but I'll give you the benefit of the doubt and see where it goes.
"Yeah, it's called building a stable API. Not all APIs are ready for external consumption."
Yet Android's APIs that allow multitasking, JITs, and sharing with arbitrary apps (instead of just the apps that Apple has blessed) have been stable too and available much longer. The stable API argument doesn't hold water.
"iOS's public APIs are way better"
As a developer, I have to disagree. Even for simple things like sharing, multitasking, default handling, and multitasking Apple's APIs remain inferior.
"[A long irrelevant rant about copying]"
Technically, the LG Prada pioneered the UI and interaction model you're talking about, but that's not the point. My point was that Android didn't use a "whatever" model for multitasking but instead designed at the outset the same save/restore transparent multitasking system that Apple adopted years later that you hold in such high esteem.
"Because there are more things to enjoying software development than 'hating closed systems' or not wanting to part with $100."
$100 per year. I have never met anybody who would prefer to pay for their hobbies when there is a free option that is just as good or better for scratching their itch.
At some stage, it takes huge talent to follow in the footsteps certain pathbreakers. At leasts successfully.
Even if android did nothing but 'copy apple' they created a second player in the space on Apple's level.
If you think this is a trivial task -- look at RIM.
The creation of viable choice and a establishment of business model that hasn't (yet) forced the implosion of the platform, is a huge amount of work even of one were to abstact away any "groundbreaking originality" (whatever that means anyway) in the platform.
Yeah, I definitely think users of both platforms have seen immense benefits due to the "copying" of features. Some of the strongest recent examples have actually been things from Android showing up on iOS like the control center toggles and replaceable keyboards.
Apple has borrowed at least as much from Android. Pretty much all the banner features in the last several releases of iOS are just catch-up with stuff Android has been doing for years.
I agree it's a pretty trite comment - unless op meant he lasted so long ".. on the robotics junket" aka exit lobby, in which case I'd agree.
Andy could be a pain but his accomplishments speak for him -- Android has long been seen as a massive success, warts and all, at the highest levels of goog.
Android is only a "success" insofar as being the only game in town for an open-source iOS competitor. I'm frankly amazed it ever gained any traction at all, but when your competition is non-free garbage like Symbian, Blackberry, and Windows mobile, I guess you can just win by default. Especially when you have the might of Google's multi-billion dollar support behind you.
Android has already gotten miles better in the year since Rubin is no longer involved, seeing long-needed improvements such as Chrome for the browser and WebViews, radically better runtime, more unified UI design, etc. Overall, Android is much better off without him and I look forward to whatever comes next (for Android, not Rubin).
That could be an indication that building a viable mobile phone OS is really, really hard.
While I'm also quite glad to see the recent Chrome/Android integration, I think Rubin should get a lot of credit for getting Android to the point where it's even worth integrating with. A bunch of competitors tried and failed; I'm glad that there's more than just Apple available in the mobile OS market.
Interestingly, the hard part is not the core "OS" code. There are many, many good open source OS's available for study (and/or license).
I realize I'm being pedantic. I think it illustrates my point: until the mid-90's, Computer Science would occasionally wish for a new OS to fix all the bad things about current OS's. Even the lack of a killer app was not considered insurmountable, because apps weren't that complex. Witness the proliferation of open source OS's.
As Android continues to dominate iOS in sheer numbers, it underscores just _why_ building a strong mobile phone OS is hard––enough that even Apple with all the early advantages still gets marginalized.
Android has:
• Open source OS (Google's/OEM's proprietary bits notwithstanding)
• Free SDK as the gold standard
• Multiple strong hardware vendors competing for the best designs and attempting to find underserved markets
• One central "authority" that champions consistentcy, interoperability, and polish (that google.com is the economic incentive to stay in charge of android becomes a strength for android––because unless another company thinks it can unseat google in their core business, they are not incentivized to try to take android from google either. Xiaomi and Samsung's Tizen may be vanity forks but other than vertical integration they have no edge in the larger android picture)
It is. But something I never understood was the choice of Java. For the original Android it made sense as it was an excellent argument for an acquisition. But since Google it was just an invitation for trouble with Sun/Oracle.
It's not like they don't have excellent runtime designers in house. They could have taken the opportunity to go with Python or something else entirely when they rewrote so much anyway.
I would love that too, but Python is a poor choice for mobile environments where every CPU cycle costs you battery life. Python code often takes up to 30x more CPU to accomplish the same work. I already get annoyed at how quickly my Moto X drains the battery when navigating or playing games; if that were 30x faster, the phone would be useless.
Now, you could argue that maybe Google should just make a more efficient Python interpreter. They did that for Android Java anyway, with Dalvik. But the design of the Python language makes it hard to optimize; witness the failure of Unladen Swallow, and all the incredibly talented engineer-hours that have gone into PyPy. A lot more happens, semantically, in each expression or function call than happens in Java or C.
CPython is not very fast, but that has nothing to do with Dalvik. When designing Dalvik from scratch they could have chosen any syntax, they didn't have to stick with Java. They could just as easily have chosen something Pythonic and ended up with something close to Groovy.
Performance was obviously not the main goal with Dalvik. If it was they would have gone with something like C++ or Go. The first versions of Dalvik was quite slow. Compact bytecode looks like the design goal which probably made sense since mobile bandwidth wasn't great at the time.
Right, they could've chosen any syntax, but they can't necessarily choose any semantics. Dalvik (and now ART) doesn't just look like Java, it behaves like Java, which means that if you're a Java programmer you can pick up Android basically immediately and have a good idea how it works. If they'd chosen a Python syntax but left out, say, keyword arguments and metaclasses and overloading of built-in operators, I doubt many Python developers would consider it the same language.
How much Java is Android, really? Knowledge of Java gets you nowhere if you want to develop apps for Android.
It may be very close to Java the syntax but it's very far from Java the language or Java the runtime. And the syntax is not really the appealing part of Java.
You don't win just by having google's pocketbook. I know some projects who wished that was true and I'm sure you do too.
You can complain about dalvik or webviews or the shitty ide or whatever, fact is there isn't a SINGLE company in the valley or Seoul or anywhere in the tech world who doesn't want to be in control of Android. How are those FB and MSFT and AMZN efforts going?
That tells you all you need to know about why Android has been and will be a "success" to google.
What was so successful about Android is the speed they pivoted as the market changed. This was, obviously, largely a response to the iPhone, which didn't stop at technology pivots, but the entire business model. This did indeed lead to a rate of development and collecting far too much crap along the way, which has been problematic since.
However, Symbian are a great example of the opposite, in the sense their development had slowed to a crawl. Things like OpenGL and anti-aliased text rendering appeared first in feature phone user interfaces, and then moved up - it was nuts. Quite how Nokia, in particular, remained oblivious to the potential UI improvements the new stuff enabled is beyond me, but then a good number of us were floored by just how bad the performance of the G1 was.
The "improvements" you mention are, with the exception of the bought in runtime, inconsequential. We've been through the phase where people wanted to use WebViews for most of the apps (I was a champion of that idea at one time) and it sucked. Do things like Google Now use the WebView for rendering their UI? Now that the lower levels are approaching good the real problems that remain are much more pervasive, causing an unbelievable amount of app developer time to be wasted (at Google too), and the sad thing is it doesn't look like they will ever be fixed because the answer will be "we're replacing them with web stuff" which is an answer no one making this stuff actually wants.
Whether intentional or not, Rubin's earlier initiative vacuuming up many of the interesting robot companies into Google, would seem to create great new opportunities for new robotics startups.
This might be a little bit of a far stretch, but based on the belief that anyone is reachable, would anyone have any leads to Mr. Rubin or would know how to make contact with him?
Google employees were implying that Andy Rubin got bored of Android and left to work on robotics and people suggesting the opposite were getting downvoted. It still could be true but looks less likely down.
Eh, those downvoted comments were from me and one was totally deserved because it was awful and I left it there to accumulate negative karma as punishment for making it. The other is a bit relevant here and was initially upvoted. It likely got downvotes by association with the idiotic comment.
Here's a more upthread link with a bit more context for the discussion:
Throwaway because I know with pretty strong confidence what went down --
The truth seems to be both (a) unpleasant for Andy and (b) unremarkable to the rest of us. In other words, it wasn't his choice, but there wasn't a scandalous smoking gun either. He just wanted what Larry wouldn't give him. Nothing that would be front page news.
I expect it might be more unpleasant for wannabe Andys. But I agree it was unremarkable. Scott McNealy used to congratulate people getting promoted with "One step up, one step closer to the door." That captured the balancing act between climbing the ladder versus being pushed off of it because someone else wanted your spot. I think Andy will be much happier in his new role, and it isn't like he has to work for a living any more :-)
"Scott McNealy used to congratulate people getting promoted with "One step up, one step closer to the door.""
God knows when I hear things like that I thank my lucky stars I don't have to work in a large corporation or answer to anyone but customers. (Well more than that obviously but at least I'm not at the whims of corporate culture.)
I am kind of hoping that it was something insane, like to be transformed into a living giant green Android, a sort-of reverse "bincentennial man" kind of story.
"Google employees were implying that Andy Rubin got bored of Android and left to work on robotics and people suggesting the opposite were getting downvoted. It still could be true but looks less likely down."
Andy definitely got bored and went to work on robots before. He even says that in the article.
As for what happened this time, no idea.
I have some guesses though, and none of them are "forced out".
Well don't leave us hanging. Let us know your guesses. I'm really interested to know. Several other people in this thread seem to know and yet are not saying anything.
Edit: I found this quote from [1].
"Jessica Lessin at The Information tweeted that Rubin wanted more freedom for his robotics group. She said he wanted a structure like Calico, which is the anti-aging company Google has started.
Our guess is that Page views robotics as something he understands better, and considers it core to Google, and therefore would not want to give it the same independence.
"
If so it seems rather short sighted for Page to let somebody like Andy Rubin leave. Rubin is self motivated,passionate,driven about what he does and he could have done great work with robotics.
My best guess is similar:
He wanted to keep independence
They were not willing to give it
He took his ball and went home.
But this is a wild guess.
Andy, from what I've heard/known, never particularly liked the "CEO" aspect of his job.
So having a more traditional structure would probably be more than just "not enjoyable" to him.
The Android team under Rubin executed extraordinarily well with a tiny fraction of Google’s engineering resources.