Symbian Signed

From UIQ Books

Contents 1 Symbian Signed 2 Introduction to Symbian Signed 2.1 Symbian Signed Options 2.2 Further Considerations 3 Application Origin 4 Capabilities 4.1 User Capabilities 4.2 System Capabilities 4.3 Device Manufacturer Capabilities 5 Routes to Symbian Sign Your Application 5.1 Open Signed 5.1.1 Open Signed – Without Publisher ID 5.1.2 Open Signed – With Publisher ID 5.1.3 Development Certificate Request Plug-in 5.1.4 Signing with a Developer Certificate 5.1.5 Deploying Your Application 5.2 Express Signed 5.3 Certified Signed 6 Procedural Impact 7 Getting Started with Symbian Signed 7.1 Publisher ID 7.2 Symbian Signed Account 7.3 Symbian Signed and UIDs 8 Submission and Compliance Criteria 9 Symbian Signed Test Criteria 9.1 Test Criteria v3.0.0 9.1.1 Universal Tests 9.1.2 Specific Symbian OS v9.x Tests and Symbian OS v9.x Capability Access Tests 9.1.3 Internet Telephony Application Tests 9.2 Test Criteria v2.11.0 9.2.1 PKG-01 9.2.2 PKG-02 (UNI-01) 9.2.3 PKG-03 (UNI-08) 9.2.4 PKG-04 (UNI-08) 9.2.5 PKG-05 9.2.6 PKG-06 (UNI-09) 9.2.7 PKG-07 9.2.8 PKG-08 9.2.9 GEN-01 9.2.10 GEN-02 9.2.11 GEN-03 9.2.12 MEM-01 (UNI-03, UNI-04) 9.2.13 MEM-02 (UNI-04) 9.2.14 PHN-01 (UNI-02) 9.2.15 PHN-02 (UNI-06) 9.2.16 CON-01 9.2.17 CON-02 9.2.18 CON-03 9.2.19 CON-04 (UNI-07) 9.2.20 Symbian Signed Test Criteria Summary 10 Lessons Learned 10.1 Ensure you understand the capability rules 10.2 Integrate the Capability Request 10.3 Integrate the Symbian Signed Test Criteria 10.4 Ensure Infrastructure Dependencies can be Accessed

Symbian Signed

In the Building an application and Multimedia chapters, we built an application, SignedAppPhase3, that we have Symbian Signed. We indicated some of the places where you need to consider Symbian Signed during your development and design. In this chapter we will provide an overview of capabilities and the Symbian Signed process. We will examine the test cases, with particular reference to the SignedAppPhase2 example. Finally, we will provide some tips and advice based on our experience of taking applications through the process.

Introduction to Symbian Signed

Symbian Signed is a scheme run by Symbian and backed by the mobile phone industry. Symbian Signed applications follow industry-agreed quality guidelines and support Network Operator requirements for signed applications.

Symbian Signed aims to ensure applications behave correctly in three main ways:

• It confirms the application’s origin and ensures that the application does what it says it does.
• It controls access to protected APIs. These are APIs that allow sensitive operations to be performed by an application such as those that initiate billable events or that access private and personal user information.
• It specifies key test cases that all Symbian OS applications should conform to, and depending on the signing option chosen, may require independent testing of conformity.

Signing in the context of Symbian Signing is the process of encoding a tamper proof digital certificate into a SIS file which guarantees the origin of the contents of the SIS file. The certificate also grants access to selected protected APIs within Symbian OS.

Symbian Signed Options

Symbian Signed was updated in late 2007 to give you three basic options for getting your applications signed:

• Open Signed makes it easy you to sign applications for limited deployment to known devices, either for testing or for personal use. Deployment is restricted by device IMEI.
• Express Signed offers an effective signing route with minimal restrictions. There is no requirement for independent testing if you own a Publisher ID and are releasing commercial software. Freeware and shareware developers without a Publisher ID can also access this signing option via publisher partners.
• For mainstream commercial software developers, the full testing and accreditation regime of Certified Signed will be the preferred option, with entitlement to use the for Symbian OS logo to aid differentiation and brand building.

Changes compared to the previous Symbian Signed scheme include:

• TC Trustcenter introduced as new certificate authority for Symbian Signed.
• Simplification of the signing options and the signing process available to developers with the introduction of Open Signed, Express Signed and Certified Signed.
• Simplification of the Test Criteria.
• Reduction in the reliance upon independent Test Houses.

This chapter is based upon the updated scheme introduced by Symbian, although some details are still in draft at the time of writing. We will also explain some of the differences that have been introduced and cover a few cases from the previous scheme.

The Symbian Signed website, www.symbiansigned.com provides further information. Sony Ericsson and Motorola both provide specific information relating to Symbian Signed for their particular handsets.

Further Considerations

Even if your application does not require access to protected APIs, you should still consider obtaining Symbian Signed certification. Your decision whether to Symbian Sign an application or not has several downstream consequences that you should consider prior to proceeding with application development.

Some distribution channels may only take applications that have been Symbian Signed. You should check the requirements of whichever channels you intend to use to distribute and sell your application.

All applications that have passed Symbian Signed are listed within the Symbian Signed applications catalog. This catalog is made available to channel partners such as operators giving added exposure to your application.

Some mobile phones default to only allowing signed applications to be installed. Attempting to install an unsigned application on such a mobile phone reports a Certificate Error. The user may request technical assistance, or may give up and decide not to install the application.

At the time of writing, most UIQ 3 phones are unrestricted for the User capability set. This means that users can choose to install unsigned applications that need User capabilities, however the general trend is to restrict installation to only those that have been signed.

Support problems can arise for users who have installed unsigned applications. For example, a mobile operator may ask if any unsigned applications have been installed and request un-installation to be sure that the issue is not caused by the unsigned application.

Application Origin

When installing an application, UIQ will present a number of informative and warning dialog boxes to the user.

Firstly, the application (Software) name, version and supplier name are presented. The first dialog box presented to the user takes its information from the vendor name and package header fields within the package (PKG) file used to create the SIS.

; Localised vendor name
%{"Sony Ericsson Mobile Communications"}
 
; Standard PKG file header
# {"LayoutManager1"}, (0xEDEAD004), 1, 0, 0, TYPE=SA

Figure 1 Typical version and vendor details

On the face of it this seems ok, however, with an unsigned SIS file this information is not guaranteed. As developers we could put any information we desire in here.

The user has no way of knowing if the information is valid or not.

Figure 2 Unsigned applications can have any vendor details

If your application is unsigned, the installer will go on to display the following warning:

Figure 3 Vendor identity warning dialog

Many users are very conscious of malicious applications; much of this having been obtained from the desktop and laptop computer world. Some users may decide not to install your application because of this warning. If your application is Symbian Signed, however, the user should feel that they can trust the supplier details and no security warning is presented.

Capabilities

Symbian OS Platform Security uses capabilities to control access to protected functions. Examples of such protected functions are:

