David Karlsson, Sony Ericsson software architect

Hi, I’m David Karlsson, a Sony Ericsson Software Architect. My work mainly involves giving architectural guidance and technical support to our development partners and third party vendors. One important developer topic that comes up frequently is how to reduce the APK file size of an app. Developers who are submitting apps to Android Market™ sometimes discover that their APK file exceeds 50 MB, the current upload size limit. But you don’t have to accept the APK file size as is. There are ways you can reduce your APK file size.

What is an APK file?

An APK is an Android application package file. Each Android application is compiled and packaged in a single file that includes all of the application’s code (.dex files), resources, assets, and manifest file. The APK file is basically a .zip file, so there’s no way of compressing its size any further.

Why you should consider keeping files as small as possible

Memory space on smartphones is often a competitive area, now that most users are storing music, video, messages are more, in addition to downloading apps. The smaller you make your APK, the better it is for the user, and that may be a deciding factor on whether to download your app, versus a similar app that takes up more phone memory.

Tips for reducing file size

Here are a number of recommendations for reducing static footprint. You can choose the ones that fit best for your own particular needs.

ProGuard

A tool for code shrinking, like ProGuard, will significantly reduce the static foot print. The tool is available at sourceforge. Note that it is very important to re-test all of the application after applying ProGuard since it may change the application behavior. As ProGuard replaces the application symbols, to make the code difficult to read, it is important that you retain the symbol mapping, so that you can translate a stack trace back to the original symbols if you have to investigate a crash in your application.

Removal of debug information

We recommend that you remove all debug-related functionality from the application. The application generally does not see or use this data, and the Android operating system does not require it to run the application. Hence, the debug information only wastes space, and should be removed.

To accomplish this, all debug related functionality must be enclosed in conditional blocks, like below:

static final debug = false;

if (debug) {

          Log.v(TAG, “Debug …”);

}

It is important that the debug flag is set at compile time (i.e. declared as static final) for the compiler to be able to completely remove all debug functionality. Creating your own debug method like the one shown below is not a good idea because the call to myDebugPrint() is not enclosed by a conditional block, which means that the compiler must retain information about myDebugPrint() in the calling class.

public void myDebugPrint() {

    if (Debug) {

              Log.v(TAG, “Debug …”);

    }

}

…

myDebugPrint()

…

Removal of debug symbols from native libraries

Using debug symbols makes sense if your application is still in development, and still requires debugging. But if debug symbols are still appearing when you compile a release build, and if you want to remove them, then we recommend that the Debug symbols be removed from native libraries (.so files). This is done using the arm-eabi-strip command, from the Android NDK.

Recommended media formats

If your application relies heavily on images, audio or video, another way you can reduce the APK size is by using certain media formats. We recommend that you use the following media formats for images, audio and video:

• Images: PNG or JPEG. Use PNGs; since it is a lossless format it is very suitable for textures and artwork as there will be no visual artefacts from the compression. If there are space constraints, use JPEGs or a combination of PNGs and JPEGs. A high quality JPEG image may work fine for large photo-realistic images, which the JPEG compression scheme is optimised for.
• Audio: AAC Audio is recommended for all audio resources. AAC achieves better compression at a given quality, compared to mp3 or Ogg Vorbis. Raw formats such as WAV should never be used. The common rational for using the WAV format is that decoding compressed audio streams usually means high latency at playback. However, Android provides the Sound Pool API which enables applications to use compressed audio streams without the penalty of high latency.
• Video: Use H264 AVC. Encode the video to a resolution no larger than the screen resolution of the target device (if known).

Optimise PNG sizes without losing quality

If you use PNG format, PNG images can be reduced in file size without losing quality. To do this, use a tool such as OptiPNG or PNGCrush. Both are great for reducing PNG file size while still ensuring image quality. PNGcrush is an open-source program that iterates over PNG filters and zlib (Deflate) parameters, compresses the image repeatedly using each parameter configuration, and chooses the configuration that yields the smallest compressed (IDAT) output. On the other hand, OptiPNG performs the trials entirely in memory, and writes only the final output file on the disk. Moreover, it offers multiple optimization presets to the user.

