Android versus Symbian OS
Here are some superficial thoughts on Android (which I don’t know much about) versus Symbian OS (which I do).
| Android | Symbian OS | |
|---|---|---|
| Business model | ||
| Revenue stream for creator | Advertising, fairy dust? | Fixed license fee per phone (with a few quirks, all publicly known |
| Source code availability | Available to nobody yet. Available to all, in theory, one day. | Available only to Symbian OS phone manufacturers, plus partners who pay a lot. |
| Source code modifiability | Freely modifiable (although I seem to remember constraints for Open Handset Alliance members, presumably related to keeping the APIs sufficiently similar between devices to keep a common platform for developers | Modifiable, but with similar restrictions aimed at keeping a common platform. |
| End-user openness | End devices will probably accept Java-language applications. No evidence that they will accept native applications. | All end devices accept Java-language applications, and virtually all also accept native applications. |
| Current market position in smartphone market | Zero, but has Google behind it | Overwhelmingly dominant in EMEA and Japan, reasonable success elsewhere except America. (American technology writers just don’t realise Symbian exists, and that it’s America which is unusual…) |
| Technical Basis | ||
| API language | Java | C++ (J2ME Java also available for a subset of APIs) |
| Standards-compliance | Highly POSIXy for native handset software. Proprietary for high-level Java APIs. | Proprietary. POSIX layer available, but it limits interaction with the rest of the OS so much that it’s only really used for porting software. |
| Kernel | Linux with minor changes | Proprietary |
| Basic user library | BSD-derived libc | Proprietary |
| User interface | Unknown; current is a ‘placeholder’ | None; UIs developed by Nokia (S60), DoCoMo (MOAP) and UIQ/Motorola/Sony Ericsson (UIQ). Other UIs have existed in the past. |
| Typical filesystem | YAFFS2 | Proprietary. |
| Toolchain for native software | Standard GCC, possibly requiring prelinking and other oddities | Proprietary, built on top of GCC |
| Binary format | Standard ELF | Proprietary |
| Toolchain for typical third party software | Ant-based, dex compiler, etc. | Same toolchain for entire device |
| Debugging/profiling/investigation tools | Standard UNIX tools | Not a lot |
| Inter-process communication | Unclear. D-bus for some layers. OpenBinder for others. Possibly something different again for messages flowing between the Dalvik-side processes. | Proprietary; based on client-server. |
| Features | ||
| Pre-emptive multithreading | Yes | Yes |
| Memory protection between processes | Yes | Yes |
| Pre-emptible kernel | Yes | Yes |
| Demand paging | Yes | Yes |
| Virtual memory (page outs) | Probably not according to Dianne Hackborn; they are anticipating devices with 64MB RAM and 128MB flash | Not yet, but it may not be long; Symbian OS has been in use on phones with hard disks for some time |
| Shared libraries | Yes | Yes |
| Copy-on-write | Yes | N/A (’fork’ is not used) |
| Reference counting of kernel objects and proper cleanup if a process dies | Yes | Yes |
| Approaches to problems | ||
| Flash space taken by many copies of symbol names for dynamic linkage | Unknown; maybe just don’t use too many native programs | Link by ordinal not by name |
| Memory allocation | Allocate a big hunk of virtual address space for process. On write, try to free up enough physical RAM pages to give it the memory it needs. | Allocate minimum virtual and physical address space; heap algorithms in user library know how to request more RAM from kernel. |
| Memory full behaviour | Kernel will kill other processes if necessary to relinquish physical RAM. If no physical RAM is available, program is killed. | On some Symbian systems, user-side heap library may request other apps to exit. If no memory really is available, malloc equivalent throws an exception and application should be able to handle it. |
| Memory management within user code | Check for NULLs from malloc if you’re lucky, but you’ve probably got spare virtual address space anyway so it’s unlikely you’ll be told of a memory allocation failure | Incredibly anal rules about memory management |
| Security | Each process runs as its own user. Unclear how this prevents access to certain APIs that could do destructive things. | Processes have capabilities and can only access APIs appropriate to their capabilities. Applications must be certified and are then signed such that they cannot access APIs beyond their capabilities. |
| Overhead of loading binaries | Store application code as dex files which can just be mmap’ped in | Store application code as native code which can just be mmap’ed in (or equivalent) |
| Overhead of interpreter startup | Application interpreter starts once (Zygote) and all other processes fork from that | No interpreter – native applications |
| Componentisation | Software uses ‘intents’ to say what it wishes to do. Other software can fulfil the intent. | Applications typically rigidly defined (but can load plug-ins). |
| XML and text files are inefficient | Compile XML down to a binary representation | Compile resource files down to a binary representation |
| Overhead of multiple threads | Remove need for multiple threads, but allow developers to use them if they wish. Provide event loop which runs in main thread and can respond to most events. Allow events to be posted onto event loop using handler object. | Remove need for multiple threads, but allow developers to use them if they wish. Provide object-oriented event loop in main thread (’active scheduler’), using ‘active objects’ to respond to each type of incoming event. |
| Overhead of making APIs and libraries thread-safe | Insist they are used only from main thread | Run in a different process; use IPC for all UI requests. And indeed pretty much anything else. |
Some of that’s probably rubbish, and may be based on misinterpreting bits of the interesting podcast. I’m happy to accept corrections, but then again, only six people read this blog anyway so this post was mostly for my own interest :-)
In other news, Motz has figured out the correct linker settings for the Android loader!
October 15th, 2008 at 1:03 pm
Hello, nice article!
But, can you update it?
Because major changes has happened since you first wrote it, such as the Symbian Foundation
October 15th, 2008 at 1:24 pm
Hi, I might do one day: I haven’t touched Android since the winter!
It will be interesting to compare them again once the code actually is released for each platform.
Ade
March 25th, 2009 at 6:26 pm
“All SYMBIAN based end devices accept Java language Applications”
(i) Does this mean that the applications made for Android would run in S60 , without any modifications??
(ii) If not then what exactly we mean when we say the above statement?? Is there any web link to which I can refer to??
(iii) What are the coding guidelines that we need to follow so that an Android application can be ported on S60 with minimum changes??
Thank you all in advance.
Best Regards,
Zhubham
March 25th, 2009 at 6:31 pm
No, although both S60 and Android can run Java code, there are other major differences. The UI APIs are entirely different, for a start. You’d use J2ME APIs for S60 but Android APIs for Android. (And Android, in itself, can’t run standard JAR applications – the Java code needs to be run through a tool to convert it to .dex files before it will run on an Android device).
March 27th, 2009 at 1:27 pm
Hi,
I am looking forward to coming with some coding guidelines so that an android application can be ported on S60 with minimum modifications. Like excluding the UI (which definitely has to be rebuilt for S60), what should a developer keep in mind so that his/her code is platform (android/S60) independant.
Can you help me with this??
Thanks in advance.
Best Regards,
Zhubham