I found that SONY released this Software binaries for AOSP Android 11.0 – Kernel 4.14 – Ganges (latest) - Sony Developer World
why not update the base hw layer for SFOS to Android 11?
Would be useful for something?
1 Like
Presumably because it is a lot of work, for at least very little benefit.
(Linux 4.14 vs 4.9)
Heck, those blobs could even be compatible (some others are), so quickly approaching zero benefit to update the port if that’s the case, or they don’t really add anything (also likely).
2 Likes
If you put those blobs in the SFOS installation folder and run the script, you’ll have a bricked Sony Xperia right?
Not bricked, it just doesn’t boot and you’ll habe to flash the correct firmware again.
3 Likes
I was gonna make a dumb, clearly-no-sleep joke; so here it is regardless.
I guess it’s not getting A11 cause it only goes up to Xperia 10.
All failure at humor aside; realistically, while a kernel could be recompiled, if said kernel config is looking for things in a different folder, it will not boot, if its expecting a file or binary and its either not there (diff folder) or not what it was expecting it, it can hang; resulting in a brick-like state. – The one way to completely fix this, as in, a true update to A11 as a base, could be a complete re-port.
When porting a Linux Distro, or at least, a Mobile linux distro, that uses libhybris or halium, said port is building on top of a specified firmware for your device. Ubuntu Touch usually recommends the latest official release, as long as there’s a Halium version that can run on it. Mind you this goes for both, actual device firmware as well as kernel. – Having said that, because of this firmware-specific situation, it’s far more common than not to have things break when changing firmware.
Most one could technically try to do either clone the SFOS kernel and manually patch things up where they make sense and don’t break, or just clone the new official kernel and apply all of the SFOS patches to it. And even then, there’s a chance you might have to build the SFOS image.
I’ve only ported UT, so please, any SFOS porters, feel free to correct (and by extension, educate) me.
1 Like
So in theory it could be done, but since Jolla has little manpower and it’s only for Xperia 10 and 10 plus it is not likely to be done.
Anyway for what’s worth I did pay the fee for the OS, hope they’ll consider the interest/passion and the “investiments” someone does.
There is also the counter argument of, what are the benefits? Besides just running a somewhat newer kernel, will this improve the stability and/or usability of the device in a way that the current work does not yet implement? – And if so, is there a way to implement it in the current version?
That’s very true, of course. 
By the way, I found very funny that SONY releases Binaries for AOSP Android 11.0 but they are stuck officially to Android 10 and Feb 2021 security patches on consumer devices. It’s like, we don’t care to provide you official Android 11, let the ball to custom roms…
Aarch64 would be a big benefit!
This has been mooted since the Xperia X, because that would be able to run the newer Android App Support with a newer base. It would be beneficial because we could support fewer Android bases, although each device has its own bugs on each base, so there would still be a lot of adaptation and testing work to do on each device. Also, the older models get more difficult to buy as time goes on, and they have less memory and so updating the app support and especially moving an aarch32 port to aarch64 would cause more problems there.
There’s also the issue of the odm blob image, which would need to be re-flashed with a different one during the upgrade, and that can only be done by downloading it yourself from the Sony site and agreeing to the terms etc. That would need some sort of new mechanism in the upgrade procedure that would get you to download it, then flash it during the upgrade. That’s a lot to do (especially to make sure it works reliably). Otherwise people would have to reflash, which would mean either dropping support for the old base as soon as a new one is released, or supporting all previous bases for each model at the same time. 32 to 64 would need a reflash. The Xperia X would definitely need reflashing anyway as migration would be pretty much impossible over such a large difference in Android versions, which heavily contributed to why that was previously ruled out.
So it’s not simple. It’s not going to happen any time soon, as I think it would require some big changes in the ways we do things. But it might happen one day if a good solution appears. Or not.
5 Likes