Porting Symbian OS to Android-based devices

[piko1bg]

this is the best idea by the way i would use Symbian today hell i still use my Nokia E5 (the one that can run gazilions of apps at the same time) its 2017 and Android lacks many of the symbian features that were great (like 2 weeks standby ) better ram management and etc

---------- Post added at 09:47 PM ---------- Previous post was at 09:24 PM ----------

now only if they give us rollback tool like on the P9 lite so we can join the official update schedule

 

[trax7]

this is the best idea by the way i would use Symbian today hell i still use my Nokia E5 (the one that can run gazilions of apps at the same time) its 2017 and Android lacks many of the symbian features that were great (like 2 weeks standby ) better ram management and etc

---------- Post added at 09:47 PM ---------- Previous post was at 09:24 PM ----------

now only if they give us rollback tool like on the P9 lite so we can join the official update schedule

@AceT2213
I strongly disagree with the "better RAM management" thing above. Symbian is very very old... It uses a very old pseudo microkernel version, was designed to run on limited resources and from my experience was laggy as hell anyway (I had a Nokia E7, was supposed to be one of the last and best Symbian phones). It therefore misses out on all the improvements made from years time. Compatibility will be even worse. You will have to deal with tons of limitations and will need to change the fundamental ways in which the OS works...

Now... Granted you find all the things you need to build the OS, you would only be able to have any progress on 6-7 year old Nokia hardware. Why? Because that's the only thing you have drivers for. For anything else you're gonna need to write them yourself. Granted you want to use it on modern hardware, of course. What's the point if we have to use 7 year old hardware to get the OS? None. :laugh:

So, we need to rewrite the kernel, drivers, system files, everything. Piece of cake, right? Hold on bro, the ecosystem itself is dead. That means no apps, updates, customization etc. So you will need to create all the most essential apps to make the OS useable. However you can't do that because of licencing, for example third-party Facebook apps can only be wrappers around the mobile version of the site. Also, signing your own apps restricts you a lot, but let's say you bypassed that when you rewrote the system.

And Symbian didn't have a lot of apps to begin with, it's not that developer friendly. This is why Android and IOS had an easy time replacing it. Apps were made to be tightly integrated with the system which made it hard for devs. To quote: "All native Symbian C++ applications are built up from three framework classes defined by the application architecture: an application class, a document class and an application user interface class. These classes create the fundamental application behaviour. The remaining needed functions, the application view, data model and data interface, are created independently and interact solely through their APIs with the other classes." And I haven't even begin about security...

Honestly I think you might have more luck with Maemo or MeeGo since they are at least Linux based...
At least Qt is still around but the new versions are definitely gonna cause a lot of compatibility issues with Symbian.
Sorry if I bored you with my long post I will follow the thread anyway as it sparked some interest in me...

 

[AceT2213]

@trax7 thank you for your long and detailed response. You're obviously informed on the topic and I very much appreciate your input.

There are certain facts we must admit if we are to remain motivated about this project (which I am):

First, there will obviously be no updates, no support, and probably very little security.
Second, there will be no wide variety of apps and in most cases, like Facebook, it would be nothing but a wrapper of the mobile site at best.
Third, it will not be the fastest system or the most versatile, and absolutely not the most popular.

Now, with all of that out of the way, I have to say that I've never used the E series. Never liked it, honestly. I've used series S60 that started with the 3650, which wasn't a very popular device. Soon after, the 6600, with a slightly updated version of the same system (to support themes) started the Nokia "smartphone" era, as I call it. This era continued, with slight tweaks, through the first official "smartphone", the 6630 (no front facing camera until the 6680 but with 3G) and eventually the N Series. After that, I believe Nokia screwed up their software, when they got into the touchscreen market. Those touchscreen Nokia systems felt like the dumbed down simplified S40, not at all on the same level of the phones before it. Yes, S60 didn't have the most or the best apps, but it was ridiculously simple to share those apps. Just copy the files to system/apps/appname and the app magically worked. This method was even possible if you received the app files via Bluetooth. Such a simple yet truly memorable experience. And personally, getjar.com never let me down in terms of app selection (at least until I wanted a real Facebook app).

