Introducing Chrome for Android | Hacker News Reader

Introducing Chrome for Android

googleblog.blogspot.com

476 pointscleverjake233 comments

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.

I'm hoping this means it will get updates every 6 weeks, too.

yes it will..

> There will be the same 6-week release cycle for new versions, Pinchai says.

http://parislemon.com/post/17215781807/chrome-for-android-th...

but i would ask will they be automatic or manual?

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.

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.

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.

Exactly, the (current) browser is not an app and hence cannot be updated independently.

You could always download an alternative browser, such as Opera.

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

It's especially valuable on slow networks (or if you have limited data) due to its "turbo" feature.

trivially? please, more detail. Also: own is a loaded term. Please, more detail. Getting access to the sdcard is not the same as owning.

I presume trotsky is referring to the "content://" URI vulnerability found by Thomas Cannon:

http://thomascannon.net/blog/2010/11/android-data-stealing-v...

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-480...

http://www.securityfocus.com/bid/48256/info

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.

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.

Direct Market Link: https://market.android.com/details?id=com.android.chrome The download is a hefty 16MB.

Features:

* Chrome-to-mobile, Sync bookmarks, history, settings, Auto sign-in

* Bandwidth management (preload webpages)

* Privacy settings

* Developer tools: Tilt Scrolling, USB Web Debugging (debug web pages from Chrome Desktop via USB??)

* Incognito mode

* About screen: http://i.imgur.com/Ahr6t.jpg

The homepage has a "sync" icon with all the tabs open on your desktop: http://i.imgur.com/6eadl.jpg

It can be a little slow to sync pages between devices, but works much better than Chrome to Phone.

Overall, Chrome Beta is a welcomed improvement.

> USB Web Debugging

That will be great. Even better if iOS gains something similar--it's maddening to not have a real debugger.

See this thing: http://www.iwebinspector.com/

Simulator != real device

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.

Instructions on how to use web debugging via USB: http://code.google.com/chrome/mobile/docs/debugging.html

You can then access http://localhost:9222/ which shows a list of all pages currently open on your device, which link to a page on http://chrome-devtools-frontend.appspot.com/ for example http://chrome-devtools-frontend.appspot.com/static/16.0.912.... which in turn connects to a websocket on localhost like ws://localhost:9222/devtools/page/2 to debug your mobile browser!

To get a feel for USB web debugging, check out this remote debugging video: http://www.youtube.com/watch?v=s4zpL4VBbuU

Similar video of remote debugging for Opera. Might be a bit outdated as it is from 2009 http://www.youtube.com/watch?v=sZt-k93qLbg

I'm guessing this shares code with Chromium, so will it be open source too?

EDIT: Looks potential: http://blog.chromium.org/2012/02/deeper-look-at-chrome-for-a...

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

No context; but there's at least an "android" folder in the build section for what it's worth

http://git.chromium.org/gitweb/?p=chromium/chromium.git;a=tr...

Woops, I pasted the wrong thing there:

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

http://code.google.com/chrome/mobile/docs/faq.html

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

With Android 4.0 at 1% market share, it'll be a long time before most people can even try this.

http://developer.android.com/resources/dashboard/platform-ve...

Yeah, while I'm generally excited about this, I won't be able to use it anytime soon, unfortunately.

Root and install a 4.0 rom!

Have any good ROM suggestions? I'm looking for one somebody with first hand use of it can sell me on.

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.

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.

If you have a Droid X and can live without the camera, EncounterICS is unbelievably good.

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.

Edit: Formatting.

I've been using this ROM on my NS4G for about a month:

http://forum.xda-developers.com/showthread.php?t=1364221

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

I'm running the same ROM on a NS4G also for about a month. It feels like a new phone and has been awesome in every way.

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.

There is only an alpha 1 version of 4.0 (CM9, in fact) out for my phone, and it still has severe bugs.

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.

Is it HTC or Google's responsibility to provide future-proof reference designs and specs?

HTC

"Future Proofing" a phone is difficult, because a manufacture needs to overspec the phone whilst still keeping it at a reasonable price.

HTC is notorious for underspecing storage on their phones. Other manufactures do not have the same problem.

Considering only 1% of android phones are capable of running ICS, I gotta blame it on the OS designer, not a reference hardware manufacturer.

In this case it is Google's responsibility.

There are ICS builds you can install on an N1 if you are willing to repartition your NAND (the stock partition layout can't fit ICS). Look here:

http://forum.xda-developers.com/showthread.php?t=1411429

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.

Apple seems to be able to innovate iOS while providing robust and timely updates for older devices.

The way Android is fragmented changes all of that. If iOS were fragmented the same way Android was, Apple would be doing the same 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.

That's certainly true for some definition of "robust" and "timely". I'm assuming yours doesn't include security and bug fixes.

Oh yeah? Let me know when I can get Siri on an iPhone 4 without resorting to some sketchy hacks.

This false equivalence is tiresome.

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.

Hardware dependant? Siri was shown running on pre-4s devices (3g if I recall correctly) before apple bought them.

Not to Apple's standards apparently.

http://news.cnet.com/8301-30685_3-57371624-264/why-apples-a5...

Siri has since been ported to older devices via jailbreaking. As I understand it, there are no performance issues.

However, I do agree that Google needs to sort the 'update problem'.

"As I understand it, there are no performance issues."

It's one thing to "work" in the hacking sense, and another to "work properly" in the Apple sense.

http://apple.slashdot.org/comments.pl?sid=2656999&cid=38...

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.

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.

"as much as they can ...not their responsibility."

You make it sound like Google's suddenly found themselves in these unfortunate circumstances through no fault of their own.

On the contrary, this is the reality of Android. You don't get to own the pluses of being "open" and not own the minuses.

> You don't get to own the pluses of being "open" and not own the minuses.

Actually you can, you wouldn't blame Linus because your linux based router comes with a broken or old version of linux.

I'm sure Linus himself would tell you that he would own that as a minus of linux and that it's far outweighed by the positives.

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.

Hey, watch it there. All WP7 devices support all the updates thus far and for atleast the next year or so.

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 agree in general but IE6 was out for five years before IE7 came out, so it may not be the best example.

Of course, that was because they disbanded the browser team after crushing Netscape.

It appears to be significantly faster on JS front than stock Browser.

Sunspider results:

    Stock - 3852.2ms
    Chrome - 3131.8ms

(tested on HP Touchpad with CM9 A.06)

edit:

I was curious and redid it after rebooting:

    Stock - 2816.1ms
    Chrome  - 2928.1ms (!)

So it turns out it's faster on systems under load, but actually slightly slower on freshly booted one. Weird.

In case anyone is interested in full benchmarks:

Stock: http://u.42.pl/2HRq

Chrome: http://u.42.pl/2HRp

Html5test.com scores? I've got a new android phone but it won't run chrome.

256+3 bonus on stock, 343+10 bonus on Chrome.

I don't know how to paste which tests pass and which fail, is there any?

Opera Mobile 11.5 is 286 + 8 fwiw. Dolphin Mini 216 + 0.

On my Xoom with stock ICS 4.0.3, Chrome is on the whole dead even with the stock browser:

    Chrome - 2276.2ms +/- 1.0%
    Stock - 2288.9ms +/- 2.0%

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.

http://images.anandtech.com/graphs/graph5517/43983.png

I use Firefox Home on iOS for the sync even though the JS is gimped in non-Safari webkit views. Sync is that killer.

He updated with a test on a Galaxy Nexus (which is a TI OMAP chipset rather than a Tegra2) and Chrome did better than stock, but still behind Firefox.

Though to be honest I'm not sure why Anandtech continue to use Sunspider as a benchmark.

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.

That's my read on it, anyway.

ICS on Nexus S.

  Browser - 4432.6 ms
  Chrome  - 3258.4 ms

EDIT: Didn't reboot or anything like that.

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

http://blog.chromium.org/2012/02/deeper-look-at-chrome-for-a...

Chromium for Android is going to be open source, and the only difference between desktop Chrome and Chromium is branding and nonfree codec support.

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:

Browser: http://db.tt/kv3xP1Mk

Browser: http://db.tt/s7S6lCBN

Chrome beta: http://db.tt/p9YXoWJU

Without testing, this particular issue looks like it could be handled with the viewport-tag and -webkit-text-size-adjust

It's apparently a feature:

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

(from http://peter.sh/2012/02/bringing-google-chrome-to-android)

Wow - I honestly can't decide if thats a horrible idea or not. But I can guarantee there's a ton of UX/UI folks who are going to get pissed that that.

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.

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.

they're ok on a normal browser.. arrows are many pixels wide and the cursors are 1 or 2 pixels wide.

on mobile.. your finger takes like 50 pixels; so yeah.

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!

Keep in mind that it's a beta

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)

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.

This is exciting news. I just got the Galaxy Nexus, so the timing couldn't be any more perfect.

It doesn't look like they allow extensions yet. :(

Big win: You can remotely debug your web application via usb and adb. (Preferences -> Developer Tools -> Enable USB Web debugging.

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.

Source: http://caniuse.com/#compare=y&b1=chrome+16&b2=androi...

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

"This item cannot be installed in your device's country"

It's currently available in: United States, Canada, United Kingdom, France, Germany, Spain, Australia, Japan, Korea, Mexico, Argentina, Brazil

Sundar, SVP of Chrome just said "We are working hard to bring this to more countries and should greatly expand within the next three months."

How hard it can be to tick a few checkboxes?

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!

Software may be global, but patent licenses for things like codecs aren't.

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.

If it works in Germany, why not in Austria?

Since I use Phonegap for my Android apps, I've filed an issue requesting that the Chrome browser be usable in WebView somehow: http://code.google.com/p/chromium/issues/detail?id=113088

Click the star if that's something you'd like too. :)

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.

I had been wondering whether Google would port Chrome to Android, or they would port Dalvik to Chrome. I'm still not ruling out the latter option.

What does "porting Dalvik to Chrome" even mean?

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.

What does "porting Dalvik to Chrome" even mean?

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

Wow, if they include extensions. This could be huge.

Yes, having extensions in a mobile browser is the next step to quick personalization beyond native applications.

I bet that web augmentation on mobiles can be really huge.

You may want to try out Firefox Mobile!

what makes you think they will ?

Firefox Mobile Nightly releases for Android already include "extensions". Here are some examples: http://people.mozilla.com/~mfinkle/addons/

Nobody uses Firefox Mobile.

Any factual statistics for that?

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

http://gs.statcounter.com/#mobile_browser-ww-monthly-201101-...

http://www.netmarketshare.com/mobile-market-share

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.

People who like AdBlock sure do.

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!

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 doesn't seem to be available in Finland, found a apk at XDA tho: http://forum.xda-developers.com/showthread.php?t=1485420

Too bad, it instacrashes om my ICS GalaxyS

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.

So what have we been using up till now on Android? Is this just a re-branding and overhaul of the Android WebKit browser?

No. We have been using a webkit mobile browser. This appears to be a separate code base.

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.

"Browser" on Android 4 syncs with Chrome already (and has folder support).

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.

well i've been using dolphin hd

Dolphin HD is just a reskinned version of the stock WebKit view that comes on every Android device/OS.

Can anyone please confirm if this includes access to the Chrome Web Store? That could be huge for web apps.

If you visit the web store it says it isn't supported by this operating system.

Oh no! I hope they will open it up. Thanks anyway; I asked because I don't have an Android device but I do make web apps.

Can anyone speak to whether or not Chrome for Android supports WebGL?

It doesn't support WebGL right now. Some more answers to questions like this at http://code.google.com/chrome/mobile/docs/faq.html

Just thought I'd try it. Nothing I've tried on chromeexperiments.com has worked using a galaxy nexus.

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.

Does anyone know if this is Open Source?

Chrome is now available in Beta from Android Market, in select countries and languages for phones and tablets with Android 4.0, Ice Cream Sandwich.

What tablets have official ICS on them? Is ICS even fully tabletized? I thought they had said they were putting that off until Jelly Bean.

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.

Running CM9 / ICS on touchpad. ICS is fully tabletized, better than my ipad, on an alpha build full of bugs.

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.

Wow, that sounds great, can you tell me more?

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

Other way around. ICS is effectively a re-merging of Honeycomb (which was tablet only) back to mainline Android.

Finally. If this can actually live up to the desktop experience, I hope we can finally bring an end to the app.

Only available for ICS https://market.android.com/details?id=com.android.chrome

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.

Just installed it in the UK.

I'm guessing it's a localization issue. Although for a Beta, I don't see why they can't just offer everyone who's keen to try it the en-us version.

You can use https://market.android.com/details?id=com.notenking.mf if you're rooted, dan werkt het wel bij mij namelijk

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.

Firefox moved to native UI on Android, which made it faster. The minus is obviously need for add-on developers to work with native UI too.

"Swipe from the edge to switch tab" is beautiful :)

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 wonder if it would be feasible for them to put Chrome on the iPhone. Technically, Apple wouldn't be against it since it's using WebKit.

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 app store rules talk about "built-in Webkit". Judging from the size, there's a good chance Chrome for Android bundles its own WebKit version.