Use 9patch PNGs to scale your images

A 9patch png is a special format for PNG that can be used for backgrounds. Nine patch images are especially useful when designing buttons. Instead of defining a regular bitmap to be used as a background, a 9patch defines nine segments – for each of the four corners, the four edges, and the centre. (See illustration).

Segments defined for 9patch PNG.

When you use a 9patch image, the image is subject to the following conditions:

• The corner segments are never scaled.
• The edge segments are repeated along the edge of the in order to fill the edge between the corner segments.
• The centre segment is repeated to fill the centre of the background between the four edges.
• The illustration below shows two buttons. The background of each button is generated from the same 9patch.
  

  Example of buttons generated from the same 9patch file.

 A single 9patch PNG can be used to replace many background images, as it can scale to fill the size of the control. Equally, a single 9patch image can be used on all devices of the same dpi screen, removing the need for screen-dependent backgrounds.

Remove unused resources

Another potential group of space wasters to consider for removal from your APK file are unused resources in your res directory, such as unused layouts, drawables and colors. To detect unused resources in your APK which might be able to be removed, use the android-unused-resources tool. Android Unused Resources is a Java application that will scan your project for unused resources.

Avoid duplication

Making sure that your application doesn’t have duplicate functionality or duplicate assets is an obvious way to avoid having unnecessary files in your APK. It is important to understand which Android APIs you use, and the full functionality that each provides. It could be that one Android API is already doing the work of another API. Duplicated assets (strings, bitmaps etc) are also a waste of space, and can be easily avoided. To a lesser extent, duplicated code will also unnecessarily increase the size of the delivered binary.

***

If you have any questions on how to reduce APK file size, feel free to leave a comment and we’ll get back to you with an answer as soon as possible.

More information

• Read our developer tip about installing large APK files to the SD card.
• Read our developer tutorial on how to use multiple APK support.

This way, we would like to continue to be transparent, share our knowledge, and get external developer contributions to make the tools even better. On our GitHub, you can also find our Web SDK  project we published a while back, and a project called DrmLicenseService, which we will tell more about soon. Stay tuned for more information about open source projects going forward!

In the ANT+ ecosystem, an Android smartphone could be used in several different ways. It could be the sensor broadcasting data, or the receiver storing data and possibly displaying it. But it could also be the Internet gateway to publish data. Or, it could be everything at once. At Sony Ericsson, we’re happy to have included support for this interesting and useful technology in the new Xperia™ S and Xperia™ ion. Besides these phones, Sony Ericsson has released several phones supporting ANT+ previously, including all 2011 Xperia™ phones except Xperia™ PLAY.

To find out more about ANT+ and the latest news about the ANT+ emulator, we spoke with Jeff Fung, who is one of the main developers at Dynastream.

Awhile back, we brought you an article on how to get your apps to work with the Xperia™ active pressure sensor. In that post, we provided instructions on how to create a simple app that could read data from the pressure sensor, along with tips and code examples to get your app to work with the pressure sensor. This tutorial builds upon that information, and provides you with a code example to show how to create applications that measure altitude differences and vertical air speed using the Xperia™ active pressure sensor. We’ve also created a small app  that demonstrates how the Xperia™ active’s barometric air pressure sensor can be used to measure altitude differences and vertical speed.

The 2012 AT&T Developer Summit will take place on January 8-9, at the Palms Casino Resort in Las Vegas, Nevada. This year’s event will focus on about emerging technologies, and will bring some nice opportunities to network with the industry’s top professionals and experts.

You can find the Developer World team in the Sony Ericsson booth at the Summit Expo on Jan 9, between 11AM and 3PM. Here you will also get to see and get demonstrations of all our latest products, and maybe even the chance to win a cool prize!

