《symbian操作系统》课程教学资源（技术资料）Evolving to Symbian OS v9.pdf_大学文库

Evolving to Symbian OS v9 Bruce Carney Head of Developer Marketing & Services The major focus with Symbian OS v9 has been to ensure everything is in place to enable Symbian OS to be used in a wider range of handsets – the higher volume ‘mid-range’ handsets – ultimately leading to wider adoption of smartphones. Symbian OS v9 brings with it great user interfaces, improved performance, rich functionality with a more robust and secure user environment and the expectations of ever decreasing device costs. Symbian OS v9 is an enabling platform, which addresses the long term needs of all the stakeholders in the industry: phone manufacturers, network operators, developers, and most importantly end-users. Soon after Symbian OS v9 was announced in February 2005, Nokia and UIQ introduced new versions of their popular user interface platforms – Series 60 3rd Edition and UIQ 3.0 – both of which use Symbian OS v9 as the underlying operating system. These flexible and compelling user interface platforms will make exciting new types of device form-factor possible, enabling Symbian OS phones to penetrate all kinds of market segment. With these changes, it is time to start preparing for an entirely new market landscape, not just a new version of Symbian OS. However, the most critical functionality has not even begun to be developed yet – your applications, content and services! As soon as Symbian OS v9 phones appear in the market, users will expect many of the more than 4,000 existing Symbian OS applications to be already migrated onto Symbian OS v9 as well as completely new applications being written. This article gives you an introduction to Symbian OS v9 and describes the market enablers provided by Symbian. Symbian OS v9 market landscape For the developer, Symbian OS v9 introduces a better environment and the prospect of a much larger market. An industry standard application binary interface, a real-time kernel and an enhanced platform security model are all key ingredients for a long lasting platform addressing the requirements of high-volume mobile phones. At the design level – a large effort has been made to create an agreed API baseline that will be maintained going forward, thus ensuring easier deployment and porting of applications between Symbian OS phones At an architecture level – Symbian OS v9 includes an enhanced platform security model and a new real-time kernel. Improved device and application security is becoming a mandatory requirement of many network operators and Symbian OS v9 delivers a platform that meets these requirements while retaining the advantages of an open platform At the core level – the Application Binary Interface (ABI) for the ARM Architecture has been adopted allowing greater flexibility and choice between compilers and, with the use of higher performance compilers, significant performance improvements in code execution At the device management level – support of OMA standards, and for developers following these standards, which will enable improvements in performance in Symbian OS phones manageability. Given the essential changes that have been introduced to Symbian OS, some steps must be taken to migrate existing products in order to benefit from the massive opportunities Symbian OS v9 offers

Practical steps in migration Over the next 3-6 months you need an action plan in place to ensure a successful migration to Symbian OS v9. Here we will examine some of the most important concepts. Understanding the changes With some new APIs and user interface changes, you will be required to do some retargeting of your application to Symbian OS v9. As the enhanced platform security model also introduces some new concepts, start learning about this early to build your knowledge and understanding. The Symbian OS v9 security framework is an evolution of the existing ‘perimeter’ security model already present in Symbian OS. It protects phones, networks and the end-user by restricting access to sensitive APIs to applications which can be trusted to use them correctly. Symbian OS v9 offers a ‘least privilege’ model i.e. applications only receive access to the minimum resources required. Sensitive APIs are mapped to ‘capabilities’ and applications are granted access to capabilities (and hence to the APIs with these capabilities) based on the trustworthiness of the application. Capabilities are a way of grouping similar types of functionality which might pose a security threat if abused. Of the many APIs present in Symbian OS, around 60% are unclassified and have no capability associated with them – using them is just like developing on a previous release of the platform. However, applications will need to be granted the required capabilities in order to call protected APIs (capabilities are assigned per process). There is some overlap between the signed and unsigned realms – and some applications may also access parts of sensitive functionality by virtue of embedded warning screens, e.g., when an unsigned application goes to send an SMS, a dialog box pops up to request permission from the user. Typical reasons for APIs to require a capability are: To protect the user – i.e. restrict access to user data such as contacts, and police events which incur billable charges

