Decoupling the browser from the OS is one of the best things that could happen for android security going forward. While it won't help people who can't get upgrades to ICS, at least it will solve the future problems of people who get stuck on 4.x while their OS browser slowly becomes more and more exploitable. I have one phone that is still on 2.2 - it is trivially easy to own the phone with a little bit of javascript on any web page.
Probably automatic, like all their other apps on Android. But you should be able to easily turn that off just like with all the other apps in the Market.
I think only the market is automatically updated, everything else is opt-in like 3rd party apps, but you can now set your default to be auto-update, unless permissions change.
Opera Mobile is awesome. It feels so much faster than the stock browser. I recommend it to anyone stuck on 2.2/2.3 for the foreseeable future (like me).
The real problem here is Android's inability to update what are considered 'OS components' independently of updating the OS. Ideally, the built-in browser (which should really just be Chrome) can be updated just like other apps can. Having a built-in browser and also Chrome for Android seems like it would confuse users, and not have the desired security impact you describe because it needs users to search for, install the browser and use it instead of the built-in version.
Google can update apps independently of the OS. Youtube, Gmail, Maps, Market - are all updated independently of the OS ever since Froyo.
They will eventually replace the stock browser with Chrome, but they're waiting until it's not beta anymore, and until ICS has bigger marketshare, or maybe they'll just make it the default browser starting with Android 5.0.
Nothing is stopping you from using another browser right now.
There are not that many browsers to choose from, but you could for instance download Opera Mobile - the next time you open a link you will be asked which browser you want to use. You should also be able to replace the browser on your home screen, although how easy it is might depend on what kind of launcher you have.
Exploit needs to be able to determine the exact path + filename of any file to be stolen.
The securityfocus.com entry referenced above includes a demo script implementing the exploit if you want to see the details.
Just wrap the XHR requests to the local URIs in a try/catch and go fishing for filenames of interest within standard directories.
As mentioned in Cannon's original article, photos would be an easy target given the common location plus filename format for the jpg files
(e.g., /sdcard/DCIM/Camera/IMG_yyyymmdd_hhmmss.jpg). Another interesting directory to poke around in would be /sdcard/Android/data/com.dropbox.android/files/scratch/.
I tweaked the demo script a bit and was able to steal my own dropbox files and photos on my junky little LG Optimus V on Android 2.2.1. Good Times.
Decoupling the browser from the OS is one of the best things that could happen for android security going forward.
Decoupling everything but the most rudimentary services is the best way forward for both security and user satisfaction. Despite the laser focus on the underlying operating system version by so many, tens of millions of Android users, across makes, models, and carriers, are seeing endless updates of mapping and navigation, the search functionality, the mail applications, the Android market, and so on. Decoupling the browser adds it into the bin of "no longer need to care about the underlying OS much", and goes a long way to make the fragmentation issue a non-issue.
If the core services are going to be different then the fragmentation is still a problem for app developers. May be not so much for the end users but I guess the end users don't care as much.
Not everyone will update frequently or would want things to get updated for them without them knowing it. Certainly not the non-techy users. This makes it a pain to account for all different versions of browsers, OS, resolution and other functionality a pain.
I have it and it's handy, but the iOS simulator is not an emulator. It behaves differently, especially Mobile Safari. When it runs fine on the simulator and not on the device, iWebInspector doesn't help.
"With hardware-accelerated canvas, overflow scroll support, strong HTML5 video support, and new capabilities such as Indexed DB, WebWorkers and Web Sockets, Chrome for Android is a solid platform for developing web content on mobile devices."
"Much of the code for Chrome for Android is already shared with Chromium and over the coming weeks, the Chromium team will be upstreaming many new components developed for Chrome for Android to Chromium, WebKit and other projects."
"Chrome for Android is derived from Chromium. Because of the ICS release timeframes, we haven’t started the open sourcing process until recently. New capabilities added for Chrome for Android will be open sourced in phases, by upstreaming components of it into Chromium, WebKit, and other projects, while maintaining the integrity of those projects."
This is common Google strategy. They are trying to build the future and pre-ICS devices are not the future. So they get shafted. Google may make unhappy customers this way, but they can move a lot faster than companies like Microsoft, who support everything back two decades or so sometimes.
But to be fair, everyone gets a cheap phone every two years, so what's 1% today will be 100% in two years. Remember, the G1 is three-ish years old, and it's mostly gone now. The Nexus One was released on January 5, 2010, and so only the earliest of early adopters (with a standard contract) are just now gaining the ability to upgrade.
Two years is a long time, but if IE 6 went away after two years, we wouldn't even remember that it was once a thing :)
I would not call iOS 4 on the iPhone 3G "robust": it was more of a disaster than anything. There are obviously strengths to all sides here, and I don't mean to champion that Google's is best or the only way. But I think it's clear what they're doing, and I'd bet they've weighed all possible options and found this to be the most economically sensible one.
I honestly thought Apple's behaviour with the 3G was shameful. I wouldn't have minded if they hadn't released the update for the 3G, but instead what they effectively did was brick a load of people's phones and then offer poor options for downgrading. It's really not what I expect from a premium brand.
this is a bad analogy, apple does not backport features to old versions of their OS, they put their new OS on old handsets. google puts their new OS onto old devices as much as they can too, the problem is that the carriers and other handset manufacturers don't. i'm sure google would love if everything would start running ICS, but it's not their responsibility.
Let's not guess what he would say. But blaming Linus for that is like the Iranian government blaming a dev because someone used his upload app to upload porn pictures or people blaming gun makers instead of killers. You can do it but it isn't the smartest thing to do to say the least IMO.
The inability to run a handful of hardware dependent features on iOS is not even in the same ballpark as the complete lack of timely updates for over 95% of Android users.
There's a difference between running and running as well as on the 4S. The demo of noise reduction is impressive.
http://www.audience.com/demos/transmit-noise-en.php [audience.com]
It's easy to see why with that noise reduction, Siri would be much more accurate than without it, in real scenarios.
Apple obviously wants Siri to be judged on it's best performance. They have a reputation for quality to maintain.
Same here, I bought into the Nexus One hype, great phone but without ICS we are left high and dry with an expensive paperweight with regards to something like Chrome on ICS.
Unfortunately, because of shortsightedness from both Google and HTC (HTC mostly), phones back then only had like 450 MB internal storage, and from that only 250 MB were for the OS itself.
This means an ICS install would be severely limited by the hardware (I think a full ICS install is significantly bigger). Modders might be able to put ICS on it by cutting apps and features, or doing other kinds of hacks to extend the internal storage, but for Google that just wasn't worth it.
I would really blame HTC for this. Pretty much all of their phones throughout 2010 were like that. It was my main frustration with HTC at the time, another one being the weak Adreno 200 GPU.
I ran 4.0 via Cyanogenmod 9 on my Nexus S 4G for weeks, and unfortunately the bugs and constant app crashes got so bad that, as much as it pained me to do so, I went back to 2.3 yesterday. I love Android 4.0, but there doesn't seem to be a good, stable implementation of it yet.
Example issues:
* Random reboots
* Choppy playback in the Music app
(Amazon MP3 worked fine)
* Random app crashes, particularly
games (possibly due to lack of official
4.0 support)
* Poor GPS performance, occasionally taking
15-20 minutes to acquire a position (typically
solved more quickly by rebooting, but it takes
several minutes to know there's a problem in the
first place)
It's difficult to blame the app crashes on the OS if the app doesn't claim to officially support 4.0, but that's still reason enough to wait.
I'm eagerly awaiting the day that CM9 is released, or MIUI releases their official 4.0 version, but until then I think it's better to stick with what works.
I've had ICS on my Nexus S for a few months now and I've not seen issues like that. I'm just using the standard Google image (AFAIK, my brother did the upgrade for me - Android 4.0.3, kernel 3.0.8-gb55e9ac). I do see a lot of battery drain when I'm using the GPS, and I don't play games, but no crashes.
In my experience, the stability and performance of various peripherals like GPS and the WiMax radio are about as good as the stock 2.3 ROM. I haven't even noticed a change in battery drain...
Definitely CynanogenMod. Probably (I haven't checked them all) the most complete and best testet Rom out there. Available for nearly every major Android hardware.
It is very phone specific for ICS right now. When Cyanogen 9 comes out there will be more 'standardization.' For now, I'd look up the dev forum for your phone on xda-developers and see if there are any good options.
Here's a screenshot of the detailed breakdown: http://i.imgur.com/WA37A.png . The "FROM" column is Chrome, the "TO" column is stock. Some tests Chrome wins, some stock.
Anandtech did a Sunspider comparison with Chrome slightly trailing stock and both somewhat behind Firefox 10. Not really gamebreaking differences though.
I believe that both browsers are based on WebKit and V8 (that's what they've said about the stock browser in the past, anyway), so your results aren't too surprising. The Chrome app adds a bunch of new features, better UI, and makes the browser into a real, bona fide app.
According to MG Siegler, Chrome is in the bizdev-required proprietary 'with Google' part of Android, not the Open Source part.
http://parislemon.com/post/17215781807/chrome-for-android-th...
That means we're stuck with legacy browsers in existing Androids and in the non-Google-blessed world (Amazon Fire and the billion Chinese phones and tablets).
Interesting. The chromium blog post linked above mentions upstreaming a bunch of new components, so maybe it will be like the Chrome/Chromium situation? Here's hoping...
My initial perception is that all the Chrome features are great, primarily the data syncing with my desktop browsers. But the rendering is flawed; it doesn't render like the standard Android browser, doesn't render like desktop Chrome, and doesn't seem to even render consistent to itself.
For example, a few screenshots comparing the standard Browser view of this comment page and the way Chrome beta views it:
"An issue that often pops up for mobile browsers is that text on the website may be too small to read properly. Where the Android Browser employs a text reflow algorithm to clarify the situation, Chrome for Android features a technique which we’ve called Font Boosting. It uses an algorithm to increase font sizes when necessary, aiming to make the text readable regardless of the zoom level."
While it's indeed imperfect and inconsistent, in the 10 minutes I've spent playing with it, it does seem much, much easier to read and click links without zooming, which is quite a bit more important to me than it being slightly ugly. I'll definitely be using it over the stock browser.
Then their algorithm isn't consistent, as shown by screenshot. Some comments on HN are "boosted", while others remain tiny. This also makes it impossible to reliably hit any of the other page controls, like voting, without having to manually zoom way in and then back out.
Of course, the voting arrows are hard to hit even on a normal browser!
I actually really like the idea of adjusting text size like this, but the particular implementations of this idea may be less than ideal. I'll have to play around with it when I get the chance and see what it's like.
I remember seeing a very similar effect on my iPhone 3G with Safari. Since it only ever happened on Hacker News, I'd personally place the blame on the HTML here, rather than the browsers. When it works I prefer this rendering, I couldn't figure out what was different at first, I assumed it was just better tuned to my Galaxy Nexus screen size/dpi.
Also, one of the other features is a zoom window when you try and click on small link targets that are close together. Not tried it here yet but it worked beautifully on the similar up/down vote arrows on Reddit. (image showing it in action: http://i.imgur.com/UpWKF.jpg)
On the other hand you cant read the text on Browser without zooming. So it is arguably an improvement. Suspect if HN was designed for mobile the result would seem less odd. Generally seems to make more stuff readable that otherwise isn't with less zooming, so an improvement. The voting controls on HN just need to be bigger!
It makes unreadable text readable for the user without requiring action on their part. Why would UX people get pissed? Seems more likely that web developers are the ones who will be uset.
For those wondering what the differences between the stock Android ICS browser and Chrome 16 (which this is based on), Chrome has extra features such as:
* WOFF fonts
* Web workers
* drag and drop (not sure if this would work in mobile)
* file API
* IndexedDB
* form validation
* CSS border images
* SVG filters
Desktop Chrome currently doesn't support touch events. I wonder if the Android port's touch events implementation will make it to the desktop.
Trying it now. It's very slick. Neat little animations and effects all over. Pulling up tabs from my Desktop Chrome works great. All of my bookmarks show up. No extension support (yet?).
Why in the world is this restricted? I live in the Netherlands, and I really don't get what's so hard about releasing here. Sure, we're a small market, so not as important, but still... Software is global, man!
Why are they even bothering with h.264 anymore? Didn't they want to remove it from Chrome since like version 10? It's about time they start to aggressively push for WebM, if it's ready.
It would be odd, at the very least, if the problem was H.264 licensing. "All" Android devices (dating back to the G1, I believe) ship with H.264. That doesn't mean there isn't some other licensing (or other legal) sticking point, though.
Since it doesn't replace the base WebKit, you'd either have to require everyone install Chrome to use your app (not guaranteed), or bundle the entire runtime (adding ~10MB to your app). It's possible, but doesn't seem very practical unless there's a serious leap in performance or capabilities in Chrome vs the baked in WebKit.
Far more likely we'll see Chromium replace Android's engine in a version or two.
Assuming that means "be able to run Dalvik bytecode in the browser", that doesn't help with all the Android APIs and such, so it's hard to see how it would be useful.
Perhaps it means porting the Dalvik VM to ChromeOS. I've wondered the same thing, since putting an Android layer on ChromeOS seems to be technically viable (if non-trivial).
I do. Deafault browser is slow, the Aurora builds for Firefox have been the fastest option I've found so far on my GNEX.
But if Chrome beta is faster I'll use it. On mobile it's all about speed for me!
I've never seen any chart or graph where Firefox Mobile even shows up. Usually when something has <1% marketshare it gets categorized as statistically insignificant or grouped in "other".
It's still not nobody. And having Firefox playing a significant role will prevent situation which existed in the past where many sites were "IE only". We don't need "WebKit only" sites.
There is a difference between "WebKit only", which means you have to support some N number of standards (CSS 1/2/3 for example) and "IE only" sites, where you have to run Windows and support ActiveX.
There are enough WebKit browsers specific things which are not standard to make "WebKit only" situation a problem. In general, well balanced browsers representation makes web developers think better and be more responsible.
Do you have evidence that they are correctly detecting Firefox Mobile? In my day-to-day use, I've seen it treated as everything from desktop Firefox to Mobile Safari, so I'm not terribly optimistic on that point.
Just a note: the rendering in this app does not use Android's webkit! For example the rounded borders on ihackersnews.com are square! It seems that it doesn't use the namespaced -webkit-border-radius but only the normal border-radius
Interesting
It insta-crashed for me too on my Samsung Fascinate with CM9. I cleared the app's data, its cache, uninstalled it and reinstalled it. It works like a dream now.
We've been user "Browser", I hope one advantage of using Chrome would be bookmark sync with my desktop browser. "Browser" doesn't even have folders for it's bookmarks.
Anyway, my phone only runs Android 2.3 so it seems I'll have to wait till my next upgrade to avoid using hacked up apps to sync my bookmarks.
IIRC, Browser's sync is just bookmarks. Chrome for Android also syncs open tabs and autocomplete suggestions from the desktop, bringing closer to Firefox Sync.
It's a shame that this has only been released for Android 4.0. My hope is that use of Chrome for Android becomes commonplace. SVG support has been lacking in the Android stock browser in all releases up to Gingerbread - Android 4.0 (and 3.0) already have SVG support, earlier release could really benefit.
I believe Transformer Prime and Xoom have it right now. Also the $79 Ainol Novo7 tablet.
They never said they will put it off until JellyBean. The only semi-official rumor about JellyBean was that they post-poned some "major changes" that were coming to ICS initially.
I was hardly using my Touchpad before I put CM9 on it. Now it really is quite delightful to use. Really looking forward to hardware accelerated video though.
I've been running a build of CyanogenMod 9 on my Galaxy Tab 10, and I'm absolutely loving it. I really liked the tablet with honeycomb, but ICS has made it literally 10 times better and faster.
Who needs an "official" ICS? I've installed a beta ICS ROM (teamDRH) on my Viewsonic gTablet and it is as tabletized as honeycomb, though it looks better (this build has issues, but developer support is pretty impressive). The best Viewsonic could do as an update was a Froyo-based bugfix release.
Besides, people who have installed custom ROMs on their phone/tablet are likely less worried about using alpha/beta software, so I wouldn't be surprised if most of the early beta testers will be from this group.
My ASUS Slider is supposed to be getting the update quite soon along with the Transformer. Last I read a couple weeks ago it was in final checks at Google.
I've been hearing that the browser in Android is kinda bad from a lot of web/js developers. I hope that this makes the situation more palatable. Even better is when they'll ship a version for Windows Phone and ios.
I wouldn't hold my breath for Chrome on iOS or Windows Phone. In both cases, the app store rules ban key features of Chrome (like the V8 JavaScript engine).
Google may well do something to address Windows Phone and/or iOS users, but it will probably be much closer to Firefox Home for iOS (which lets you explore your bookmarks, open tabs and history and then follow links in Mobile Safari) than it will be to Chrome for Android.
The blog post doesn't go into it, but I'm curious to know what the long-term implications of this release are for the built-in android browser and the android SDK's WebView and WebChromeClient.
If this is indeed the first step towards decoupling the browser from the Android platform itself, I would expect to see continuing development of those aspects of the SDK to dwindle and die completely, leaving them in the dust feature-wise when compared to native apps, and putting the people who work on web-wrapper-apps at an even more serious disadvantage.
That's a very good question indeed, especially since some seem to suggest that Google will eventually replace the stock browser with Chrome, and Chrome is proprietary.
The FAQ's been linked to a couple of times from here, and it vaguely says:
Are you still working on the Android browser, or are you dropping support in favor of Chrome?
Android Browser and Chrome for Android are both derived from Chromium and already share a lot of code. We will continue to evaluate where it makes sense to harmonize our efforts; for instance, Google now has just one port of WebKit to maintain.
Too bad it's only available in "select countries", which certainly don't include the Netherlands... Probably just the US and Canada? Kind of old-fashioned.
Firefox for android unfortunately started out real slow...might be a good move for Google. Time to go to xda-developers and see if it'll be on your phone.
It's something I've been asking from Google for a while. They need to implement swipes and gestures like that throughout the OS, and get rid of the bottom buttons which I think are wasting space.
I don't believe the iOS sandboxing would allow for V8, though. Isn't this the same problem as "my third party app WebView is slow because it doesn't support Javascript JIT"?
You are right, it wont allow V8. The only app allowed to JIT on iOS 4.3+ is Safari (before 4.3 not even Safari was allowed to modify it's own code).
It is technically part of the Mandatory Code Signing trusted computing implementation of iOS more than of the Sandbox. They use the dirty bit normally used to do Copy on Write to re-verify signatures when dirty executable memory is paged in.
The problem with FireFox on my (512 mb) phone is that the OS usually kills it when I switch to another app (even tiny apps like messaging), and it's a slow FireFox restart if I want to use it again. The OS doesn't do this with the stock browser.
Would this have any benefit if I don't use chrome on my computer (and even if I was I probably wouldn't want all my tabs syncing to phone)? Because the ad left me with impression that syncing is its only feature.
I wonder how chrome does speed wise when compared to opera mini. I'm currently using opera mini as its one of the fastest browsers for my phone; G1 running the superE rom.
EEeaagh...getting tired of the upbeat-catchy-music-with-stop-motion-video-and-smarmy-narrator product demos. Who started these? I think it was Apple, not sure though...
Does anyone know if it comes with the same tab sandboxing it has on the PC? They say it has the same security as Chrome for PC, but they don't specify this.
While I understand the appeal (and - being stuck on pre 4.0 anyway, not utterly relevant for me at this time): I really hope that this will stay an optional offer, with a simple browser being the default.
Things like "When searching, your top search results are loaded in the background as you type so pages appear instantly." make me shudder in disgust. The 'inspired by WebOS' card stuff looks nice, but I won't be having more than 2-3 tabs open on my phone at any given time (tablets might be different here).
A browser is a very central part of the user experience. I prefer it simple and stupid.
If I read what MG Siegler wrote correctly, it will eventually replace "Browser" on Google Android builds. People like Amazon who aren't paying Google for Android won't get it.
This is unusable on the Galaxy Nexus due to its mysterious tendency to make fonts microscopic for random sections of the page. Guess it never occured to anyone to test their flagship browser on their flagship phone? It doesn't even resize the page to fit the screen when you pinch zoom (which the stock browser does)
Also, it has a persistent address/menu bar that takes up the top 10% of the screen, no doubt thanks to ICS' lack of a dedicated menu button. Once again, proof that removing said button was a pure stroke of idiocy.
Put the stock browser into fullscreen mode and you see the button was totally useless. You just scroll up a bit for the address/menu/tab buttons to show.
Can we please stop with the hyper-generalization that is that each permission is being used for the app 100% of the time for everything? In almost every instance, one permission or another is required for some trivial task, and they add up quickly.
and for something like a browser, a silly bug will make my personal data ... heck even my mic vulnerable.
android permission is only good if you make specialized apps and make them talk togheter. like it was the original intent with actions and intents. but i guess it didn't worked out ok.
I think is the death knell for ChromeOS. Android browser has always sucked, it was the primary reason I haven't bought an Android device. Google had the resources to make Chrome on Android a long time ago, so I presume they were dragging their feet in a "wait and see" approach for whether ChromeOS had any chance on its own.
First off, this took so long because Chrome was built using a "normal" devel framework (gcc, make, etc) with a few added tools (repo, gyp). The UX for Chrome is provided via OS-specific graphical APIs, like X.org, Cocoa, and Win32.
Android uses a Java framework, which in turn contains the code that manages all rendering and UX, so not only did Chrome UX needed to be ported to Android's graphical API, but the entire build environment needed to be JDK compatible.
I agree the Android browser is laughable compared to Chrome, and Chrome on Android is the future, but there were so many developmental problems that needed to be solved first before one could stick to the other.
Regarding your ChromeOS comment, this has nothing to do with that as ChromeOS is designed to solve an entirely different problem. Many power-users (developers, technology bloggers, etc) seem to have a hate-on for ChromeOS because they're afraid it'll kill their venerable laptop. That will never happen. :)
ChromeOS is designed to kill those netbooks and laptops where common-users (my wife, for example) only use them for browsing gmail, facebook, and a few forums. 95% of what these users do are web based, barring a few native apps, of which NaCL and other HTML5 technologies are aiming to solve.
Apple doesn't allow applications to provide their own runtimes:
“3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple’s built-in WebKit framework.”
I think it will be a matter of time until the iOS platform (3-5 years) is more akin to that of the Mac platform, where there is a walled garden app store, and an outside ecosystem as well. Buying from the walled garden will have many advantages, so it will thrive, but having the ability to buy apps from other locations will enable the platform to also stay competitive.
That's not very precise. Legally, Apple doesn't allow to use iOS SDK, i.e. to build such applications. If you manage somehow to build it any other way (not using Apple's SDK), this restriction has no meaning, and while Apple could reject such kind of software from their app store, you could deploy it to alternatives, like Cydia, and still be legal, since you didn't violate any licenses.
I.e. for browsers makers the concern is not that they'll be rejected from the app store, but that they can't even legally build them with the Apple's SDK.
The rule above is not from the App Store guidelines, but from the SDK license. I.e. even if you use alternative app store without restrictions (Cydia), but build a browser with Apple iOS SDK - it's still illegal, and that's why major browsers like Firefox wouldn't do it.
I'd say it's a very ugly practice, to use development tools license to ban competition. It's like saying buying this chisel you are bound to only carve logos of the chisel making company.
I'm rather confused that Google seems to be aiming to fragment the browser market for its own platform. I already wasn't looking forward to supporting/testing both Browser and Firefox on Android... Is Google just this disorganized internally?
Chrome and the old Android browser are both based on WebKit. Google will almost certainly make Chrome the default browser for new editions of Android, and will likely push for it on IOS and Windows phone.
The license doesn't allow a different browser on iOS unless it uses Apple's Webkit anyway. Opera Mini was a technical exception. Every other browser is Safari, just with a different chrome.
Unless you think Google can negotiate exceptions to Apple's and Microsoft's respective store rules (or, more impressively, convince them to change the rules), we're not going to see Chrome for iOS or Windows Phone anytime soon (if ever).
Much like Facebook's S-1, Google is seeing a huge increase in mobile traffic but not strong way to monetize it via advertising. I'd wager the preview pane (and maybe even the browser itself) is a play to increase the interaction they get on mobile advertisements.
I'm so sorry, I was incorrect. I briefly owned a Nexus S which had an unlocked bootloader. I currently own a Motorola Photon, and even though there are ways to flash the bootloader, doing so cripples 4g (I believe this is by design).
Most of the non-Nexus phones technically have a locked bootloader, so that people can only run firmware signed by the carrier. In practice, there are ways of jailbreaking the vast majority of locked phones, but there are some people who don't want to void their warranty or don't want to use community ROMs.
AFAIK (and some google searching seems to confirm) the Galaxy SII does not have a locked bootloader. I believe that the original Galaxy S was also unlocked.
So which Samsung Android devices have locked bootloaders?
Motorola and HTC tend to lock their bootloaders more often (though this situation is improving).
It's using 4.0 APIs, according to Matt Seigler's story and interview with Google SVP of Chrome Sundar Pichai:
"Back to the bad news: some of the more advanced features of Chrome for Android require APIs found only in Ice Cream Sandwich, so the team made the call to make it only available for Android 4.0 and beyond. Again, this means only 1% of current Android users out there can actually get and use the browser right now."
- http://parislemon.com/post/17215781807/chrome-for-android-th...
1% of Android users is still at least a couple million. That's more than enough to get a reasonable pool of beta testers. By the time it gets out of beta, the Android release distribution will probably look quite different.
And in typical Google fashion, they have assumed that devices have an infinite amount of memory: https://imgur.com/zkh7C (this is with the app in the background!)
What else are you going to use the RAM for? Hell, you have 45MB wasted right there!
If the OS refuses to kill the app under memory pressure then you have a point. Until someone demonstrates this, you're being a bit more than disingenuous.
Well, that's what memory is made for right? You could also not run any apps and enjoy 300MB of unused memory, but that wouldn't be very useful. Android has a very nice system in place that manages its memory.
It's almost like they set minimum system requirements and then users installed it on phones that didn't meet them yet they felt the need to complain even though it still ran on their phones.
Look - as I said in my other comment, the issue isn't that it uses a tonne of memory. The stock browser does so too. The issue is that it is using that memory in such a way that it is evicted too late. The app is multi-process, but they're putting background services in the wrong process - they run in the main process that you'd expect to be heavy on memory usage. So instead of the memory-heavy UI stuff being evicted shortly after the UI goes away, it is evicted after all other background (multitasking) processes - including the launcher - have also gone away.
Note that my screenshot shows the active (i.e., not background processes that can be thrown away at any time) section of the running processes screen.
Why bigot your statement with such a ridiculous lead-in?
On my Gingerbread device the browser right now, in the background, is using 67.15MB. What does that demonstrate? Nothing, given that the RAM was available and web browsing is one of, if not the most, complex activities you can do.
I should have qualified my statement by mentioning that the Chrome app process runs a couple of background services - this causes it to be killed for low memory after normal background processes (the actual behaviour is a little more complex than that, but that's the gist of it), which could potentially impact the performance of multitasking. The proper thing to do is to run background services in a separate process from the UI or whatever uses the most memory so that the latter can be evicted more quickly.
I stand by my assertion that optimising for memory isn't a priority at Google. An Android engineer poignantly put it (sorry, can't remember who) when they bragged on G+ that Android 4.0.3 was the first time since Gingerbread that they'd run the OS on a <1G RAM device (namely Nexus S). Then again, as an actual embedded engineer (none of this gigs of RAM crap!), all I care about is memory usage...
Given the context and the joking tone (complete with smiley), I think you're reading way too much into the comment. Given the devices ICS had been shipped on at the time, she could have just as easily said it was the first time in a year that they'd shipped Android on:
