Oreo source - Githubissues

Uzephi commented 6 years ago

Version: ODX27.109-34 Device: Nash Branch: 8.0

I see the Verizon Z2 updated to 4.4.78. When can we get the kernel source for the Nash? Can we get an ETA when the new source will be made public to follow GPL?

Uzephi commented 6 years ago

https://android.googlesource.com/kernel/common/+/android-4.4/Makefile

luca020400 commented 6 years ago

@Uzephi I think they know how to handle kernel updates properly, unlike you apparently. It's dangerous to merge newer kernel releases, the profit isn't worth the risk.

Uzephi commented 6 years ago

https://medium.com/thecyberfibre/android-kernels-does-upstream-matter-fbf5f81542c0

I can bring up more articles as well if you want. If Google gives the code to build a stable Android kernel and most OEMs don't follow it as well as they should.

fgl27 commented 6 years ago

They don't update to "upstream" because they internal rules, that has many many rules and one that causes this is, that any change must goes through it's internal process of a "Gerrit Code Review" https://gerrit.mot.com/ with is close for us, but you see the link on commits or some process like that...

Any one that had experiences with those review process know how exhausting it can be, and to apply that to hundreds of changes is need a lot of time, and linux is know to have a lot of updates on it branch update.

So I assume they don't do because of that and as a lot of the changes to linux don't affect android and or the device it self, you can see by your self that, after all linux is for all devices not for that device alone, so any thing that runs a "modern" cpu can be supported and then a big part of the changes on linux updates are related to make all devices out there stable and support all of they featuring...

You also can see that they do security updates (updates from linux upstream) and etc related to android or the device, but they don't do all the linux update with makes sense on the situation of how things must work on Moto.

Update linux to latest branch version is not a problem any one that has done it for some time knows it, after all they do also have they own review process, yes they can cause problems but most developer will notice the problem under 24h of use, personalty doing it over 50 times I had only two times a problem, those two was after the branch hit EOL (but that doesn't means a fully supported branch can have problem also) and the problem was associated to one commit it time, reverting it problem solve, one of the changes was properly fixed on the next linux update the other was a conflict with a device specific driver and that was all...

So it's about it individual to do they own process, but that individual process can't be apply to a corporation like Moto, is easy to understand that when you have a idea of how things work and that doesn't means they are't doing the proper changes they do but on they own time and internal process until the device hits EOL...

Uzephi commented 6 years ago

That makes more sense than saying it makes it highly unstable and dangerous from previous comment. I'll upstream myself but would still like to get source for the kernel and an ETA on when they can release it.

fgl27 commented 6 years ago

try to use correct info on the issue like: https://github.com/MotorolaMobilityLLC/kernel-msm/issues/135

Uzephi commented 6 years ago

Updated initial query, thanks for the heads up.

@charleseb

texasaggie1 commented 6 years ago

Please release the source code for OREO so we can make proper recovery images and custom ROMs. Thank you! @charleseb

kendallgreen commented 6 years ago

I am having problems downloading the Oreo update for my Moto Z2 force on T mobile NCX26.7. We need the kernel source to help. Motorola issue #180106002025

awheeler-mmi commented 6 years ago

Hey all,

@charleseb will post the Z2 Force (nash) source next week! We just need to wrap up some internal gates with Marketing and Legal, and then push the code out.

Rebasing to a new kernel version during an upgrade is tricky. QCOM and other chipset vendors tend to stick with a particular kernel version for the lifetime of a chipset family, and just backport the desirable features and fixes. If we move the kernel "ahead" of our chipset vendor then they have a much harder time supporting us. Since we try to get the upgrades out as quickly as possible, we stay aligned with the chipset vendor's kernel as much a possible.

I suspect that Google will continue to pressure chipset vendors to keep their kernels up-to-date, so maybe we will see some changes in 2018. We will also ask Google to consider a kernel update as a "security update" rather than an a full-fledged upgrade. This removes a number of barriers to getting new kernels into the handsets of consumers as quickly as possible.

Uzephi commented 6 years ago

Thank you for the update!

Thank you also for informing about the CAF update process. I just like staying upstreamed for the sake of security. Like the minor fixes that have been done to x86 quietly in the uostream for the past couple months about the KPTI leak recently.

I know this is arm64, but if something like that quietly gets done for our chipset, I like the comfort knowing my phone has that patch asap.

luca020400 commented 6 years ago

For the matter CAF merged kernel/common in the latest LA.UM releases, merging new android features and security features ( like PAN, and in the last days KPTI ) I'm now seeing google already driven to do major kernel updates ( see marlin jumped from 3.18.31 to 3.18.70 during the migration to O-MR1, and they had to deal with CAF random upstream picks and changes ) Hopefully sometime soon vendor kernels will be much less different from korg releases allowing easier upstream merges

awheeler-mmi commented 6 years ago

Ok, I just looked. Nash O is based on LA.UM.6.4, which is up to ~4.4.78. Google appears to be keeping their kernel aligned with korg (last merged a few days ago) and CAF last merged Google's branch ~5 months ago. That is... actually much better than baselines from even last year...