Profile data on 3rd edition

On 1st edition and early 2nd edition FPs, there was no officially sanctioned way to get profile data, although CProfileAPI was easy enough to generate from the LIB files. Later we got CSettingInfo. In 3rd edition profile data is kept in the central repository, and you can access some of it with the keys in profileenginesdkcrkeys.h.

But the documented keys only provide access to a subset of the profile data, for example not to vibrating alert status or the ringing tone. And it’s read-only.

Luckily, CRepository allows you to enumerate keys. You just open the repository with the CRepository::NewL(KCRUidProfileEngine), and enumerate them with:

CRepository* iRep;
iRep=CRepository::NewL(KCRUidProfileEngine);
RArray<TUint32> found;
iRep->FindL(0, 0, found);
for (int i=0; i<found.Count(); i++) {
    key=found[i];
    /* do something with the key*/
}

Dumping the keys from the profile repository gives something like:
Continue reading

Posted in Symbian | 13 Comments

MTMs and Contact fields, Question

I thought I’d replace our ages old hand-crafted Create Message menu in Jaiku Contacts with a standard CSendUi/CSendAppUi menu, so that we can pick up arbitrary MTMs (and ECOM plugins now with 9.1). The menu should work so that you select a Contact, then you click the Create Message menu item, and get a list of possible message types to send to that contact (like SMS, MMS, e-mail, what have you).

Turns out it’s not that simple.

On any device, there is an arbitrary set of MTMs. They can be enumerated, and files can be sent through them. Some of them can send messages to specific addresses. An address is a string.

On any contact, you have an arbitrary set of contact fields. They can be enumerated, and you can ask what kind of a field it is (e.g., the Home Phone Number). You can let the user pick a suitable field for, say SMS with CPbkSmsAddressSelect.

Now answer me this: if you have an arbitrary MTM with UID XXX, how do you:

  • Know whether it can send a message to a specific address (maybe CSendUi knows if you give it an address in CMessageData)?
  • What address you should give it (SMS, MMS or e-mail)?

CSendUi (or something) should have a method like ShowAListOfMtmsThatCanSendToThisContact() and CreateANewMessageForThisMTMUidandThisContact().

It doesn’t seem to have such a thing.

So maybe we can just filter out IR and BT from the list of MTMs and get only ‘addressable’ MTMs. That still doesn’t tell us which address we should use…

Posted in Symbian | 9 Comments

More 3rd edition Answers

Drawing on top of the Phone/Active Idle app works without TrustedUi. We’ll have to check the different 3rd edition phones to make sure we are not drawing on top of anything, but it seems that this should still work. Have to also check whether it may require TrustedUi on some devices (testing only on an N80 so far).

There is no better inactivity detection on 3rd ed. (this from Nokia support). Capturing keys works if you have SwEvent. We’ll at least try to do that, let’s see how it goes in testing.

We are no longer over-riding UIDs. Changing active idle shortcuts requires a non-public API (which might be available, if we manage to convince the powers that be). We are directing the user to change the shortcuts on their own for now.

CPbkSingleEntryFetchDlg was a false alarm, it still exists and works. It was actually only ever missing from the 1st edition SDK.

I haven’t yet found how to get the phone’s own Bluetooth address. I assume it’s something obvious that I’ve just missed.

Stay tuned for 3rd edition versions of Jaiku and Merkitys-Meaning within the next two months.

Posted in Symbian | 2 Comments

Overriding built-in components

So we have struggled with FP3, trying to override built-in applications (FP3 changed the game: now all components are searched for first in ROM, and only then on disk).

Today I realized that maybe it _shouldn’t_ be that easy to override the built-in components :-).

We have a combined autostarter and watchdog, which is called ‘starter.exe’. It’s previously been installed to \system\apps\starter (since that’s where it lives on WINS, where it’s and app). On FP3, however, it pops up in MyOwn, which we don’t want.

So I moved it to \system\programs\, reinstalled at everything worked fine. I then shut down the phone and tried to boot. It just kept looping, showing the Nokia logo. I’m testing on a FP2 phone.

Some of you might realize where this is heading…

