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...
Update from the CEO
191–200 of 216 posts
Re: Update from the CEO
#192Earlier quoted context omitted.
The lack of "of"?
You can let someone go without letting go of them.
That would be "Google let its Android head go". Maybe the title edit was by a Brit who prefers "their" (plural) over "its" (singular) for companies?
http://en.wikipedia.org/wiki/American_and_British_English_di...
Re: Update from the CEO
#193Earlier quoted context omitted.
He's not wrong. There's always a tradeoff between security and usability. http://www.schneier.com/blog/archives/2009/08/security_vs_us... The key is finding the right balance.
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…
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 because , and Android has versus . 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.
Re: Update from the CEO
#194Earlier quoted context omitted.
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…
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 because , and Android has versus . 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…
I linked to our research page, right?
http://www.trailofbits.com/resources/mobile_eip_2.pdf
http://techchannel.att.com/play-video.cfm/2013/1/8/Conferenc...
http://techchannel.att.com/play-video.cfm/2011/7/14/Conferen...
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 :-).
http://www.f-secure.com/static/doc/labs_global/Research/Mobi...
EDIT: I'll give you a few hints.
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.
Re: Update from the CEO
#195Earlier quoted context omitted.
"Before Android, you could write a Windows Mobile app and have it run pretty much on every Windows Mobile device" - yeah, all one million of them.
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.
Three. Luckily only one (ARM) survived by the 2002 release.
Re: Update from the CEO
#196Earlier quoted context omitted.
> Since Sundar Pichai is the head of ChromeOS, perhaps this move is part of a larger move to unify Android and ChromeOS. I can't see both exist at the same time for much longer, and Android is encroaching on ChromeOS' domain much faster than the other way around. I'm predicting that ChromeOS will be shut down within a couple of years.
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".
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.
Re: Update from the CEO
#197This 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…
> 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...
Re: Update from the CEO
#198Earlier quoted context omitted.
Firefox for Android supports Froyo (2.2) up the latest Jelly Bean (4.2). Chrome for Android only supports ICS (4.0).
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?
Re: Update from the CEO
#199Since Sundar Pichai is the head of ChromeOS, perhaps this move is part of a larger move to unify Android and ChromeOS.
You noticed that did you? 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 g…
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.
Re: Update from the CEO
#200Earlier quoted context omitted.
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. :/
> 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.
And both get translated into native code by V8 at runtime.