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

Tags: ,

Loading Facebook Comments ...
  1. #1 written by José González DAmico (@Jose_GD) October 19th, 2011 at 13:54

    Nice article Max. Like you, I feel disappointed that ICS didn’t include Chrome

    Saludos desde Corrientes!

    RE Q
  2. #2 written by Trygve Lie October 19th, 2011 at 16:24

    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.

    RE Q
  3. #3 written by firt October 19th, 2011 at 16:29

    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).

    RE Q
  4. #4 written by Jonas October 19th, 2011 at 16:41

    I just hope that multitouch events finally work. -.-

    RE Q
  5. #5 written by firt October 19th, 2011 at 16:42

    No way to try it without a real device :(

    RE Q
  6. #6 written by Atanas October 19th, 2011 at 17:11

    GPU acceleration by any chance?

    RE Q
  7. #7 written by firt October 19th, 2011 at 17:12

    Impossible to say until having a real device

    RE Q
  8. #8 written by Simon MacDonald October 19th, 2011 at 19:55

    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.

    RE Q
  9. #9 written by Juhani October 20th, 2011 at 13:20

    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!

    RE Q
  10. #10 written by firt October 20th, 2011 at 14:17

    I don’t remember exactly when was some kind of official announcement, but there are plenty of references: http://news.cnet.com/8301-30685_3-20095696-264/google-move-hints-at-chrome-for-android/ and it’s a fact for Googlers. Talking with them feels like: “we are not making too much effort right now on Android Browser because it will become Chrome someday and we will not maintain two browsers”. It’s the logical decision.

    RE Q
  11. #11 written by Victro October 21st, 2011 at 11:36

    @ Trygve Lie
    Websockets too not supported by android 4…
    =)

    No Server-sent events (BTW, does anybody use it?)
    but there are CORS+XHR 2, so
    you can use polyfill for EventSource:
    https://github.com/Yaffle/EventSource

    RE Q
  12. #12 written by Luis Montes October 22nd, 2011 at 04:35

    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.

    RE Q
  13. #13 written by Luis October 25th, 2011 at 16:06

    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.

    RE Q

SetPageWidth