Andy Rubin was the major factor responsible for insecure Android devices. He thought it was impossible to be both secure and 'X' for any 'X'. Meanwhile, Andy Rubin's replacement is Sundar Pichai, SVP for Chrome and ChromeOS.
Your slander against Rubin, that he was the major factor, is unsubstantiated. And your 'X' sentence makes no sense, it translates to "He thought nothing was secure", huh?
Dan is characterizing Rubin's position around security as non-inclusive. Not that "nothing was secure", but that any feature (X) that was prioritized was done so not just without taking security into account, but with a belief that security was at odds with said feature (for all examples of X).
Basically, in a bastardized form of the "Good, Fast, Cheap. Pick two."
I don't know who was the responsible party for Android's terrible security track record, but Dan knows a lot more about mobile security than I do, so I'm hesitant to say he's slandering anybody.
heh thanks for the support and, yes, you got my position right. For anyone who might be thinking I'm an iOS fanboy or something, our company is probably harder on Apple than any other in the world with regard to security:
His attitude towards security is well known among those attempting to help make Android devices safe for people to use. His refusal to believe that a device could be both safe to use and popular or safe to use and useful has directly led to hundreds of millions of unsafe devices around the world.
You couldn't be more wrong and, unfortunately, I don't have the karma yet to enable downvoting :-). Easy example as long as we're on the topic, the Chrome browser or ChromeOS.
I can think of a dozen things that could be done to Android to both mitigate against current threats and exploited weaknesses and either not interfere with or improve user experience. Unfortunately, we are long past the point where fundamental architecture changes can be made to Android. We are stuck with a system that allows execution of downloaded code at runtime, that never updates, and that blames the user for security problems. Android would have been wise to adopt some of the best security decisions from iOS.
Please be humble, when you have the capability to down vote comments in the future and think of the humbleness from the HN Guidelines and this particular part: "When disagreeing, please reply to the argument instead of calling names." (Albeit, you're not calling names - but threatening to down vote is a little bit uneasing.)
The usability of the browser is severely hampered by the security requirements. For one, it necessitates running code downloaded from the web in a sandbox, which prevents it from interacting with the rest of the computer in a meaningful way except through narrow channels designed painstakingly by committee.
The web would be a much more interesting place if we could hook up arbitrary peripherals. It's holding back the entire world from developing better computer interfaces.
>The web would be a much more interesting place if we could hook up >arbitrary peripherals. It's holding back the entire world from developing >better computer interfaces.
Im enginering something, that was a spinoff of this thougths.. i 've go an answer balancing the good parts of the web with the good parts of the app platforms.. plus some concepts of biological cells..
it may be a party for google, apple samsung and the like.. but we technological people are back to the nighmare that were the 90's.. with multiple platforms.. and thats the only reason browsers became popular..
even when we were loosing so much..
here we are into the nightmare again.. have to create things for multiple platforms :(
I think Google can fix many of the security issues with Android, even at the cost of breaking compatibility. They will presumably try to merge Android and ChromeOS, and taking more of the ChromeOS security model on tablet/PC-form-factor devices makes sense.
You manage to say a lot while saying absolutely nothing of value. That sounds harsh, but seriously thus far you've said that Andy Rubin is to blame for <something vague and unsubstantiated> because <something vague and unsubstantiated>, and Android has <some unstated fundamental security gap> versus <some other alternative>. I don't think I've ever read such an absolutely and completely unsupported comment chain that wasn't sitting deep in negative territory on HN. And seriously, the nonsense tweet by Schiller (who would have known that Apple would toss barbs Android's way?) is why you think Rubin moved on? Give me a break.
Android has a deeply secure design that runs each process as isolated, low-privilege users, needing to request services after passing through fine grained permissions. Do you contest this? Architecturally Android is much more secure than iOS.
The only issues remaining are getting security updates out quickly, though in actual practice this has proven to not be an actual problem (somehow people imagine that if a device is on Gingerbread that also means security patches can't be deployed, I guess having never worked in branched source control systems), and better vetting of the Play store (which will come. The Play store can be both vetted and agile/inclusive. They need to block the bullshit). Neither of this are the apocalyptic "that ship has sailed" nonsense that you are parading.
If you think that Android has a "deeply secure design", than then you probably want to start at the top. Android sits somewhere between "gift to hackers" and "Windows XP". Phil Schiller's tweet was pointing out the consequences of this and how it shows up in successful attacks performed against the Android platform. F-Secure, even though they're an AV firm, does good work once in a while :-).
First, Android hasn't solved the updating problem. It's getting better but at far too slow a rate. Every day, hundreds of thousands more devices that takes month to years to patch are entering the market. Furthermore, poor patch management by OEMs and carriers mean that sometimes they think they've patched when they've really rolled back updates. They do this unknowingly because their software deployment processes are abysmal. See http://www.xray.io for more info.
Second, Android exploit mitigations are very, very weak. It lacks code-signing, one of the strongest mitigations available (just go ask an iOS jailbreaker). Apps have access to a shell. The Linux kernel is full of infoleaks that make kernel ASLR nearly useless. App Permissions, though many people think they help with this problem, actually have nearly no effect whatsoever on the ability to root/jailbreak/privilege escalate on Android. This is what I meant by "blaming users" for security problems, since so many people fall back on "educating" people not to allow apps with certain permissions even though, ironically, it does nothing. End effect: even if Android could patch, rooters will write new exploits when they need them, as they need them. It's getting harder, but it's nowhere near where it needs to be and we're on version 4 now.
Third, Bouncer has a severely limited ability to impact this problem. Due to the lack of code signing and the overall architecture of Android, Bouncer can't ensure that the app that it scans is the app that runs on the phone. Apps can dynamically update their own code at runtime. Bouncer appears to rely principally on dynamic, rather than static, verification leading to tricks you can play with timers and environment detection (these attacks have been proven). Further, what about third party appstores? There are dozens out there and you can't just say that they're all second-class (third?) citizens that deserve to get 0wned. 3rd-party appstores are supposed to be a key feature for Android, but they're unsupported entirely by these controls.
If you wanted to develop a mobile/embedded platform to bring a new generation of users onto the web and into your customer base, you should have spent about 5 minutes figuring out how to do it without opening them up to harm. Android is the way it is because it wasn't believed these design features (aka safety) couldn't be included in the beginning.
> First, Android hasn't solved the updating problem.
Sure it has - buy a nexus device, get updates. The rest isn't Google's problem as they aren't Google's devices.
> It lacks code-signing
Wrong.
> Apps have access to a shell.
So? The shell they can access can't do anything the app can't. That's like saying apps can run code - no shit, what's your point?
> App Permissions, though many people think they help with this problem, actually have nearly no effect whatsoever on the ability to root/jailbreak/privilege escalate on Android.
Of course they don't, because those are completely unrelated. iOS's code signing and other stuff hasn't stopped it from getting jailbroken. Complex systems have bugs, who'd have guessed it?
Also rooting is an actual feature on some Android phones (such as all Nexus ones) - not an exploit.
> Apps can dynamically update their own code at runtime.
Yup, and as a result Android users get to enjoy real web browsers, for example. And languages with JITs.
> If you wanted to develop a mobile/embedded platform to bring a new generation of users onto the web and into your customer base, you should have spent about 5 minutes figuring out how to do it without opening them up to harm. Android is the way it is because it wasn't believed these design features (aka safety) couldn't be included in the beginning.
Wrong. Android is easily the most securely designed OS out there that still allows side loading, period. Not claiming it is the most secure, as there are obviously bugs, but the most securely designed. Desktop OSes are incredibly bad here, and iOS only manages to prevent it by stripping you of all your freedom.
I'm getting tired of this. If you want to stick your head in the sand and ignore the data, then fine. Try and ignore this: 50% of all Android devices have unpatched vulnerabilities for which exploits exist.
Firstly, the updating problem is a distribution flaw, not a design flaw. The carriers are to blame for that.
Secondly, code-signing is a very restrictive approach and is hardly without tradeoffs. If you're going to use iOS as an example, it strongly discourages casual development for a slew of reasons, and there are countless examples of Apple rejecting apps for arbitrary reasons, far beyond issues of malware.
Your third point is really only an extension of your second.
Maybe you don't personally feel you've had to give anything up for the security that iOS affords, but it's disingenuous to assert that there aren't any tradeoffs at all. Android's more open approach is more true to its open source roots. For it to be different than iOS gives us choice, which is a good thing.
The updating problem is a design flaw they knew they would have to deal with and that they did nothing about until version 4, when they started trying to separate core functionality out into apps. That's not acceptable.
Code signing can be implemented while still allowing for casual development. See my comment above about the hardware switch on ChromeOS devices.
My third point is regarding how the architecture of the platform complicates the ability to analyze apps that run on it for malicious behavior. The NDK, the access to the Linux kernel, and a strategy based around dynamic analysis were all design choices that impacted that.
I understand that Android wants to be more open than iOS but you're making the same mistakes the Android team did. Namely that there's no way to deploy the same or similar security improvements without sacrificing something else. It's just not true.
If Android didn't have side-loading, the capability of having third-party app stores, and access to the shell (to the point of being able to run a terminal), I would likely not be using it. The more PC-like it is, the more usable it is to me, in the medium / longer term, as devices in tablet form factor replace mobile PC use cases.
There are safe ways to enable access to it. Take ChromeOS for example, which has a hardware switch on the outside of the device that "jailbreaks" it and allows access to these features. Lack of such creativity by the Android team with regard to security has had a major impact on their current state.
>Android sits somewhere between "gift to hackers" and "Windows XP".
It is hard to take you seriously.
Let's be clear that the malware problem on Android aren't apps exploiting any weakness in the platform itself beyond the simplicity of pushing apps onto the market. They aren't exploiting that devices are running Gingerbread or anything like that.
These are apps doing exactly what they are allowed to do by the system -- after advertising their intentions and doing exactly what they declared that they could do -- but they are malicious because the things they are doing aren't in the best interest of the user.
e.g. an ostensible puzzle app that actually sends contact information to a third party (after declaring and getting permissions for contacts and internet access), or that sends pay SMS' to Nigerian sex operators, again after declaring and getting permissions for contacts and internet access.
When anti-virus vendors and please-pay-attention-to-us tiny security upstarts talk about malware, that occupies 99.9% of the space (if not 100%). It is a trust and validity issue with Google and the Play Store that requires much better vetting and culpability of developers, and vetting of applications (not in the "don't do anything that overlaps us" manner of Apple, but simply to validate the scope of functionality, fitness for advertised purpose, and lack of clear trademark and copyright infringement that is so prolific on the Play store).
That has nothing to do with the platform and everything to do with one store.
You clearly didn't read a single link that I posted. I did a comprehensive study of all malware targeting mobile devices between 2011 and 2012 and, yes, they are targeting the device itself and the design choices made while building it.
EDIT: oh wait, there you go blaming the user again. "Grandma should have known the difference between THIS app that requested her contacts and THAT app that requests her contacts and stole them. Jeez Grandma! Get with it!"
How is that not a design problem? I thought we gave up delegating security decisions to the user after we saw what happened with SSL?
EDIT: oh wait, there you go blaming the user again. "Grandma should have known the difference between THIS app that requested her contacts and THAT app that requests her contacts and stole them. Jeez Grandma! Get with it!"
No, I didn't blame the user. I pointed out that most of the problem with malware on Android, for the overwhelming majority of users (who don't sideload), was that the Play store is a wild west right now, where people pay $25 and make an account where they can instantly publish "Temp1e Run" that is actually nothing of the sort. This is the cause of the overwhelming majority of malware on Android.
Should apps be able to have those specific rights (such as sending pay SMS')? Yes, absolutely they should. The ability for apps to do more interesting things is exactly what differentiates it and makes it better. Simply saying "keep every app in a silo where it can't do anything" is not a choice users want.
EDIT: And just to loopback again, you again claim that malware needs to somehow break the bounds of the Android system to do its evil deed (exceeding permissions, cracking ASLR, etc). That is absolutely untrue in practice. Malware on Android, courtesy of the practically unmaintained primary market, is largely a study of social hacking.
Surely some security comes for "free". My iPhone has military grade encryption, but all I see is a 4 digit passcode. If I shut it off, however, and have the 10 max attempts, then it's virtually impossible to break in (without other data, e.g. smudges where the passcode numbers are).
In any case, it should be a tradeoff the user controls. People have drastically different needs, think OpenBSD versus Windows for a usability/security tradeoff.
What's your benchmark? If you have access to the hardware virtually everything can be jailbroken. With the iPhone, however, you can't do it non-destructively (i.e. you can't get personal information). At least that's my understanding, if I'm wrong please correct me.
The original user-friendly jailbreaks worked by pressing a button on a website. That means that any website could use the same technique to run native code with root privileges on your iPhone. I'm not sure how much physical access is required for current jailbreaks.
IIRC it's been years since that's been possible, recent attempts seem to all fake a software update/reset via host computer connection. I'm not saying the iPhone is anywhere impossible to break into (I'm sure, like all OSs, there are vulnerabilities that allow access exposed to the user that have not been found yet), but because the apps are sandboxed, hackers need to break into software and then out of the sandbox (probably into kernely memory, again, but possibly just into privileged system access to the file system). The iPhone is certainly far more secure than most desktops because of this, and I suspect that because of Apple's control over it, the chance of your iPhone getting accessed without your permission is miniscule.
However, I am no mobile developer, so take this with a grain of salt.
Not to mention that Chrome has figured out how to push updates, while a majority of Androids are still running a version released over two years ago. If Google can start pushing auto-updates to all of its devices, that would be one of the greatest improvements ever made to Android.
Also, one of Chrome's most touted features is performance, which has always been Android's weakest point. Hopefully he'll be willing to assign more people to the task of making Androids work as smoothly as iPhones.
Much harder for an OS than an app. Phone makers have their own custom set of drivers for driving their unique hardware and these often have to be changed in subsequent releases to deal with changes to the hardware abstraction layer. And even for releases that don't change the exposed hardware abstraction layer it can be really difficult to know if each phone maker's drivers will deal properly with subtle changes to the underlying OS.
This is not an impossible problem to mostly-solve, but it is orders of magnitude harder than what Chrome browser has to deal with.
Exactly. I mean, Chrome itself (being an app) is pushing updates on android at a cadence now that almost matches what they are doing on the desktop.
Doing hardware integration is a lot harder than writing an app. I wish more app developers recognized this.
(That said: I do think Google could have done a much better job at separating out the true kernel/HAL/BSP layer stuff, which needs to be done per-device, from the framework layers that are largely device-independent. There's no reason to force a full hardware test just to push an fix for the Intents framework or whatever).
Performance is part of the Chrome brand and supporting 2.3 would only serve to weaken that brand. It would also require a monumental engineering effort.
Can you be more specific? There is no reason for Chrome to use the platform WebView on any Android version supporting loading native libraries.
Are there OpenGL limitations or something else blocking Chrome from running on 2.3?
I also have heard carriers generally do not allow it (i.e. software makers pushing updates without the carriers permission). I have heard the reason is basically support costs. If they have not had time to test and vet your update against all the models running on their network, and you brick a phone (or a million), those customers are calling the carriers and they are probably pissed. They wouldn't know how to contact Google even if the thought of doing so wasn't so laughable.
> Not to mention that Chrome has figured out how to push updates, while a majority of Androids are still running a version released over two years ago.
The reason for the hold out is the carriers, not Google. Google is very good at pushing updates to phones when it's not limited by the carriers (and Android implemented over the air updates years before anyone else did. iPhones still require cables to be updated).
> The reason for the hold out is the carriers, not
> Google. Google is very good at pushing updates to
> phones when it's not limited by the carriers
I didn't imply it had to be a technical solution. If users can't update their phones that run Google's operating system because Google isn't leaning hard enough on the carriers, then Google needs to fix that.
Apple has managed to strong-arm the carriers into letting it supports its customers, and Google's market position isn't too much weaker than Apple.
> iPhones still require cables to be updated).
iOS has supported OTA updates since iOS 5, which was released almost two years ago.
Android ought to update like Chrome: silently downloaded via Wifi (optionally via 3G/4G), installed in the background to whatever extent possible, and then show a reboot prompt only if needed.
Android is a Linux distribution, so most updates ought to be possible without having to reboot the device.
Chrome's auto-updating has broken flash for me several times. The auto-update arrow icon seems to turn from green to red to brown (?), and once it's past green, flash stops working, more or less forcing me to restart it.
It's pretty much the equivalent of forcing a reboot of an OS like Android.
I'm led to believe there's some kind of regulation preventing phones from updating without user intervention, given the 'you will not be able to make emergency calls' prompt most phones seem to show on an update.
The day Google auto-pushes a new OS to my phone is the last day I ever use any Android device. It is my device, not theirs, and I will decide when and if I will change its OS.
I think you're probably right, and this was one of my biggest problems with the Android platform. He did a lot of things right, but was completely wrong about security, and from what I've heard, actively stood in the way of the Chrome/ChromeOS people improving Android security.
> But his insight immediately struck a chord because at the time it was extremely painful developing services for mobile devices. We had a closet full of more than 100 phones and were building our software pretty much device by device. It was nearly impossible for us to make truly great mobile experiences.
This is highly ironic statement given that one of the biggest pain developers trying to build mobile experiences face today is the number of devices they have to test on, and that Android plays no small part in making it worse.
The drawer/closet you have, full of all those test devices? it's called the "Drawer of broken dreams."
Device fragmentation on Android is nothing like fragmentation used to be. At least on Android you can write one app and then tweak it to work on different devices, previously you had to write apps as different as Android/iOS/Windows for each device - and often individual manufacturers even had multiple platforms to write for.
And don't even get me started on distribution. You used to have to negotiate with carriers in each country to get them to carry your application. Now I publish on Google Play and my app is available to 750 million people four hours later. And if you build a good app, and figure out the app SEO, you will get hundreds or thousands of downloads a day.
>At least on Android you can write one app and then tweak it to work on different devices, previously you had to write apps as different as Android/iOS/Windows for each device - and often individual manufacturers even had multiple platforms to write for.
>So I think we owe Google some congratulations.
Before Android, you could write a Windows Mobile app and have it run pretty much on every Windows Mobile device and the same with Blackberry and iPhones.
The biggest problem with Android is that the OEMs and carriers abuse the open nature to make their own custom skins which are not compatible with updates. Google did not take a hard line on this like, say, Windows Phone did
Also, to be more serious, Pocket PC once ran on top of two processor families, so if you think fragmentation with a VM is bad, it's a lot worse when you have to build two binaries and try to explain to users which one they need to install.
The Holo theme is required to be present on all devices that wish to carry the play store. If you write an app targeting 4.0 or higher that uses the default theme, it will look the same across all phones.
> However, you will lose the 2.3 users, who still hold a ton of market share.
Like with all massive ecosystems, change in the android world takes time. Google is addressing the problem and solutions, like instituting a required theme, are rolling out.
Give it a year, maybe a year and a half, and the need to support 2.3 will be much less pressing.
No it isn't. The GP isn't saying people buy the phones for the crapware, the GP is saying that the carriers wouldn't have adopted it if they couldn't put their bloat on it.
While Apple was in a very strong position, the carriers had a strong interest in another player to counter Apple's market power. In the case of fragmentation, I think Google was just more willing to negotiate away things like this in the interest of getting a strong presence on the devices.
So you mean Google picked popularity over consistency and sold out to the OEMs and carriers for the sake of marketshare? Android is the pretty much the only OS where this is such a big problem, unlike Windows, OS X, Windows Mobile, Blackberry, Windows Phone, iOS and probably even Linux.
I don't know where you get your information from, but Blackberry has broken compatibility in the last 3 OS releases, and Windows Phone 8 doesn't even run the same kernel as the previous version (breaks compatibility). I'm not sure if you ever touched Java ME back in the day... but yeah. You're just wrong on this one.
>Windows Phone 8 doesn't even run the same kernel as the previous version (breaks compatibility)
Windows Phone 7 apps run fine on WP8. Anyway breaking compatibility is a tad different from fragmentation. If your app runs on a WP7 phone, you can be reasonably certain it runs on all other WP7 phones. With Android, you can easily run into device specific bugs even though the version is the same and thus you're forced to test on the real hardware devices.
> Before Android, you could write a Windows Mobile app and have it run pretty much on every Windows Mobile device and the same with Blackberry and iPhones.
Considering that Android pre-dates the iPhone (and thus iOS), the statement isn't accurate. This article cites 2004 and the iPhone didn't debut until the middle of 2007. It was indeed a nightmare, not only in the development process but in distribution. Good luck getting your app widely distributed across platforms/countries/carriers.
I remember being at CES around this time and the Google guys did a keynote where they made it a mission to get rid of all the different charging standards in use at the time (every phone was different, remember having to find a charger that worked for your phone?). It was a whole different game back then.
Note that 2007 is the iPhone's public debut. The project was started in 2004 [1]. Android the product was also announced in 2007, after the iPhone, although the project indeed started before the iPhone, in 2003 [2].
There weren't a lot of Windows Mobile devices. What usually happened back then was an app would get written once, then outsourcing companies would be hired to port it to the 50 popular feature phones or whatever that made the majority of the market.
Did windows mobile ever really have a wide variance in hardware types, e.g. phone size devices vs. tablet sized devices? It was my understanding that windows mobile targeted certain screen resolutions (that or those resolutions were the only ones manufacturers were producing) and that was pretty much it.
This is clearly the comment of someone who has not used Android recently, and only occasionally reads articles about what is going on in the space. Enjoy your koolaid...
That's a very narrow perspective, based solely on what is "painful" for the developer. Developer pain isn't, generally, a good indicator of the public good.
Obviously the real driver for "fragmentation" is that there exists a market which is (1) lucrative and (2) easy to enter. So everyone rushes in with their devices and competes. And somehow you think this is a bad thing?
Stated simply: "fragmentation" is a side effect of "market efficiency". The reason almost everyone (for the appropriate definitions of "everyone", of course) in the developed world has a smartphone (be it an iOS one or not) is precisely because of this efficiency. And you can't have it without a little fragmentation to go along with it.
Basically, your utopia where everyone uses one device not only doesn't exist, it can't exist.
I agree with the efficiency part with regards to android lowering the Barrier to Entry, but the 2 year contract to make the devices "affordable", surely doesn't work in favor of market efficiency.
Certainly there are factors that work against efficiency. Any kind of lock-in, be it an enforced contract term or a putative monopoly position for Apple is going to harm things. But on balance, Android being cheap and easy (and thus fragmented) has made smartphones cheaper/better. I don't think there's a serious counterargument to be made on that point.
My N4 out of contract from google wasn't that much more than say an S3 on contract... My last three phones have been off contract with cheap all you can use reseller services... the lower month to month makes up for the price difference in 4-6 months
I think you are missing the point of Android. Android starts with the premise "fragmentation exists, how do we make the best of it?" and goes from there. The idea that every person on the planet is going to use the same phone with the same capabilities and the same size screen is a fantasy world iOS developers live in.
> The idea that every person on the planet is going to use the same phone with the same capabilities and the same size screen is a fantasy world iOS developers live in.
I was under the impression the problem with fragmentation was along software lines—i.e., not many people have the latest android, so people can't exploit it. Hardware is much easier to adapt to.
>fragmentation exists, how do we make the best of it?
>The idea that every person on the planet is going to use the same phone with the same capabilities and the same size screen is a fantasy world iOS developers live in.
There are a billion plus PCs running Windows with various hardware, screen sizes and even different form factors. Yet fragmentation is not as big a problem as on Android.
Your evidence for app incompatibility is... variant icon art and placement on a bunch of pre-ICS phones that aren't sold anymore?
I mean: it's true, Google failed to enforce a layout for the original Android buttons (Home, Menu, Back, and Search). And device manufacturers put them in different places (sometimes omitting Search entirely) and used different art, and that was bad. And Google fixed it with ICS (a year and a half ago!), which uses soft buttons exclusively. So sure, it's a valid point.
But to argue that somehow you can't write a compatible app because Samsung put the back button on the other side from Motorola is just ridiculous, sorry. Get a better example.
Microsoft required an illegal monopoly in order to obtain the incredible resources needed to certify Windows on all that hardware. And the prices were astronomical, for PCs, peripherals, etc.
The kind of fragmentation Google has to deal with in developing Android and its framework is very, very different from the kind of fragmentation the average app developer deals with. The vast majority of apps only need to test on a couple different device types, all of which can be done via the emulator. Most app developers have trouble with the APIs their apps use that do not behave as expected on some devices, usually as the result of a manufacturer or carrier change that subtly alters the behavior of or breaks the API.
Google, OTOH, has a significant amount of testing to do on most Android devices produce. Not only do OS devs need many devices to ensure the OS and framework continues to function, but most (if not all) devices will be run against the Android CTS (http://source.android.com/compatibility/cts-intro.html).
Having been working in the Android space as a programmer, IMO the idea of Android fragmentation is mostly overblown these days. It was more of an issue in the past, but post-Gingerbread it has ceased to be a practical problem for any dev work I've done.
This isn't to say Android development is wonderful, it (often) isn't. And I've been increasingly concerned with the amount of "OMG HOW?" bugs that have been introduced into the Android OS and frameworks over the past few releases, but generally speaking the code you write for one modern Android device runs (or breaks due to OS or framework bugs) equally across all the phones, at least those that (legally) ship with the Play store.
I think testing on a closet full of devices is a huge improvement over making unique implementations for each device in said closet, and THEN testing each implementation. Still a schlep for sure, could be improved a ton. But progress is progress.
Sort-of thank you to the mod who changed the title. The old one ("Google lets go its (sic) Android head Andy Rubin, appoints Sundar Pichai") was editorializing and incorrect, but the new one ("Update from the CEO") is completely useless.
On a related note, I find it rather fascinating that Andy is planning on staying in Google.
Andy’s decided it’s time to hand over the
reins and start a new chapter at Google.
I also think he could do a great job leading the nexus program or something alike in motorola, but I feel he'll just hang around for a little while so as not to create much fuzz before leaving google entirely.
> Sundar will do a tremendous job doubling down on Android as we work to push the ecosystem forward
This is really incongruous. You don't move a project from having a dedicated top level manager to being one-of-many under someone else as a way of "doubling down" on it (what an awful expression). It makes no sense, if Google sees Android has having future in its own right as one of Google's top priorities, that they put it under management with somebody with so many other priorities.
I can only conclude that either a) Sundar is a temporary replacement while they locate someone of Andy's stature as a replacement to lead Android in its own right or b) Google has charted somewhere far in the future that Android will get folded, substantially merged or otherwise share some kind of significant synergy with the other projects that Sundar Pichai is in charge of.
I find b) quite worrying because it signals an end to the (healthy) competitive tension that Google promoted internally where both Android and ChromeOS were pursued as independent ventures and "may the best man win" would determine the outcome. I also find it worrying because no matter how they spin it, I don't see how this can not seem like a blow to the esteem of the Android team - they've effectively been taken over by another division, effectively falling down one step in the company ladder. To have that happen after establishing one of the most incredible technology success stories in history - I can't imagine how deflating that would be to the team members. I hope Android doesn't lose a lot of talent from this. A huge amount is going to depend on how well Sundar Pichai handles this transition.
New Pope, New Head of Android--a wonderful correlation...just kidding.
It's an obvious move to try and blend Chromes OS with Android more seamlessly but I think it also means something else BIG at Google is coming--and not their everyday-'big'. As qualified as Pichai is, it doesn't make sense for Rubin to go anywhere UNLESS he truly is upto something groundbreaking.
My bet is that Rubin has a vision, perhaps a "moonshot" as Paige said, that impressed the execs at Google so much that it made sense for him to move on from his current position. It'll be interesting to see exactly what this is, but I have to imagine Rubin is upto something the masses (most of us) have not yet heard about...and his ingenuity will be absorbed by Google themselves.
I suspect that Andy is not in fact staying on at Google but instead this is a golden parachute in which he will pretend to stick around as "a consultant to the CEO" before leaving.
Wouldn't the announcement mention Andy's new role even if the project could not be named? Without mentioning his plans, it leaves open questions like these, which does not make Andy look good.
I never really understood this sort of thing. Why would he stick around and do nothing? To "save face"? And if he is not being useful why do they want him around or play along?
Might be sort of like a non-compete period. Instead of being contractually bound to not compete for a period after leaving a company, which isn't always enforceable, pay the person enough to stick around for a while, perhaps with limited access to information about upcoming products.
“We’re getting closer to a world where technology takes care of the hard work—discovery, organization, communication—so that you can get on with what makes you happiest… living and loving.”
Just lie back and let yourself sink into the goo. Don't worry about all that messy technology behind the curtains. We've got that taken care of. Have a nice day :)
There are lots of Indians in top Google management, definitely, but they're hardly the majority. Maybe 25% of "key divisional leads", maybe 25% of SVPs (a group that greatly overlaps with "key divisional leads").
First of all, there's no "key divisional lead" of "engineering". That's not a division at the top level. That'd be a pretty stupid top-level division, in a company which is mostly engineering (I'm deliberately obfuscating exact ratios).
Second, the SVP of Ads is Polish, and the SVP of Youtube is Persian. So that's two more things wrong with the four examples.
Indian: Chrome/Apps/Android, G+, and Sales/Business.
Not Indian: Ads, Search, YouTube, TechInfra, Finance, Legal, Sergei (a law unto himself), Geo/Commerce, Motorola, HR, PR, .....
In short, who the heck is Benedict Evans, and given that he is gibbering, why are you quoting him?
Yeah, I too can find no publicly available org chart. I was careful to restrict myself to public information in that comment (except, I guess, "engineering is not a top-level division").
"Nikesh oversees all revenue and customer operations" - revenue, and more.
Two SVPs are listed for specifically for engineering, both Indian.
Android and Chrome, obviously. And there is no bio given for Salar Kamangar, Youtube, which sounded as thought it could have been an Indian name but obviously wasn't.
That's quite a high proportion of Indian people in senior positions, don't you think?
Beyond that, you're getting very upset by minor lack of precision in a tweet, of all things.
It couldn't have anything to do with the fact that Apple's 20 years older than Google, Apple has had really good retention, and the make-up of the Valley has changed dramatically in that 20 years? The implied racial dig is beneath HN.
EDIT: Another thought: Google has also done a huge amount of its growth through acquisitions, whereas Apple has done very few. That likely further pushes Apple's leadership to "old-school" people in the Valley: they haven't brought in large numbers of executives of smaller companies that effectively start at the middle-top in Google.
This is an interestingly timed article. We're building our Android app right now, and its certainly more annoying than when we built out iOS app.
As an app developer, in Canada (not Canadian however) i'm excited that RIM have attempted to prevent further fragmentation by sticking close to the Android stack, however i really don't want to deal with the distribution and other issues (such as screens, OS bugs etc) that i'm sure will come with releasing on a 3rd platform.
I feel like we're dealing with the issues similar to what were encountered during the 17-1800's with different size railway tracks. Is it just a matter of time until we agree upon a standard?
> however i really don't want to deal with the distribution and other issues (such as screens, OS bugs etc) that i'm sure will come with releasing on a 3rd platform.
Is this better or worse than developing for a completely different platform (i.e. BB<10, WP7/8, etc)?
I think its better for sure, but i'm sure there will be bugs that only exist on Blackberry and those that only exist on Android. I suspect that eventually we would (will...) end up with two builds anyway.
Overhead, it would be great if Blackberry could just start making Android phones...
Whether Android and ChromeOS are merged or Android scales up to the desktop, I hope Google makes a big play for the desktop within the next 1-2 years.
1. Microsoft support for Windows XP ends in about a year leaving a huge chunk of their users orphaned.
2. PC sales are flatlining... there's a sense among users that performance is getting to be "good enough"
3. Apple isn't really even trying to compete in countries that aren't somewhat well to do.
4. The ARM Cortex-A15 will help bring those ARM mini-pc sticks and net tops up to task for desktop work.
The "open source" posturing is very annoying. They're just doing it for the PR.
Even considering the subset of Android that is "open source" the development process is closed and we just get code drops after product releases. It's like Apple used to do when they were playing the game with Darwin. They're doing a lot of work to avoid and purge LGPL and GPL code so they can work this way. It's not even free to use for vendors, you need to pay licensing fees to get a useful system out of it and sign contracts subjecting you to Google's whims.
Wait... where is this post saying what's going on with Andy Rubin? Let me understand: you have a guy that leads one of the most adopted projects coming out of Google and then you announce a new person to lead that project without mentioning anything about the former? That should be an awesome feeling for everyone at G...
Rubin is someone who, from his days of running a BBS in New York many years ago, to creating and working to expand Android more recently, has always had a strong alignment with the values of free software, hackers and hobbyists. Over two decades ago he praised those who "write their programs for the hobby, for the hack". His commitment and his efforts for open source software and open platforms have borne fruit with an open platform which accounted for over 70% of smartphone sales in the fourth quarter of 2012. I am grateful for his efforts in this regard, especially since I have been focusing on writing Android apps for the past few years.
I know something for sure and that is Java is not the future of Android. Android will run web apps in future. In makes sense in many different ways:
- Google is a huge pusher of web platform. They want it on mobile.
- They are pushing new APIs to HTML5 everyday to make it more suitable for mobile
- Google is the only one that can make real mobile web apps a reality
- Did you ever see that metal android status in Google campus? They want choromize the Andriod
I really don't understand the attraction of "making the one thing."
Chrome/ChromeOS and Android are very different. Neither is going to supplant the other.
They also have some clashing goals: Chrome wants to be more security paranoid than Android. In theory Google can find Android malware authors, cut them off from access to Google Play, and kill bad apps in the field, while Chrome is exposed to both malevolent and hacked Web sites.
I see harmonization as more of a product management activity than any particular technical choice.
Another way to look at it is that Android was a home run and basically accomplished everything it was supposed to do, not much left for Rubin to accomplish.
Sure, it's probably achieved everything it was meant to - like Google probably had when they first became the top search engine. I really doubt anybody is leaving because of that though, it's certainly not perfect, and it's certainly not achieved everything it can achieve. In fact, it probably hasn't achieved everything it is meant to achieve now. Goals aren't static, nobody's going to leave because there's nothing left to achieve with Android.
This is an unusually bleak and uninspiring message. Reads like a mundane press release. An average update from a small startup founder is more exciting.
I would've preferred Vic Gundotra to take the lead of Android. He's a much more "experience" kind of guy, and a great speaker, too.
But I guess Sundar Pichai isn't a bad choice, either, especially if they plan on unifying the 2 platforms. But he's still more of a "core" product guy, than a human interface guy. I just hope he at least leaves Matias Duarte enough independence.
My read is that Pichai is a really good at ops, and the experience stuff will be left to Duarte. It seems like a good partnership to have on the Android boat.
In particular, page rendering and repaints appear noticeably faster in Chrome than in Firefox of Opera. However, I notice the difference more on Linux than I do on my Windows machine.
Come on. Few nerds like us are concerned with benchmarks and perceived performance. Most people don't know what a browser is or what's their preference in the matter, they just use whatever is installed.
Given the same base OS (Linux) in Android and ChromeOS and much of the same sorts of things. The redundancy of having two teams is pretty obvious. So if everyone agrees that you're going to do both going forward (and I think this is a ringing endorsement of ChromeOS as a 'long term' bet by Google) it only makes sense to make one team out of them.
Then the question becomes who leads it? The guy who leads ChromeOS or the guy who leads Android? Andy wasn't a big fan of ChromeOS when I was there, I don't know if that changed, his passion was making a better phone experience. I don't think I ever talked to or hear Sundar speak when I was there so I don't know what he thinks about phones.
So Sundar gets the nod and Andy gets to pick his next role (or exit which isn't uncommon in these situations). I don't doubt Andy would be on the short list of a number of CEO search committees so perhaps he'll pop up as the new CEO of Sony or something.
I would imagine it could start by eliminating bionic, which seeems designed primarily to keep hardware OEMs happy that everything is under a weak (BSD style) license.
ChromiumOS uses a standard Linux libc (probably glibc) and is more compatible with commonly available userland software and the newest ARM hardware and ABIs.
The Chromium build system is also more suited to building an OS than a Java application.
I'll assume that Dalvik stays, and that the Android API is supported.
The Android window manager is pretty powerful (actually underutilized on phone form factors, as it supports movable frames and overlap, though that is not apparent from using it. Chrome has it's own window manager, as well as it's own desktop UI.
One question might be what direction Google TV goes in, possible with a more exclusive partner arangement. Does it make sense to build Google TV apps on Android, or should it move to more of a web model using Chrome? (This isn't neccessarily assuming that Google TV survives as it's own product line).
I haven't seen what information has been publically released about Google Glass development, but it's UI could be accomplished equally with Android or Chrome underneath, and eventually it makes sense for them to be webapps.
Another possibility, seemingly out there, would be for Android to move towards a WebOS/FirefoxOS model where core applications are built using HTML and interfacing with exposed libraries, but Android apps would still be first class citizens.
I think this may sound crazy but android's days as a apremium OS are not as secure as they seem. Take Samsung out of the android picture and you will see that there is barely any device maker that is leading charge.
Add to that the pressure brought on by Microsoft which runs almost the same version of OS on its phone and PC. This will allow them to innovate much faster. Google wants to be there. So even though the brand name will stay, Android as n OS will evolve to what is Chrome today. Completely controlled by Google.
I'll take that bet. Instead I think it's going to happen the other way. Chrome is going to be more tightly integrated into Android. Eventually the Play store will contain Chrome Packaged Apps that appear to the user no different than the Java apps. Chromebooks will remain untainted. They'd be giving up too much security wise by allowing native apps on Chrome OS, one of its biggest selling points.
ChromeOS is going nowhere, it's currently the best OS option that is able to turn a PC into an instant-start, always-connected "appliance" where end-users don't need to care about the mundane details of using a PC, e.g managing files and folders, backing up, syncing, updates, security and virus-scanning protection, etc - everything runs in a sandbox, gets updated automatically and "just works".
I think there's no point in carrying forward ChromeOS ahead, when Android can already do so much more, without needing to be always connected to the internet. The world (even the first world) hasn't reached to a place yet where it can depend on always being connected.
How is ChomeOS better positioned for this metric than iOS or Android? While I am not a huge fan of them as general purpose computers, our Kindle Fires actually fit these bills rather well.
Except it doesn't "just work". For example, offline support is abysmal, and standard tasks such as viewing PDFs or Office documents are riddled with display bugs. Chrome OS has a long way to go before it's a serious competitor to the mainstream operating systems.
Yeah it's just a browser if you forget about the Custom Firmware, Custom Hardened Linux OS with auto-updating sandbox, built-in TPM support and a trusted bootpath optimized for FastBoots, customized Portage build system, Custom Window Manager, built-in media player, file manager, integration with Google Cloud Print, Chrome Shell/SSH, Chrome Remote Desktop.
But it's comforting that there are people that just think of it as just another web browser - that's the whole point, just think of it as a web browsing appliance that "just works like a browser" -- even though it's not.
Chrome is a platform for running web apps, just like android is a platform for running android apps. It is literally the exact same concept, each type of app just has different strengths and weaknesses.
I believe Chrome will exist as a unifying brand. ChromeOS will probably be web apps running alongside a "native" Android apps on an Android foundation. Over the last year, Google has been downplaying the Android brand and differentiating its own Google-branded devices.
How would that work? What would it be like? Android is powered by native apps, Chrome by cloud apps. Chrome already runs on Android. They have different approaches and I don't see how they how they could form a coherent whole or how one would benefit from a merger with the other. :/
Move Native Client for ARM into Chrome on Android (or, wait until PNaCl is ready, and move that into Chrome for Android).
Focus effort on exposing functionality currently available to native Android apps through web APIs in Chrome to make Chrome apps (using NaCl/PNaCl where that kind of performance is needed), rather than Dalvik ones, the preferred mechanism for delivering apps on Android.
At that point, Android and ChromeOS are pretty much the same thing.
Thanks for your input. Now I can see how that would fuse the systems and how that would make for better web apps that had the strengths of native apps (Something like Firefox OS I figure).
But would that improve the Android platform? I'm wondering if it would be confusing or complicated for users, getting some apps from play and other from the Chrome store. Having apps in the launcher and some other apps you have to run from Chrome. Although at that point Google could merge the Chrome store and Google Play and have shortcuts for Chrome apps that launch a chrome-less browser to look native. Now that I've though about it I think it could work rather well, but I'm still wondering what would be the benefit for the users of Android.
Edit: Now that I've seen vibrunazo's comment I think I get it. If Google build a web programming api that is the same as Android's programming for one is programming for the other. I think that would be truly awesome indeed, I enjoy developing for android, not so much for web.
Good point. Android is ahead of Web apis, and Google have been adding android apis to the Web for a while (example intents). They just need to keep doing that until there's 1:1 feature parity, so we can develop apps for either one or the other as if they were the same. And the same apps would work predictably on both.
> Android is powered by native apps, Chrome by cloud apps.
Android is powered by Java apps (mostly). Java apps run in a virtual machine, just like web apps. Java apps are no more native than Chrome packaged apps.
No no, a cloud ecosystem, on an operating system, on top of an operating system, on top of the linux kernel. It's a great idea, especially on a power-constrained device like a phone.
Just add in Bellard's jslinux, and you can go 'round again.
That's very likely the intention here. If not merging them fully then at least synergies between similar areas of the two and a merging of the app ecosystem of each.
http://en.wikipedia.org/wiki/Sundar_Pichai
If you care at all about the security of Android mobile devices, this is probably a good sign.
EDIT: I wonder if this helped move Andy out the door? http://www.macrumors.com/2013/03/07/phil-schiller-tweets-lin...