Symbian OS

30
SYMBIAN OS -By Adit Pathak (09bce053) Faculty guide:- Vibha Patel

Transcript of Symbian OS

Page 1: Symbian  OS

SYMBIAN OS -By Adit Pathak (09bce053)

Faculty guide:- Vibha Patel

Page 2: Symbian  OS

PRESENTATION FLOW

Memory management -Leave & cleanup stack Socket Communication Security(Application signing) Application development -User interfaces -Tools required -Important files - Building,testing & installing application

Page 3: Symbian  OS

MEMORY MANAGEMENT Systems with No Virtual Memory, no disk drive. These systems have two types of storage: RAM and

flash memory. RAM stores the operating system code ;flash

memory is used for both operating memory and permanent (file) storage. Often, it is possible to add extra flash memory to a device (such as a Secure Digital card), and this memory is used exclusively for permanent storage.

RAM size is small as compared to PC: 32-64MB Dynamic memory allocation must be used No frequent rebooting

Page 4: Symbian  OS

PROBLEMS IN DYNAMIC MEMORY ALLOCATION

Have to release memory as soon as possible Nested function calls , in which fn calls another fn

which in turn calls another & so on. Problem occurs when every fn allocates memory for

class object At every allocation memory allocation errors must be

checked. If fn at the bottom of this nested calls can’t allocate

memory then it will return error value ,which in turn return error value to its calling fn & previously allocated memory must be released.So code becomes complex.

Page 5: Symbian  OS

LEAVE AND TRAPD

Use of leave & trap will solve the problem Whenever allocation fails fn leaves It leaves all fn in sequence untill it finds TRAPD() TRAPD(error,HandleKeyL());

PROBLEM -> Memory allocated by calling fn in sequence is

not freed

Page 6: Symbian  OS

case Use3: { CX* x=new (Eleave) CX; x->UseL(); delete x; } Void CX::UseL() { Tint* pi=new (Eleave) Tint; delete pi; } No problem if cx fails But there is problem if UseL() leaves

Page 7: Symbian  OS

CLEANUP STACK Stack which is cleaned automatically when leave

occurs case Use3: { CX* x=new (Eleave) CX; CleanupStack::PushL(x); x->UseL(); CleanupStack::PopandDestroy(x); }

Page 8: Symbian  OS

SOCKET COMMUNICATION

Sockets API have become the standard API in establishment of TCP/IP connection on many platforms including Symbian.

Symbian can use sockets API to establish a connection of infrared, Bluetooth and other protocols.

Socket in the network represents a communication path endpoint.

Endpoint is identified by the IP address of the machine with a combination of a port address.

The communication between two end points is called a channel.

Page 9: Symbian  OS

CLIENT API CLASSES

RSocketServ : creates session with socket server, used for establishing subsessions for RSocket & RHostResolver. To establish a session with socket server the member function RSocketServ::Connect() is used. RSocketServ::Close() closes all subsessions automatically.

Rsocket : the endpoint of socket based communication.Each instantiated object of this class represents a single socket.It allows:

-Socket opening -Read-write data from/to prorocol

RHostResolver: provides the interface for host resolution services

RConnection: selects internet access point. It supports multiholming(Several

network interfaces active at the same time).

Page 10: Symbian  OS

STEPS FOR TCP/IP USING SOCKET

Create a connection to socket server (RSocketServ) Choose Internet access point (RConnection) Send DNS-request (RHostResolver) Close connection to DNS resolver (RHostResolver) Open TCP socket (RSocket) Connection request+ target IP (RSocket) Data Transfer (RSocket) Close Socket (RSocket) Close connection (RConnection) Close socket server connection (RSocketServ)

Page 11: Symbian  OS

SECURITY IN SYMBIAN OS Smartphones are single-user devices and require no user

authentication to use basic functions. Even more complicated functions (such as installing

applications) require authorization but no authentication

Gatekeeper security before version 9 User was asked for permission before installing application ,user was

trusted to use them wisely The thinking in this design was that only user-installed applications

could cause system havoc and an informed user would know what programs he intended to install and what programs were malicious

A new smartphone with no user-installed applications would be a system that could run without error.

Installing only applications that a user knew were not malicious would maintain the security of the system.

Page 12: Symbian  OS

problem with this design is that users do not always know the complete ramifications of the software they are installing

There are viruses that masquerade as useful programs, performing useful functions while silently installing malicious code.

Normal users are unable to verify the complete trustworthiness of all the software available.

Platform Security Architecture(PSA) for version 9

verification of trust prompted a complete redesign of platform security for Symbian OS version 9 which keeps the gatekeeper model, but takes the responsibility for verifying software away from the user

Page 13: Symbian  OS

PSA & APPLICATION SIGNING

Each software developer is now responsible for verifying her own software through a process called signing and the system verifies the developer’s claim

Not all software requires such verification, only those that access certain system functions.

Self signing (no capabilities or unrestricted capabilities)

When certain capabilities are required the application must be signed

Page 14: Symbian  OS

STEPS IN APPLICATION SIGNING When a developer has developed a software package and want

to distribute it, he or she must submit his package to a trusted third party for validation.

The trusted third party then verifies that the list of software access types is complete and that no other type of access occurs. If this third party can make this verification, the software is then signed by that third party. This means that the installation package has a special amount of information that details what it will do to a Symbian OS system and that it may actually do that.