It's similar in size to Firefox, which obviously has to bundle its own Gecko rendering engine.

All I want to know is how long till it replaces the current implementation of WebView in the Android SDK.

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 if/when the "Browser" app will get the hardware-accelerated canvas support.

Currently, some of the canvas apps I've tried on ICS run worse than on Gingerbread. However, those same apps run acceptable in this Chrome beta.

Never by the sound of it. It will be discontinued in favour of Chrome now.

It reminds me of the truth that speed is the best user experience.

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.

A x-post by Google: http://news.ycombinator.org/item?id=3562814

This app is incompatible with your Nexus S. :(

Will this replace the browser that ships with Android in ICS, or will the user have to download Chrome?

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.

Crashes on start on my HTC Incredible (4.0.3 via Evervolv), and on my Nook Color it can't load pages.

Why only "in selected countries"?

missing i18n?

It was about time!

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.

A browser with that many permissions? what good is sandboxing and everything if the browser can access 100% of my device, including microphone?

i'm thankful this is not available for my ancient, 11mo old, nexus one.

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 never thought I would see the day that a BlackBerry can run Chrome. I still never think so, but I never thought so, too.

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.

I don't believe so, for both your statements :)

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.

That's exactly the same market android tablets target. The market for ChromeOS is rapidly evaporating.

Chrome for iOS please.

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

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 App Store guidelines only apply to the App Store", while a true statement, is a pretty useless one.

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.

For the same reason there's no Firefox for iOS. Enjoy your walled garden.

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.

No luck. Just don't use iOS.

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.

Given that IOS is already on WebKit, there's no fragmentation here. WebKit has a monopoly on mobile.

And that's bad, since it promotes bad coding practices. Also, WebKit is far from being uniform, and differs from one flavor to another.

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.

Douche move making it require Ice Cream Sandwich while they don't require telcos to ship any of us upgrades.

If Samsung didn't lock down the bootloader so fucking tight on my $500 phone I wouldn't have to care what the telco does.

Which Samsung Android device has a locked bootloader?

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

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

Yeah, lets just go ahead and assume there are no technical reasons here...

Do you really still think Google has any say in the whole carrier upgrade thing?

You're right, it's not Google's fault that they're only armed with:

a) the only operating system that really competes with iOS while everyone struggle to compete with the iPhone

b) mountains of cash

c) a factory full of smart people solving much harder problems

It's much better to just abandon every single generation of Android and the hardware it shipped on!

It has canvas hardware acceleration. Hardware acceleration is a new feature in Android 4. Hence, it is only available on ICS.

They could have added fallbacks. HW graphics acceleration is also possible on pre-ICS Android, anyway.

probably more related more to a minimum hardware requirements.

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

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

The comment I was referring to is under this G+ post: https://plus.google.com/105051985738280261832/posts/intiB73F...

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:

- a single-core device

- a device with a screen smaller than 4.5"

- a device with less than 720p resolution

- ...

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.

Using lots of memory is not necessarily wasteful. Actually, NOT using memory that would otherwise sit there full of zeros is almost always a waste.

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.

this might be because: - its loading its own webkit/js lib - it might be multiprocecss (is it?)

I'm wondering how much firefox nightly uses on your phone

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.

Reply on news.ycombinator.com