|
1 =============================================================== |
|
2 Python for S60 1.9.x on S60 3rd and higher editions, 24.01.2009 |
|
3 =============================================================== |
|
4 |
|
5 |
|
6 Contents: |
|
7 |
|
8 1. Introduction |
|
9 2. Overview of PyS60 on S60 3rd and higher editions |
|
10 3. Standard development lifecycle in 3rd and higher editions |
|
11 3.1 Signing and distribution |
|
12 3.2 Module level details |
|
13 4. File locations |
|
14 5. Capabilities |
|
15 6. Porting PyS60 1.4.x scripts to PyS60 1.9.x |
|
16 7. Native extensions |
|
17 7.1 ABI compatibility |
|
18 7.2 Porting PyS60 1.4.x extensions to PyS60 1.9.x |
|
19 7.3 Embedding the interpreter |
|
20 8. Summary |
|
21 9. Glossary |
|
22 |
|
23 |
|
24 1. Introduction |
|
25 --------------- |
|
26 |
|
27 This document describes the changes to Python for S60 (hereafter PyS60) needed |
|
28 in order to support S60 3rd edition (hereafter also S60 3rdEd) or higher editions. |
|
29 Starting from PyS60 1.9.0, the supported editions are only S60 3rd and higher |
|
30 editions. |
|
31 |
|
32 The new platform security (hereafter platsec) features in Symbian OS 9.x/EKA2, |
|
33 and S60 3rdEd onwards require several changes to the whole PyS60 framework. |
|
34 Without these modifications S60 3rd and later editions would not be supported |
|
35 by PyS60. The implementation alternative selected in order to support S60 3rd |
|
36 and higher editions is tightly aligned with the common EKA2 platform security |
|
37 framework in order to minimize the work for a PyS60 developer. At the same time |
|
38 this limits the possible security threats posed by PyS60. |
|
39 |
|
40 The solution for PyS60 in EKA2 is based on two use cases: |
|
41 |
|
42 1. Stand-alone installation - in essence this makes Python applications no |
|
43 different from native Symbian applications, a user cannot tell whether this is |
|
44 a Python or C++ application. The application is visible in the device main |
|
45 menu |
|
46 |
|
47 2. Plain script running and the application to enable this, aka the script |
|
48 shell – the Python application seen in PyS60 1.0 onwards |
|
49 |
|
50 In this document we provide information how the new platform security features |
|
51 affect PyS60, what will be the development options and offer advices for native |
|
52 extending. |
|
53 |
|
54 For all questions and feedback, related to PyS60 and platsec, please use the |
|
55 Forum Nokia discussion board: |
|
56 |
|
57 http://discussion.forum.nokia.com/forum/forumdisplay.php?f=102 |
|
58 |
|
59 Tip: use the advanced search option with keyword "platsec" and select the Python |
|
60 forum for the search. |
|
61 |
|
62 |
|
63 2. Overview of PyS60 on S60 3rd or higher edtions |
|
64 --------------------------------------------------- |
|
65 |
|
66 In 3rdEd and higher edition devices, platsec is enforced. This means that all the |
|
67 installed SISX files need to be signed (NB. there might be an option to install |
|
68 unsignedpackages in some devices). Unsigned packages cannot be installed to a device |
|
69 and neither the old style SIS packages nor the binaries packaged from 2ndEd or 1stEd |
|
70 are compatible with the 3rdEd. |
|
71 |
|
72 The software installer (hereafter SWInstall) will check if the application in |
|
73 the SISX package is signed. For more information about signing, see the Section |
|
74 "Signing". |
|
75 |
|
76 A fundamental concept in platsec is 'capability' which is the term used for what |
|
77 the running process can do in the device - process is the basic insulation |
|
78 granularity in platsec and capabilities are forced during runtime. A capability |
|
79 must be held by the executable binary if the process needs to access some |
|
80 restricted resource. |
|
81 |
|
82 Since a standalone PyS60 application is no different from a native C++ |
|
83 application and runs in a separate process it needs to be signed if it uses |
|
84 controlled APIs or it is distributed via a SISX package. |
|
85 |
|
86 What a Python standalone application can do will be limited by the capabilities |
|
87 assigned to the interpreter DLL - these capabilities are listed in Section 5. |
|
88 "Capabilities". In other words, this is the upper bound for any Python |
|
89 application which uses the Nokia signed PyS60 distribution. There is of course |
|
90 the possibility to sign the Python interpreter DLL for special purposes with |
|
91 larger capabilities if needed but this discussion is left out from this |
|
92 document. |
|
93 |
|
94 As the Python application seen from the device main menu, aka the script shell, |
|
95 is also a Python application it needs to be signed. The script shell should not |
|
96 enable the running of scripts with large capabilities and thus it is not signed |
|
97 by Nokia with the same capabilities as the interpreter DLL. This should not |
|
98 cause problems for development - a developer can sign the script shell |
|
99 application with developer certificate (hereafter devcert). Due to separate |
|
100 signing needs for the interpreter DLL and the script shell application, there is |
|
101 a need for two separate packages ('X' indicates version number): |
|
102 |
|
103 * Python_X.X.X_3rdX.SIS - contains the interpreter DLL, all the Nokia |
|
104 provided native Python extensions and other needed files |
|
105 |
|
106 * PythonScriptShell_X.X.X_3rdX.SIS - contains the script shell application, |
|
107 does not work without the above package |
|
108 |
|
109 A developer should keep in mind that the script shell is just a Python script, |
|
110 similar to the one you package with the ensymble tool and subject to the |
|
111 same security preconditions as described earlier in this document. The |
|
112 interpreter DLL is the one used by all the standalone Python applications and |
|
113 the entity that needs to be signed with a large set of capabilities to ensure |
|
114 that individual Python applications can access the controlled resources as |
|
115 freely as possible. Notice that the script shell Python application visible in |
|
116 the device main menu has nothing to do with other standalone Python applications |
|
117 (ie. there are no logical or conceptual dependencies). |
|
118 |
|
119 For clarification, here is an outline of a standalone Python application in |
|
120 3rdEd devices: |
|
121 |
|
122 default.py |
|
123 | (wrapped together with 'foobar.exe' e.g. with ensymble py2sis) |
|
124 | |
|
125 foobar_0x01234567.exe |
|
126 | (a simple launchpad application for interpreter creation etc. |
|
127 | Another example is the Python_launcher.exe) |
|
128 python25.dll |
|
129 | (shared between standalone Python applications) |
|
130 | |
|
131 location.pyd |
|
132 (all the other native extensions are at this level also) |
|
133 |
|
134 In the above diagram, the 'python25.dll' is signed with selfsigned certificate, |
|
135 and as stated previously, it provides the upper bound for what the 'foobar.exe' |
|
136 can access (in the platsec sense) in the device. For the 'foobar.exe' the developer |
|
137 has chosen a suitable set of capabilities limited by the developer's certificate |
|
138 and/or the Python APIs utilized. The capabilities needed for the APIs are outlined in |
|
139 Section 3.2. |
|
140 |
|
141 For more information, please see the platsec material provided by Symbian and |
|
142 Nokia, e.g. here is an overview of the Symbian signed process and platsec: |
|
143 |
|
144 https://www.symbiansigned.com/How_has_Symbian_Signed_evolved_with_Symbian_OS_v9.pdf |
|
145 |
|
146 Symbian signed |
|
147 -------------- |
|
148 |
|
149 In principle, there is no problem in getting a standalone Python application to |
|
150 be Symbian signed - a standalone Python application is no different from a |
|
151 native C++ application. |
|
152 |
|
153 Symbian signed Python applications are not tested yet with PyS60 1.9.1. |
|
154 |
|
155 For more information, please refer to: https://www.symbiansigned.com/ |
|
156 |
|
157 |
|
158 3. Standard development lifecycle |
|
159 --------------------------------- |
|
160 |
|
161 The S60 emulator allows unrestricted access to the platform(set PlatSecEnforcement |
|
162 to OFF in epoc32\data\epoc.ini & restart the emulator) and therefore the PyS60 |
|
163 developer is advised to first use the emulator for overall testing of a Python script. |
|
164 Useful information especially about the platform warnings can be found from the |
|
165 emulator log file, located usually under directory: |
|
166 |
|
167 c:\Documents and Settings\<USERID>\Local Settings\temp\EPOCWIND.OUT |
|
168 |
|
169 For example, the following warning message would be emitted to the log file if a |
|
170 script tries to delete a file ("traceback.pyc") under \resource: |
|
171 |
|
172 64.990 *PlatSec* WARNING - Capability check would have failed - A Message |
|
173 (function number=0x00000013) from Thread Python[10201510]0001::PYTHON, sent to |
|
174 Server !FileServer, was checked by Thread EFile.exe[100039e3]0001::Main and |
|
175 was found to be missing the capabilities: TCB . Additional diagnostic |
|
176 message: \resource\traceback.pyc Used to call: Delete |
|
177 |
|
178 This error is due to 'data caging' and the protection of folder \resource for |
|
179 modifications. |
|
180 |
|
181 The emulator can be configured also to simulate the platsec constraints, see |
|
182 the SDK documentation for more information (search the SDK with "Platform |
|
183 Security Tab"). |
|
184 |
|
185 In a device the following would be received if the Python script tries to write |
|
186 to a restricted/not restricted location (example via Bluetooth console in Nokia |
|
187 N73): |
|
188 |
|
189 [GCC 3.4.3 (release) (CodeSourcery ARM Q1C 2005)] on symbian_s60 |
|
190 Type "copyright", "credits" or "license" for more information. |
|
191 Type "commands" to see the commands available in this simple line editor. |
|
192 >>> f=open('c:\\sys\\bin\\test.log', 'w') |
|
193 Traceback (most recent call last): |
|
194 File "<console>", line 1, in ? |
|
195 IOError: [Errno -46] : 'c:\\sys\\bin\\test.log' |
|
196 >>> f=open('c:\\Python\\test.log', 'w') |
|
197 >>> f.write('foobar') |
|
198 >>> f.close() |
|
199 >>> |
|
200 |
|
201 The first file open fails since location c:\sys\bin is restricted in 3rdEd |
|
202 devices. The second file open succeeds as this location is not controlled by |
|
203 platsec - this location is also the folder for scripts seen in the script shell |
|
204 application. Notice also that the platform security constraints can be handled |
|
205 at Python level with e.g. try-except constructs. |
|
206 |
|
207 |
|
208 3.1 Signing and distribution |
|
209 ---------------------------- |
|
210 |
|
211 For executing the scripts in an actual S60 3rdEd or later device there exists |
|
212 numerous alternatives for signing and distribution e.g.: |
|
213 |
|
214 1) Using a devcert for SISX signing |
|
215 |
|
216 2) Self-signing the SISX |
|
217 |
|
218 3) Signing the Python script shell application with the above 1) or 2) |
|
219 alternatives and installing the individual scripts with separate packages |
|
220 (which need to be signed as well) |
|
221 |
|
222 4) Packaging the scripts with ensymble - py2sis (and signing the SISX packages). |
|
223 |
|
224 By following the first alternative, a developer can sign applications with |
|
225 devcerts prior the official Symbian signing and test the application in |
|
226 production devices with almost full capabilities. Again, applications you are |
|
227 planning to distribute for 3rdEd handsets need to be signed since the platform |
|
228 security restrictions are taken into use in the target handsets. For obtaining |
|
229 devcerts, see: |
|
230 |
|
231 https://www.symbiansigned.com/app/page/devcertgeneral |
|
232 |
|
233 For the second alternative, self-signing, please see the 3rdEd SDK documentation |
|
234 for more information: |
|
235 |
|
236 Introduction to S60 3rd Edition >> How to Sign .sis Files |
|
237 |
|
238 (or search with keyword "self-sign") |
|
239 |
|
240 In the third alternative, the Python script shell SIS package is signed with a |
|
241 devcert or self-signed and the individual script can be packaged to a SISX file |
|
242 and e.g. Bluetooth beamed to the device. Here is an example ".pkg" file used for |
|
243 generating a SISX file (for processing this file, please see the above document |
|
244 about signing): |
|
245 |
|
246 ; |
|
247 ;Languages |
|
248 &EN |
|
249 ; |
|
250 ; The packages UID from test range |
|
251 ; |
|
252 #{"MyTestPackage"},(0xE000000F),1,0,0,TYPE=SISAPP |
|
253 %{"Vendor-EN"} |
|
254 (0x101F7961), 0, 0, 0, {"Series60ProductID"} |
|
255 ; |
|
256 ; Files to install, this file needs to be found by 'makesis.exe'. |
|
257 ; The file location on the right side is the directory seen by the script shell |
|
258 ; application in the device, you can install your scripts there for easy |
|
259 ; invocation |
|
260 ; |
|
261 "c:\src\mytest.py" -"c:\data\Python\mytest.py" |
|
262 |
|
263 The above example uses UID from the range 0xE0000000 - 0xEFFFFFFF, this range is |
|
264 reserved for testing. For more information about UIDs, please see: |
|
265 |
|
266 https://www.symbiansigned.com/app/page/uidfaq |
|
267 |
|
268 In the fourth alternative, a developer can use the ensymble program to package |
|
269 individual scripts to installable SISX packages. The packages generated by |
|
270 ensymble require the Python runtime sis to be installed in the device. |
|
271 For details about ensymble usage, refer 'tools\py2sis\ensymble\README.txt' |
|
272 |
|
273 |
|
274 3.2 Module level details |
|
275 ------------------------ |
|
276 |
|
277 The Python functions or modules affected by platform security are outlined in |
|
278 the following table: |
|
279 |
|
280 .--------------------------------------------------------------------------. |
|
281 | Function or module | Capabilities needed | Devcert | Self-signing | |
|
282 |--------------------------+----------------------+---------+--------------| |
|
283 | location.gsm_location()* | ReadUserData, | | | |
|
284 | | ReadDeviceData, | X | | |
|
285 | | Location | | X^ | |
|
286 |--------------------------+----------------------+---------+--------------| |
|
287 | contacts | ReadUserData, | | X | |
|
288 | | WriteUserData | | | |
|
289 |--------------------------+----------------------+---------+--------------| |
|
290 | sysinfo.imei() | ReadDeviceData+ | | X | |
|
291 |--------------------------+----------------------+---------+--------------| |
|
292 | telephone | NetworkServices | | X | |
|
293 |--------------------------+----------------------+---------+--------------| |
|
294 | messaging | NetworkServices | | X | |
|
295 |--------------------------+----------------------+---------+--------------| |
|
296 | e32.set_home_time() | WriteDeviceData | X | | |
|
297 .--------------------------------------------------------------------------. |
|
298 |
|
299 * = Gives false data if the executable is not signed with the specific |
|
300 capabilities. |
|
301 |
|
302 + = Claimed by the S60 SDK but in practise self-signing is sufficient. |
|
303 |
|
304 ^ = On 3rd Ed FP2 and higher devices. |
|
305 |
|
306 No capabilities are needed e.g. by the following extensions or self-signing is |
|
307 sufficient: |
|
308 |
|
309 * camera |
|
310 * e32db |
|
311 * inbox |
|
312 * audio |
|
313 * socket |
|
314 * graphics |
|
315 |
|
316 |
|
317 4. File locations |
|
318 ----------------- |
|
319 |
|
320 In EKA2 the file locations have changed, as previously mentioned, the concept |
|
321 'data caging' refers to the changed and controlled locations. The file locations are |
|
322 as follows: |
|
323 |
|
324 c:\sys\bin |
|
325 |
|
326 Contains all the native extensions including all the binary launchpads for |
|
327 Python applications. |
|
328 |
|
329 c:\resource\python25 |
|
330 |
|
331 Contains the Python standard library files bundled with the Nokia PyS60 SISX |
|
332 package. |
|
333 |
|
334 c:\private\<UID> |
|
335 |
|
336 Contains the "default.py" script which is the script interpreted first by the |
|
337 launchpad binaries. The <UID> is the unique identifier assigned to a Python |
|
338 application. |
|
339 |
|
340 These locations have special constraints, see Symbian and Nokia platsec |
|
341 documentation for more information. In summary, \sys\bin is the only place where |
|
342 executable binaries (including DLLs) can exist, \resource can only be read, not |
|
343 written to (except by TCB programs) and \private\<UID>\ is only accessible by |
|
344 the process in question (and TCB programs). |
|
345 |
|
346 Most notably this is seen in the "import" path of the interpreter. The following |
|
347 is the output from the script shell application using Bluetooth console: |
|
348 |
|
349 >>> import sys |
|
350 >>> sys.path |
|
351 ['c:\resource\Python25\e35e00df', 'c:\resource\Python25\python25.zip', |
|
352 'c:\resource\Python25', 'c:\resource\Python25\site-packages'] |
|
353 |
|
354 Notice that the directory under c:\resource\Python25, named after the process UID |
|
355 (in the above example c:\resource\Python25\e35e00df) is a new search location for |
|
356 the interpreter. In this example it is the one assigned for the Python script shell |
|
357 application. If you package your application with ensymble, the "import" path will |
|
358 automatically contain the correct search path similar to the path above but with the UID |
|
359 assigned to your application. This new search path has implications for native |
|
360 extensions, see Section 6.2 for more information. |
|
361 |
|
362 |
|
363 There is a new function for obtaining the process UID in PyS60: |
|
364 |
|
365 appuifw.app.uid() |
|
366 |
|
367 Returns the UID, in Unicode, of the native application in whose context the |
|
368 current Python interpreter session runs. |
|
369 |
|
370 |
|
371 5. Capabilities |
|
372 --------------- |
|
373 |
|
374 The capabilities assigned by Nokia to PyS60 'devcert build' are as follows: |
|
375 |
|
376 User Capabilities: |
|
377 |
|
378 * NetworkServices |
|
379 * LocalServices |
|
380 * ReadUserData |
|
381 * WriteUserData |
|
382 * Location |
|
383 * UserEnvironment |
|
384 |
|
385 System Capabilities: |
|
386 |
|
387 * PowerMgmt |
|
388 * ReadDeviceData |
|
389 * WriteDeviceData |
|
390 * TrustedUI |
|
391 * ProtServ |
|
392 * SwEvent |
|
393 * SurroundingsDD |
|
394 |
|
395 A Python application using the Nokia signed Python SISX package cannot have more |
|
396 capabilities than in the above list, less is of course possible. If more |
|
397 capabilities are needed, the Python DLL capabilities need to be changed like |
|
398 stated before and the SISX package signed with a certificate with enough signing |
|
399 metacapabilities. For more information, please see the 'README.txt' in the |
|
400 source distribution. |
|
401 |
|
402 The 'self-signed build' of PyS60 consists of the following capabilities: |
|
403 |
|
404 * LocalServices |
|
405 * NetworkServices |
|
406 * ReadUserData |
|
407 * UserEnvironment |
|
408 * WriteUserData |
|
409 |
|
410 6. Porting PyS60 1.4.x scripts to PyS60 1.9.x |
|
411 ------------------------------------------- |
|
412 |
|
413 Here are some changes needed for porting existing PyS60 scripts: |
|
414 |
|
415 1. The main script of the PyS60 applications, default.py is not executed |
|
416 directly, as was the case in PyS60 1.4.x. The wrapper script, launcher.py |
|
417 (ext\amaretto\python_ui\src) is first executed which in turn does an |
|
418 execfile on the default.py. Therefore, to exit the application |
|
419 programmatically use appuifw.app.set_exit() |
|
420 |
|
421 7. Native extensions |
|
422 -------------------- |
|
423 |
|
424 This section highlights some of the changes needed for porting PyS60 1.4.x |
|
425 extentions on PyS60 1.9.x. |
|
426 |
|
427 |
|
428 7.1 ABI compatibility |
|
429 --------------------- |
|
430 |
|
431 Nokia binary distribution of PyS60 is compiled with ARMV5. The PyS60 SDK |
|
432 package contains both GCCE and ARMV5 link libraries. Developers have to use |
|
433 either ARMV5 (RVCT 2.2) or GCCE target for compiling their native extensions |
|
434 for devices. |
|
435 |
|
436 |
|
437 7.2 Porting PyS60 1.4.x extensions to PyS60 1.9.x |
|
438 ----------------------------------------------- |
|
439 |
|
440 Here are some changes needed for porting existing native PyS60 extensions: |
|
441 |
|
442 1. There is no TLS functionality as this is no longer needed. Use |
|
443 EPOCALLOWDLLDATA in the MMP file if the module has initialized static data. |
|
444 |
|
445 2. Use PyGILState_Ensure() and PyGILState_Release() functions for acquiring and |
|
446 releasing the global interpreter lock, instead of using |
|
447 PyEval_RestoreThread(PYTHON_TLS->thread_state) and PyEval_SaveThread(). |
|
448 |
|
449 3. The interpreter DLL name is changed to python25.lib and hence modify the MMP |
|
450 file so that the module is linked against this DLL instead of python222.lib |
|
451 |
|
452 The Python header files are now in \epoc32\include\Python25 and hence the MMP |
|
453 file needs to be updated accordingly. |
|
454 |
|
455 4. From PyS60 1.9.x onwards, the pyd name expects a prefix as the new import |
|
456 mechanism expects this. Until 1.9.3 this prefix was '251_'. From 1.9.4 |
|
457 onwards the prefix has been changed to 'kf_'. Note that this change is |
|
458 required only for the pyd name and module name is not required to have this |
|
459 prefix. |
|
460 |
|
461 5. Place the compiled binary (.pyd) and other possible wrappers under a directory |
|
462 by the same name as the extension and place this directory in the module-repo |
|
463 folder on your system. For detailed instructions on this topic read |
|
464 Section "Extending Module-repo" in Chapter "Module Repository" from the |
|
465 S60 documentation. |
|
466 |
|
467 6. You can package your extension to a SISX file using the PyS60 application |
|
468 packager. Refer the PyS60 application packager HELP for information on this. |
|
469 |
|
470 Refer to the elemlist module under extras\elemlist for a quick startup information. |
|
471 |
|
472 Note that the init-function still needs to be exported in the pyd in ordinal 1. |
|
473 |
|
474 |
|
475 7.3 Embedding the interpreter |
|
476 ----------------------------- |
|
477 |
|
478 An example code snippet depicting embedding of Python interpreter into an application |
|
479 is given below: |
|
480 |
|
481 #include <Python.h> |
|
482 |
|
483 int main(void) |
|
484 { |
|
485 Py_Initialize(); // Initialize Python interpreter |
|
486 |
|
487 PyRun_SimpleString("print 'hello world!'"); // Execute a Python statement |
|
488 |
|
489 Py_Finalize(); // Finalize the Python interpreter |
|
490 |
|
491 return 0; |
|
492 } |
|
493 |
|
494 8. Summary |
|
495 ---------- |
|
496 |
|
497 This document highlighted the changes to PyS60 in 3rdEd and later editions, |
|
498 and also the changes needed for porting existing native extensions to PyS60 1.9.x. |
|
499 Without these changes Python would not be supported in 3rdEd devices. |
|
500 The changes outlined in this document are briefly as follows: |
|
501 |
|
502 * The script shell application is separated to a new SISX file from the main |
|
503 Python interpreter distribution. The two SISX files can be signed with different |
|
504 set of capabilities. |
|
505 |
|
506 * In order to access broader set of functions in PyS60 and more locations in |
|
507 the device a developer might need a devcert. |
|
508 |
|
509 * The location of different Python specific files has changed. This change has |
|
510 implications e.g. for the interpreter search path. |
|
511 |
|
512 |
|
513 9. Glossary |
|
514 ----------- |
|
515 |
|
516 platsec |
|
517 Platform Security |
|
518 |
|
519 EKA2 |
|
520 EPOC32 Kernel Architecture 2 |
|
521 |
|
522 capability |
|
523 A capability, when hold by a running process, gives permission to access |
|
524 system resources |
|
525 |
|
526 data caging |
|
527 The concept of dividing a file system hierarchy to generally accessible and |
|
528 restricted locations |
|
529 |
|
530 RVCT |
|
531 RealView Compiler Tools (ARM ltd.) |
|
532 |
|
533 pyd |
|
534 Binary Python extension (written in C/C++) |
|
535 |
|
536 PyS60 |
|
537 Python for S60. In this document, this term might refer also to the |
|
538 interpreter DLL and the native extensions (i.e. pyds) |
|
539 |
|
540 SISX |
|
541 The new format used for SIS files by SWInstall (Software Installer). Notice |
|
542 that the file ending is still .sis |
|
543 |
|
544 Script shell |
|
545 In this document, an S60 application visible in the device menu which enables |
|
546 a user to run individual Python scripts. Part of the Python for S60 |
|
547 distribution |
|
548 |
|
549 SWInstall |
|
550 A program running in the target device handling SISX installer packages |
|
551 |
|
552 TCB |
|
553 From the 3rdEd SDK: "TCB stands for "Trusted Computing Base." The trusted |
|
554 computing base consists of a number of architectural elements that cannot be |
|
555 subverted and that guarantee the integrity of the device. This trusted core |
|
556 runs with "Tcb" system capability. The components with Tcb capability have |
|
557 full access to file systems including reading/writing to \sys\bin. TCB is not |
|
558 granted to third-party applications." |
|
559 |
|
560 ensymble |
|
561 The tool to package Python scripts to SIS packages which can be installed by |
|
562 SWInstall to a Symbian OS device. The created SIS packages require that there |
|
563 is PyS60 already installed. Part of the Python for S60 distribution |
|
564 |
|
565 appmgr |
|
566 Writes Python scripts from device inbox to the location where these can be |
|
567 interpreted by the script shell. Part of Python for S60 distribution |
|
568 |
|
569 devcert |
|
570 Developer certificate. More APIs can be accessed when signing SISX packages |
|
571 with this certificate, for more information about this please search your SDK |
|
572 with the terms 'developer certificate' and see |
|
573 https://www.symbiansigned.com/app/page/devcertgeneral |
|
574 |
|
575 |
|
576 Copyright (c) 2006-2009 Nokia Corporation. Nokia and Nokia Connecting People |
|
577 are registered trademarks of Nokia Corporation. |