So, with all of that in mind, I ask again. Is it possible to accomplish this goal? Imperfections aside, and maintaining that it's not for everyone, not even in this community, but rather as an option for those willing to make those small sacrifices in return for a drastic improvement in battery life.

 

[AceT2213]

The main issue you highlighted would have to be drivers. How would we go about making Qualcomm drives for the outdated system? I very much doubt that either of those companies would help us in this endeavor, so how can we do it ourselves?

 

[trax7]

The main issue you highlighted would have to be drivers. How would we go about making Qualcomm drives for the outdated system? I very much doubt that either of those companies would help us in this endeavor, so how can we do it ourselves?

Yes, no help is expected whatsoever. It will be near impossible to do (especially alone). Even if the code itself is already there it's sometimes much easier and cleaner to write from scratch instead of trying to work around legacy software.

In the end, I doubt an increase in battery will be seen anyway due to the fact that the system will be terribly inefficient. Also, no matter the OS, heavy tasks will consume lots of energy, things like Camera and such.

Nevertheless, if you want to consider it as a learning experience, you are welcome to try. I could try and make some small contri from time to time if I feel like it

I remembered the thread began as a sort of a complaint for the 'inefficiency' of Android. The Java VM makes it run considerably slower, that is true. The trade-off however for compatibility is huge, we have an OS which runs on lots of CPUs on more than one architecture (x86, ARM, MIPS) and is able to use the same apps on all of them without big hits in performance or the need to recompile for every architecture. This is very big and the reason why Java is used.

There was a project to translate the whole Android to C (XobotOS, I think there was smth else too tho...), thus benefiting from the more mature language and eliminating the eternal bottleneck - the VM. You can search for it if you're interested - I physically think way more can be had from that than rewriting Symbian...