There is also a program called z:\system\programs\starter.exe, which is responsible for a lot of the Symbian side boot process. Now in the boot the phone ran _my_ starter.exe, instead of the one in ROM. My starter.exe, to put it mildly, is _not_ capable of booting the phone.

So I renamed starter.exe to cl_starter.exe (bonus points for knowing what ‘cl’ refers to), and everything works fine.

Posted in Symbian | 4 Comments

3rd Edition As, part II

Photos from the camera application can be ‘caught’ the same way as before: they just appear in the filesystem (under \data\image instead of \Nokia\Images, but that’s a minor point). The new camera app seems to automatically put them in subdirectories based on the month (e.g., 200609), which is also the case on newer FP3 firmwares. The code that watches the directory has to switch to such a directory if it appears or exists. Doesn’t need any caps.

It seems that we can still draw on top of the phone application, at least with TrustedUI cap. That said, the normal idle screen has a different UID now and the topmost windowgroup belongs to the phone app only when actually making calls. I just have to find out the new UID. Whether we will be allowed to actually get the code signed is another matter, of course.

A normal program is not allowed to enumerate dlls under \sys\bin. I switched the dynamic dll loading to use a naming convention instead: the blackboard datatype dll with UID 0xdeadbeef now has to be named bbfdeadbeef.dll. Easy peasy, with no functionality sacrificed. (The ‘correct’ way would of course be to use the ECOM framework, but I don’t actually need it for this, since the UIDs are known beforehand in either code or in serialized object representations).

And BTW, and components that need capabilities do need to have UIDs from the V9 protected range. We had to switch all our old ‘legacy’ UIDs to the new ones, which ended up being much more hassle than I would have thought: although all our UIDs reside in one central header (which is not great for compilation times when it needs changing, I admit) and so only had to be changed once, to actually get the applications compiled right I had to delete the %EPOCROOT%\epoc32\BUILD directory – the appname.UID.cpp files were not being recreated even with abld reallyclean – abld build.

And another ‘BTW’ from Nokia/Symbian: 9.1 has stack unwinding! Which breaks auto_ptr … had to change auto_ptr so that it doesn’t use the cleanup stack anymore.

Posted in Symbian | Comments Off

3rd edition A(nnoyance|nswer)s

Small things I’ve had to fix in the past few days:

The value of EAknEnableSkin had changed. We had previously used a hardcoded value in the App Ui’s BaseConstructL call: BaseConstructL(0×1008), so we could compile on 2.0/2.1 and run correctly on higher FPs. When we specified the wrong flag, we of course didn’t get any skins but more seriously clicking on setting items crashed the application.

We have to move from etelmm/etelbgsm to the 3rd party telephony interface CTelephony. Basically all CTelephony methods are asynchronous (taking a TRequestStatus parameter), including the ones for requesting the IMEI and IMSI. We have needed the IMEI in a couple of places before, and accessed it with PlpVariant::GetMachineIdL, which is a synchronous call. So for 3rd edition, I wrote an alternative that uses CTelephony::GetPhoneId() and User::WaitForRequest’ing on the TRequestStatus. This of course hung the app. CTelephony is obviously written as a helper class on top of other asynchronous services and uses an active object internally to call them, and thus can not be waited on. Any code that calls CTelephony has to be asynchronous.

Calling CWsBitmap::Load for loading bitmaps from a MBM file is quite slow. Each call opens the file separately, reads the header structure and then the actual data. To speed this up I wrote my own function that handles the MBM header, keeps the file open and uses CWsBitmap::InternalizeL to actually read the data. This speeds up loading significantly. RFile::Open(fs, filename, EFileRead|EFileShareAny) returned an error on 3rd ed when used on the MBM file under \resource. It seems you are not allowed to specify EFileShareAny now, prob. due to platsec. Falling back on EFileRead seems to do the trick.

CSendAppUi is no more, and the less functional CSendUi seems to require a very extensive set of capabilities, including Read/WriteDeviceData (although this is under dispute). I’ll probably have to reimplement the UI functionality of CSendAppUi on top of the new RSendAs class.

More things will follow…

Posted in Symbian | 2 Comments

3rd edition Qs

