[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Good Day;

So there is an RC build up, subsequent builds will replace the OP download, sooner than later. It is here; https://github.com/nine7nine/Apps/raw/master/exNoShadez_eas_RC1_44994a5.zip

Changelist;

- Rolled back the sources to 3.18.78 (Oct 30), then (re-)merged in LTS-3.18.79/80 (Oreo Nov stuff)

- No Binder 4.4 fork (isn't ready for general use, due to the camera crap)

- Scheduler and workqueue subsystems are updated to match linux-3.19.0

- deadline io scheduler has been updated to 3.19, as well

- A number of bug fixes / cherry picks taken from my dev branch

- all of the audio patches that I've been working on through November. (re-committed/cherry-picked.)

- I merged in the remaining CopperheadOS kernel hardening/defences

- Support for binfmt_misc - it isn't enabled by default / must be mounted as root to use (but the support in the kernel is enabled)... So those who want to run Linux desploy, should be able to *cough* [MENTION=7122309]billiepreks[/MENTION]

I still have some patches to merge in, nothing crazy - but a few that I had to revert while doing the rollback on the source code.... Battery life on this one is yet to be determined, it might be down due to having not included a few patches that *I will commit*, before I update the OP download. also, CopperheadOS merge may affect battery slightly. ~ I'll get this all cleaned up in the next few days....

If you have been using my test builds / unstable builds - you will need to disable/uninstall google camera, then enable/ update it, otherwise it might crash (just a cached setting is probably mangled or something). I've been using the camera all evening with this build and since it doesn't contain the binder rt stuff - it's fine...

I would like to try and keep the CopperheadOS commits in, but we'll see how this all plays out on overhead ~ I find it takes me a day to get any sort of accurate read / estimate from Accubattery or the BatteryStatsService anyway, so I'm just going to run this one - while I get the rest of my cherry-picks and cleanups done... Maybe i'll flash a new build to test tomorrow night with all of the fixes and a few updates...

I've also changed my default branch on github - so that it will stay 'build-able' (development happens on my local branch and other branches. I'm also tracking changes using a text file in the kernel sources, with a file called "pull_track". I tag / add versioning to subsystems that I've upgraded, keep track of the lts / Oreo monthly version. It looks like this;

lts-3.18.80

Oreo-Nov 5

Sched-3.19

locking-3.19

workqueues-3.19

notes/documenting new (relevant) system calls/functions, configs, etc are added too)

I've got the majority of the 4.4 sched/locking code lined up - but I'm adding it very slowly to avoid any regressions. I'm also sitting on the akpm / mm patches, but they are more extensive, so not pushing them fast into my local tree or github ~ Basically, rather than doing big merges (which could lead to big regressions) - I'm slowly going to modify each subsystem to very major linux version. together, but one at a time.... In the commit log, it's very hard to tell; what patches lead upto each upgrade; which is why I'm using a separate file to track it ~ then after each set of commits; I update the file (which then shows as a commit - so it becomes very easy to see what groups of commits are from what kernel).

I've also had someone contact me privately, who is interested in getting involved. So, it's a possiblity there may be 2 people working on this kernel sooner than later ;)