See you in Vegas!

More information:

• Learn more about the 2012 AT&T Developer Summit.
• Stay connected with us and all our latest CES news through Twitter (@SonyEricssonDev).

This ROM is strictly targeting advanced developers, and it will not work for ordinary everyday usage, as it only has a limited set of features working (you can for example not make any phone calls). Several more legal and usage conditions apply – please see the Important information section below for more details.

As you read this, a few weeks have passed since the source code for Ice Cream Sandwich was released. Since then, the Sony Ericsson engineering teams have been working hard on all the activities needed to roll out the final software upgrade of Ice Cream Sandwich for the 2011 Xperia™, as previously described in our article Ice Cream Sandwich – from source code to software upgrade.

Creating a full software upgrade is a complex process involving hardware bring up of the lower software layers, software and feature adaptations, certifications and approvals. However, even though we are now in the Bring up phase, we wanted to release a snapshot of where we are today, for advanced developers in the open community who want to try it out.

Important information
Since this is far from the final software upgrade roll out, there are a few things to pay close attention to before you download and install the ROM:

• You should be an advanced developer with extensive knowledge in how to install, and switch between different ROMs. If you are a consumer without these developer skills, then we strongly recommend you not do try this as you may damage your phone.
• You must be using Xperia™ arc S, Xperia™ neo V or Xperia™ ray, running the latest Sony Ericsson software release (which is 4.0.2.A.0.42). Please note that you can’t use the original Xperia™ arc or Xperia™ neo, as they have different partition layouts.
• You must unlock your phone using Sony Ericsson’s Unlock boot loader service, and agree to all the legal and warranty conditions that apply. Please note that you may void the warranty of your phone and/or any warranty from your operator if you unlock the boot loader of your phone. Sony Ericsson can then no longer guarantee the full functionality of your phone, and will not be responsible for any unusable functions or loss of personal data associated to the alpha ROM being flashed to the phone. Please pay special attention to the following legal statement before downloading (the full statement is available on the download link):

“You must acknowledge that the software is provided “as is” without warranty of any kind, express, or implied, and to the maximum extent permitted by applicable law.”

• Also, if you unlock the boot loader, you will not be able to download and install the final Ice Cream Sandwich software upgrade from Sony Ericsson. For additional information on limitations and warranty, please see the Sony Ericsson Unlock boot loader service.
• You should have read through and acknowledged the limitations of the software described below. 
• You must read and accept the end user license agreement on the download link, before you can download the alpha ROM zip file.

Limitations and functionality
The number of features and functionalities working and turned on in this alpha ROM are very limited. This is because many features are not yet certified, and in a few cases because we have more work to do on certain features, as they are still in the Bring up phase. These are some of the features turned off or not yet working in this alpha ROM: 

• Google Mobile Services (GMS) apps are not included (for example, Gmail, Google Maps, etc.).
• Modem is turned off and SIM card will therefore not be recognised (this also means you can’t make any phone calls).
• Bluetooth™ is turned off.
• Wi-Fi® is turned off.
• ANT+ is turned off.
• FM-radio is turned off.

In other words, this software is not intended for ordinary everyday usage – it is for demonstration purposes only. However, this alpha ROM includes a number of new features:

• New “Roboto” font.
• New “Holo” theme is supported (you are able to test apps written to make use of the Holo theme).
• Music player control from lock screen.
• Updated UI in the Settings menu.
• Updated UI in the web browser.
• Updated UI and interaction with the new messaging action bar.
• Updated UI for improved multitasking.
• Swipe to dismiss notifications, tasks and browser tabs in the Notification menu.

Check out the video in the beginning to see a demo of some of these features!

Download and install
Follow the instructions below to download and install the alpha ROM. Please note that it only works with Xperia™ arc S, Xperia™ neo V and Xperia™ ray.

