Great, now let's hope Jolla manage to incorporate this into an upcoming Sailfish X update !

the adaptation is open, you can try and build it with the 4.4 kernel yourself, no need to wait for Jolla to do it

If you can point me to a repo from which a could git clone some free time I could do my own build :-D

As @Andy Branson denoted in a comment:

All of the Xperia SailfishX adaptations are open-source and can be found here: https://github.com/mer-hybris/

Reopening the thread just to find out that you bumped it with no new information is also depressing.

@Sthocs : question converted to wiki. Feel free to make it better or more structured if you have free time for that.

? it's already great and well structured, thanks!

This indeed used to be a problem on Jolla 1 : it's kernel only covers API that are useable up to Jellybean 4.2, it doesn't cover the API require by Kitkat (there are some theads discussing it).

On the other hand, the Linux 4.4 kernel isn't only used on Android Oreo 8, but Sony is also using it on older versions of android (the same where they used the previous 3.10.84 kernel, so there are chances that there's an overlap in the provided APIs). Some expert in Alien Dalvik should jump in to give more info...

Also kernel 4.4 is also useful for another android layer : Andbox! (it exposes all the cointainer-related API that are required by andbox). So some of the comunity would be able to experiment with it as a solution of getting support for more recent apps that have switched from the dalvik JIT to the current runtime.

Will kernel 4.4 fix cpu utilize and bring more power to sailfish x

Yup, scheduling with big.LITTLE cores has been improved in that kernel (seems it has been introduced in kernel 3.13 as seen here on Phoronix, so the current 3.10.84 in Sailfish is missing it, but Sony's 4.4 kernel in AOSP 7.1/8.1 has it)

downgraded by sailfish like central processing unit is currently in xperia x.

The thing is, the kernel version 3.10.84 has no idea about big.LITTLE CPU cores.

So on older versions, Sony has written additional custom proprietary libraries to handle the CPU optimisation.

By kernel version 4.4, the kernel is able to handle the situation and would work out-of-the-box without any special library needed.

What about xperia X graphics processing unit, is it work correctly like in official Sony's android? I mean is it also downgraded

The whole raison d'être of the hybris hardware abstraction layer) is to be able to take the normal Android (Linux + Google's bionic libraries, etc.) drivers used by Sony and slap them as-is on a GNU/Linux OS like Sailfish.

Jolla doesn't re-write their own set of drivers, they use whatever the chipset manufacturer provides.

The only problem is that their current adaptation is designed to work with the drivers that came with Sony's Android 6.0 Marshmallow for Xepria X.

Current AOSP 7.1 Nougat and 8.1 Oreo that use Sony's kernel 4.4 obviously use a more recent driver from Qualcomm, so Jolla would need to make a new hybris adaptation.

Which is still a bit of work. Thus don't expect anything before Sailfish 3.0, and even then Jolla's will have to decide if it is worth the effort (my humble user's opinion would be : yes)

Allright thank you for your quick answers! Very nice to see so quick and proper answers! Now I have more knowledge about this subject. Xperia Xa2 have only kernel 4.4 so it contains those many improvements so it supposed to work better than currently xperia x. So at least in future we have even greater device indeed in many aspects.

I'm so excited about xperia xa2 with sailfish x although it have decent hardware today.

You may find my howto on using big cores of some use: https://together.jolla.com/question/187833/howto-enable-a72-cores-to-make-xperia-17x-faster/

thank you, @butler, this looks interesting.

1. The current kernel is at 3.10.84 already, you doofus. Try at least to get your facts straight.

Sony has already ported the 4.4 kernel to Loire platform. Jolla would in theory only have to redo their adaptation layer. (In practice, given the latest Blog entry they've apparently went a little bit further, and are recompiling Sony's kernel themselves from source and enabling a couple of extra stuff like BTRFS)

The 3 million lines worth of git diff that you're citing are across the whole fucking kernel codebase.

• That includes a few bits that are running on the smartphone (e.g.: the newer, better optimised scheduler that better handle the litte.BIG core configuration, leading to more responsive system and better battery usage).
• But that includes ton of other stuff that will never be compiled-in in the kernel running on your hardware (better opensource drivers for desktop graphics cards like AMD Radeon and Intel. drivers for buses on desktop like PCIe. drivers for buses on clusters like Infiniband. drivers for networking system used by banks like X.25 etc.)

Version 4.4 is a LTS edition.

• It's what Sony will be spending resource to keep up to date for the Loire platform
• It's what google recommends (together with 3.18) for Android, so that's where ressource from Google and every other hardware manufacturer will be spent to maintain.
• It's an LTS edition that tons of other distributions (like RedHat/CentOS/Fedora) will be maintaining too
• In short, that's the surest things that will be kept up to date.

Backporting security fixes is going to be a nightmare where Jolla would be on their own.

• that would main weeding through all the 3 million line you cite to find which are security fixes relevant to the current 3.10.84 kernel
• that means adapting and rewriting a lot of the fixes because 4.4 doesn't look exactly like 3.10.
• all this done on Jolla on their own, because every other developper on this planet will be working on 4.4

In short, your idea is completely stupid if you'd had any consideration to the work that "back port security fixes" represent and if you spent more than half second thinking what real danger those 3mio diffs pose.

So please stop repeatedly polluting useful discussions with your misconstrued paranoid lies.

Go troll somewhere else

"bloated kernel". This post must be one of the most stupid I've read in this forum.

@johanh : the worse part is that alloj keeps reposting the same stupidy each time without even paying attention to any attempt at constructive answer (see the other one).

Resource drunk kernel

It's just the kernel, just the part that talks to your hardware. Not the whole android. It's far from resource drunk.

Also speaking about "talking to the hardware", newer kernel bring very interesting optimizations that actually help performance : the 4.4 kernel has better handling of the scheduling of mixed little.BIG cores.

Backporting security fixes is a tedious task, that must be done in addition to development done on main kernel. (i.e.: the security fixes that kernel 4.4 introduce come "for free". backporting them to 3.10.xxx would require additional dev-time. Whereas with 4.4 you "only" need to backport what fixes have come between 4.5 and current 4.14 - like what Google did for 4.4 and 3.18. Meaning less efforts)

New millions of lines of code leads to more security vulnerabilities.

Nobody forces your to enable every last kernel feature like X.25, Infiniband fabric and other useless stuff that have no use on a smartphone, so you won't be affected by ALL THE DIFFS between 3.10 and 4.4

Also, if the industry is standardizing to a more recent kernel for Android Oreo (4.4, with the exception of extremely old hardware stuck at 3.18), means that is going to be even more scrutinity around this kernel. (Instead of each device stuck with its own 3.2, 3.4 (Jolla), 3.10 (Nougat Xperia), etc. kernel).

(Chances are higher that the "next Blueborne" will be seen faster, if more chip maker and handset manufacturer and 3rd party OS devs all look at it).

not to forget treble support: https://source.android.com/devices/architecture/treble

I am trying to port SFOS for the OnePlus 5. However, since it uses the 4.4 kernel this is a difficult task as usb_gadgets are dropped from the mainline kernel. So no telnet to see whats failing. Anyone on this forum know of 4.4 kernel configs that are required for it to be "mer friendly"?

Update: I found a solution to the kernel 4.4 usb_gadget issue (https://developer.ridgerun.com/wiki/index.php/How_to_use_USB_device_networking) I am now able to telnet into my OnePlus 5 with the Mer Boat Loader running

"resource drunk kernel"? From which Microsoft planet are you?