To protect the device – i.e. ensure code does not interfere the device’s primary function as a phone, allows other applications to work and handles extreme or unexpected situations To protect the network – i.e. identity of source of application and introduce traceability to ensure applications can be revoked and removed if they pose any threat to network integrity. Even though there is this new approach to API access management, the majority of API usage remains unchanged. Another proactive security mechanism introduced in Symbian OS v9 is data caging to protect content and manage executable code. You can obtain more information on Symbian OS v9 from: White papers and tutorials on www.symbian.com/developer and partner developer program websites; see Further Reading at the end of this paper. Formal classroom training from Symbian and training partners www.symbian.com/training Two new books due soon: Symbian OS Internals (on the new real time kernel) and Symbian OS Platform Security Once you have a solid understanding of the technical requirements for Symbian OS v9, the next phase is to begin actual development. The essential architectural changes in Symbian OS v9 mean there is no direct binary compatibility with earlier releases of Symbian OS, however a large degree of source code compatibility has been maintained where possible. At a minimum you will need: A Symbian OS v9 specific SDK and emulator from the relevant UI provider (e.g., Forum Nokia or UIQ) New build tools - so you have to allow time in your budget and schedule to acquire tools and familiarise the team with their functionality If your application will require access to sensitive APIs you will need to start using ‘Developer Certificates’ to test and develop on real devices Eventually an actual phone running Symbian OS v9 once these are available To assist with this transition, you may wish to consider using professional developer support companies or if you work for a Symbian Partner, Symbian’s Technical Support Helpdesk. Equally most of Symbian’s Partner competency centres also have strong Symbian OS v9 skills and are able to help you. Build environment and tools Introducing new compilers means, at a minimum, recompilation to the new target platform is necessary. You currently have the choice of ARM’s RVCT high performance compiler or a freely available GNU GCC compiler for less performance-sensitive applications. Thanks to the support for the Application Binary Interface (ABI) for the ARM Architecture standard, you can expect to see more IDEs and compilers becoming available. There are also some technical changes to the build process. Symbian has automated and improved the way UIDs are allocated; it is now simpler and faster to get one. UIDs have evolved with the improvements in platform security and there is therefore a new process to cater for these changes: in Symbian OS v9, UIDs are split into a protected range (required for signing Symbian OS v9 applications) and an unprotected one (for unsigned Symbian OS v9 applications and testing/development). UIDs (and the newly introduced ‘Secure IDs’ or SIDs) are allocated from the www.symbiansigned.com site where you can also find more details about the ranges and how they work

Developer Certificates Symbian is introducing free ‘Developer Certificates’ (DevCerts) to enable developers to write and test Symbian OS applications on target devices before submitting them for signing. DevCerts allow you to access sensitive capabilities on your own phone and to freely develop and debug your applications without the need for special phone software builds or other expensive alternatives. Importantly, not all applications need access to sensitive capabilities, so not all applications will require a Developer Certificate. Individual developers can register at the Symbian Signed website and download free Developer Certificates restricted to a single phone (via the IMEI number) with a validity period of six months. Professional development organisations, with an ACS Publisher ID, can get DevCerts that work on up to 20 devices with a validity period of six months. As their identity is validated by their ACS Publisher ID, they will also gain slightly more access to some of the sensitive capabilities. Unsigned or Symbian Signed Once you have completed your development, the next phase is to decide whether to leave your application unsigned or pass it through Symbian Signed. The great news is that Symbian OS v9 will not introduce a significant amount of change from what is happening already with Symbian Signed and existing versions of Symbian OS. For applications which use sensitive system functionality, the enhanced security model means it will be necessary to pass through Symbian Signed in order for your application to access these APIs. In most cases, signing will be via the existing, publicly accessible Symbian Signed process. However the ‘right’ to sign against some very inner core functionality – such as DRM or granting access to the underling file system – will only be possible with permission from the specific phone manufacturer. Details of this process are available on the Symbian Signed site for the very limited number of developers who need to obtain such access. As an unsigned application has no proof of origin the user will continue to see the familiar ‘health warning’ to advise that the application is from an unknown source. So, even if your application does not need to access any sensitive API, you do need to consider how Symbian Signed may be beneficial for your route-to-market. Symbian Signed is increasingly being endorsed and used as the industry-wide agreed standard on what is required from an application to be distributed to mass-market devices. Already an increasing numbers of channels are expecting applications to be Symbian Signed before they distribute them, in order to help boost user confidence. The Symbian Signed process basically remains: You obtain an ACS Publisher ID from VeriSign (the certificate authority). This is a crucial step and effectively provides assurance of organisational identity You pre-test against the Symbian Signed test criteria on your own phone(s) You submit your application to one of the independent test houses (currently NSTL, MphasiS, and CapGemini). Turnaround time for testing is usually around one week. For Symbian’s Platinum Partners and large ISVs that meet the eligibility criteria, there is the opportunity to join the Self Certification program. Self Certification allows you to run the test criteria in you own QA process, rather than requiring an independent test house. Symbian Signed will be announcing and introducing expanded routes to market for smaller ISVs, and freeware and open source developers later this year. Conclusion Over the next 3-6 months you need an action plan in place to ensure that: Your technical staff understand important changes in Symbian OS v9