1. Make sure your phone is running the latest software release, which is build number 4.0.2.A.0.42. If not, upgrade your phone through PC Companion. If you can’t upgrade to this build number, it is not possible to try the Ice Cream Sandwich alpha ROM for Xperia™ phones.
2. Go to unlockbootloader.sonyericsson.com  and unlock the boot loader of your phone. To do this, you must read through and agree to all the legal and warranty conditions that apply. 
3. Download the Ice Cream Sandwich alpha ROM for Xperia™ arc S  (132MB), the Ice Cream Sandwich alpha ROM for Xperia™ neo V (131MB) or the Ice Cream Sandwich alpha ROM for Xperia™ ray  (132MB) depending on your phone model.
4. Extract the downloaded zip file to your Android Fastboot directory. For example: ..\android-sdk\fastboot\Xperia_arcS_ICS_alpha.
5. Open a command prompt and go to your Fastboot directory: ..\android-sdk\fastboot\
6. Flash the three alpha ROM files one at a time using Fastboot. Use these three commands (replace the folder name if you are using Xperia™ neo V or Xperia™ ray):
• fastboot flash boot ..\Fastboot\Xperia_arcS_ICS_alpha\boot.img
• fastboot flash userdata ..\Fastboot\Xperia_arcS_ICS_alpha\userdata.img
• fastboot flash system ..\Fastboot\Xperia_arcS_ICS_alpha\system.img
7. Once done, please reboot your phone.

Please let us know what you think about this alpha ROM
Another ambition with this release is to work with all of the talented developers in the open community to get feedback on this alpha ROM. If you download and install the alpha ROM, please try out the software and go to our Ice Cream Sandwich alpha ROM survey for Xperia™ phones, to send us your feedback. It is very much appreciated – the summary of this survey will be used for future product and software strategies short term and long term. Your voice counts!

Additional feedback
If you want to discuss this alpha ROM initiative, please check out the Ice Cream Sandwich alpha ROM for Xperia thread on the XDA forum. Here you can discuss with other developers, and ask questions to us. We will monitor this thread and reply to any questions as soon as we can. If you have any additional ideas on what you would like us to do, feel free to drop us a comment below!

More information: 

• Download the Ice Cream Sandwich alpha ROM for Xperia™ arc S.
• Download the Ice Cream Sandwich alpha ROM for Xperia™ neo V.
• Download the Ice Cream Sandwich alpha ROM for Xperia™ ray.
• Learn what happens from the Ice Cream Sandwich source code release until the final software upgrade.
• Read about Sony Ericsson’s unlock boot loader  initiative.
• Check out the Sony Ericsson Unlock boot loader website.
• Learn how to build a Linux kernel.
• Read about and download camera libraries for the 2011 Xperia™ phones.

Head over to the design3 blog post to read more more about it! design3 is one of the leading game development portals in the industry. You can find hundreds of hours of video tutorials on game engine, 3D tools, 2D tools, and much more on their website. For more information about Xperia™ PLAY game development, check out our game development section.

In our pursuit for greater openness in the Android community, we would like to share some exclusive information of the different phases and activities of Sony Ericsson’s Android development, starting with the release of the Ice Cream Sandwich source code, and leading up to the release of a software upgrade for you to download on your phone. Find out more after the jump!

On the Sony Ericsson Product Blog, we have previously announced that all our 2011 Xperia™ phones will receive software upgrades  to Ice Cream Sandwich (please check the Sony Ericsson Product Blog for upcoming announcements regarding the timing for these software upgrades). However, before we can roll out those software upgrades, there are a lot of activities to first of all get Ice Cream Sandwich to work and become stable on all Sony Ericsson phones. We call this the Bring up phase.

Secondly, and perhaps most important, we must certify and approve the new software release with all the different technologies, networks, and hardware that a modern smartphone should work with. We call this the Certification and approval phase.

Illustration showing activities from source code release, to software upgrade.