Edit: Forgot about the drivers... You can look into CAF sources, however I doubt that you can make anything since bootloaders are very hard to break and they are strictly proprietary, almost no documentation exists for them (how r u gonna call the kernel when the bootloader won't recognise it, know what I mean?) You will need to hijack the boot process using an working kernel and bridge the two or make the first /compatible one/ boot the second Symbian based one. Bridging Android/Linux and Symbian will need so much hackery... Once boot is complete tho u should be with only second kernel... Kexec-Hardboot? No, kernel still needs to be compatible with bootloader...

You need to think about partition schemes, how would you make them compatible. Port Symbian to Android partition scheme or? This will make the bootloader go nuts! Every action in the boot chain needs to be verified or the bootloader won't execute the kernel and without the kernel u r as naked as a potato :silly: Also, Symbian has a two kernel implementation so that needs to be unified or smth, u cant walk around calling kernels all day lol.

In the end, you can probably see where I'm going with this...

 

[AceT2213]

I was thinking more that the simpler ecosystem of Symbian would be easier on battery, precisely due to all of the abovementioned sacrifices that some people might be okay with. The problem with all current-gen OS's, I think, is that they're all high-performing, making them heavy on battery. But you're right. Unless the port is perfect, there wouldn't be a noticeable increase in battery life. And the newer hardware itself probably uses more power than that of the now-10-year-old Nokia devices.

You've successfully killed my dream lol I'll leave this thread open though in case it inspires someone one day.

 

[trax7]

I was thinking more that the simpler ecosystem of Symbian would be easier on battery, precisely due to all of the abovementioned sacrifices that some people might be okay with. The problem with all current-gen OS's, I think, is that they're all high-performing, making them heavy on battery. But you're right. Unless the port is perfect, there wouldn't be a noticeable increase in battery life. And the newer hardware itself probably uses more power than that of the now-10-year-old Nokia devices.

You've successfully killed my dream lol I'll leave this thread open though in case it inspires someone one day.

No! Don't give up yet :crying:! I edited my post, go see it I urge you to look at Android to C. It's pretty close to what you want to achieve but is more streamlined, less stuff needs wild hax and the results if successful are amazing! Try it!

 

[culiacanazo]

You've killed the man's dream! After all this!

 

[discourse]

I just charged up my old Nokia N8 and listened to music I still have on there from years back and I've been poking around to see which apps still work and I was able to get the Podcatcher app to subscribe to some of the podcasts I listen to on my Android and iOS devices. On new hardware this OS would be awesome. Maybe a libhybris type solution would work.

 

[Dush4711]

Off topic:

Symbian was god at multitasking.

(Nokia C6-01) (256 MB RAM)

You can run at least 20(minimum)apps and can switch between them easily and no app will restarts,it resumes where you left it.

I remember I minimized dungeon hunter and opened it after 4-5 days and when I opened,
It resumes at same state and without loading or reopening.

In its time (2011) no other phones OSs was able to that.

(Sorry if English is bad)

 

[trax7]

Off topic:

Symbian was god at multitasking.

(Nokia C6-01) (256 MB RAM)

You can run at least 20(minimum)apps and can switch between them easily and no app will restarts,it resumes where you left it.

I remember I minimized dungeon hunter and opened it after 4-5 days and when I opened,
It resumes at same state and without loading or reopening.

In its time (2011) no other phones OSs was able to that.

(Sorry if English is bad)

It could do that because apps and everything in general was smaller in size and less resource intensive. The system as a whole was made to work with scarce resources, that was one of the pillars it revolved around.
Also, some apps will have dumped their state in swap space, making the transition slow but doable.

If you remember, Symbian was very slow with tasks such as web browsing. This is because elements on the page actually had to stay in RAM to ensure any kind of tolerable user experience. And moving them to swap because of low RAM makes everything run extremely slowly, while in the case of switching apps this could more easily be masked behind smartly made animations and delays.

Also, Symbian didn't have a lot of things to do behind the scenes... Imagine your Android device without things such as push notifications. Blasphemy! All those things that are fast, look good and are so convenient are possible because of better resources. Make better hardware and you will be able to run better and more sophisticated software. Bring back old software on new hardware and watch it fail miserably :silly:

 

[madb1lly]

Having gone back to my trusty N8 after Lumia 925 kicked the bucket I found myself wondering about the same thing as the OP. Here's a few thoughts of mine:
1. Focusing on a single target device is the best way to start. Open hardware is obviously the best bet, but is there something available that's more similar to existing phones that used Symbian? The 808 Pureview was the last Symbian so the one most likely to still have similar hardware available.

1a. Since Symbian's strengths are low power usage what about a Symbian band/watch?!....

2. Nothing wrong with "wrappers" for websites - look at Firefox OS. Websites often have way more functionality than apps anyway, that's why I much prefer websites to apps most of the time.

3. Little of the source code was made public and then it was closed up again so improvements made after 2010 are hidden again I think. Who has the rights to Symbian now? I assume that Nokia sold it to Microsoft, and Accenture had the contract to "maintain" it until 2016 (not that they did). MS sold it's feature phone business to HMD Global, did they also sell the rights to Symbian (and what about MeeGo/Harmattan?).

4. I think battery life will always be improved running code natively rather than through a VM, regardless of how optimal the compiler is.

If I understand correctly you want to bring Symbian on an Android smartphone. This is a nice idea. I suggest you direct your attention on Symbian ^ 3. I have never done such a thing, my knowledge is limited to the PC programming of very simple games. But they are available for this project. But, you need people with this knowledge to do such a thing. You'll need the SDK for Symbian and its source code. I am in possession of the source code.

P.s. Sorry for my bad English, but I'm italian

You have source for what? The SDK? Or Symbian itself? Which version?

 

[trax7]

Having gone back to my trusty N8 after Lumia 925 kicked the bucket I found myself wondering about the same thing as the OP. Here's a few thoughts of mine:
1. Focusing on a single target device is the best way to start. Open hardware is obviously the best bet, but is there something available that's more similar to existing phones that used Symbian? The 808 Pureview was the last Symbian so the one most likely to still have similar hardware available.

1a. Since Symbian's strengths are low power usage what about a Symbian band/watch?!....

2. Nothing wrong with "wrappers" for websites - look at Firefox OS. Websites often have way more functionality than apps anyway, that's why I much prefer websites to apps most of the time.

3. Little of the source code was made public and then it was closed up again so improvements made after 2010 are hidden again I think. Who has the rights to Symbian now? I assume that Nokia sold it to Microsoft, and Accenture had the contract to "maintain" it until 2016 (not that they did). MS sold it's feature phone business to HMD Global, did they also sell the rights to Symbian (and what about MeeGo/Harmattan?).

4. I think battery life will always be improved running code natively rather than through a VM, regardless of how optimal the compiler is.


You have source for what? The SDK? Or Symbian itself? Which version?

You are absolutely right! I wouldn't make a watch out of it, you'd have to remake it in order to be usable or ergonomic. It simply wasn't made with this in mind... (it's not impossible of course, just not worth the effort)