• access to contact or calendar information, in order to protect the user’s private data
• sending an SMS, because the user must pay
• controlling the power state of the phone, since this could cause the user to miss incoming calls.

Capabilities are simply a set of attributes an application can possess. They grant an application the privilege to access otherwise protected system resources and sensitive data through Symbian OS APIs. Around 40% of the APIs in Symbian OS v9 are classified as sensitive and require that applications have the appropriate capability to use them. The remaining 60% have no such requirement.

To access the user’s private calendar entries, your application must have the ReadUserData capability. Once granted, your application will also be able to read contact information too, because ReadUserData gives access to a number of APIs.

The capabilities are divided in to three groups, User, System and Device Manufacturer.

Capability Group	Capabilities	No Signing	Open Signed		Express Signed	Certified Signed
			Online	Offline
User	LocalServices Location NetworkServices ReadUserData WriteUserData UserEnvironmant	✓ (*)	✓	✓	✓	✓
System	PowerMgmt ProtServ ReadDeviceData SurroundingsDD SwEvent TrustedUI WriteDeviceData	×	✓	✓	✓	✓
	CommDD DiskAdmin MultimediaDD NetworkControl	×	×	✓	×	✓
Device Manufacturer	AllFiles DRM TCB	×	×	✓ (**)	×	✓ (**)

(*) Signing not required, however it is recommended, as discussed in the Further Considerations section.

(**) Subject to device manufacturer approval; each manufacturer can approve for their mobile phones only.

Prior to the changes in Symbian Signed during late 2007, the capability groups were slightly different. User capabilities were known as Basic capabilities and System capabilities were called Extended capabilities. Also, CommDD, DiskAdmin, NetworkControl and MultimediaDD were in the Device Manufacturer group.

User Capabilities

User capabilities are designed to be meaningful to mobile

phone users. Depending on mobile phone manufacturer security policies, users may be able to grant blanket or

single-shot permission to applications which use these capabilities. You can get User capabilities via any of the signing options.

The capabilities in the User group cover the following areas of functionality:

Capability	Functions covered
LocalServices	Local USB, infrared or Bluetooth network. In general these services do not incur any financial cost to the user but could compromise privacy.
Location	Location based services offered by a mobile phone, for example determining the current network the phone is on. The user may wish location to be kept private.
NetworkServices	Functionality associated with the network, for example sending an SMS or using GPRS. Usually such services incur a financial cost to the user.
ReadUserData	Read data that has been marked as private to the user. For example, the contacts engine requires you have this capability before you can read contacts.
WriteUserData	Update user data stored within system components. For example, the contacts engine requires you have this capability if you want to update a contact entry.
UserEnvironment	Access to information about the user and their current environment, such as using the camera.

If you use one, some or all of the capabilities from the User group then your application does not have to be signed. You do however you need to consider what happens when the unsigned application is installed. To show what this means in practice, we have modified the LayoutManager1 application so that the capability LocalServices is declared in the MMP file. Although the application does not require any capabilities protected by LocalServices, by declaring it in the MMP file we will trigger the software installer to check to see if the application is signed using the correct certificate.

We subsequently built the application for the emulator and packaged it up in an unsigned SIS file.

The user is presented with a dialog asking for the capability to be granted:

Figure 4 Grant single capability dialog for unsigned applications

Symbian offers a configurable policy that allows handset manufacturers the ability to state which capabilities a user can grant (rather than requiring a digital signature). Currently the manufacturers follow Symbian’s recommendation and limit this to the User group. Capabilities from the System or Device Manufacturer group must be signed for. There is no guarantee that this will stay static in the future and some Manufacturers or even operators may adopt a different policy.

Returning to our example, remember that the MMP was modified so that the application requires the single capability LocalServices and that the application does not use any APIs protected by this capability.

Pro tip: When you declare the capabilities that the application requires in the application's MMP file, the software build tools will not check to see if your application actually uses these capabilities. It is up to you to ensure that you declare the correct capabilities for your application.

If multiple capabilities are required, all are listed within the single dialog so the user only has the option to grant all of them or none of them. The example below shows the same application, however this time it declares that it requires the capabilities Location, NetworkServices and ReadUserData.

Figure 5 Grant multiple capabilities dialog for unsigned applications

Some of you may have noticed that the user only gets the option to continue with the installation. You may be asking ’What if the user does not want to grant capabilities?’ Within the emulator there is no easy way to do anything else apart from continue. However, if we look at actual hardware and take two examples, the Sony Ericsson P990i (Pen Style) offers the standard Cancel button on the button bar and the M600i (Softkey Style Touch) offers the Cancel button on the title bar.

Figure 6 Cancelling the grant capabilities dialog

Selecting Cancel in both cases stops the software from being installed.

Even if it only requires User capabilities, signing your means that the user will be presented with a trusted application and will not be asked to grant capabilities.

System Capabilities

If your application uses one or more capabilities from the System group then it must be Symbian Signed (Open, Express or Certified Signed). Unless a mobile phone manufacturer changes the phone configuration at some point in the future, the end user cannot grant these capabilities. The System group includes these capabilities and functionality:

Capability	Functions covered
PowerMgmt	Set power states of the phone, such as standby modes or switch off.
ProtServ	Symbian OS server processes that wish to register themselves with protected names. Is also required by plug-ins to such servers, for example ECOM based recognizers.
ReadDeviceData	Access operator, manufacturer and phone settings.
SwEvent	Generate and capture key presses and pen events
SurroundingsDD	Access device drivers that provide information about the surroundings within which the phone exists.
TrustedUI	Create a trusted UI session and display dialogs in that environment.
WriteDeviceData	Modify mobile phone settings.
CommDD	Direct access to the communication sub-systems device drivers.
DiskAdmin	Access file system administration functions, for example formatting a disk.
MultimediaDD	Priority or direct access to the multimedia subsystem device drivers.
NetworkControl	Access or modify any of the network protocol settings.

Note that the last four System capabilities, CommDD, DiskAdmin, MultimediaDD, and NetworkControl, are not available via the Express Signed option or via Open Signed without a Publisher ID. To deploy an application that uses them to a phone for testing, you will need to use Open Signed with a Publisher ID, and to release your software you will need to sign using Certified Signed, which requires independent testing by a Test House.

Device Manufacturer Capabilities

The final group of capabilities is the Device Manufacturer group, which is also known as the Licensee or Channel group. For the purpose of this chapter the term Manufacturer has been chosen to imply that ultimately the phone Manufacturer (Sony Ericsson, Motorola, etc) is responsible for approving or rejecting the use of these capabilities. The manufacturer only approves or rejects the use of these capabilities for their particular phones. If one phone manufacturer grants the use of a manufacturer capability then there is no guarantee that another phone manufacturer will also grant its use.

The capabilities in the Manufacturer group cover the following areas of functionality:

Capability	Functions covered
AllFiles	Read access to the entire file system and write access to the private folders of other applications.
DRM	Access to Digital Rights Management (DRM) protected content.
TCB	Trusted Computing Base (TCB). Install software, create processes and set capabilities.

You must use the Open Signed with Publisher ID option for development and testing and the Certified Signed method for the final product.

Using Open Signed with a Publisher ID enables you to download a developer certificate from the Symbian Signed portal. When you request a certificate with one or more Device Manufacturer capabilities it will not be immediately available. The Manufacturer will be notified of your request and the individual or group responsible will review your request and either reject, approve or ask for further information or clarification.

This means that you must work with a manufacturer to gain approval for your Symbian Signed application. You must justify your request and provide supporting information such as:

• the capabilities required by your application
• why these capabilities are needed
• alternatives using less sensitive functions, and why these cannot meet your needs.

When you submit your application for Symbian Signing via Certified Signed, the Test House will contact the manufacturer on your behalf and request approval for the use of the capabilities. Again, the individual or group responsible within the manufacturer will handle this request and update the Test House with the decision. Granting of capabilities is not guaranteed. We have seen situations where the use of certain capabilities has been refused, and, due to poor design it has required months of work before the application could be re-submitted.

Pro tip: Very few applications need to have Device Manufacturer capabilities. However, if your application does fall into that category, you must have a very strong relationship with a mobile phone manufacturer and an extremely compelling reason to have the capability.

Routes to Symbian Sign Your Application

Symbian Signed gives you three different options for getting your application signed. Depending on the capabilities that your application uses and the options that you choose, you can trade off speed and convenience on the one hand, against fewer restrictions in terms of API access and scale of deployment on the other.

FOR DEVELOPMENT AND TESTING

• Open Signed can be equated to developer certificate (DevCert) signing; in fact Open Signing replaces this concept. It is available to developers with and without access to a Publisher ID, although it is more powerful and flexible if you do have a Publisher ID. Its aim is to provide signing for applications that require limited deployment to known phones during test, development and evaluation.

FOR DEPLOYMENT TO CUSTOMERS

• Express Signed. Available to any developer who has access to a Publisher ID certificate. Testing may be done in-house rather than at an external Test House. As noted earlier, Device Manufacturer capabilities can not be obtained using this method, and the most sensitive System capabilities are also not available.
• Certified Signed. Signing option that provides the maximum level of application quality assurance and trust to end users. It is also required if the developer requires access to the most sensitive capabilities.

Publisher ID is a key concept in Symbian Signed. This is a digital certificate that is issued by a third party trusted authority. It verifies your identity to the Test House and to end users installing your application. TC TrustCenter is the certificate authority for Symbian Signed.

Open Signed

Open Signed enables you to sign applications for limited deployment to known mobile phones (based on IMEI) for development and testing. It is similar to the developer certificate in the previous Symbian Signed scheme. Open Signed is available online without a Publisher ID and offline with a Publisher ID.

Open Signed – Without Publisher ID

Without a Publisher ID, signing is wholly performed by the Symbian Signed website portal. You fill in online forms, upload your application and receive an Email when your signed application is ready to download. The main features of this signing option are:

• no Publisher ID is required
• no Symbian Signed account required
• all User and most System Capabilities (excludes CommDD, DiskAdmin, NetworkControl, MultimediaDD and Device Manufacturer set) are available
• restricted to a single mobile phone (one IMEI)
• no cost to developers
• testing and personal use only; not suitable for commercial distribution
• signed application is valid for 36 months.

Open Signed – With Publisher ID

Open Signed with a Publisher ID provides you with a developer certificate that you can download and use locally to sign applications offline. The main features of this option are:

• Publisher ID required (US$200 per year at the time of writing).
• Symbian Signed account required.
• All User and System capabilities may be requested.
• Device Manufacturer capabilities subject to approval.
• Application can be installed on up to 1000 mobile phones, based on a list of their IMEIs.
• Developer certificate is downloaded and used to sign applications locally using signsSIS.exe.
• Developer certificate can be used to sign any number of applications during its lifetime.
• Testing and personal use only; not suitable for commercial distribution.
• Signed application is valid for 36 months.

Unlike the online option, the above procedure uses a combination of PC-based tools and the Symbian Signed website, as well as a downloaded developer certificate. Since we use a developer certificate to build the SignedApp example for deployment to real mobile phones, we will explain developer certificates in more detail.

Note that you can specify up to 1000 IMEI numbers, making deployment to large groups more manageable. You must specify each IMEI so it is recommended that good hardware tracking and management is enforced within your software development projects.

Obtaining a Developer Certificate

This section describes the process required to obtain a developer certificate. It considers the scenario of a certificate for an application that requires a Device Manufacturer capability as this is the most complex. We highlight where this differs from the process of obtaining a certificate for the User set or System set.

You will need a Symbian Signed account and a Publisher ID.

The process of obtaining a developer certificate is a straight forward one; however for first time users it can be confusing, especially if you require Device Manufacturer capabilities, as we do in this example.

Download the latest version of the DevCertRequest tool from the Symbian Signed website. The DevCertRequest tool is a Microsoft Windows based application wizard that generates a Symbian development certificate request file (CSR). The certificate request file represents your requirements which included the IMEIs and capabilities that the certificate will sign for. This file is subsequently uploaded to your Symbian Signed account and used to generate your certificate.

Figure 7 Creating a certificate request file

DevCertRequest provides a GUI for you to select the required capabilities and identify if Device Manufacturer capabilities are required.

Once created the CSR file cannot be modified; if it contains any errors or omissions then a new file must be generated.

To obtain the developer certificate, you upload your CSR file to your Symbian Signed account. The portal will creates certificate and makes it available for you to check and download.

If you request Device Manufacturer capabilities, you must provide extra information with your CSR file upload. Your request will be routed to the selected manufacturer for approval. Once approved, you can download your certificate.

Once you have your certificate, you can use it to sign your application any number of times during the test and development phase. Your certificate will have a lifetime of 36 months so after this period you will need to request another development certificate. Note too that the applications you sign with it will only install during that 36 month lifetime. If you change the capabilities or IMEIs required then you will also need to request a new developer certificate.

Comparison with Previous Scheme

Prior to the Open, Express and Certified Signed schemes introduced in late 2007, the term Developer Certificate Signing was used for signing applications during the development, test and evaluation stages.

Old development certificates were valid for only six months and for a maximum of 100 IMEI numbers. The previous scheme used ACS Publisher IDs from VeriSign. For the time being, these remain valid for Open Signed offline. New Publisher IDs should be obtained from TC TrustCenter.

Development Certificate Request Plug-in

One recent addition to the process of obtaining a development certificate it the request plug-in tool available for the Carbide IDE. This allows you to load the request tool directly from your IDE.

Figure 8 Carbide – requesting a developer certificate

