6.2 Enter Sony Ericsson

In the first few years of the new millennium, cellular phone manufacturers like Sony Ericsson added features to their products at a furious pace. The bulky communications devices of the middle of the 1990s developed into slender all-purpose devices, with high-resolution color displays, three-dimensional downloadable games, built-in cameras and music players.

It is no surprise, then, that Sony Ericsson’s codebase ballooned in size and complexity. At the time when Ericsson and Sony joined forces, most of the codebase was written in C, and consisted of a mixture of user-facing applications, services running in their own processes and libraries running in the caller’s context. Code running in different processes communicated using a technology requiring developers to handle marshalling manually.¹

In ECM, Sony Ericsson saw the potential to modularize its codebase by making use of ECM’s object model for internal projects. However, ECM was found wanting in some areas, prompting Sony Ericsson to devise an extended version, named ECM Extended, or ECMX for short.² A number of features have been added to ECMX over the years, including the ability to generate proxies for inter-process communication, a Java language binding, single implementation inheritance, execution tracing and a declarative means of ensuring thread-safety.³ The first two features are discussed at some length in this section, and execution tracing is the subject of Chapter 7.

ECM and ECMX remain binary compatible, enabling an ECMX class to implement an OPA outgoing interface. However, Sony Ericsson’s IDL dialect is no longer fully compatible with EIDL, as ST-Ericsson continued to add new features to its version after ECMX was born. There are plans to alleviate this situation through closer cooperation between Sony Ericsson and ST-Ericsson, with the desired outcome of only having one IDL dialect, one IDL compiler, and one ECM/ECMX runtime system.

Sony Ericsson has traditionally elected to link its software statically with ST-Ericsson’s platform. There have been efforts in recent years to separate the software into dynamically linkable modules, primarily to reduce build times and to ensure that there are no unwanted dependencies between modules. This effort is developed in-house, and does not make use of ST-Ericsson’s application suites. Dynamically linked modules are required to expose their functionality exclusively through IDL interfaces, thus using the indirection of dispatch tables not only to facilitate dynamic dispatch, but also dynamic linking (as discussed in section 4.4.4).

Like ST-Ericsson’s application suites, Sony Ericsson’s modules in some respects qualify as software components, but only from a technical point of view, as they are not intended to foster a vibrant component ecosystem comprised of third-party components (though they would likely make a good base on which to build a component model).

Sony Ericsson does make use of third-party libraries in its phones (including the Access NetFront web browser and Nuance’s T9 predictive text input software), but these libraries are typically shipped by their vendors as pre-compiled libraries bundled with C header files or as (often obfuscated) C source code. Integrating third-party code in this fashion is expensive and labor-intensive, as “glue code” must often be written that gives the third-party code access to the native environment (such as drawing to the screen), or that replaces libraries bundled with the third-party software with calls to pre-existing code with equivalent functionality (a practice which helps cut down on code size).

Sony Ericsson’s phones offer one environment, though, that allows for separately deployed third-party extensions that are loaded at runtime and have access to a rich object-oriented library: Java applications. These applications have many of the properties of software components, including being written to vendor-agnostic standards.⁴ As applications, though, they must be considered too coarse-grained to be considered true components, much like applications for desktop computers.

Footnotes

1. Sony Ericsson sells phones that run a variety of operating systems, including Symbian, Windows Mobile and the Linux-based Android. Network access is typically provided by a second chip from ST-Ericsson running Enea’s OSE real-time operating system. The work related to Sony Ericsson presented in this thesis invariably concerns the company’s so-called “central” phones, which make up the bulk of sales and are primarily developed in Lund, Sweden. The application software of these phones either runs directly on ST-Ericsson’s network access CPU, or on a dedicated CPU also running OSE.
2. The ECMX name is rarely used within Sony Ericsson, and few developers recognize it. Instead, the technology is simply referred to as “IDL.” This thesis uses the ECMX name to avoid confusion with other interface description languages and to make the ECM heritage clear.
3. “Thread-safety” is somewhat of a misnomer when applied to Sony Ericsson’s system, as the main use of this declarative attribute is to protect code from concurrent access by multiple processes. The memory management unit (MMU) in Sony Ericsson’s OSE-based products is typically not used to protect the memory owned by one process from tampering by other processes, though there are exceptions.
4. Java applications can often elect to use proprietary extensions, though.