I also don't think any changes have been done even a few years back - it's just an old system and managing/mantaining it is pointless and only costs money.

That said, making a new OS with the same choices in mind would arguably be a better undertaking than fixing or patching old foreign code

 

[madb1lly]

You are absolutely right! I wouldn't make a watch out of it, you'd have to remake it in order to be usable or ergonomic. It simply wasn't made with this in mind... (it's not impossible of course, just not worth the effort)

I also don't think any changes have been done even a few years back - it's just an old system and managing/mantaining it is pointless and only costs money.

That said, making a new OS with the same choices in mind would arguably be a better undertaking than fixing or patching old foreign code

I did a bit of digging around on this the past week, it's quite an interesting project to consider.

The source that was released was called "Symbian^3" (Symbian OS v9.5 and S60 v5.2). There was probably some other stuff in the repositories that wasn't exactly related to Symbian^3 but since I'm not an expert I don't know the difference.

Nokia soon made the source closed again (I don't know how that's legally permitted for stuff derived from public EPL-licensed code, anyone have any idea?) and continued development in house. The last version of Symbian was "Nokia Belle FP2" (Symbian OS v10.1 and S60 v5.5). So there's changes to both the core and the platform/UI that were not released as source code. I've no idea what the developments are, but for anyone starting a project it would be useful to have the latest sources (especially since Qt on ^3 was weak compared to Belle).

The mediafire link above has loads of tools (and books!), the publicly released source is in several places on the web, as is the source for some of the incubator projects. As was noted above, the most interesting project (in terms of this thread) was Wild Ducks which got S^3 running on a Beagleboard (OMAP3, like some S60 5rd edition phones from Sony and Samsung). Symbian also demoed a version running on a NovaThor test setup (Cortex-A9) but this didn't go anywhere and I don't know if the source was released.

In terms of getting it to run on "Android" devices, I think this is very ambitious as first step! After investigating I would first try and get it running on an OMAP3 Beagleboard (if you can find one), then try porting it to another SBC, either also running a Cortex-A8 CPU or an ARM11 CPU (last Nokia Symbian phones used single-core ARM11, not Cortex). Ideally the GPU would be PowerVR (as in OMAP) or Broadcom VideoCore (as in latest Nokia Symbian phones). FYI Raspberry Pis have VideoCore and ARM11 or Cortex CPUs (but not Cortex-A8). Only after successful porting to similar hardware would it be realistic to look at real phone hardware. However, perhaps I'm being pessimistic myself.

In summary, my first step would be to target Beagleboard or equivalent OMAP3 SBC; second would be an ARM11/Cortex-A8 and PowerVR/VideoCore SBC; third would be real phone hardware.

Now I've written my thoughts down I might try it myself!

 

[4ngl09669]

Having gone back to my trusty N8 after Lumia 925 kicked the bucket I found myself wondering about the same thing as the OP. Here's a few thoughts of mine:
1. Focusing on a single target device is the best way to start. Open hardware is obviously the best bet, but is there something available that's more similar to existing phones that used Symbian? The 808 Pureview was the last Symbian so the one most likely to still have similar hardware available.

