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.

This entry was posted in Symbian. Bookmark the permalink.

11 Responses to 3rd edition Qs

  1. carlo says:

    Look forward to see your findings.

  2. holgi says:

    you can intercept&delete incoming SMS with the standard self-signing capabilities. only sending “the classic way” seems to need ReadDeviceData capability (but RSendAs maybe is enough which doesn’t reqiure this!).

    The self-signed certificate “Free” capabilities are only:
    NetworkServices ReadUserData WriteUserData LocalServices UserEnvironment

  3. Mika says:

    Yes I know which capabilities you can get with self-signed. I meant the Symbian Signed freeware signing programs: it’s not documented anywhere if there are limitations on what capabilities you can request for your freeware app.

  4. mnpg says:

    Hi Mika,
    about 3rd edition Qs, do you also planned a port of gnubox?

  5. Mika says:

    I haven’t, no. There has been much more work on gnubox at http://gnubox.dnsalias.org/gnubox/ . I would assume modifications of commdb need extended capabilities, which means testing and other hassles.

    Many 3rd-ed phones have WLAN, which makes IP-over-bluetooth less interesting.

  6. cyke64 says:

    Q> Can you get ReadDeviceData (or any other restricted capability) through the freeware signing?
    A> Yes ! Symbian allows you now to get ReadDeviceData,WriteDeviceData and TrustUI … http://blogs.forum.nokia.com/view_entry.html?id=295

    Q>Is there an officially sanctioned way to use cell-id in a part of our system that does not have ReadDeviceData capability?
    A> Now with dev cert free you can access to cell info.

  7. Mika says:

    Hmm. The blog post you link to talks about DevCerts, not freeware signing. Do you have a link to somewhere they state these are available through freeware signing as well?

  8. patel says:

    How we can get the area name ( location name ) on 3rd edition phone? Is it possible?

  9. Mika says:

    If you are talking about cell broadcast, I have never looked at it. I think the underlying telephony APIs are still based on RMobilePhone and friends. With a Binary Access Kit you can try them out, or maybe even the 3.0 beta SDK. CBS is only supported on certain networks (Germany seems to be leading in that).

    If you need a more generic solution, you need a database mapping cell ids to names. You can talk to the relevant operators or build your own (which is what we are doing).

  10. patel says:

    thanks for reply, but in my country i have made an application which fetches the area name out of the CBM, for that i have used the RMobileBroadcastMessaging, but for symbian 3rd edition phones, they dont support this 3rd party api? and i dont find any method in CTelephony for getting the cell broadcast.

  11. patel says:

    There is one more question and i find it very confusing, how can we access some functionality even if the sdk doesnt provide any class or methods for it by using 3rd party, it means that the device should have support for that particular function requested?