Here’s some of the things I have to figure out in the next couple of months, for porting ContextPhone/Merkitys/Jaiku to the 3rd edition.

  • Can you get ReadDeviceData (or any other restricted capability) through the freeware signing?
  • How do we access the images captured by the phone camera now?
  • Is there an officially sanctioned way to use cell-id in a part of our system that does not have ReadDeviceData capability? Technically it’s of course easy: just write the thing to the blackboard and don’t check capabilities in the blackboard server. Symbian’s Murray Read seems to indicate that it’s allowed to split work to a capability-enabled server application, but at least naively that would break the sandbox. Having parts of the system not require testing would allow for much quicker turnaround in development…
  • Am I allowed to Kill() threads/processes anymore? If not, how do you implement a watchdog. Again, naively, you would assume that you could kill processes with the same vendor-id without any restrictions?
  • How do we dynamically load DLLs based on UIDs now? We have our own ‘instantiate object by name’ framework, which is based on polymorphic dlls.
  • Can I draw indicators in the idle screen? There seems to be a plugin API for the idle screen, but it might not be available to non-partners. Indicators for presence on/off are quite important for privacy management.
  • Capturing keypresses needs the SwEvent capability. We’ve been doing that as it’s been the only reliable way to know when the phone is idle or active (the system inactivity timer gets reset by charging and other random events on 1st and 2nd edition). Maybe there’s a reliable inactivity indicator provided by the the system now?
  • Can we programmatically modify the active-idle settings? Previously we’ve overridden the built-in phonebook, but I guess that’s not possible anymore. It’s not strictly necessary either, as long as we can make our phonebook as easily accessible as the built-in one – meaning we want to replace the built-in phonebook button in the active idle screen with our one.
  • Can we intercept (as in listening for them and automatically deleting as necessary) incoming SMS (for operator location services)? What capabilities are needed? Might there finally be a way to suppress the message-received alert?
  • Is there are an official replacement for CPbkSingleEntryFetchDlg now? (I assume it’s not available any more.)
  • For research use: can we still programmatically record phonecalls? What capabilities does that require?

I’ll be posting answers to these as I figure them out. I really hope that I can test most things in the emulator, but the past has taught me not to expect too much… Stay tuned.

BTW, at least some things are easier now. Much of the system state (profile, bluetooth settings, charger, battery etc.) is now provided by the central repository, has been documented and is officially supported. Yay for that.

Posted in Symbian | 11 Comments

Stack size for RUNINSTALL, RUNREMOVE programs

Context_log runs as a system application (calling iEikonEnv->SetSystem(ETrue)). This means that the installer can’t shut it down (which could be considered more a bug than a feature, but nevermind). Instead, we run a small program at installation and removal time that shuts it (as well as the watchdog process) down.

I wrote that shutter program and was happily using it for a couple of weeks on an N70 (2nd edition FP3) until the time came to test it on earlier phones, firstly on a 6600 (2nd edition, no FP). Here the shutter crashed with a KERN-EXEC 3.

After a bit of head-scratching – since my debug messages via RFileLogger never appeared anywhere – I realized the shutter was running out of stack. Which was weird, since I was specifying EPOCSTACKSIZE 16384 in my MMP file, and if I launched the same exe from FExplorer, it worked fine.

It looks like the earlier Nokia installers don’t respect the EPOCSTACKSIZE (they must be doing their own process launching code, since the normal RProcess::Create does respect that). So I had to pare down my stack usage.

I removed the debug code, moved objects to the heap, but still it was crashing with KERN-EXEC 3. After much debugging, I realized I’d left a TFullName on the stack, taking up some 500-odd bytes out of the 8k. In the end I had almost nothing on the stack – it does seem that either the installer launching code or some other platform code takes up most of that 8k…

In the process I also noticed that the installer itself leaks memory: it doesn’t close the handle it has on the processes it launches… and since the installer is actually most often embedded in the Messaging app, these handles (and the corresponding process objects) will stay around until you close the Messaging app – probably until the phone is rebooted.

Posted in Symbian | 4 Comments

Errorhandling revisited

I’ve now gathered my writings on errorhandling to errorhandling.org. Read and comment.

Posted in CS, Symbian | Comments Off

Jaiku launched!

The first beta of Jaiku is live! Run, don’t walk, to http://www.jaiku.com/ to get a real version of ContextContacts to run on your phone.

Posted in Symbian | Comments Off