1a. Since Symbian's strengths are low power usage what about a Symbian band/watch?!....

2. Nothing wrong with "wrappers" for websites - look at Firefox OS. Websites often have way more functionality than apps anyway, that's why I much prefer websites to apps most of the time.

3. Little of the source code was made public and then it was closed up again so improvements made after 2010 are hidden again I think. Who has the rights to Symbian now? I assume that Nokia sold it to Microsoft, and Accenture had the contract to "maintain" it until 2016 (not that they did). MS sold it's feature phone business to HMD Global, did they also sell the rights to Symbian (and what about MeeGo/Harmattan?).

4. I think battery life will always be improved running code natively rather than through a VM, regardless of how optimal the compiler is.


You have source for what? The SDK? Or Symbian itself? Which version?

I have the PDK of all version of Symbian. About 13 GB if I'm not mistaken.

 

[madb1lly]

I have the PDK of all version of Symbian. About 13 GB if I'm not mistaken.

I found a lot after some searching. The makers of the Delight custom firmware made their collection available online and a few others have done the same (on an archive of the symbian.org wiki and in web.archive.org, amongst others). I can't remember all the versions I now have, but it includes:
Symbian PDK 3.0.4.a
Symbian PDK 4.0.a
Symbian PDT 1.7.0
Various SDKs for Qt, Symbian^3, Belle and older versions of S60.

I've put more thought into this since my post above. It's a huge amount of work, with many possible dead-ends. My approach would be incremental steps, attempting a baseport to a similar device each time, e.g. Syborg QEMU emulator -> Beagleboard -> Pandaboard (like the Wild Ducks project) (needs to be SMP safe) -> another SBC with ARMv7-A multi-cores but from another SoC vendor (not TI) -> ARMv8-A multi-core. Maybe an intermediate step to add asymmetric multiprocessing support as well.

I'd take this incremental approach because I'd be learning all the way, but someone who already knows what they're doing with drivers, multi-processing, ARM architectures, etc. could probably go straight to a modern phone-equivalent SBC; or even a phone

 

[fedor4ever]

Well, symbian source dumped at sf.net and source code cloned at bitbucked too with full history.

---------- Post added at 10:58 PM ---------- Previous post was at 10:40 PM ----------

Hi all! I saw i not alone at my researches I recomend pasberry pi as start point because they have gpu open source driver with manufacture documentation.
I spend a lot time with fixing elf2e32 whitch sometimes fails to build symbian apps. Now it doesn't fails but inserts many zeros at certain points.

 

[brainycaleb]

Off topic:

Symbian was god at multitasking.

(Nokia C6-01) (256 MB RAM)

You can run at least 20(minimum)apps and can switch between them easily and no app will restarts,it resumes where you left it.

I remember I minimized dungeon hunter and opened it after 4-5 days and when I opened,
It resumes at same state and without loading or reopening.

In its time (2011) no other phones OSs was able to that.

(Sorry if English is bad)

Sorry for waking the thread but it's almost 2018, no android phone has been able to achieve that level of multitasking!

 

[trax7]

Sorry for waking the thread but it's almost 2018, no android phone has been able to achieve that level of multitasking!

Note several things:

1. Symbian apps were way smaller and less functional, intuitive and fast. Symbian apps are nothing compared to Android apps.

2. The implementation of multitasking is fundamentally different between the platforms.

3. Symbian does not run on a VM. Thus, you will need to recompile and keep track of different versions of the same app for every CPU architecture.

Those are only the things off the top of my head. I am not bashing or defending anything, just want to clear things up why they are different amd why a comparison is not applicable

 

[atrack2008]

Sailfish OS for ZE551ML

Hi, I want to know if there will be (soon or not) any solution to get sailfish os on the Asus zenfone 2 ze551ml. I know , this phone isn't the the adaptation list, but, i had to ask.