HTML5 Zone is brought to you in partnership with:

Mobile and web 2.0 developer, consultant and speaker. Author of "Programming the Mobile Web" book, published by O'Reilly in 2010. Forum Nokia Champion. Maximiliano is a DZone MVB and is not an employee of DZone and has posted 35 posts at DZone. You can read more from them at their website. View Full User Profile

Overview of HTML5 Support in the Android 4.0 Browser

10.20.2011
| 34362 views |
  • submit to reddit

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.
References
Published at DZone with permission of Maximiliano Firtman, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Robert Craft replied on Thu, 2012/01/26 - 6:56am

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.

Spring Security

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.