This installation package is sent back to the software developer and may now be distributed to users.(sisx file)

The install process checks the signage of the installation package. If the signing of the package is valid, the capabilities granted the software are recorded and these are the capabilities granted to the application by the kernel when it executes.

Page 15: Symbian  OS

DIFFERENT LEVELS OF TRUST

Page 16: Symbian  OS

APPLICATION DEVELOPMENT

User interfaces ->S60 -> UIQ What is needed Different files Building and testing Installing on phone

Page 17: Symbian  OS

USER INTERFACES –S60 The S60 Platform is a software platform for mobile phones that

runs on symbian os. S60 has been designed for easy one-handed use. All S60 phones use a navigation controller that allows

navigation in four direction,a confirmation key & 2 hardware buttons called softkeys.

S60 has 4 versions:s601,2,3 & 5.

Edition Devices

S60 1st Nokia 7650,3600,3620

S60 2nd Nokia 6600,Panasonic x700,Samsung SGH-D720

S60 3rd Nokia 3250,N73,N71,E60

S60 5th Nokia 5233,5800,C6-00

Page 18: Symbian  OS

S60 PHONE

Screenshot of a typical Nokia S60 user interface.

Page 19: Symbian  OS

USER INTERFACES – UIQ

UIQ (formerly known as User Interface Quartz)   is a software platform  based upon Symbian os.

UIQ phones employ touch screens with a resolution of 208×320 pixels (UIQ 1.x & 2.x) and 240×320 (UIQ 3.x). Depending on the phone, the color depth is 12-bit (4096 colors), 16-bit (65536 colors), 18-bit (262144 colors), and 24-bit (16,777,216 colors) on some newer phones.

 It can be configured with respect to touch/non-touch screens, screen size, the use of a menu bar or the use of soft keys.

Edition Devices

UIQ 2.x Nokia 6708,sony ericsson p800,motorola A920,A925

UIQ 3.x Sony ericsson M600,P1,P990,G700 Motorola RIZR Z8,Z10

Page 20: Symbian  OS

UIQ PHONES

Screenshot of a typical UIQ 3 user interface.

Page 21: Symbian  OS

WHAT IS NEEDED?

a PC running Windows NT or better an SDK (S60 or UIQ) which will contain emulator a C++ development IDE supported by your SDK.(eg.

Carbide.c++) the appropriate phone handset on which to test your

application The ability to deploy code onto the phone (for

example, a removable media card, for example, MMC or Memory Stick, or a connection between your development PC and the handset using USB or Bluetooth).

Page 22: Symbian  OS

DIFFERENT FILES

Creating project using carbide.c++

It will create different file for skeleton application

Files in different directories

Group- .mmp & bld.inf file, src- .cpp source files , data- resource file, inc-headerfiles , sis- .pkg ,.sis,.sisx files

Page 23: Symbian  OS

.MMP FILE A project definition file (.mmp file) that describes a project to

be built. This is an environment neutral file that can be used by the tools to produce make files for any of the supported target environments. It also defines resource files to be built.

Page 24: Symbian  OS

BLD.INF FILE A component description file (bld.inf), which lists a group of

related projects, and gives additional build instructions. Its main purpose is to list the project definition mmp files and

any files that the build tools must copy into place before a build. 

Page 25: Symbian  OS

APPLICATION FRAMEWORK Every Symbian OS GUI application, regardless of the UI

platform on which it is based, will use the application framework architecture, which means it will derive from a particular set of UI-specific classes: application, document, application UI and application view.

Application: When instantiated, the object is used to identify the application, by returning its UID. It also creates the application’s document class.

Application Document: :The document class handles any persistent non-GUI data for the application and instantiates the application UI class.

Application UI: The application UI handles UI events generated from the user’s actions (except low-level touch screen events and alphanumeric keyboard input). It also instantiates the application’s default view.

Application view: This is the root GUI control which activates the main application window and acts as a container for other controls used.

Page 26: Symbian  OS

BUILDING & TESTING Select build target- emulator debug or phone release To run,right click on project select run as symbian os

c++ project. It will open emulator

Page 27: Symbian  OS
Page 28: Symbian  OS

INSTALLING ON PHONE

Go to .pkg file in project navigator Right click & select build package It will self sign the application & .sisx file will

be created. Transfer to phone using data cable,bluetooth

etc & install it

Page 29: Symbian  OS

REFERENCES [1] Advanced Symbian OS C++:Programming mobile Phones, by Richard

Harrison  [2] Modern operating system, by Andrew S. Tanunbum  [3] Symbian Os Explained:effective C++ Programming for Smartphones,

by Jo Stichbury  [4] Symbian OS C++ for mobile phones, by Richard Harrison, Mark

Shackman  [5] en.wikipedia.org/wiki/Symbian  [6] library.developer.nokia.com/...Developers.../index.html  [7] E-Pass Using DRM in Symbian v8 OS and TrustZone : Securing Vital

Data on Mobile Devices, by Wan Huzaini Wan Hussin, Reuben Edwards and

Paul Coulton [8] Testing the Symbian OS Platform Security Architecture ,byThomas

Badura and Michael Becher,University of Mannheim, Germany [9] File Transmission via socket from Smartphone to PC Based on

Symbian OS, by LinChunmin,LuoDelin,WuShunxiang

Page 30: Symbian  OS

THANK YOU