×
Namespaces

Variants
Actions

UID Q&As (Symbian Signed)

From Nokia Developer Wiki
Jump to: navigation, search
Article Metadata
Compatibility
Platform(s):
Symbian
Article
Created: hamishwillee (16 Dec 2010)
Last edited: hamishwillee (26 Jul 2012)

This article provides an overview of UIDs in relation to Symbian Signed, and gives guidance for which range you should get a UID from for your application.

Contents

What are UIDs?

A UID (Unique Identifier) is defined in this context 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. For instance, the UID3 in an MMP file (or TARGET.UID3 in a Qt .pro file) uniquely identifies the binary (EXE or DLL) within the system.

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. The UID3 is the number you specify in your MMP file with the keyword UID to uniquely identify your application within the system, the purpose of which is to prevent one executable from interfering with the operation of another.

UIDs have evolved from Symbian OS v9 onwards and have been split into 2 ranges; protected and unprotected.

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.

UID Class Range Purpose
Protected Range 0 0x00000000 - 0x0FFFFFFF Development use only (legacy)
1 0x10000000 - 0x1FFFFFFF Legacy UID allocations
2 0x20000000 - 0x2FFFFFFF V9 protected UID allocations (Nokia Store compatible)
3 0x30000000 - 0x3FFFFFFF Reserved
4 0x40000000 - 0x4FFFFFFF Reserved
5 0x50000000 - 0x5FFFFFFF Reserved
6 0x60000000 - 0x6FFFFFFF Reserved
7 0x70000000 - 0x7FFFFFFF Vendor IDs
Unprotected Range 0 0x80000000 - 0x8FFFFFFF Reserved
1 0x90000000 - 0x9FFFFFFF Reserved
2 0xA0000000 - 0xAFFFFFFF V9 unprotected UID allocations, self-signed releases only
3 0xB0000000 - 0xBFFFFFFF Reserved
4 0xC0000000 - 0xCFFFFFFF Reserved
5 0xD0000000 - 0xDFFFFFFF Reserved
6 0xE0000000 - 0xEFFFFFFF Development use only, randomly generated
7 0xF0000000 - 0xFFFFFFFF Legacy UID compatibility range

From which range should I use a UID?

Symbian OS versions prior to v9

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.

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.

Symbian OS v9 onwards - Signed Applications

If you are developing an application for Symbian OS v9 or later that you intend to Symbian Sign, you should request UIDs from the protected range.

Symbian OS v9 onwards- Unsigned Applications

If you are developing an application for Symbian OS v9 or a later that you do not intend to Symbian Sign, you should get a UID from the unprotected range.

How about SDK example or test code?

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.

This option is probably more suited to projects (e.g. file-manager or games)

  1. Use UIDs from the test range 0xExxxxxxx by choosing non-clashing "random" values from within this range

This option is probably 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 option (1) for all these examples though, if you wish.

  • 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)

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/signedui/welcome to avoid any issues.

How do I get new UIDs?

You need to be a registered user on Symbian Signed - https://www.symbiansigned.com/signedui/welcome Once you have registered and logged in click on "UIDs" and then "Request " on the left navigation bar.

If you are going to use Nokia Publish's free signing offer then the UIDs you need must be requested from Nokia Publish (which in turn gets them from Symbian Signed, under their own account).

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. The Symbian Signed Administrator will review your case and may modify your Symbian Signed account to increase the allocation limit.

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

A requirement for getting an application signed for Symbian OS v9 or later 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/signedui/welcome 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

Why the change between Symbian OS v8 and Symbian OS v9?

The new UID allocation system is automated, and so does not incur any delays whilst awaiting manual UID allocation.

However, the existing data in the legacy UID database was not complete enough to check the ownership of the UIDs as required for Symbian Signed with Symbian OS v9 applications. As a result this has not been migrated to the new system.

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 (or TARGET.SID in a Qt .pro 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.

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 (or TARGET.VID in a Qt .pro 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 Support, Application Packaging and Distribution and Security forum.

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 and the application will fail Symbian Signed.

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

Once you are logged in to https://www.symbiansigned.com/signedui/welcome, click on "Manage UIDs" tab. This page displays all the allocated UIDs along with the date of issuance to 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.

How do I change the UID of my application?

If you change the UID of your application, you must make sure you propagate the change throughout your source code. This means changing it in the following places:

group/<your project>.mmp

inc/<your project>.hrh

sis/<your project>.pkg

As well as anywhere it is used in your source code files.

Qt applications need only change the value in the .pro file; the qmake toolchain automatically updates any other instances.

Who do I contact if I have other questions?

Please post all issues on the Symbian Signed Support, Application Packaging and Distribution and Security Forum which can be found here. For further information on Platform Security, please click here

Licence icon cc-by-sa 3.0-88x31.png© 2010 Symbian Foundation Limited. This document is licensed under the Creative Commons Attribution-Share Alike 2.0 license. See http://creativecommons.org/licenses/by-sa/2.0/legalcode for the full terms of the license.
Note that this content was originally hosted on the Symbian Foundation developer wiki.

This page was last modified on 26 July 2012, at 09:14.
253 page views in the last 30 days.
×