Carbide provides a form for you to enter the required information. This example lists the capabilities according to the groups that applied before the introduction of Open, Express and Certified signing.

Figure 9 Carbide – Developer certificate request wizard

Once the certificate is created you must still upload the certificate request file to your Symbian Signed account.

Signing with a Developer Certificate

Once you have obtained your developer certificate, you can use it to sign your application. To do this, you use the signSIS tool which is available in the UIQ SDK. You will need your developer certificate CER file and password.

For detailed guides to signing and installing application SIS files, refer to the Software Installation Toolkit guide and reference, under Tools and Utilities in the Symbian OS Library documentation in the UIQ SDK or online from

developer.symbian.com.

You can sign your application any number of times; there is no restriction on the number of development-build-sign loops.

We advise you to keep a careful note of the developer certificate expiration date, which is 36 months after the creation date. If your application suddenly fails to install, an expired developer certificate is very likely to be the problem. The error message you see does not indicate that the certificate has expired; you are simply told that a component has failed a security check.

Once you have your signed SIS file, it can be deployed to your mobile phone in the usual manner. Remember that the certificate restricts this distribution so it will only install on devices whose IMEI is declared in the certificate (this was done when the certificate request file was generated). There is no difference in the way a development certificate signed SIS file is deployed compare to unsigned or Symbian Signed SIS files. The SIS file can be installed using PC based software or sent to the device via Email, MMS, IR or Bluetooth. With all of these methods it is the software installed on the phone that will validate the certificate and ensure all requirements (IMEI, capabilities signed for, certificate expiration, etc.) are satisfied.

Deploying Your Application

When testing is complete and your application is ready for final signing, you must move on to use either Express Signed or Certified Signed.

Express Signed

Express Signed is intended for applications that will be released to the public, including commercial and non-commercial applications. The main features of this signing option are:

• Publisher ID is required (US$200 per year at the time of writing).
• Symbian Signed account required.
• All User and most System Capabilities (excludes CommDD, DiskAdmin, NetworkControl, MultimediaDD and Device Manufacturer set) are available.
• Unrestricted deployment.
• No independent testing required; you must however test and pass the Test Criteria and may be audited for compliance.
• Signed application is valid for 10 years.

Express signing is not free although the cost model is simple and predictable. As well as the annual cost for the Publisher ID, you will need to purchase a number of content IDs from the certificate authority TC TrustCenter. Each signing submission will use one content ID. Although the cost for each content ID may change with time it should be around the US$20.

The basic procedure follows these steps:

• Test and debug your application to meet the Test Criteria.
• Sign your application using SignSIS and your Publisher ID.
• Make sure you have sufficient content IDs in your Symbian Signed account.
• Submit the signed SIS, PKG and documentation to the portal.
• Select options and supply further information to the submission page.
• Portal validates the application.
• Download your signed application once it has been accepted.

All applications submitted through Express Signed should be tested against the Symbian Signed Test Criteria and it is the responsibility of the person or organization submitting to ensure that this has been done. Symbian will carry out random auditing of submitted applications to verify that they meet the standards set by the Test Criteria.

Freeware and software publishers without a Publisher ID can access this signing option via publisher partners. In general, these are companies that will publish and distribute your application. They have the ability to sign your application. Different Publisher Partners have different terms and conditions which dictate how the testing costs are recuperated and may have commercial restrictions on what you can do with your signed application.

Prior to the introduction of Express Signed there was a service called Self Signing. Express Signing is very similar to Self Signing and is in some way a replacement. The significant difference is that it is not possible to access Device Manufacturer capabilities through Express Signing.

Certified Signed

For mainstream commercial software developers, the full testing and accreditation regime of Certified Signed will be the preferred option. It also entitles you to use ‘for Symbian OS logo’ to aid differentiation and brand building for your application.

The main features of this signing option are:

• Publisher ID is required (US$200 per year at the time of writing).
• Symbian Signed account required.
• All User and System Capabilities are available; Device Manufacturer capabilities can be granted with manufacturer approval.
• Unrestricted deployment.
• Applications are tested by an independent Symbian Signed accredited Test House as part of the process. You must pay for this testing.
• Signed application is valid for 10 years.
• Your application may display the Symbian OS logo and branding.

If your application requires any of the Device Manufacturer capabilities (AllFiles, DRM or TCB), or the most sensitive of the System Capabilities (CommDD, DiskAdmin, MultimediaDD, and NetworkControl), Certified Signed is the only option available to you when you need to release for wide scale deployment.

Because Certified Signing requires independent testing it is considered to be the most trusted of all signing options. Symbian recommends that this should be considered the natural choice for all commercial and enterprise software indented for wide scale deployment.

The procedure for Certified Signed is as follows:

• Sign your application using SignSIS and your Publisher ID.
• Submit the signed SIS, PKG and documentation to the portal.
• Select options and supply further information to the submission page.
• Select your chosen Test House and accept the legal agreement.
• Track the progress and test results via the portal.
• Download your signed application once it has been accepted.

The Test House may require access to external servers, or to be loaned SIM cards, hardware or other facilities in order to test your application.

Procedural Impact

Symbian Signed should be a part of your software design, implementation and testing procedure. We recommend that you decide as early as possible to include Symbian Signed in your plans. This enables you to do the right thing at various points in the development process and avoid rework later on.

In the design phase, you will need to assess whether any functions must make use of protected APIs, for which capabilities are required. We cover this in the Capabilities section of this chapter.

Symbian Signed provides a Test Criteria document detailing the tests to be performed and the expected results. The tests are updated periodically, so check that you are working to the latest version, especially if you are working on a long software project. You should check your application design against this document to make sure that the tests can be passed. In Symbian Signed test criteria section we examine our SignedAppPhase2 example application in respect of these criteria.

If you are using Certified Signed, you will need to submit your application to a Test House. This adds at least one week to your development schedule, perhaps longer. We recommend that you should allow at least two weeks for your first application. For both Express and Certified Signed, you need to allow time and resource for understanding and complying with the Test Criteria in order to maximize your chances of successfully passing the tests.

If your application requires a waiver to particular test case, then the Test House will also have to contact the appropriate manufacturer for a decision on how to proceed. This will require extra time.

Failing Symbian Signed does not always mean disaster for your software project. On many occasions, a supplier is simply required to make small changes, such as updating the package file. The application is then re-submitted, which only results in minimal delays to your project.

Getting Started with Symbian Signed

Publisher ID

For all except Open Signed online, you must have a Publisher ID. Publisher ID digital certificates form part of the public key infrastructure, and are issued by Certificate Authorities. The Certificate Authority for Symbian Signed is TC TrustCenter. You can find out more and purchase a Publisher ID at www.trustcenter.de/en and follow the Products & Services, TC Certificates links. At the time of writing the cost is US$200 and the certificate lasts 12 months.

The TC TrustCenter certificate is assigned to companies or organizations and not individuals (a one-person ISV working outside a company can be considered to be an organization). If your organization does not have one of these certificates and the application you are developing requires a capability from the System group or Device Manufacturer group, then you will need to obtain one.

