Android 4.0 Browser: smartphones meet tablets on HTML5 APIs

Android 4.0 was announced and the SDK was released. So, I’ve washed my hands, I’ve opened the emulator and I’ve started to dive into the new browser and see what’s in there and what’s not. Unfortunately it’s still Android Browser and not Chrome, but it comes in a better way.

Busy month

October 2011: Busy month for mobile web world.  Just a few days ago, I’ve blogged about Safari on iOS 5; yesterday BlackBerry announced the first mobile browser with WebGL support on the (future) PlayBook platform and a few weeks ago Amazon announced Silk, a new proxy-based browser for tablets.

And now, it’s the Android turn. Android 4.0 was released and while there is no real phone yet to test it on (the Galaxy Nexus will be available soon) I’ve downloaded the emulator and I’ve tested the browser comparing it to Android 2.3 (smartphones) and Android 3.2 (tablet) that I both have on my hands.

Google announced that Google Chrome will be the future of browsing in Android but it was not 4.0 the time for that.

Smartphones meets tablets

This version merges both smartphones and tablets, so smartphones jumps from 2.3 to 4.0 acquiring all the new things on the browser available on 3.x, including:

  • SVG
  • Motion Sensor API (accelerometer and gyroscope -on compatible devices-)
  • 3D Transforms on CSS3
  • XHR 2 & CORS
  • File API
  • HTML Media Capture API for camera/microphone access through file management
  • Binary Arrays (Int16Array, Float32Array, etc.)

What’s still missing on Android 4.0

Unfortunately, there are still some missing APIs that are available on Google Chrome and on iOS5 -some of them-, including:

  • No Server-sent events (BTW, does anybody use it?)
  • No WebSockets
  • No WebWorkers
  • No IndexedDB
  • No Web Notifications (that is a real shame for this platform – Firefox on Android is doing it-)
  • No WebGL
  • No History Management API
  • No rich input controls! I’ve found a huge bug on the range input type (no rendering at all), and no date controls are working. Even it seems that Android 3.x has better support than 4.x (more testing soon)

New stuff

The new stuff for both smartphones and platforms I’ve found:

  • Navigation Timing API, same API in IE9 on Windows Phone and in Firefox 7 for Android
  • New Console API, but not working properly, for example there is a console.memory.usedJSHeapSize and console.memory.totalJSHeapSize attributes, and some new functions but I could not make them work yet.
  • The HTML5 <keygen> new form is available
  • Basic MathML seems to work

New things to know

The browser has new user features that can change the way our website will work.
  • New Incognito Tab
  • New “Labs” section where the user can add full-screen webapp support on the browser and some gestures over the browser (similar to Firefox for Android)
  • New “Request Desktop site” feature that I’m not sure exactly everything it does, but it changes the User Agent at least.

Performance

Android browser is well known as a problematic browser in terms of performance. Google in its official documentation claims to have a faster browser in 4.0 with an updated V8 JavaScript engine. The new engine shows a 35-550% performance improvement on different devices and tests according to Google. I can’t test it until have a real device with Android 4 installed.

 

Share

13 thoughts on “Android 4.0 Browser: smartphones meet tablets on HTML5 APIs

  1. Regarding Server-sent events (SSE) and your comment if anybody use it. I think more should and not just jump on WebSockets. There are many, cases where SSE fits a purpose. SSE are half duplex from the server to the client while WebSockets are full duplex with communication both ways and in ex a stockticker, monitor systems on hardware etc full duplex are not needed. Push one way from the server are just fine.

    One benefit SSE have over WebSockets today are that SSE will work trough existing infrastructure like proxies etc. Many infrastructure devices out there does sadly not understand how to handle WebSockets.

  2. I agree with you on the idea, but my question was because I’m not seeing lot of websites using it (or even understanding it).

  3. Sadly, it doesn’t look like the Media Capture API is working in the Android WebView. It works in the browser just fine but not in the WebView component. If anyone knows why, please let me know.

  4. Hey Max,

    Do you have any source reference for the “Google announced that Google Chrome will be the future of browsing in Android”. Only reference I’ve seen for Chrome on Android is a version control comment. Do you have something better?

    Cheers!

  5. Firefox for Android had WebGL support well before Blackberry had it.

    And you’re missing the Web Audio API from the list of things missing. Web Audio is necessary for low-latency audio in HTML5 gaming.

    I’m extremely dissapointed that WebGL and Websockets are missing. I’m willing to bet that if WebGL is missing, then 2d drawing context isn’t accelerated either.

    The Tmobile G1 with Android 1.0 had OpenGL hardware acceleration for native apps. A GPU was a requirement from the first day. It makes no sense not to use it.

    And there is no reasonable polyfill for websockets in multiplayer gaming. XHR2 and SSE aren’t the same thing. You need bidirectional communication without sending cookies and header for ever tiny piece of data you want to send.

    What a waste of an opportunity on a major release like this.

  6. Firefox for Android had WebGL support well before Blackberry had it.

    And youâre missing the Web Audio API from the list of things missing. Web Audio is necessary for low-latency audio in HTML5 gaming.

    Iâm extremely dissapointed that WebGL and Websockets are missing. Iâm willing to bet that if WebGL is missing, then 2d drawing context isnât accelerated either.

    The Tmobile G1 with Android 1.0 had OpenGL hardware acceleration for native apps. A GPU was a requirement from the first day. It makes no sense not to use it.

    And there is no reasonable polyfill for websockets in multiplayer gaming. XHR2 and SSE aren’t the same thing. You need bidirectional communication without sending cookies and header for ever tiny piece of data you want to send.

    What a waste of an opportunity on a major release like this.

Leave a Reply

Your email address will not be published. Required fields are marked *