Peter Beverloo

Finally we’re able to provide an answer to the many rumors which have been going around in the past few months: Google Chrome is nowavailable for Android devices running Ice Cream Sandwich. On my Galaxy Nexus, the browser scores 343 points on html5test.com, runs the SunSpider test in 1880ms and scores 1308 points on the v8 test.

Support for the Web Platform
The first beta uses the same basis as Google Chrome 16, meaning it has most Chromium and WebKit changes up to mid October 2011. I’ve already iterated through many of the changes which were included in that release, most of which will apply for the Android version as well.

To name some highlights, Chrome for Android supports pretty much all of the Web Platform’s exciting features, including CSS 3D Transforms, GPU accelerated canvas, CSS Animations, SVG, WebSockets (including binary messages!) and Dedicated Workers. It supports IndexedDB, Application Cache and the File APIs, date and time pickers, parts of the Media Capture API and mobile oriented features such as Device Orientation and Geolocation. Fixed positioned elements are also working and even look smooth while scrolling!

What the Android-based Chrome does not support is Flash, following Adobe’s announcement in November. Other unsupported features in the beta release are Extensions/Apps, WebGL, Shared Web Workers and the Web Audio API.

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.

And for the Web Developers among you, it’s also possible to utilize Web Inspector’s Remote Debugging feature to inspect and modify pages while viewing it on the device itself.

Google Chrome 16 and mobile limitations
Of course, bringing a browser to a different -much more limited- platform goes further than simply re-using code. Mobile devices have a lot of limitations compared to desktop and laptop machines. Besides the lower amount of available memory and CPU power, other constraints lie in less memory bandwidth and VRAM on the device’s GPU. Google Chrome has a complicated architecture which imposed some interesting challenges here: separating the browser from the renderers through its multiple process architecture, to name an example. Decreased rendering and scrolling performance were also an issue, to which Chrome’s GPU team provided an excellent answer in the form of a threaded compositor.

Another characteristic of the Android platform is that the APIs for most significant features are exposed through the Android SDK, making them available to Java code. To this end, part of the browser layer has actually been implemented in Java, communicating with the rest of the Chromium and WebKit code through Java Native Bindings.

Becoming part of the Chromium project: upstreaming our code
Chrome for Android has been developed in a separate repository as a fork, which means that most of the code will have to be upstreamed. To date, about 150 commits have landed in Chromium making many preparations, including the build environment and bots for Chromium and WebKit, not to mention WebKit’s umbrella bug and the twoannouncements.

As having a fork is far from ideal, one of the current top priorities will be to upstream most new and modified code to Chromium and WebKit, while the build and testing infrastructure on Chromium’s waterfalls is expected to evolve significantly. A snapshot of the current source-code of Chrome for Android can be downloaded as a tarball.

Of course, keep in mind that today’s release is just a beta; much more work, features and stability will be needed to actually be able to release the first stable version. Personally, I’m very glad that the project has been announced, and definitely am looking forward to continuing development in the open!

Jake Archibald

February 8, 2012 at 9:35 pm

It’s already replaced the default browser on my Galaxy Nexus. Much better than the default.

I’m not convinced about the ‘font boosting’ thing, I much prefer the reflowing of the default browser, it lets me choose whatever font size I need at the time (eg, early morning I prefer larger text. The font boosting doesn’t seem to activate for all text either, leaving some too small and requiring horizontal scrolling to read.

That aside, t’is brilliant. Looking forward to seeing it develop.

antonio

February 9, 2012 at 3:43 am

hi peter. would you have screenshots or videos of font boosting feature in action?

like with and without it would be cool to see…:)

congrats and keep it up!

Miika Koskinen

February 9, 2012 at 9:07 am

Thanks Peter for the insight and great work, I really enjoy browsing with the current beta Chrome with my GNexus!

In contrast to Android Browser, I’m guessing the plan is to eventually replace current Android Browser with Chrome for Android in future Android releases?

Cole

February 9, 2012 at 12:43 pm

Hello.

Been having fun with PeerConnection and MediaStream in Chrome, wondering how PeerConnection, getUserMedia and Media Capture APIs are going to interact all together.

As for SSE, I’m wondering what Chrome devs think of Mozilla’s Web Push?

Dimitris Manargias

February 9, 2012 at 2:56 pm

Hi,

My site is not rendered correctly with this beta release of Chrome for Android due to the “Font Boosting”. Is there a way, for example by embedding a flag, to opt out of “Font Boosting”;

Peter Beverloo

February 10, 2012 at 4:27 pm

Thanks for the comments guys!

Ben Collier: We are looking into ways to make this happen, but have no plans to announce at this time.

Andrew: You can check the “auto-update” box in the Android Market, which will automatically download and install updates. Thanks!

Jake Archibald: Cheers! Font boosting takes some time to get used to, and there are still bugs (which are being worked on), including some on selecting the right pieces on a website to “boost”. Feel free to report bugs on http://new.mcrbug.com/

Miika Koskinen: Good to hear you like it so far! We’re definitely looking into ways to harmonize the efforts, considering maintaining two ports of WebKit (which Google is doing now) is not ideal, but there is nothing to announce for now.

Cole: They’re all part of either HTML5 or the WebRTC specification, and will be working together quite well. SSE is supported by WebKit itself and, while other features (for example WebSockets) are also available to provide similar functionality, it does have its use-cases. I can’t comment on the Chrome team’s position on the feature, that’s kind of out of scope here as well.

Dimitris Manargias: No, there are no ways to disable Font Boosting in the beta. You can file a bug on http://new.mcrbug.com/ to report compatibility issues with your site.

Randall

February 12, 2012 at 12:29 am

I took a peek at the early tarball, but it looks incomplete or at least missing the Java UI bits. How does the Phone UI slot on top of the existing code — does it use a lot of “chrome/” or is it a peer to “chrome/” and built more like the new content shell?

I assumed it was built directly on content, but on tablet the UI looks a lot like regular chrome…

[…] separate repository as a fork, which means that most of the code will have to be upstreamed,” mentioned Peter Beverloo last year, when Chrome for Android was launched. “Of course, bringing a browser to a […]

[…] browser landscape lately: Opera moving away from Presto, Chromium for Android and Firefox Mobile making a stronger stand on mobile platforms. Web Platform has less fragmentation right now than it ever had […]