The Bring up phase: Getting Ice Cream Sandwich to work on our phones
On November 14, the Ice Cream Sandwich source code  was made available. This was also the day when our engineers started their work in order to get Ice Cream Sandwich to run on the 2011 Xperia™ phones, by starting the Bring up phase, as we didn’t have pre-access to the Ice Cream Sandwich source code.

The first thing we do is to integrate the latest available Android source code with the Sony Ericsson development branch, to make sure it compiles. This is done by our engineering teams, who in addition need to confirm that all test and debugging tools are in place. Since we will continue to build more on this basic set of code, the stability of the software is very important at this stage.

In the first Ice Cream Sandwich source code that was released, the Hardware Abstraction Layer (HAL) – the software layer giving applications direct access to the hardware components – was to some extent adapted for a Texas Instruments hardware platform. However, for all 2011 Xperia™ phones, we used a Qualcomm hardware platform. This means we have to replace the default HAL coming with first source code released for Ice Cream Sandwich, with our own HAL.

The HAL changes have impact on several features on a phone, including the camera, different sensors (such as proximity, light, accelerometer and compass), audio, Bluetooth™, Wi-Fi™, GPS, as well as multimedia and graphics components. Thus, we do not only have to modify and configure the HAL according to the Qualcomm hardware platform, but also all the other hardware components used in a phone.

Another layer of complexity to the adaption work is the fact that even though all the 2011 Xperia™ products are based on the same hardware platform and use the Qualcomm 8255 chipset, there are several variations in screen size, memory, peripheral components (such as the camera) and modem constellations. At this stage, we make sure to get all the legacy and basic functionalities (such as phone calls, SMS, MMS, SIM card and access to the SD card) to work.

Integrating Android patches
In the Bring up phase, another task is to integrate a number of patches, to improve and adapt the Android legacy code according to our needs. These are customised patches important to the phone, such as improved error handling. To avoid fragmentation, many of these customised patches are actually contributed back to the Android Open Source Project, so that they are included in the default Android source code for the next software release. This work has made Sony Ericsson one of the main contributors to Android. At this stage, we also integrate our own feature upgrades, such as customised graphics.

As we incorporate these customisations, we also do a basic quality check to confirm that all the integrated changes fulfill the required quality level. Here we run many tests cases, such as confirming the functionality of the music player, video streaming, USB and DRM. When we eventually merge all the functionalities in to one code branch, we run more tests to ensure that all our legacy user scenarios run without problems. This also includes that we ensure that apps installed from Android Market are working properly in general.

Getting the software stable and adding localisation
When all functionalities have been merged into one code branch, we start on the stability tests to make sure the software runs stable in all sorts of use cases. Besides pure lab testing, we rely on a number of live users for testing and reporting defects. And along with pure stability testing, we are continuing with the quality tests. For example, we are performing power consumption tests to improve the power consumption in different user scenarios.

Another important task in this stage is to integrate the localisation support in our applications. In most cases, we are adding more languages to the Android software itself. For example, in the software upgrade we rolled out to our 2011 Xperia™ phones in October, we added support for bi-directional languages such as Arabic.

Once all of these tasks are done, and the software is stable and tested, the software is ready to be submitted for certifications. However, the Bring up phase is overlapped by the Certification and approval phase, as some parts of the software are ready for certification earlier than others. As soon as a specific software module is ready, it’s sent for certification. So while one module can be in the Certification and approval phase, others are still in the Bring up phase.

Illustration showing simplified Android architecture.

The Certification and approval phase: Making sure the software and hardware is compliant
A phone comes with parts and software working with a number of different technologies, such as Bluetooth, Wi-Fi, modem and so on. To use these technologies, we have to certify that the new software is compliant with these technology standards. We therefore need to certify a new software release for all of these different technologies due to operator community requirements (GCF , PTCRB , CCF) and Intellectual Property Rights (IPRs), if we have modified the software module related to such technology.