Pro tip: The process from applying for your Publisher ID and obtaining it can take a significant amount of time which can run in to weeks. You may have to provide proof of identification such as certificate of company incorporation, which may take time for you to locate within your organization.

The main purpose of this trust certificate is to securely identify the application and authenticate the organization providing the application. This gives the end user the confidence that the application can be traced back to a development source and that the application they are installing is what they expected.

Symbian Signed Account

Creating a Symbian Signed account is free. It is recommended that where possible you only have one account and that all UID requests, Development Certificate requests and Symbian Signed submissions are managed from this one account. Once the account is created, there are no real restrictions on the number of development certificates that you can request through this account. This is much simpler to manage than having your developer certificates, IMEI lists and other portal transactions spread across a number of accounts.

Pro tip: There are at least two legal agreements within the Symbian Signed process that you need to accept. The first is required when you sign up to join the Symbian Signed website. The second is only accessible when you attempt to submit an application to a Test House. If, like most organizations, yours has a legal department that needs to authorize all legal agreements, we strongly recommend that immediately you sign up to Symbian Signed, you also go through the submission process at least to the point where you are presented with the second agreement. By getting these agreements resolved early in the development process, you should not encounter delays later on when you application is ready to submit to the Test House.

Symbian Signed and UIDs

Each application on a mobile phone needs to be uniquely identified. This is achieved with a 32-bit unique number known as a UID. Prior to UIQ 3, or strictly speaking, prior to Symbian OS v9, a UID had much less significance than it does now. UIDs are allocated from three number ranges according to the intended use.

The example applications in the List boxes, Command and categories, Layout managers and building blocks, and Views and dialogs chapters used UIDs in the range 0xE0000000 to 0xEFFFFFFF. These values are reserved for internal development purposes only. Any applications that are to be distributed should not use these UID values. In particular there is no formal mechanism to ensure two developers do not use the same values from this particular range.

If you have chosen not to get your application Symbian Signed, development can proceed more or less as it did with previous versions of Symbian OS, provided that you obtain a UID from the Symbian OS v9 unprotected range 0xA0000000 to 0xAFFFFFFF for your application UID. You cannot use previously allocated UID values from the 0x10000000 to 0x1FFFFFFF range. The application installer refuses to install such applications.

Request the correct UIDs for your application. There is comprehensive information available on the Symbian Signed website covering protected and unprotected UIDs, what range of UIDs to use for test code, etc.

If you have chosen to get your application Symbian Signed, your first requirement is to obtain a UID from the Symbian OS v9 protected range 0x20000000 to 0x2FFFFFFF. If you later change your mind and decide that you no longer want to go through the Symbian Signed tests, you have to change the UID. Unless they are signed, the application installer refuses to install applications with UID values in the protected range.

Figure 10 UID ranges and Symbian Signed

UIDs are obtained via the Symbian Signed website, and are registered against the company or organization that requested them. In this way the Test House can verify that the UID of a submitted application belongs to the same developer that has submitted the application.

Submission and Compliance Criteria

You should review the submission and compliance criteria prior to each submission. The aim of the criteria is to ensure that your submission meets a certain standard and to reduce the chance that it gets rejected. Failure of a criterion can result in one of the following:

• WARNING: signing of the application is permitted, assuming all relevant test cases pass, although the developer is warned that this may cause further issues.
• REVOKED: the application will either fail during submission or in some circumstances if a signed application is found to not comply at any stage after signing it may be revoked.

The submission and compliance criteria include the following checks:

• Any embedded SIS file included is already signed, depending on the contents of the embedded SIS file and the capabilities it requires. Failure of this criterion will result in a warning.
• The SIS file being submitted must be correctly signed with a valid Publisher ID. The Publisher ID you used to sign the SIS file must match the Publisher ID in your Symbian Signed account. Failure of this criterion will result in a revocation.
• The SIS file includes correct version information which corresponds to the application About box and/or supporting documentation. If you do not adhere to a consistent naming convention, you may have difficulties in delivering future upgrades and patches. Failure of these criteria will result in a warning.
• Declarative statements. At time of submission the developer must declare their capability usage with satisfactory rationale. The capability usage must disclose the API(s) being used for each declared capabilities. These statements shall be retained on file and must be true and accurate. Failure of this criterion will result in a revocation.
• Correct Product/Platform UID. The Product/Platform UID matches the specified target products. Failure of this criterion will result in a warning.
• Correct PKG file UID. The PKG UID is owned by the developer and is from the correct range. Failure of this criterion will result in a revocation.
• Correct application UID. All UIDs are owned by the developer and are from the correct range. Failure of this criterion will result in a revocation.
• Correct PKG file VID. If a VID is specified, the VID it is from the correct dedicated range. Failure of this criterion will result in a revocation.
• Adherence to special rules for Central Repository and C32 updates.
• Illegal recognizer usage for auto-start. Note that this is only applicable if auto-start functionality is present and the ProtServ Capability is required. Failure of this criterion will result in a revocation.
• Operator approval required for use of NetworkControl capability for accessing the SIM. Note that this is only applicable if application accessing SIM card and requires NetworkControl capability is required. Failure of this criterion will result in a revocation.

Symbian Signed Test Criteria

The full Symbian Signed Test Criteria document is available from the Symbian Signed website. It is updated from time to time and a significant update is in draft at the time of writing this book. We provide an overview of the proposed new Test Criteria and discuss the current v2.11.0 Test Criteria in detail.

Test Criteria v3.0.0

With the introduction of Open, Express and Certified Signed, Symbian is undertaking a major review of the Test Criteria. This section presents an overview of the new Test Criteria, which are still in draft at the time of writing.

The tests are broken into three sets:

• Universal Tests.
• Specific Symbian OS v9.x Tests and Symbian OS v9.x Capability Access Tests.
• Internet Telephony Application Tests.

Universal Tests

All applications must meet these basic criteria:

• install correctly, including from memory cards
• uninstall correctly, leaving no installation files behind
• reinstall correctly
• backup and restore successfully, using appropriate file creation locations
• survive low memory at startup
• handle exceptional events such as out-of-memory
• survive power-down and reboot events
• handle service interruptions and repeated switching
• handle system events correctly and comply with task list behavior guidelines.

Specific Symbian OS v9.x Tests and Symbian OS v9.x Capability Access Tests

All UIQ 3 applications must meet the relevant criteria:

• comply with scaleable UI requirements
• capability declarations must be correct
• policy statement dialog must be displayed telling the user which phone features are used
• multimedia applications must not interfere with phone calls
• applications which access the mobile network must have network operator approval.

Internet Telephony Application Tests

If your application uses VoIP or replaces the standard phone UI, then the following tests also apply:

• phone applications must present a UI which gives the user control of the application
• VoIP applications must present a Device Manufacturer disclaimer, and must not interfere with GSM-based telephony functions, including the ability to make emergency calls.

