Google Chrome for Android
Welcome to the mobile HTML5 world
About 8 min reading time
It’s that time of the year again when the mobile web ecosystem changes. Google Chrome Beta for Android was released and it appears as the future replacement of Android Browser. I’ve made a deep analysis on the browser HTML5 compatibility and the comparison with Safari on iOS and Android Browser and I’ll show in this post my results.
Quick look #
If you have an Android 4.0 device, go to the Market and download it so you can try it yourself. Chrome for Android is a big step for the whole mobile web community and I’m happy for it. It’s still the first beta so there are some things that need some work but in a quick look, it seems stable, fast, nice, and with the latest HTML5 support.
It’s the beginning of the future of some APIs in the mobile world, including Request Animation Frame, FullScreen API, Page Visibility API and IndexedDB. Unfortunately, Chrome is not available yet for Android 2.x and 3.x and WebGL is still out of this version.
I’ve played a couple of hours with the browser and here is my review. I’ll update this post if I find some new information to add or correct. Follow me if you want to get updates.
Why Chrome? #
Do we really need a new browser for Android? The answer depends on our point of view. Android is right now the platform with more options in terms of web browsing: the by-default Android Browser, Opera Mobile, Opera Mini, Firefox, UCWeb and now Google Chrome. Chrome appears in the Android world not as a new browser but as a long-term replacement for Android Browser.
The problem was Android Browser. It was always behind Safari on iOS for iPhone and iPad and it was far away behind its desktop cousin Google Chrome; at least, in terms of HTML5 compatibility. Android Browser had problems in the past and the worst problem from my point of view: it doesn’t auto-update. And we know that Android users –because of vendors and carriers- usually upgrade only one version of the operating systems, so millions of users are prisoners of the same Android Browser version until they upgrade their device.
Today, the future of Android browser has begun. Google has released the first beta version of Google Chrome for Android. Starting from the ground from the Chromium Project instead of the original WebKit-based Android browser, Google did a good job aligning the browsing experience and HTML5 compatibility with the present and future standards.
Chrome Beta is a 17Mb free download available on selected countries via Android Market only for Android 4.0 smartphones and tablets. And that is the first bad news: Gingerbread (2.3) and Honeycomb (3.x) users don’t have a Chrome version now and there is no official communication about a version for those platforms in the future. Currently, only 1% of Android users are using 4.0+.
The browser claims to have a faster scrolling experience and I’m not sure yet if SPDY protocol is supported, but I hope so.
One of the most important features for me: it’s an Android app downloaded from the Market. Why this is so important? Because it can be updated in the same way. We will get auto-update feature on Chrome, and that’s the best news we as web developers can receive.
Chrome for Android has a nice UI optimized for tabbed browsing using a new tab browsing experience compared to Android Browser. You can flip/swipe between tabs, as in webOS (if you are creating a touch game, you should avoid use the edges).
It supports Incognito mode (private mode) and a feature called Bandwidth management that preload pages when you are using Wi-Fi. There is no information on how this feature works (rel=preload maybe?) but I believe the search bar is using it. When you search something the first results are being preloaded by default if you are on Wi-Fi.
The user interface includes a fixed URL bar, a tab button and a menu button. The URL bar is always visible and there is no way to hide it, as in Safari for iOS or even Android Browser. The URL bar doesn’t show the page’s title or the page’s icon, just the URL.
I really like the new feature called Link Preview that will make a quick zoom on areas with lots of links in a site without a mobile viewport (see image below). This feature helps the user selecting the right link.
Of course, if you sign in with your Google Account, you will get full synchronization between Chrome for Desktop and Chrome for Android, search suggestions, opened tabs, history and bookmarks.
To avoid misdetection of Chrome for Android as a desktop, the user agent looks like:
Mozilla/5.0 (Linux; U; Android 4.0.2; en-us; Galaxy Nexus Build/ICL53F) AppleWebKit/535.7 (KHTML, like Gecko) CrMo/16.0.912.75 Mobile Safari/535.7**
As you can see, there is no Chrome string there; just CrMo (Chrome Mobile?) and other Android-typical strings.
I’ve made a quick test on some websites, and they are all detecting Chrome as Android Browser.
Remote debugging #
For developers, remote debugging and profiling is one of the greatest additions. I’ve received lot of feedback a month ago when I’ve created iWebInspector, a remote debugger helper for iOS Simulator. Now you have the same tool for Android devices.
It allows us to use a full Remote Inspector –the same as in Chrome for Desktop- remotely using USB debugging. Unfortunately, this feature doesn’t work via the network as in BlackBerry Browser for PlayBook and Smartphones 7.0, Weinre or iWebInspector.
You need to use USB debugging mode, meaning that you as a web developer needs the Android SDK tools, the debugging drivers of your phone for Windows users and a couple of command-line tools to deal with. Maybe, it’s time for a iWebInspector for Chrome to help designers with this process :). I believe this process should be easier for web developer but it’s not a big deal when you understand how to do it.
For more information and instructions on how to set this up, visit http://code.google.com/chrome/mobile/docs/debugging.html
Hybrids and PhoneGap #
This is a big question. Every developer that had experience with hybrid development in Android, including PhoneGap apps knows that sometimes the embedded WebView on Android gives us lots of problems compared with UIWebView on iOS.
At least today in this first beta, there is no way to use Chrome engine inside your hybrid Android app. However, in the FAQ this feature is mentioned so I believe it’s being under consideration so go now and help me ask for this feature. In the future, PhoneGap or other frameworks can detect if Chrome is available and use ChromeView instead of the original WebView. Let’s dream with that :)
About UI frameworks, just a quick test says that jQuery Mobile and Sencha Touch seems to work properly on Chrome for Android.
HTML5 compatibility #
The Chrome team did a good job porting Chromium to Android with the latest HTML5 APIs that we already have in Chrome for Desktop and Chrome OS. First, we have almost every API available in Android Browser 4.0. The only missing API is Network Information API that is on Android Browser since 2.2 and it’s not here on Chrome.
We have the typical HTML5 basic support, such as new elements, video –H.264 and WebM support- & audio tags, Geolocation, hardware accelerated Canvas (2D Drawing), Web Storage, SQL Storage (ok, we can discuss if it’s an HTML5 API), Offline AppCache, and all the CSS3 stuff, such as selectors, effects, media queries, transforms, transitions and animations.
The browser also adds support for mobile-specific stuff such as Touch events, viewport definition, mobile icon support (apple-touch-icon) for bookmarks and orientation change events to the Chrome for Desktop compatibility APIs.
- History API
- SVG and inline SVG
- XMLHttpRequest 2.0
- Device Orientation & Motion API (accelerometer and gyroscope)
- Media Capture API
- Web Workers (not shared)
- Web Timing API (available also on iOS5 and IE9 on Windows Phone 7.5)
- Chrome Performance Timing API (http://ecmanaut.blogspot.com/2010/06/google-bom-feature-ms-since-pageload.html)
- File API (File, FileList, FileReader, Blob types)
- Console API
- Content Editing API (contenteditable attribute and selection API)
- Flex CSS Model (the legacy version, not the latest standard)
- Form validation and new input types including range and date selections (excepting week selector).
- Fixed positioning and scrolling areas (overflow: scroll).
And for new APIs in the mobile world, we can mention compatibility with:
- Page Visibility API
- IndexedDB –the standard replacement for the SQL Storage API- (Firefox already supported this on mobile)
- Request Animation Frame for smoother animations using HTML5
- FullScreen API, but it’s not working properly yet (see below)
Missing features #
Looking at the APIs available on other mobile browsers or in Chrome for Desktop that are not there yet in this first beta version for Android:
- WebGL, aka 3D drawing API. The objects seems to be there as in iOS 4 and 5 but there is no way to use it.
- Network Information API
- Full Camera API (for using the camera source in a
<video>tag and create augmented reality experiences)
- Notification API, available in Chrome for Desktop and Firefox for Android
- Gesture Events (they are only on Safari for iOS)
- Flash Player support. However, this is a good decision, as Adobe will not support Flash Player in mobile in the future.
- No home screen / applications menu icon support yet.
- Some text-based input types don’t change virtual keyboard, such as email and url while number-based input types do.
- There is still no support for datalist, menu and command. However, almost no browser is supporting these HTML5 elements.
- No Input Speech extension for input types, available on Chrome for Desktop with the x-input-speech.
- No extensions support yet. However, the APIs for extensions are there but disabled, such as window.chrome.app.experimental APIs.
- SearchBox API is there but is not working. This API allow us to communicate with the URL bar (known as Omnibox in the Chrome world) while the user is typing or searching.
- No compass support
- No Web Audio support available on Chrome for Desktop
- Custom Protocol Handler API is there but it’s disabled.
This is the first beta version and there are still some bugs to be solved . If you find a bug, you can fill a request.
- SearchBox, Custom Protocol Handler and Add Search Providers API are there but they don’t work
Emulating Chrome for Android #
Unfortunately, there is no official way to emulate Chrome for Android. You can say that Chrome for Desktop should be enough but the reality is that it’s not. Mobile has specific design properties that need other kind of testing. While the code is based on Chromium, as far as I know, it’s not exactly 100% the same source code as Google for Desktop, so we still need testing on it.
We have Android Emulator; however there is no official way to install Chrome on it. Android Emulator doesn’t support Market so you can’t install the Chrome package. If you are curious like me then you will find a way to get the Chrome package and install it on the emulator. Yes, I did it (don’t ask me how). However, Chrome is not working fully (it has something to do with some libraries). I could get the Chrome UI but not the ChromeView (the rendering area), so nothing is shown on the screen. I hope the Chrome team can figure out some way to emulate it soon. I know they are reading this post (right? ;) ), so make us happy team.
It’s a great time for the mobile web. This release even put in hold my vacations in the great Tokyo for a couple of hours so I could make this review.
A new first-class browser appears in the mobile web space, joining the list to Firefox, Safari and Internet Explorer. We are going to deal in the next –maybe two- years with Chrome and Android Browser at the same time but for the future, it was a good decision from Google.
I’ll continue my testing over a real device with Android 4.0 and post my results here. I’ll also update Mobile HTML5 in the next few days.
Did you find anything else on Chrome for Android? Do you have any other ideas? Use the comments area below.