**EDITED** Real World Ramblings Of The ‘Improved’ Multitasking Android Runtime On Jolla **EDITED**
It appears that the memory issues I had been experiencing (mentioned in the article below) have been addressed by Jolla in the latest software update 9, earlier today (22/10/14) including the following:
The low memory killer is now properly killing Android applications according to their set priority
In addition to that, certain thresholds for when memory killer should kick in has been added
NB. With this in mind you can largely ignore the rest of this article. Thanks.
For a while now I have been using the new android runtime system (since July’s Tahkalampi update) on my Jolla which allows for separate multitasking panes or cards to be handled individually on the homescreen.
This was a much requested ‘feature’ from the community and one that made sense on many levels, but after some real world usage how does it really stack up ?
Well it is clear from experience with other Android devices and now after using various apps on Jolla that many of these Android apps are very resource hungry and for me at least have so far caused the most battery drain and system lag (due to memory overload) on my Jolla.
The previous system utilised by Jolla worked much the same way as Android does where you load an app and that then becomes the app in the forefront, however upon loading a new (Android) app, the previous app was put into a state of “suspense” so that it used very little RAM ie. not true multitasking. The previous system made accessing the previously opened Android app(s) accessible via the “card” button which would bring up all the open apps for you to select which one you wanted to navigate to next (from within a single recent app pane hosting all recent Android apps in one area). The downside (and perhaps upside) of this system was that the “suspended” app would go into a freeze state so when you next accessed it, the app would reboot ie. app is not subjected to live refresh.
This “old” system in fact was not a true multitasking system when compared with the behaviour of Sailfish native apps which each have their own “space” on the homescreen, however it was (IMO) an efficient way of dealing with the power/RAM hungry Android apps and one that Android OEM manufacturers utilise themselves (even with the benefit of higher RAM flagship models). In fact even the alternative 2 main OS’s (IOS and Windows Phone) operate using this “suspend-upon-launching-new-app” recent app approach where true multitasking (ie. apps constantly running in the background), is dropped in favour of this simplified system.
So the question is: if handsets with far larger RAM/processor power at their disposal are not using a true multitasking approach in Android, why should Jolla ?
Well the benefits are, for example, should you require constant refreshing of a certain Android app that is unavailable in native format (eg. skype) you can have that without affecting the constant running next time an Android app is launched. In essence, no Android app will be put into a state of “suspense” until you decide to exit said app which of course has it’s plus points.
The obvious downside however is that the more of these resource heavy Android apps we have running simultaneously, the more laggy and drained the system becomes. The only OS that offers a similar approach to Jolla (with regard Android) is Blackberry’s BB10 which also allows for true multitasking of Android apps. However, the majority of Blackberry BB10 devices are manufactured with higher RAM specifications probably to deal with this precise issue.
So the options we/Jolla have available to cut down the affect off these “resource heavy” Android apps are as follows:
1/ revert to original “one card” Android runtime system for the time being in order to prevent system overload
2/ keep the new system but be aware of the problem and constantly “kill” unused android apps to maintain system resources at optimal level in order to prevent further battery drain and lag
3/ speed up native app development to replace the unintegrated, resource hungry Android substitutes
It goes without saying that point 3 is needed regardless and should be of utmost priority. It is problems like this which will hopefully incentivise developers to come up with native solutions that integrate beautifully and run optimally with our much loved Sailfish OS.
Having used the new system for a few months now, I would happily revert to the old system (option 1) combined with a big jump for option 3 in order to kurb my general reliance on Android apps.
How do your experiences with the new, revised android runtime compare ?
Latest posts by JollaTides (see all)
- #Jolla Tablet Campaign: Last Chance To Order + Juicy Perks - December 8, 2014
- #TOHKBD: Go, Go, Funky Configurator! - November 28, 2014
- #Jolla Tablet: Campaign Adds Bulk Retailer Option And Stretch Goals! - November 27, 2014