Test Criteria v2.11.0

In this section we examine the SignedAppPhase2 application that we developed in the Building an application chapter to help explain the nature of the testing, the possible impacts upon our development and how to maximize our chances of passing. Note that the Symbian Signed Test Criteria are updated from time to time, so it is important to keep checking for updates. We have taken Test Criteria v2.11.0 as these were current at the time of writing. While they change over time, the general principle of checking your application against the specification remains the same. The IDs of the revised v3.0.0 Test Criteria are added in brackets where applicable.

The Symbian Signed tests aim to check the general behavior of your application and interoperability with Symbian OS.

The test cases do not aim to:

• comprehensively test all of the functionality of your application
• test that you have implemented correctly against your specification
• ensure that you have followed the UI Style Guide.

PKG-01

The SIS file has been signed with a valid ACS publisher certificate.

Symbian provides a tool called VerifySymbianSigned, freely available from the Symbian Signed website that can analyze a SIS file. For our application the tool provides a report as below:

------------------------------
File format : SISX (V9)
SIS file : SignedApp_ACSCert_uiq_3_0_v_1_00_01.sis
------------------------------
Symbian Signed : No
Developer Certificate Signed : No
ACS Publisher Signed : Yes
Unknown Certifictaes : 0

When run on the SignedApp_ACSCert_uiq_3_0_v_1_00_01.sis file, this tool confirms our SIS is signed with an ACS Publisher Certificate. We comply with this test.

In the new Test Criteria v3.0.0 scheme, this criterion becomes part of submission and compliance.

PKG-02 (UNI-01)

Installation and startup.

A Symbian native application is expected to start up within a reasonably short timeframe, presenting a progress indictor if start up takes more than about five seconds. Our application starts up rapidly so does not require any progress information. We should not have a problem with this test.

PKG-03 (UNI-08)

File creation location. Files should only be created on the drive the application was installed to.

Our application has chosen to store configuration information within an INI file. The application framework creates that file on our behalf, currently always on the internal drive C irrespective of the disk the application is installed on.

An exception is available, EX-006, which covers the case where the system code creates files on our behalf. To ensure we do not fail this test it must be documented within a readme.txt file. This file must be submitted along with the application so that the exception is clear to the tester.

While we recommend that you design commercial applications to meet this criterion, our example application makes use of the exception.

PKG-04 (UNI-08)

Uninstall removes all files originally installed or created by the application.

On Symbian OS v9 mobile phones, the uninstall process automatically removes all files within the private application folder. Since our application creates files only in that folder, we should not have any problems with this test. If we later change the application to create files in other folders, we must reconsider this test.

PKG-05

Installation to all media drives.

Our PKG file contains statements such as:

"\epoc32\release\gcce\urel\SignedApp_0x20000462.exe"-"!:\sys\bin\SignedApp_0x20000462.exe"
"\epoc32\data\z\resource\apps\SignedApp_icons_0x20000462.mbm"-
 
"!:\resource\apps\SignedApp_icons_0x20000462.mbm"
 
"\epoc32\data\z\resource\apps\SignedApp_0x20000462.mbm"-"!:\resource\apps\SignedApp_0x20000462.mbm"
 
"\epoc32\data\z\private\10003a3f\apps\SignedApp_reg_0x20000462.rsc"-"!:\private\10003a3f\import\apps\SignedApp_reg_0x20000462.rsc"

These statements inform the installer to place files into the disk !. When an application is actually installed and the user chooses a specific media drive the ! is replaced by the actual drive letter. Our PKG file has no statements that require application files be installed to specific media drives so we should not have a problem with this test.

PKG-06 (UNI-09)

An application can be reinstalled to a device after it has been uninstalled.

We have no specific requirements as to which media drive our application is installed. When uninstalled we remove all the application files so it is highly unlikely that we would have a problem with this test. You should perform this test to ensure compliance.

PKG-07

UID and platform compatibility information are appropriate for the target device.

Our application UID, 0x20000462, has been allocated correctly by Symbian Signed and is within the correct range of UIDs for applications that can be Symbian Signed. Our package file does not specify a VID, so that defaults to zero as required.

Our PKG file contains the following statement:

; ProductID for UIQ 3.0
; Product/platform version UID, Major, Minor, Build, Product ID
[0x101F6300], 3, 0, 0, {"UIQ30ProductID"}

This statement claims our application supports UIQ from version 3.0 onwards. If your application requires functionality that is only present in UIQ 3.1 or higher, you must update the statement.

Our application is designed to operate on all versions of UIQ 3 from 3.0 onwards, therefore the statements in the PKG file are correct and we should not have a problem with this test.

PKG-08

Version information is consistent.

This test requires that the version information contained within the SIS file is consistent with the version information displayed within your application About box and is consistent with any documentation supplied as part of the submission.

Our PKG file contains the following statement:

; What our app name is displayed as
# {"Signed App"},(0x20000462),1,00,01,TYPE=SA

This statement declares our application to have a major version number of 1, a minor version of 00 and a build of 01. The About box MUST present the same values, and very particularly must present the same number of leading zeros in each of the fields. Otherwise, the application is very likely to fail this test.

You must include an About box within your application to pass this test. Our example application contains an About box so should pass that part of the Test Criteria.

Pro tip: The Symbian Signed Test Criteria state that you must have a major, minor and build number. If your version control system does not actually work like that, we suggest that you map and/or allocate major and minor version numbers in a simple way which also allows you to identify future versions. The build number would be chosen to match your version control build label. While it is only a ‘guideline’ within the Test Criteria, our experience is that if you do not have all three fields or do not use exactly two digits for the minor version number, you are highly likely to fail this test.

GEN-01

The application does not affect the use of system features or other applications.

The basis of this test is to ensure your application behaves responsibly. Symbian OS is a powerful operating system with many features. Abuse of these features can cause a mobile phone to misbehave or affect other applications. For example, you could write an application that monitors incoming Email messages and automatically deletes them. Such an application would be considered to be detrimental to the overall user experience of a mobile phone and is unlikely to pass Symbian Signed testing.

Poorly designed or malicious code is likely to fail this test. We also advise careful inter-operability testing, since new or changed features in inter-operability can give rise to failure cases. We do not expect any such problems with our application.

GEN-02

The application can handle exceptional, illegal or erroneous actions.

The Test House spends around 15 minutes stress testing your application, for example attempting to enter too many characters into text editors or deleting all entries then choosing all remaining menu options available. If the Test House manages to cause your application to panic, for whatever reason, you will fail this test.

This is probably one of the hardest tests to pass since it implies there are no bugs in your application. Passing this test requires you design, implement and test your application as much as you can before submission to a Test House. You should design and run your own stress tests; simple functional testing is not enough to pass this criterion.

GEN-03

The application should support various device resolution and formats appropriately.

