What are UIDs?

Symbian has defined a UID (Unique Identifier) as a number in the 32 bit range 0x00000000 to 0xFFFFFFFF. Individual numbers from this range can be allocated to named entities and used for various purposes. UID3 in an MMP file uniquely identifies the binary (EXE or DLL) within the system. Its purpose is to prevent one executable interfering with the operation of another executable. 

If you are developing an application for Symbian OS versions 5, 6, 7 or 8, then you should get UIDs only from the protected range - regardless of the signing intention.

If you are developing an application for Symbian OS v9 that you intend to Symbian Sign, you should request UIDs from the protected range. Otherwise, for unsigned Symbian OS v9 applications get UIDs from the unprotected range.

For previous versions (Symbian OS pre-v9) of the operating system UIDs were allocated in the range 0x10000000 - 0x1FFFFFFF. UIDs have evolved in Symbian OS v9 and have been split into 2 ranges; protected and unprotected.

You can find other UID related FAQs in the Symbian OS FAQ knowledgebase.

What are UIDs and what's the difference between "Protected" and "Unprotected range" UIDs?

Any UID values less than or equal to 0x7FFFFFFF are classed as "protected" and are only intended for use with signed applications (or those pre-installed in ROM). The software installer will refuse to install an unsigned application if it uses a package UID in the protected range. New UID allocations (shown below) will start from 0x20000000 for the protected range, and from 0xA0000000 for the unprotected range.

From which range should I use a UID for pre and post Symbian OS v9 applications?

Use UIDs for your application from the protected and unprotected range as specified below:

All applications for Symbian OS v5,v6,v7 and v8 must use protected UIDs.

All applications that are or may be Symbian Signed for Symbian OS v9x must use protected UIDs.

Due to UID range restrictions in Pre-v9 Symbian OS, use 'protected' UIDs for all signed or unsigned pre-v9 applications. This includes UIDs in the binaries and the accompanying .application .pkg file (i.e. SISUID). The Makesis.exe tool will throw an error if unprotected UIDs are used in pre-v9 SIS files, and the application might fail to execute when installed.

Note that Symbian OS v9 applications must use allocated and protected UIDs; otherwise the SIS file submission will result in a failure.

What UID range should I use for SDK example or test code in Symbian OS v9?

For Symbian OS pre-v9 use UIDs from the test range 0x01000000 - 0x0FFFFFFF.

For Symbian OS v9, there are basically two options for UIDs for SDK examples (assuming they are to be chosen from the unprotected range, so people can run the application without a DevCert)

1. Use UIDs from the unprotected range 0xAxxxxxxx by officially allocating UIDs out of your Symbian Signed portal account.
2. Use UIDs from the test range 0xExxxxxxx by choosing non-clashing "random" values from within this range. Note that this replaces the pre-9.x test range of 0x01000000 - 0x0FFFFFFF; so anywhere you previously used those UIDs you can now use these for Symbian OS v9)

Within the broad area of example/test applications:

(1) is probably more suited to projects (e.g. file-manager or games), and
(2) is more suited to programs purely for illustrative/learning/test purposes (e.g. HelloWorld) which will not be redistributed via a SIS file. You may opt for (1) for all examples though, if you wish.

Note that which ever UID range you use, it needs to be stressed that an ISV application should not copy the UIDs from the examples, but should instead allocate their own UIDs from https://www.symbiansigned.com to avoid any issues.

I have UIDs allocated from uid@symbiandevnet.com.* Can I still use them?*

A requirement for getting a Symbian OS v9 application signed is that the UID comes from the new system and is in the protected range. Even if you have previously obtained a UID from Symbian it will be necessary to reapply at https://www.symbiansigned.com regardless of whether or not you are intending to sign your application.

You can also continue to use your existing allocations for unsigned application usage on Symbian OS v9. To do this, simply replace the first hex digit (a 1) with F, and leave the remaining digits unaltered. This maps your UID into the Legacy UID compatibility range; where it will not conflict with any other allocations. For example, you have a UID allocation 0x100F55BE which you can transpose to 0xF00F55BE for use in an unsigned Symbian OS v9 application

How do I get new UIDs?

You need to be a registered user on Symbian Signed, click here to register. Once you have registered and logged in click on "UIDs" and then "Request " on the left navigation bar. If you are developing an application for pre Symbian OS v9 you can get UIDs from the protected or unprotected range. If you are developing your application for Symbian OS v9 to be signed, you should use UIDs in the protected range before submitting your application to Symbian Signed. If you are not intending to get your application signed, use UIDs in the unprotected range. Unsigned applications with UIDs in the protected range will not install.

Why not continue using the old system?

The existing data in the legacy UID database is not complete enough to check the ownership of the UIDs required for Symbian Signed with Symbian OS v9 applications. As a result this has not been migrated to the new system. Symbian Signed requires all Symbian OS v9 signed applications to use protected range UIDs from the new system. In addition the new system is automated and does not have incur any delay with manually allocating UIDs.

