email article printer friendly more resources

Migrate Mobile Client Applications
Port your applications built for the S60 1st/2nd Editions to the S60 3rd Edition platform to take advantage of the Symbian security architecture.
by Phong Vu

April 17, 2006

The S60 3rd Edition platform is based on the Symbian OS platform security architecture (Symbian OS 9.1), which is rearchitected from its previous versions to meet the security requirements of the open mobile phone platform. The primary aims of the Symbian OS platform security architecture are protecting the integrity of the phone; providing confidentiality for sensitive data; controlling access to sensitive operations; and preventing—as opposed to detecting and reacting to avoid corruption of binaries and data—and avoiding misuse or abuse of operations.

The capability model and data caging scheme are among the core concepts in the platform security. Capabilities determine the privilege of a process to perform sensitive operations on a mobile device, and data caging provides a mechanism of file-access control.

Source code and binary code breaks were inevitable because of the evolution from nonsecure to the secure platform architecture. However, the changes were done deliberately and with great control to minimize the effects on porting client applications from previous releases of the Symbian OS platform.

Porting S60 client applications implemented on the S60 2nd Edition platform to the 3rd Edition can be as simple as doing little modifications in a few places and recompiling the application. However, the porting can be much more complicated depending on the implementation of a particular application, especially if the application involves a client/server solution and the third-party server application was implemented using Symbian Epoc Kernel Architecture 1 (EKA1) used in the S60 2nd Edition.

Let's take a look at the basic components and the differences among client applications developed for S60 1st and 2nd Editions and for the 3rd Edition. This comparison will give you a starting point for your migration work.

Comparing MMPs
If you compare the MMP files among the S60 3rd Edition and the previous two editions, the first feature you'll notice is the change of application types (see Table 1). In S60 1st and 2nd Editions, the target path for an application needs to be defined explicitly in the MMP file; in S60 3rd Edition, all executable programs and DLLs must be located in the \sys\bin\ location, and there is no need to specify the target path in the MMP file.

There are some new keywords to be declared in an MMP file for a S60 3rd Edition application project:

• VENDORID defines a vendor identifier (VID). The VID uniquely identifies the source of the application.
• SECUREID defines the secure identifier (SID), which is a locally unique identifier (that is, in the device where it's installed). Each executable contains a secure identifier. The purpose of a SID is to determine which private directory a process can access and identify the caller applications. If a SECUREID statement is not given, the UID3 specified in the MMP file is used.
• CAPABILITY defines the capabilities for the application. If this keyword is not present in the MMP file, the default CAPABILITY NONE is used.

Application resource files' locations are also changed in the 3rd Edition to comply with the data caging scheme (see Table 2 for a comparison of file locations between both the first and second editions and the third edition of the platform).

Changes in the application information file framework. In S60 3rd Edition, application information files (for example, appname.aif) are replaced by application registration information files (for example, appname_reg.rsc), which support scalable and localizable application icons and captions.

Because the system folders such as \sys\bin, \resource\apps\, resource\plugins, and so on are flat directories—meaning you cannot create any subfolder under those folders and all client applications are installed under the same locations—the potential problem of applications' file names crashing is higher than in the previous platform releases where most of your application components are stored under your own application's folder name. When the installer application detects an existing file that has the same file name as your application's file that is being copied into the same subdirectory (even on a different drive), the installer application will stop the installation process.

Therefore, make sure that your executable program and its components' files names are unique. If your application and its component files (DLLs, or resources that go under \resource\apps\) have popular names—for example, addressbook.exe, appengine.dll, or image1.mbm—using the UID3 of the application or the DLL together with the name of the component to make a unique file name—for example, appengine_ a0000180.dll or image1_ a0000180.mbm—is recommended.