The intention of this test is to ensure your application can be used properly on those mobile phones you intend the application to support. In particular, is it required that the application correctly handles any dynamic screen switching it claims to support.

At the time of writing, only the Sony Ericsson P990i supports dynamic screen switching. You have two choices:

• fully support both the flip open and flip closed modes
• not support flip closed at all.

Flip open and flip closed are usually handled using the view architecture and QIK_VIEW_CONFIGURATIONS. In addition we indicate support for flip closed mode by the inclusion of a VIEW_DATA structure within our application localization file:

VIEW_DATA
  {
  uid=EViewIdPrimaryView;
  screen_mode=EQikScreenModeSmallPortrait;
  caption_and_icon =
    {
    CAPTION_AND_ICON_INFO
      {
      }
    };
  }

Apart from testing that the example application operates in both flip open and flip closed mode we do not have to perform any special actions to pass this test.

Some applications may choose not to support flip closed on the Sony Ericsson P990i. In this case you should ensure that you do NOT include a VIEW_DATA structure claiming that you do, and that you document this in any submission notes.

Pro tip: Sometimes this test is not as exact as stated in the specification. For example “All menu controls are fully visible” does not mean that all menu controls must be fully visible all of the time. In our example, we have a cascade menu and our menu scrolls. By definition, cascade menu items are hidden until the user expands the cascade and scrollable items are off screen and therefore not visible. The primary intention of the test is to ensure your application is fully usable in all mobile phone configurations. The intention of this test could perhaps be stated as “All menu controls are accessible”. Applications that contain cascade or scrollable menus will not fail this test. As we saw earlier, UIQ allows applications to change the content of menus and distribute commands over other controls, such as command bar buttons, dependant on the current mobile phone configuration. Other Command Processing Framework flags allow you to specify various attributes about commands such as: EQikCpfFlagOkToExclude EQikCpfFlagTouchscreenOnly EQikCpfFlagNoTouchscreenOnly EQikCpfFlagPortraitOnly. If you use these advanced features, we strongly recommend that you fully document your application behavior as part of your submission. If you do not, you risk the Test House raising questions or comments, or possibly even failing your application.

MEM-01 (UNI-03, UNI-04)

The application handles low memory situations during application start up.

Currently the tool to perform this test is not available for Symbian OS v9 applications. As a result, neither the Test House nor developers are able to perform it. Even if the test tool were available, the change from APP to EXE introduced in OS v9 means that we can now specify the EPOCHEAPSIZE within our MMP file. If you specify a minimum heap that is in excess of the amount of memory required to start your application, it is not possible for the application launcher to actually run your application until that amount of memory is available.

MEM-02 (UNI-04)

Low storage during execution.

In a multi-tasking operating system it is both difficult and inappropriate for one application to control or restrict the actions of another completely independent application. In particular, even if your application checks to see if there is enough space on a disk to store its content, by the time it comes to actually store that content it cannot guarantee that other applications in the system have not used the disk space. It is, however, reasonably easy to simulate low storage.

Data on media drives is rarely allocated at a byte level, there is usually a sector size dictated by parameters such as the size of the media and the type of filing system on the drive. The amount of disk space used by your application is usually in excess of the number of bytes saved and is rounded up to the nearest sector size. In general, applications do not and should not need to worry about the detailed internal operation of the file server and its associated media device drivers.

From the practical perspective of passing this test the important point is to ensure your application can survive errors saving content to disk. In particular, we recommend that your error handling code for a failure to fully save a file causes the file to be removed from the media drive. Our application uses system-managed INI files. At the application level we do not have much control over their internal buffer sizes or when they choose to flush buffers to disk. We do, however, know when we have finished writing our application data to a stream and are required to commit the stream, then the dictionary to the media drive. The stream store functions that commit the data leave on error; our task is to ensure we handle the leave appropriately, typically by deleting the partially-formed file.

PHN-01 (UNI-02)

Incoming interruptions pause and save state.

A mobile phone has numerous mechanisms by which the current activity can be interrupted. The classic example is an incoming phone call. Applications need to be written to integrate properly with these types of activities. In general, either a view switch or a background event occurs to handle the alternate task. On the emulator you can simulate this by selecting the applications button.

Many applications do not have to perform any special tasks; our example is one such application. If your application contains a significant amount of animation and state changing, as most games do, you need to make your application reach a quiescent state with no further animation running, so the user can resume from the position they left the application. In many applications this may be as simple as stopping the animation timer; in others it may be slightly more complicated as the animation is updating the UI to display the new engine state. In such cases your application needs to be able to cancel (or complete) the animation rapidly.

PHN-02 (UNI-06)

Unexpected reboot.

This test is to ensure that a mobile phone and your application can survive situations such as the user removing the battery of a phone. There is not a requirement that the application continues from the position it was last at, only that the mobile phone and application can be re-started.

In practice this means that your application needs to be able to handle error conditions when starting up, such as its INI file being incomplete. Our application creates and initializes the engine with a set of default data. It then attempts to load the INI file. Only when that is fully successful will it switch to using those parameters. An error reading the INI file causes the engine to roll back to a stable state, using the default parameters. This should be sufficient to pass this test.

CON-01

The application can be closed via the task list.

On many actual mobile phones there is a task manager application. We have already discussed the ability of our application to respond to any close messages sent by the task manager, so we should be able to pass this test. Your application must not panic in this situation.

CON-02

Privacy statement dialog.

A Symbian OS v9 application must display a dialog informing a user about the usage of various OS functions if such functionality exists in an application. The functionality covers:

• network access, such as using GPRS, SMS or MMS
• local connectivity, such as using Bluetooth or infrared
• multimedia recording
• reading or writing any user data, such as reading Contacts or Agenda entries
• usage of any Location services.

The intention of the test is to inform the user of the type of activity the application may perform. The user can then take an informed decision as to whether they find it acceptable for an application to use these services. Any dialog presented to the user needs to be coherent, however it only needs to summarize the services used rather than attempt to explain in detail exactly which APIs are used, when those APIs are used and why.

Since our application supports Send as, which can send content via MMS, Bluetooth or infrared, our application requires a privacy statement dialog. Without such a dialog our application will fail this test. SignedAppPhase2 does not have such a dialog, so we add it in SignedAppPhase3.

This criterion is expected to be removed in Test Criteria v3.0.0

CON-03

Billable events.

Our application supports Send as. One of the transports that a user can choose on a real mobile phone is MMS. Even though our application passes control to the UIQ Messaging application to send the MMS, a Test House may interpret the specification strictly and require that our application must provide a warning dialog. To be sure of passing this test, we therefore adjust our application to present a billable events dialog prior to using the Send as functionality.

It is acceptable to include a “Don’t tell me about this again” option in the dialog, so that the user does not have to go through the warning every time.

This criterion is expected to be removed in Test Criteria v3.0.0

CON-04 (UNI-07)

Backup and restore compliance.

