Wiley.Symbian.OS.C.plus.plus.for.Mobile.Phones.Aug.2007 (779890), страница 55
Текст из файла (страница 55)
The program is then visible from the ApplicationLauncher.One of the benefits of installing applications using the SIS file format,rather than by copying files directly, is that you get an entry in this listing.This means that you can use it to remove the application; just tap on280PLATFORM SECURITY AND PUBLISHING APPLICATIONSUninstall and select your application from the list of uninstallable programs.
Then press Uninstall again to confirm. Go back to the ApplicationLauncher and see that it is gone.9.6 List of CapabilitiesThe unsigned-sandboxed and basic capabilities are:• LocalServices, which grants access to local network services thatusually do not incur a cost, such as Bluetooth• NetworkServices, which grants access to remote network services thatmay incur a cost, such as text messages; this capability is granted ona one-shot basis if not previously authorized• UserEnvironment, which grants access to live confidential informationabout the user and their immediate environment (e.g., audio, video orbiometric data)• ReadUserData, which grants read access to data that is confidentialto the phone user (subject to confirmation)• WriteUserData, which grants write access to data that is confidentialto the phone user (subject to confirmation)The extended capabilities essentially control access to services anddata.
They are defined at a general level, so that a server can presentthem to the end-user of a phone when installing an application, allowingthe end-user some control over what an application may do.• CommDD grants access to communications device drivers.• MultimediaDD grants access to multimedia device drivers.• PowerMgmt grants the right to power off unused peripherals, switchthe phone into and out of standby state, and power the phone down.• ReadDeviceData grants read access to confidential phone settings ordata.• WriteDeviceData grants write access to confidential settings thatcontrol the phone’s behavior.• DiskAdmin grants access to specific disk-administration operations.• NetworkControl grants access or modification rights to network protocol controls.SUMMARYSummaryIn this chapter, we’ve looked at:• key concepts in Platform Security• authorizing applications• implementing Platform Security in application and project files• how to build an application for delivering to a phone• how to get an application Symbian Signed.28110Debugging and the EmulatorDebugging is an indispensable step in the software development cycle.
Itis used to find out why an application is not behaving as expected andto correct the behavior. To help with debugging, all Symbian OS SDKscome with an emulator, which allows you to see, on your PC, what willhappen when you run the code on a target device – a mobile phone.The emulator is designed to be the primary development and debugging tool for Symbian OS, alongside any language-specific tools providedby the development environment.For most development purposes, you can write the same source codeto run on both the emulator and Symbian OS phones almost 100 % of thetime.
The basic emulator is delivered by Symbian, but is then customizedby the UI vendors for S60 and UIQ.This chapter looks at the emulator and the debugging facilities offeredby Symbian OS on the emulator, to help you to create robust applicationsrapidly and efficiently.10.1 Using the EmulatorSymbian OS phones use an ARM processor but PCs usually use an x86processor, so C++ programs for the emulator are compiled to nativex86 machine instructions and the emulator uses Win32 APIs to emulatemachine hardware and Symbian OS services.
Due to the hardwaredifference, there are some restrictions to bear in mind when testing withthe emulator.• The emulator cannot be used to test that code behaves the sameon phones of different capabilities (e.g. S60 phones with differentprocessor speeds or specifications), but can be used to test some284DEBUGGING AND THE EMULATORdifferences in behavior such as for different screen resolutions andorientations in later SDK versions.• The speed at which the emulator runs is dependent on the PC anddoes not mimic the hardware. Timing differences may be significant,hence testing on hardware is important, even at the early stages, toprove that a concept is possible on the phone and not likely to be tooslow to be usable.The emulator can be slow to start up, which is frustrating, but thiscan be improved in various ways, depending on the version of the SDKin question.
For example, the S60 3rd Edition emulator can use a modified version of the starter.rsc file. The simplest existing version isepoc32\release\winscw\udeb\z\resource\starter_shell.rsc,which can considerably speed up the emulator start time The drawback is that it does not start everything you need in the full emulator(for example, you can no longer double click to navigate through theemulator screens, but need to use the four-way navigation buttons, leftand right soft keys and menus).You can give this a try by renaming epoc32\release\winscw\udeb\z\resource\starter_shel l.rsc to starter.rsc. It is advisableto back up the current starter.rsc by renaming it before you do this,so you can roll back and use it, if you decide the ‘skinny’ emulator startup is no good for your purposes.Drive MappingThe emulator maps features of the target machine onto features of thePC environment.
For software development, it is particularly important toknow how the emulator maps drives and directories onto your PC’s filesystem.On a Symbian OS phone, there are two important drives (seeFigure 10.1):• Z: is the ROM, which contains a bootstrap loader and all the EXE,DLL and other files required to boot and run Symbian OS and itsapplications. All files on Z: are read-only; program files are executeddirectly from the ROM rather than being loaded into RAM.• C: is the read–write drive that is allocated from internal RAM.C: contains application data, application and system INI files anduser-installed applications.On the emulator, these drives are mapped onto subdirectories of thedrive on which you installed the SDK (see Figure 10.2 and the followingdescription).
This is to separate different emulator builds, and to ensureUSING THE EMULATOR285Free RAMKernel and user memoryRAMC: RAM diskZ:ROMFigure 10.1 Drives on a Symbian OS phonethat applications running on the emulator cannot write to other locationson your PC’s C: drive. An emulator configuration directory and startupdirectory completes the list of directories required by the emulator.epoc32dataEmulator configuration directoryreleasewinscwudebStartup directoryzEmulated Z: drivewinscwcEmulated C: driveFigure 10.2 Emulator directories• \epoc32\data\ is the emulator configuration directory. It containsthe initialization parameters for the emulator (epoc.ini), the bitmapused as the fascia surround for the screen (epoc.bmp), and variantsfor screens of different sizes.• \epoc32\release\winscw\udeb\ is the emulator startup directory.
It contains the Windows emulator (epoc.exe) and all theshared library DLLs.286DEBUGGING AND THE EMULATOR• \epoc32\release\winscw\udeb\z\ is the emulated Z: drive. Itcontains everything that the EPOC Z: drive should contain, exceptshared library DLLs, which are in the parent directory.• \epoc32\winscw\c\ is the emulated C: drive. It contains data andfiles. It does not contain compiled C++ programs – those should allbe on Z:.
In the emulator, all compiled applications become part ofthe pseudo-ROM that is the emulated Z: drive.You might wonder why there are so many deeply nested directories.The directories categorize the Symbian OS SDK materials, as follows:• epoc32\ sets apart the Symbian OS SDK run-time software fromanything else on the same drive• release\ sets apart released code from documentation, temporarybuild files, configuration files, etc.• winscw\ sets apart the emulator from target-machine builds; differenttargets use different directories; for Carbide.c++ and MetrowerksCodeWarrior, it is winscw• udeb\ sets apart the debug build from other builds; an executableC++ program built for the emulator debug build won’t run in anyother execution environment, so the debug build is kept distinct fromany other build• z\ attempts to mirror the structure of Z: on a real Symbian OS mobilephone.It would be nice if \epoc32\release\winscw\udeb\z\ could contain the entire emulated Z: drive.
Unfortunately, it cannot: EXEs andshared library DLLs cannot use the file structure of Symbian OS, withoutimpractical implications for the path environment in Win32. The onlypractical thing to do is to place all EXEs and shared library DLLs in thestartup directory: \epoc32\release\winscw\udeb\.Finally, data is independent of whether a build is release or debug, soC: is mapped to the \epoc32\winscw\c\ directory and shared betweenall builds.Emulator KeysThe majority of the PC keyboard is mapped in a straightforward way tothe Symbian OS keyboard. However, some special keys are available, asshown in Table 10.1.USING THE EMULATOR287Table 10.1 PC key mappings to Symbian OS functionsPC keySymbian OS facilityF1Alt+F2Menu keyHelp key (this doesn’t work in theUIQ emulator as there is no systemhelp file)Close the emulator windowPower onPower offAlt+F4F9F10Different user interfaces have additional keys that are part of thehardware.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