To a great extent, we try to get global certifications, but in many cases specific countries demand specific tests. For a global, worldwide product, we need local certifications approvals in up to 80 countries. For all these external certifications we are either allowed to test ourselves, and submit evidence that we passed, or we can get external test houses, such as Cetecom, to perform the tests.

Besides the operator and IPR certifications, we must externally comply with certifications for regulatory requirements. For example, we must show evidence that we comply with spurious emissions, SAR, EMC, as well as other environmental and health compliances. But when it comes to software upgrades for existing phone models, not all of the regulatory certifications are needed as they have already been performed once.

On top of this, Sony Ericsson is doing internal self certifications in areas we have identified as extra important to deliver the highest possible quality.

All certifications are based on each phone model, and even if a phone model has been certified with a previous software release, the parts which have been changed must be recertified if we are doing a new software release. So if we, for example, have made changes to the Wi-Fi module in an existing phone model, we need to recertify it. When we are working with a new Android release, such as Ice Cream Sandwich, all the affected areas must be recertified.

Another example is if the Bluetooth stack is changed. Then we have to recertify the Bluetooth part of the new software release. There are many apps that needs to be recertified for each of our phones, if they are changed in a new Android software release, for example Bluetooth, MMS, Wi-Fi, HDMI, DLNA and Adobe FLASH. Besides this, we rerun the Android Compatibility Test Suite (CTS) to make sure that we are compliant.

Contrary to what people may think, it is not the Bring up phase, but the Certification and approval phase that is the most time consuming process when it comes to getting a new software release out on our phones. This is one of the major tasks that are legally required from us as phone manufacturer, but is a task that the custom ROM community doesn’t have to take into consideration. Furthermore, by putting all this efforts into testing and certification, we ensure that quality and conformance is at a top level, in benefit for all consumers worldwide.

Additional approvals might be needed
In some cases, the new and complete software release has to be approved to be used in all the different networks that our phones should work in. Many operators also want to customise the software according to their requirements, which in turn are based on their market, network, differentiation and business model. We implement all of these customisations and create a variety of software packages and releases for each operator.

When all of this is done, we are ready to roll out the software release variants as software upgrades to operators and consumers around the world. The software upgrade can then be downloaded and installed either in the operator’s own update tool (if they have one), from Sony Ericsson’s PC Companion tool, or by over the air updates (FOTA – Firmware Over the Air).

***

It should be pointed out that this summary of all the activities and phases is somewhat simplified and is meant to provide a general picture of what we do from the release of the first Ice Cream Sandwich source code, until it is released to our consumers. From Sony Ericsson, we hope it has shed some of light on the work being done for the software upgrades.

If you have any question on this topic, feel free to drop us a line below. We will try to respond as soon as possible. For general software announcements and product information, please check the Sony Ericsson Product Blog regularly.

More information:

• Check the Sony Ericsson Product Blog regularly for product information and software announcements.
• Read the 2011 Xperia™ phones Ice Cream Sandwich software upgrade  announcement on the Product Blog.

In this article, Anders Isberg from Sony Ericsson’s Technology Reseach department explains more about WebGL and what to think of when you develop 3D web applications for touch-enabled devices. If you scroll down, you will also find three WebGL examples that you can browse to from the Android browser, if you have the latest software on your 2011 Xperia™ phone. You can also check out how it looks in the video above.

***

Earlier this year, I made a blog post about an internal WebGL research project  on how WebGL could be implemented in phones. Based on the feedback we received back then, we decided to launch support for WebGL in the latest software upgrade  we rolled out for the 2011 Xperia™ phones during this autumn and winter. Now let’s take a closer look at what WebGL support means for mobile.

Anders Isberg, Sony Ericsson.

What is required to implement a WebGL application?
Unlike other 3D web technologies, WebGL will not require any plug-in modules. Once the device is WebGL enabled, no further installations are required, and developers can go ahead and explore the WebGL™ functionality. To learn how to develop WebGL applications, we recommend visiting one of the following online resources that gives an introduction on WebGL application development, for example, Learning WebGL or the Khronos WebGL Tutorial.