What are SIDs?

A Secure ID (SID) is a special use for a UID. In Symbian OS v9 each executable has a SID which, unless explicitly specified by the SECUREID keyword in the application's MMP file, will default to be the same value as the application's UID3. The SID value is not relevant for DLLs as a process's SID will always be that of its EXE.

A server can permit or reject a call to a particular API based on the client's SID. It also determines the name of the application's private directory.

To avoid confusion, it is recommended that a SECUREID not be specified in the application's MMP file; instead UID3 always be specified.

What is a UID3?

The first 12 bytes of any Symbian OS file are used to store three 32 bit numbers (UID1, UID2 and UID3) that identify what type of file it is. UID3 is the number you specify in your MMP file with the keyword UID to uniquely identify your application.

What are VIDs?

A Vendor ID (VID) is another special use for a UID in Symbian OS v9. Symbian has set aside part of the 32 bit UID range (0x70000000 to 0x7FFFFFFF) for VIDs. A VID can be used as a runtime mechanism to check that a binary comes from a particular source. It is specified by using the VENDORID keyword in a project's MMP file; if this is not found the VID will default to zero. The VID of a DLL is not relevant - similarly to the SID, a process's VID will always be that of its EXE.

Most developers will not have a VID allocated to them and hence will use the default value of 0; VIDs are most useful to network operators and phone manufacturers - for instance a network operator could use the VID mechanism to allow only applications with a certain VID to access a particular Network API or service.

If you require a VID please post your request and justification why you require a VID on the Symbian Signed Forum which can be found here.

What's the maximum number of UIDs that a developer can get?

Initially all users will have a limit of 20 UIDs per day. If the number is exceeded the user will receive an error message Daily UID Allocation Limit Exceeded!.  If you would like to increase your daily limit, please post your request with justification why you require more than 20 UIDs per day on the Symbian Signed Forum which can be found here. The Symbian Signed Administrator will review your case and may modify your Symbian Signed account to increase the allocation limit.

Does Symbian Signed check that a UID belongs to a developer pre Symbian OS v9.x?

There is no change to the existing Symbian Signed process for pre Symbian OS v9 applications. Developers do not require UIDs from the new system to get their applications signed.

Are there any exceptions where it might be acceptable to submit an application with someone else's UID or a UID from the unprotected range?

If you are submitting your application through a publisher certifier then you may use your own UID even though your application will be signed with the publisher certifier's publisher ID. A publisher certifier is an organization that is trusted to test 3rd party applications which the publisher certifier has signed with their own Publisher ID. Some software publishers such as Handango and Cellmania use this model.

How does Symbian test that a UID belongs to a developer?

When a developer submits their Symbian OS v9 application, during the application upload process Symbian scans the SIS file (note that Symbian Signed only checks the UID ownership in Symbian OS v9 onwards). The Distinguished Name contained within the publisher ID and the UIDs from within the application are then recorded by the system. The user can find the results of the SIS file scan by following the link from the application information page. The system looks up the UIDs that have been found in the application and displays the owner of the UID that is listed in the UID allocation database next to each UID. It is then easy for the test house to compare the owner of the UID with the Distinguished Name taken from the Publisher ID. Note: Only non-zero VIDs are displayed. If a UID from the file cannot be found in the database then an error will be reported by the system. A test house would fail this application.

How can I find out which UIDs have been allocated to me?

Once you are logged in to https://www.symbiansigned.com, select "UIDs" and then "My UIDs" on the left navigation bar. This page lists all the fields from the UIDs database that are associated with your Symbian Signed account. The records are clearly grouped according to whether the UIDs allocated were in the protected or unprotected range and are shown alongside the distinguished name and organisation name. Paging is used to limit the number of records displayed at one time with a search facility (including wildcards) on UID, Organisation Name and Distinguished Name.

What is data caging?

In any open operating system there is the threat that one application will interfere (maliciously or accidentally) with another application's private data. To prevent this, Symbian has introduced the concept of data caging. Data caging in Symbian OS v9 is used to restrict access to certain areas of the file system based upon the capabilities an application has. Each application also has exclusive access to its own private directory, enforced by the file system. To ensure uniqueness this directory is defined by the application's Secure Identifier (SID). For example an application with a SID of 0x12345678 would have the private directory:
\private\12345678\

As part of the certification process signed applications will have been checked to ensure that they are the rightful owners of the SID that they use. Since the software installer will only allow signed applications to use SID values in the protected range, there is no danger of clashes occurring unless the owner reuses their own SID themselves. Unsigned applications might try to use a SID which has already been used by another application on the phone, but in that case the software installer will spot that and refuse to install the second application.

Whilst it is not possible to read or write in another application's private directory, it is possible to add files into that application's import directory, at installation time only. This might be used, for example, when providing add-ons to an existing application. The import directory for the example application given above would be:
\private\12345678\import\

Who do I contact if I have other questions?
Please post all issues on the Symbian Signed Forum which can be found here. For further information on Platform Security, please click here