It can be quite useful to have a list of UIDs for important Symbian OS application. Here is a start:
|10003a37||Contacts database (contacts.cdb)|
|10003a5b||Calendar database (calendar)|
|10003a3f||AppArc server (responsible for showing icons on the shell; application registration resource files; appname_reg.rsc)|
|10202be9||Central repository server (initialisation files for apps)|
During the development of Symbian OS application platform security can be problematic. Debugging platform security issues in Symbian OS can be time consuming. Therefore keep in mind the basic rules for platform security:
- Rule 1: If a process gets created it will run with the capability set as specified in the .MMP file of the executable.
- Rule 2: If a process loads a DLL this DLL needs to be trusted with the same set or a larger set of capabilities.
For a DLL capabilities are a level of trust and this level of trust (the set of capabilities) is specified in the MMP file. For a EXE capabilities indicate what a process can do (which APIs it is entitled to use).
Mostly an executable links against static interface DLLs (using the LIBRARY keyword in the MMP file). If the executable uses static interface DLLs the code for these DLLs is loaded into the process directly at startup. The file loader loads the code for the EXE and associated DLLs. Simultaneously it checks whether the EXE and set of DLLs complies with the platform security rules. If only one of the DLLs in the LIBRARYs list violates against rule 2, the process will not start.
A common symptom for this is, if you click on an application icon in the shell of the phone, the application does not start. The icon only shortly blinks and then nothing happens anymore. As a developer, if this symptom shows, you should immediately think “most likely this is a platform security problem”.
Turn to the Series 60 emulator – turn platform security off in the menu – run the application (A) – then try to run the application with platform security enabled in the emulator (B). If the application runs in situation (A), but not in situation (B) it is confirmed that there is a platform security problem.
Now look into the file epocwind.out to find out which capabilities are missing. The file epocwind.out can be found in c:\Documents and Settings\<your username>\Local Settings\Temp (make sure Windows Explorer shows hidden directory – select on “Show hidden files and folders” under Tools | Options | tab View). Search for the text “*PlatSec*”.
147.680 *PlatSec* ERROR – Capability check failed – Can’t load sample_0x20030359.exe because it links to slogtool.dll which has the following capabilities missing: ReadDeviceData WriteDeviceData NetworkServices ReadUserData WriteUserData Location.
This gives you the information to add the capabilities “ReadDeviceData WriteDeviceData NetworkServices ReadUserData WriteUserData Location” into the MMP file of slogtool.dll to fix the platform security problem. Rule 2 has been violated here. The sample.exe links against slogtool.dll. Sample.exe has capabilities “ReadDeviceData WriteDeviceData NetworkServices ReadUserData WriteUserData Location”, but slogtool.dll has not. The slogtool.dll has less capabilities as the loading process (EXE). Therefore the process can not be started.
Correct the situation in the MMP file of slogtool.dll and compile again for the device (do not forget to re-run bldmake bldfiles) and try to run the application again on the device.
If you are unsure about the capability set for a EXE or DLL then ELFTRAN is a handy tool which comes pre-installed with your Series 60 SDK to query the capability set of a DLL or EXE. See below for examples of the commands. Note that ELFTRAN will only work for DLL/EXEs which have been compiled for the device (armv5 or gcce) and can list the capabilities for DLL/EXEs which have been compiled for the emulator (winscw).
Query the caps of an executable:
elftran -dump s <filename of executable or dll>
Query the dependencies of an executable:
elftran -dump i <arm executable>
Show the exports of a DLL:
elftran -dump e <arm executable>
petran should be used only for Symbian OS versions before 9.1
If you need more information or expertise on platform security for Symbian OS consult the training page of Inmote or drop me an email at email@example.com.
Display technology will have a big impact on the mobile industry in the next years. Slowly improvements are coming to the market.
Samsung introduced AMOLED (=Active Matrix Organic Light Emitting Diode) screens into mobile phones such that the end user can also read things on the display in bright sunlight. Touchscreens have become extremely popular with the introduction of iPhone, though some users did give it a try and are returning to keypad only mobile phones as the touchscreens tend to be too ‘touchy’ (things can get started easily while carrying your phone in your pocket).
Improvements in display technologies are also important for other devices beyond mobile phones like e-readers, navigation equipment, TVs, etc. Improvements in display technology has a direct impact on the user experience. Displays allow a larger viewing angle, will be thinner, consume less power, have brighter colors and deeper black.
For touchscreens there is two types of main technologies:
A resistive touchscreen responds to pressure from a stylus or your finger. Nowadays more phones are equipped with capacitive touchscreens. A capacitive touchscreen uses the fact your body is conductive and therefore a capacitive touchscreen can only be operated using your finger. Personally I do not like this idea as I can press buttons and small items on the screen more easily using a stylus (normally I would just use a pen for this although manufacturers warn you this can harm your resistive touchscreen).
Currently Samsung is the main manufacturer of AMOLED displays for mobile phones. There is difficulties to meet the demand of mobile phone manufacturers for AMOLED displays. Some manufacturers like HTC have turned to alternative sources and competing technologies for displays like Super technology from Sony (HTC Desire). Apple developed their own Retina display technology for the iPhone 4.
Interestingly Nokia took the lead in touchscreen enabled mobile phones as reported by Canalys earlier in february this year. Canalysis estimates touchscreen smartphones took 55% of the mobile smartphone market in Q4 2009. By volumes Nokia has been the leading vendor for touchscreen phones (mostly N97 and 5800) followed by Apple, HTC and Samsung. More details can be found here.
Here is a list of Nokia codes which may be handy when testing and developing software for Nokia phones.
|Reset the phone (secure code: 12345 for Nokia; 0000 for Sony Ericsson Satio and Vivaz)
(all installed software apps will be removed!)
|*#06#||Show the serial number (IMEI)|
|*#0000#||Show the software version number of the installed firmware|
|*#92702689#||Life timer (Nokia 6220 Classic)|
It is a good practise to reset the phone using *#7370# to test a software application before final release to the customer to avoid any interference of previous installed versions or user actions that may affect the behaviour of your application during acceptance testing.
The Nokia codes below are not working on my Nokia 6220 Classic, but may have some use on other Nokia models.
|*#67705646#||Clear LCD display|
|*#7370925538#||Reset the wallet. All wallet contents will be deleted.|