Due to the fact that WebGL is a low level API, the technical threshold is rather high if you are new to developing WebGL applications. However, there is no reason to be scared by this. There are several JavaScript frameworks available that make it easier to create WebGL applications. Several of these can be found on the Khronos WebGL Wiki.

Navigating and interacting with 3D web applications
Most of the existing WebGL applications available on the web are tailored for a desktop environment. Consequently, those applications are making use of the W3C DOM Mouse and Keyboard events to navigate and control the WebGL application. However, on a mobile device, the touch events must be used to navigate and control the 3D scene. The Android web browser supports three basic touch events that can be used to navigate and control the WebGL application:

• touchstart: generated when the finger is placed on a selected DOM element.
• touchmove: generated when a finger is moved over a DOM element.
• touchend: generated when the finger is removed from a DOM element.

The following code example shows how an event listener is assigned to touchmove event on a WebGL accelerated HTML Canvas element:

// Add an event listener on the WebGL™ canvas
webglcanvas.addEventListener('touchmove', onTouchMove);
function onTouchMove (event) {
// Cancel the default event handler
event.preventDefault();
// Readout the current X and Y coordinate relative the viewport
var currentX = event.targetTouches[0].clientX;
var currentY = event.targetTouches[0].clientY;
}

In many cases, the same code used to handle mouse movements can be reused for touch events. There are also frameworks available to simplify the handling of touch events. For example, there is a jQuery plugin that unifies touch and mouse events across platforms, as well as a Mobile jQuery that has support for high level events like swipe.

Considerations when developing for mobile
Devices such as Xperia™ PLAY, Xperia™ arc, Xperia™ neo and Xperia™ pro are equipped with a 1 GHz Snapdragon™ processor and an Adreno™ 205 graphics processor, so even if the processing power is not in parity with desktop computers, there are enough processing capabilities to create astonishing 3D web applications. Check out the video in the beginning to see some examples of WebGL running on a 2011 Xperia™ phone. You can also check out these examples by browsing to them from the Android browser on your 2011 Xperia™ phone, if you have the latest software. Just click one of the links to the demos below. Please be patient while the demos are loading, it might take some time. 

• WebGL-based interactive 3D demo of the Sony Ericsson logo. 
• WebGL-based interactive 3D demo of Walt Disney. 
• WebGL-based interactive 3D demo of two Ninjas.

When working with WebGL in mobile devices, it is important to take a look under the hood to get good performance. It is essential to consider how the shaders are written, how many polygons that are used in the 3D model, and to select textures carefully. At Developer World, we have published a blog post called Optimising shader performance for the Xperia™ PLAY, which includes several useful tips that can be used to enhance the performance.

One limitation in the Android browser is that web workers are not supported. For some WebGL frameworks that could be a limiting factor. For example, the WebGL framework three.js implements resource loading with web workers. In the WebGL examples listed earlier you can see how this can be solved by using a JavaScript shim layer that emulates web workers. More information about this topic is available at the Google Code Web Workers Emulation project site.

Hopefully this has given you enough information (and confidence!) to get you started with your own WebGL project! Good luck!

Anders Isberg
Master Engineer Technology Research
Sony Ericsson

More information:

• Learn more about WebGL  in Anders Isberg’s previous post.
• Check out the Learning WebGL website. 
• Find out more in the Khronos WebGL tutorial.
• Find more information about our latest software upgrade for the 2011 Xperia™ phones.
• Check out the WebGL-based interactive 3D demo of the Sony Ericsson logo. 
• Check out the WebGL-based interactive 3D demo of Walt Disney. 
• Check out the WebGL-based interactive 3D demo of two Ninjas. 
• Find out more about the WebGL framework three.js.
• Learn more about the Google Code Web Workers Emulation project.
• Learn how to optimise the shader performance for the Xperia PLAY.