[oldxoog]

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.

[mbca]

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).

[nostrademons]

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.

[sounds]

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)

• Complete administrative backend (cloud, app store, PR, etc.)

[xorcist]

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.

[edraferi]

Yup, I want to live in a universe where Android is built on Python3.

[nostrademons]

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.

[xorcist]

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.

[slantedview]

Java has the biggest community of application developers, so the decision made perfect sense.

[xorcist]

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.

[mehrdada]

"That could be an indication that building a viable mobile phone OS is really, really hard."

It is an indication that giving away a viable mobile OS is really, really hard. Google was able to pull it off because it is tied to their cash cow.

[oldxoog]

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.

[fidotron]

oldxoog is right about what I meant.

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.