To comply with this Test Criterion, the primary application requirement is to provide a backup_registration.xml file as part of the application installation package.

Our backup_registration.xml file contains the following content:

<?xml version="1.0" standalone="yes"?>
<backup_registration>
<passive_backup>
<include_directory name="\"/>
</passive_backup>
<system_backup/>
<restore requires_reboot="no"/>
</backup_registration>

There are two distinct types of backup, one in which an application actively participates, called active backup, and one where the application does not participate, called passive backup. Typically, applications that perform data synchronization perform active backups. Other applications perform passive backups. As indicated by the XML, our application performs passive backup. All the information of interest is stored within our private folder. The ‘include_directory name=”\”’ statement specifies that we want all files within our private folder backed up.

The statement specifies that all executables and resource files defined within the original PKG file should be backed up. We recommend that you include this statement. Otherwise, should a user backup their mobile phone, perform a master reset then restore their data, your application is absent and the user has to reinstall.

The full syntax, or in XML terminology, the backup registration file DTD, exists within the document How to write backup aware software This document also discusses backup and restore fully.

It is also possible to opt out of backup and restore (that is, the application does not register with the backup/restore server), if it is not necessary for your application.

Pro tip: Unfortunately it is not actually possible to test application backup and restore if an application is signed with a developer certificate. Since it is not possible to install applications signed with a full certificate until they have been Symbian Signed, it is a difficult to verify backup and restore compliance. Symbian Signed and the Test Houses are aware of this issue. Therefore, your application should not be failed if backup and restore compliance is not met, given that it is not testable. The vast majority of applications should simply use the backup_registration.xml example file as it is shown above.

Symbian Signed Test Criteria Summary

Having gone though each of the Symbian Signed tests, we can be satisfied that our SignedAppPhase2 application conforms to the vast majority of tests. Although some of the tests appear quite onerous, we do not have to perform any significant modifications to our application in order to conform. The two tests we need to address are CON-02 and CON-03 where we need to add a fairly simple dialog. These are added in SignedAppPhase3, described in the Multimedia chapter.

Lessons Learned

We would like to share with you a number of key Symbian Signed lessons that we have learned as a result of working with the Symbian and UIQ development community.

Ensure you understand the capability rules

Understanding the Symbian capability rules is essential for anyone who is designing and implementing an application for a UIQ phone, so before we go any further we should familiarize ourselves with the rules as set out in the book Symbian OS Platform Security:

• Rule 1 – Every process has a set of capabilities (as defined by an EXE) and its capabilities never change during its lifetime.

• Rule 2 – A process can only load a DLL if that DLL has been trusted with at least the capabilities that the process has.

• Rule 2b – The loader will only load a DLL that statically links to a second DLL if that second DLL is trusted with at least the same capabilities as the first DLL.

The Symbian Platform Security model has been designed to control what a process can do which means your application can only perform the tasks (use the APIs) for which capabilities have been approved. When a binary is built (this can be an EXE or DLL) it is done so with a set of capabilities defined in the applications MMP file. The capabilities defined in the MMP file should match the capabilities that your application uses. When this binary is installed using a SIS file, the software installer will check to see if it is trustworthy and is allowed to use these capabilities. Experience shows that the confusion arises in the different way that an executable and DLL is treated.

If you consider your application EXE, when a process is created from this executable, the process runs with the capabilities declared at build time for that executable. Once this process starts its capabilities cannot change, which means that loading a DLL with higher capabilities will not increase the capabilities of the process (Rule 1).

This differs from a DLL; the capabilities declared within a DLL indicate a level of trust. A DLL can at run time be loaded in to a process with fewer privileges, as Rule 2 states that essentially a process can only load a DLL which has a superset of capabilities. The critical point is that many developers believe that their application needs the same capabilities as the DLL it is loading. This is not the case; you only need the capabilities for the APIs that you are using. There are some DLLs that have all – TCB (All capabilities except TCB). Many vendors believe that to use this DLL they also require all –TCB when in fact they only need one, two or three capabilities as they don’t use all the functionality provided by the DLL. This problem is often identified when a request gets rejected because the vendor or developer is asking for a capability that they do not use.

Integrate the Capability Request

When you submit your application to Symbian Signed and it requires Device Manufacturer capabilities, part of the process requires you to complete a capability request form. This form requires basic information such as organization and contact information. More importantly, it asks you to provide the name and description of the application, the capabilities that it requires, the APIs used for each of these capabilities and the functions implemented using these APIs. It is critical that this information is concise, accurate and up-to-date because this document is used by handset manufacturers (along with information from the Test House) to determine if an application should be granted its required capabilities. It is also used in the case when one or more waivers are required.

If your documents are inaccurate or invalid, then only option the handset manufacturer has is to either reject the request or ask for more information before the request can be approved. In the first instance, the Test House must mediate between the handset manufacturer and the software vendor. By embedding the capability request form in to your project and assigning clear responsibility for managing the submission, you can ensure that the correct people update the documentation (such as Architect, Systems Analysis) as the application is being developed. It also ensures that the documentation is maintained and reflects any changes in design.

Integrate the Symbian Signed Test Criteria

The Symbian Signed test cases are not secret. Despite the fact that they are easily available from the Symbian Signed website, many vendors and developers do not test their application against these test cases in advance of submission. They only find the outcome when they get the good or bad news from the Test House. On many occasions this is not a big problem, however, sometimes this can cause serious delays. For small developers, the unnecessary additional cost of re-testing may also be significant.

The most successful vendors and developers (successful at getting their application through the signing process as quickly as possible) are those who have the Symbian Signed Test Criteria integrated in to their test plan. Usually this means that their application is tested against the criteria at the major project milestones such as an alpha release, beta release and most significantly against the application they plan to submit. This means that there are no surprises and it also means that they can have ready all the required documentation such as failure justification and waiver documentation when they actually submit to Symbian Signing.

Ensure Infrastructure Dependencies can be Accessed

In general, this particular lesson only applies to vendors or developers who are providing a client application that utilizes the services of a backend infrastructure. For example:

• Instant messaging client.
• Push email client.
• PBX or VoIP client.
• Streaming Audio or Video client.
• Blogging client.
• Mobile TV.
• VPN Client.

The key difference with many of these is the proprietary nature of the service that the client is implementing on the smartphone. When the client is submitted to the Test House it is not just a case of providing an application. In many cases user accounts, server access and even hardware such as SIMs are needed. Many clients have associated desktop software that puts requirements on the host network (e.g. ports x to y must be open). It can also be complicated when the available network operators available to the Test House (limited by geographic location) do not support a specific client because the client will only work on Operator X or Operator Y. As the vendor and developer are so committed to getting their application out on time and at the right quality, these small complications are often neglected and it is assumed that the Test House has everything in place to support their client.

In almost all except for a few extreme cases, the Test House is able to accommodate the particular clients, however, it does take time for the Test House and vendor to get everything in place.