Bringing Google Chrome to Android

Published on February 7th, 2012 in Google Chrome, tech, WebKit.

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 now available 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 two announcements.

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!

24 Responses to “Bringing Google Chrome to Android”

Both comments and pings are currently closed.

What’s the feasibility of embedding the Chrome rendering engine and these enhancements for web views in apps? Or can we expect to see this become the core engine in Android eventually?

Great work!

This is great news! Are there plans to include WebGL support soon?

Is the silent auto-updater included? IMO that’s the most important part of Chrome.

Otherwise, this is pretty darn fantastic for “just” a beta.

[…] post: Bringing Google Chrome to Android « Peter Beverloo This entry was posted in News and tagged chrome, cream, devices-running, few-months, galaxy, […]

What about NaCL support and Pnacl?

Can’t wait to give it a spin!

You hero, you <3

It is very disappointing to a region restricted browser launch.

Any ideas if Server-Sent Events is implemented? Would be a nifty way of providing push notifications for web apps, specially if the connectionless push described in the spec is implemented. http://dev.w3.org/html5/eventsource/#eventsource-push

Thanks Peter.

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.

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!

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?

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?

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

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!

seutje, thanks!

Ed Mackey, oscar: I can’t comment on that, sorry. Check out the FAQ here: http://code.google.com/chrome/mobile/docs/faq.html

Alejandro: Yes, server-sent events should be available!

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/

Antonio: Thank you! I’ve uploaded a screenshot (http://peter.sh/files/Screenshot_2012-02-10-14-12-00.png) which shows the article’s content font being bigger than the menu one. This required no changes to my website. It’s similar to text reflow in some ways.

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.

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…

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

Not quite the same. 🙁 What if people don’t do that? In a year will we still have to worry about people running the outdated Chrome beta? IE6 all over again! (half joking)

You should check out this link I have posted to your trackback…

Did you request that I link back to your site?…

It’s difficult to find knowledgeable individuals on this subject, but you sound like you realize what you’re talking about! Thanks

Just been trying chrome but I’ve noticed its not reflowing the text when you zoom in. I’m i doing something wrong

boss your site is very help, many time i try to search for this content but i can’t finished my needed content. but i found your site on my friend and now i am thingking your site is rocking.

I’m trying to make a cross-platform/cross-browser HTML5 game and I was hoping to use pixel perfect sizes but ‘Font Boosting’ is stopping me from doing this.

Is it simply not possible enforce a pixel size anymore? Thanks.

Hi John, There currently isn’t a convenient way of disabling Font Boosting. A work-around is setting:

max-height: 1000000px;

on an element for which you’d like it disabled, but this really is just a hack, and I don’t think it will be supported well in the future.

[…] 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 […]