• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

Development [Kernel][15.01.2022][Android 12] Kirisakura 1.5.0 for Pixel 6/Pro aka "RAVIOLE"

Search This thread

Utini

Senior Member
Dec 25, 2010
1,161
210
www.whymacsucks.com
www.whymacsucks.com
Is there anything in the Kernel or configuration/companion app that speeds up the "deep sleep" state?

I have only 60% deep sleep which is caused by very long activation times to get into deep sleep after the screen is off. I do not know yet how to trouble shoot what is preventing my phone from going into deep sleep faster but I was hoping that the kernel or companion/configuration can enforce a faster deep sleep state?

During a night: 98% deep sleep with like 2% battery loss
During a work day: 50-60% deep sleep
 

Freak07

Recognized Developer / Recognized Contributor
Jan 2, 2011
5,275
17,080
Is there anything in the Kernel or configuration/companion app that speeds up the "deep sleep" state?

I have only 60% deep sleep which is caused by very long activation times to get into deep sleep after the screen is off. I do not know yet how to trouble shoot what is preventing my phone from going into deep sleep faster but I was hoping that the kernel or companion/configuration can enforce a faster deep sleep state?

During a night: 98% deep sleep with like 2% battery loss
During a work day: 50-60% deep sleep
as a short answer: no and you probably don´t want that.

a longer answer: the kernel can´t know what´s happening on your phone or what you´re doing with it.
If there´s nothing to be done from any app/service or other processes the system/framework "asks" the kernel to go to sleep and it will do so, eventually entering deep doze (where the system/framework also limits network traffic and wakeups etc). that´s what´s happening during night and it works fine for you.

during the day if you actually use your phone the system/framework requests the phone to wake up/wakelocks. depending on your location you might have bad mobile reception, switch network often, bluetooth devices connected, wlan connected, you receive notifications, listen to music/podcasts, make calls, have a bluetooth watch connected etc....
If you listen to music/podcasts or call someone while screen is off during the day, the phone can´t deep sleep during that. If you receive notifications the phone won´t deep sleep. If you receive notifications while on bad network the phone will stay awake for longer. If you´re constantly switching networks the phone won´t sleep as much as when it´s stationary overnight and enters deep doze if you don´t touch it for 20 minutes.

Then there can be apps that keep the phone awake for longer as necessary when it should be sleeping (there can be many reasons, sloppy coding, "spying", collecting information, making sure you really receive notifications), but again the kernel can´t know that. To get back to the beginning, you wouldn´t want the kernel to always force deep sleep as your phone would not function properly then.

Depending on what you´re doing 60% deep sleep can mean, let´s say your day spans 15 hours from 7-22. That means your phone sleeps for a bit less than 10 hours of that entire 15 hours. If you have 3 1/2h of SOT, that leaves your phone awake for 1 1/2 hours - 2 hours. If you make some calls, get notifications, switch screen on/off regularly (as opposed to never during the night) that´s plausible if one of the factors above apply (bad network, switching networks, lots of apps syncing, bt devices connected)
It all depends on your personal usage patterns and the factors I described above. If the phone is used for extended periods of time and then just kept idle for extended periods of time it´ll end up with more "deep sleep", as opposed to checking it every few minutes for a minute reply to texts etc.
 

Utini

Senior Member
Dec 25, 2010
1,161
210
www.whymacsucks.com
www.whymacsucks.com
as a short answer: no and you probably don´t want that.

a longer answer: the kernel can´t know what´s happening on your phone or what you´re doing with it.
If there´s nothing to be done from any app/service or other processes the system/framework "asks" the kernel to go to sleep and it will do so, eventually entering deep doze (where the system/framework also limits network traffic and wakeups etc). that´s what´s happening during night and it works fine for you.

during the day if you actually use your phone the system/framework requests the phone to wake up/wakelocks. depending on your location you might have bad mobile reception, switch network often, bluetooth devices connected, wlan connected, you receive notifications, listen to music/podcasts, make calls, have a bluetooth watch connected etc....
If you listen to music/podcasts or call someone while screen is off during the day, the phone can´t deep sleep during that. If you receive notifications the phone won´t deep sleep. If you receive notifications while on bad network the phone will stay awake for longer. If you´re constantly switching networks the phone won´t sleep as much as when it´s stationary overnight and enters deep doze if you don´t touch it for 20 minutes.

Then there can be apps that keep the phone awake for longer as necessary when it should be sleeping (there can be many reasons, sloppy coding, "spying", collecting information, making sure you really receive notifications), but again the kernel can´t know that. To get back to the beginning, you wouldn´t want the kernel to always force deep sleep as your phone would not function properly then.

Depending on what you´re doing 60% deep sleep can mean, let´s say your day spans 15 hours from 7-22. That means your phone sleeps for a bit less than 10 hours of that entire 15 hours. If you have 3 1/2h of SOT, that leaves your phone awake for 1 1/2 hours - 2 hours. If you make some calls, get notifications, switch screen on/off regularly (as opposed to never during the night) that´s plausible if one of the factors above apply (bad network, switching networks, lots of apps syncing, bt devices connected)
It all depends on your personal usage patterns and the factors I described above. If the phone is used for extended periods of time and then just kept idle for extended periods of time it´ll end up with more "deep sleep", as opposed to checking it every few minutes for a minute reply to texts etc.

Uh thanks for the detailed response.

I am definitely prone to bad phone signal on my office location but I am also always connected to good WiFi signal.
So deep sleep does limit network traffic meaning telegram/whatsapp/signal/fairmail/etc will all not work as expected anymore? And if I have them "not optimized" they will keep working but prevent the system from going into deep sleep?

I know this is not kernel and topic related but:
Would "Naptime" or "Greenify" help with putting the system into deep sleep when using any "spying" or bad coded apps? Or would there be any "reasonable" way to figure out if I have any of such apps?
 
  • Haha
Reactions: Mrcactuseater

xflowy

Senior Member
Jun 4, 2011
1,770
209
Google Pixel 6 Pro
guys. i just saw in gsam app, that my phone does only go in light doze and not deep doze. is this app related (and just does not work properly with the 6 pro) or is sth wrong here?
 

Freak07

Recognized Developer / Recognized Contributor
Jan 2, 2011
5,275
17,080
Uh thanks for the detailed response.

I am definitely prone to bad phone signal on my office location but I am also always connected to good WiFi signal.
So deep sleep does limit network traffic meaning telegram/whatsapp/signal/fairmail/etc will all not work as expected anymore? And if I have them "not optimized" they will keep working but prevent the system from going into deep sleep?

I know this is not kernel and topic related but:
Would "Naptime" or "Greenify" help with putting the system into deep sleep when using any "spying" or bad coded apps? Or would there be any "reasonable" way to figure out if I have any of such apps?
if your device deep sleeps it does deep sleep. if an app or a service wants to work it needs to request a wakelock, waking the device. that´s the simple explanation.
You´ll see it as an alarm, a wakeup , a partial wakelock or a kernel wakelock in bbs, similar apps or battery historian.
Some of those wakelocks belong together, if you´re device is sleeping while connected to wlan, an app or the system wakes up and needs wifi connection, you´ll see a bunch of wakelocks. wifi, activity manager, a wakelock for the app, a wakelock to wake up the ril.

If you really want to figure out what´s happening you need to invest a lot of time, now that BBS is not fully functional. You can try to tackle it from different fronts. Disable mobile network entirely while you´re in the office and solely rely on wlan. you can try to uninstall apps one by one and see if that makes a difference.
You can try to change your usage pattern. Let your phone sleep at the office without touching it for 3 hours there and check deep sleep then.
I don´t know anything else besides BBS or battery historian. I generally don´t like to use apps such as GSAM or those other monitors, but I did when I got the pixel 6 pro as BBS wasn´t working properly. I also don´t use monitors for active and idle drain such as in FKM or EXKM.

But again, it doesn´t sound that bad, if your usage is similar to what I described above.

But this derails this thread further and further. It´s unrelated to the kernel.

I personally don´t use apps like naptime or greenify. I gladly trade a few less % of deep sleep over day, so that I don´t get delayed or missed notifications.

guys. i just saw in gsam app, that my phone does only go in light doze and not deep doze. is this app related (and just does not work properly with the 6 pro) or is sth wrong here?
let´s please move this discussion out of this thread. It´s getting more and more unrelated to this kernel and the subject of this thread.

I don´t mind occasional off-topic or explaining certain things (even multiple times), but this isn´t the right place for it.

I answered basically the same thing to @Utini in the thread that was created here:
 
Last edited:

Nezorflame

Senior Member
Good find, thank you for the report! It's related to a bug in the pixel6 detection in the app I didn't notice yet... rolling out an update to the play store with a fix. As soon as google approves it, should be available.

I can confirm that after updating the Companion app to the version 3.3.3 (162), flag Enable Proximity Sensor Screen on is now visible. After setting it to off and rebooting, it's not locked to 60Hz anymore.
Thanks again!
 
  • Like
Reactions: Freak07 and tbalden

Freak07

Recognized Developer / Recognized Contributor
Jan 2, 2011
5,275
17,080
Hey there @Freak07 , will you wait for the December update next week before releasing a new kernel? Cheers mate.
yeah I guess next update will drop alongside whenever december source code drops. :)
as of right now I´m just enjoying the device and the kernel in its current form.
I can confirm that after updating the Companion app to the version 3.3.3 (162), flag Enable Proximity Sensor Screen on is now visible. After setting it to off and rebooting, it's not locked to 60Hz anymore.
Thanks again!
thanks for reporting back, glad it´s working fine now.
hats off and thanks to @tbalden for the quick fix! :)
 

milestoneman

Senior Member
Aug 8, 2010
82
12
Is this kernel beneficial for battery life?

I've not used a kernel for years but feel the 6 Pro needs some tweaking

Will my gpay still work or do I need to do anything extra?

Cheers
 
  • Haha
Reactions: Mrcactuseater

Freak07

Recognized Developer / Recognized Contributor
Jan 2, 2011
5,275
17,080
Is this kernel beneficial for battery life?

I've not used a kernel for years but feel the 6 Pro needs some tweaking

Will my gpay still work or do I need to do anything extra?

Cheers
every user has their unique usage patterns, so nobody will be able to definitely answer the question for you.

The only two things that definitely will improve drain:
take a look at the first post. If your usage includes listening to music/podcasts with screen off during the day, the provided magisk module, which tunes the powerhal will improve battery drain a bit.

in the CleanSlate config app, you´ll find a batterysaver that restricts max cpufreqs at 3 chooseable levels, which will improve battery drain as well. (if you´re willing to restrict max cpufreqs during regular usage.)

Battery life on this phone is pretty stellar to me though, so I have nothing to complain. :)


edit: gpay will stop working as soon as you unlock your bootloader. that´s unrelated to the kernel.
safetynet can be fixed, via other means though so you can get it working after unlocking, which is a requirement to flash the kernel! :)
 
Last edited:

milestoneman

Senior Member
Aug 8, 2010
82
12
every user has their unique usage patterns, so nobody will be able to definitely answer the question for you.

The only two things that definitely will improve drain:
take a look at the first post. If your usage includes listening to music/podcasts with screen off during the day, the provided magisk module, which tunes the powerhal will improve battery drain a bit.

in the CleanSlate config app, you´ll find a batterysaver that restricts max cpufreqs at 3 chooseable levels, which will improve battery drain as well. (if you´re willing to restrict max cpufreqs during regular usage.)

Battery life on this phone is pretty stellar to me though, so I have nothing to complain. :)


edit: gpay will stop working as soon as you unlock your bootloader. that´s unrelated to the kernel.
Thanks, I do listen to lots of podcasts so this is appealing
 

Nekromantik

Senior Member
Apr 1, 2010
6,668
888
London
Google Pixel 6 Pro
Is this kernel beneficial for battery life?

I've not used a kernel for years but feel the 6 Pro needs some tweaking

Will my gpay still work or do I need to do anything extra?

Cheers
If you want to use GPay on unlocked phone then you need to root and use magisk and saftynetfix to make gpay work. there are threads on this already on forum.
 

DanielF50

Senior Member
Jul 22, 2010
458
206
Hampshire, England
Google Pixel 6 Pro
Hello a noob question after installing this kernel, i lost root (magisk) any ideas plz ?
Of course you did - you flashed a boot.img that doesn't have Magisk installed?

2a. If you want to stay rooted patch the provided boot.img in magisk manager prior to flashing it via fastboot. Of course you need to adjust your command to flash like you did when rooting the device.

Looks like you missed the above step in the OP. Patch the kernel's boot.img in the Magisk app and flash it again to recover root.
 

Lughnasadh

Senior Member
Mar 23, 2015
2,710
2,353
Google Nexus 5
Huawei Nexus 6P
every user has their unique usage patterns, so nobody will be able to definitely answer the question for you.

The only two things that definitely will improve drain:
take a look at the first post. If your usage includes listening to music/podcasts with screen off during the day, the provided magisk module, which tunes the powerhal will improve battery drain a bit.

in the CleanSlate config app, you´ll find a batterysaver that restricts max cpufreqs at 3 chooseable levels, which will improve battery drain as well. (if you´re willing to restrict max cpufreqs during regular usage.)

Battery life on this phone is pretty stellar to me though, so I have nothing to complain. :)


edit: gpay will stop working as soon as you unlock your bootloader. that´s unrelated to the kernel.
And just to add a bit related to my own experience, blocking those 2 WLAN-related wakelocks seems to help a bit with my idle drain (maybe a decrease of .1% compared to stock?) as well as adding roughly 9% to my deep sleep percentage.
 
Last edited:

Top Liked Posts

  • 21
    I´d appreciate if we could keep anything "drama", non XDA-related and other topics that are not at all related to the topic of this thread, out of here.

    I´m not really interested in comparing my kernel versus "other kernels". I´m also not really interested in reading comparisons no matter the outcome of the comparison.

    I´m doing all of this during my free time, because I enjoy doing it and share what I´m personally running with everyone here on XDA.
    There needs to be no "rating" of those hours I spent working on my projects as they´re completely free of charge.
    I assume the same is true for others that work on similar projects too.

    If you appreciate the work, drop a thanks, write a few friendly lines, maybe consider a small donation, participate in the thread, report bugs in a proper manner if you encounter any, be friendly and helpful or contribute to the project here as all the source code is up on github.


    Everyones usage differs, everyone has unique usage patterns. So just try what´s available and choose what suits you best and be glad there are options for this device.
    7
    @xflowy Yes lets stop comparison on kernel devs thread.
    if you want to compare feel free to create thread on general forum.

    Or even better: Don´t create a thread to compare ROMs/Kernels or other projects at all.
    I don´t understand why there´s the urge to constantly compare projects as if there was some kind of competition. Use what suits you best and be happy it´s available.
    That's what I'd prefer.
    If one is not satisfied about what's available they might even start to get into starting a simple first project themselves.

    The XDA I know from back in the days when I was just a user, when I was not contributing anything in form of a development project because I simply lacked any knowledge and was instead just a mostly lurking and learning user, had a few unspoken rules that included to not do exactly this. (create "comparison" threads)

    Did a clean install of the January build and directly installed your kernel again.

    Thanks, i really appreciate your work. 👍

    Also I like the way off communication with your users.

    Great kernel, smooth as hell and definitely better than stock. 😊

    Gonna buy you a beer mate 🍻

    Happy to hear. :) Thanks for the kind words and the beer.

    Is there a way to further limit the core frequency when the screen is off using the module?
    Yes it could be reduced further, but the lower it gets the more likely it gets to territory once entered where issues like stuttering during music playback etc could occur.
    4
    Thank you for your kernel.

    I no longer need to install the p6 powerhint module along with the kernel zip (1.5.0) as it now comes bundled already with the flashable zip. Correct?
    Correct (y)
    3
    Hey, thanks for the update. I just flashed 1.4.0 however I seem to have an issue with Bluetooth audio, I cant for the life of me to get audio to work on my car over bluetooth.

    Could this be related to the Kernel or should I be looking at other possibilities.
    It could be related. Did you flash 1.4.0 on January or is that a typo?

    1.4.0 was for December, 1.5.0 is for January.

    I have a few Bluetooth devices (although no car that has Bluetooth) and all of those devices work fine on my end. Tried also pairing new devices.

    You can try to reboot, make sure you're running the correct kernel for the correct firmware build and if that doesn't work try to restore stock kernel and see if that changes anything.

    If it's related to anything I changed, i might need logs to do anything.


    edit: I just googled bluetooth issues on cars with the pixel 6, there seem to be a lot of complaints too.

    Oh i was asking because i dont play music and if it can be reduced lower to only need support for notifications
    I can't decrease it for everyone as that won't work.
    If you're interested how to change it yourself pm me, I'll write you a short explanation.
    3
    Did a clean install of the January build and directly installed your kernel again.

    Thanks, i really appreciate your work. 👍

    Also I like the way of communication with your users.

    Great kernel, smooth as hell and definitely better than stock. 😊

    Gonna buy you a beer mate 🍻
  • 31
    I wish those who celebrate it Merry Christmas!🎄⛄✨

    I hope everybody has a nice time and is enjoying the holidays with their beloved ones.
    31
    Update to 1.5.0

    Hey guys and girls,

    I hope everybody started into a Happy New Year 2022. I´m very happy how this project turned out so far. The kernel runs absolutely great and despite many complaints I don´t really had a single issue on my pixel 6 pro. Luckily it seems my carrier and the bands that are used for network were unaffected by the bug that plagued a lot of users.
    Aside from that I´m also very happy how this thread turned out so far. There seems to be some sort of community spirit that I´m missing often lately on XDA, people help each other and there´s a friendly constructive atmosphere. Big thanks to @roirraW "edor" ehT who constantly pops up here and helps other users and everybody else contributing one way or the other too.

    I´m giving my best to reply to questions in a timely manner, at least as timely as my time allows, so it´s great to see this thread evolving over time and everybody helping each other. Thank you all for that and keep it up.


    Alright here´s the next update then. :) There were only very minimal changes to this kernel in the January Source drop, but I managed to squeeze out two builds before I have to leave for work. :)

    The mechanism that prevents small tasks to cause frequency spikes is now tied into the powerhal. That means when interaction is needed (app launches, camera launches, interaction) this mechanism is toned back as the device gets boosted anyway.
    In all other cases the mechanism now gets more strict to prevent frequency spikes, videos, audio, navigation etc.

    Next release will probably have a few more very interesting changes that are currently under testing so stay tuned. Didn´t think google would drop this before Monday.

    Several other improvements are included as well. More details in the changelog.
    Download is below.
    Updated instructions in the OP!


    Changelog:
    - January Source update merged
    - linux-stable 5.10.91
    - use latest google prebuilt clang 14.0.1 for compilation
    - improvments from kernel/common
    - tie "prevent frequency spikes caused by small tasks into the powerhal"
    - add latest CleanSlate features and updates (huge thanks to @tbalden, if you enjoy these features maybe buy the apps from the playstore to give a bit of support :) )
    - other changes please look at my github


    Download:


    Instructions can be found in the OP! Please follow the instructions to avoid any issues.
    If you´re coming from another kernel restore stock boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img before flashing. Thank you.
    21
    I´d appreciate if we could keep anything "drama", non XDA-related and other topics that are not at all related to the topic of this thread, out of here.

    I´m not really interested in comparing my kernel versus "other kernels". I´m also not really interested in reading comparisons no matter the outcome of the comparison.

    I´m doing all of this during my free time, because I enjoy doing it and share what I´m personally running with everyone here on XDA.
    There needs to be no "rating" of those hours I spent working on my projects as they´re completely free of charge.
    I assume the same is true for others that work on similar projects too.

    If you appreciate the work, drop a thanks, write a few friendly lines, maybe consider a small donation, participate in the thread, report bugs in a proper manner if you encounter any, be friendly and helpful or contribute to the project here as all the source code is up on github.


    Everyones usage differs, everyone has unique usage patterns. So just try what´s available and choose what suits you best and be glad there are options for this device.
    16
    just a heads up. there´s no january source code released yet and it´s getting late here.

    Working day for me tomorrow, but I´ll try to update the kernel as soon as possible once January sources are released.

    In the meantime the 1.4.0 zip works fine for me on January update. There seem to be not that many kernel changes as the stock kernel still has a November build date. :)
    10
    Do you envision a new kernel update soon @Freak07 or are you waiting for the January update? Cheers.
    I´m waiting for the January update :)
  • 74
    Kirisakura-Kernel for the Pixel 6/Pro

    Hello everyone,

    To keep it short: Here is Kirisakura - Kernel for the Google Pixel 6 Pro aka Raven and the Pixel 6 aka Oriole, together Raviole.
    I would appreciate if everybody that flashes the kernel, reads at least once through this opening post and the following ones.

    The kernel aims to keep most of the subsystems updated, way ahead of the stock kernel, thereby improving security, stability and performance!
    This includes Linux-Stable, F2FS-Stable and kernel/common!
    If that got you curious,have a read about linux-stable and why it is important here. The stable-process is not the same for every subsystem, but the general idea, rule of thumb and benefits are applicable for other subsystems as well.

    The kernel includes a lot of improvements and contributions from other developers as well. Without this kernel would not exist.
    A big part of improvements originate from @arter97´s, @kdrag0n´s and @Sultanxda´s work. Many others contributed in some way or another to this kernel.
    A big thanks to all of them at this place!

    Now lets continue with a list of features in the next paragraph!

    Features:
    Main Features:
    - Based on latest kernel sources from Google, Kernel is made for Android 12
    - Linux-Stable-Upstream included to 5.10.91 (stock is 5.10.43)
    - Compiled with prebuilt Google clang 14.0.1
    - merged kernel/common
    - pelt multiplier tied into powerhal (more info here)
    - prevent frequency spikes caused by small transient tasks (more info here)
    - tie mechanism to prevent frequency spikes caused by small tasks into powerhal
    - F2FS-Stable updated
    - TCP backports from mainline
    - BFQ updates backported from mainline
    - use bbr as default TCP congestion algorithm (fasted algo according to this excellent research from @kdrag0n found here )
    - Enable support for TTL spoofing
    - Include LRNG, see here and here for more info (thanks @arter97 for the work on his op9 kernel)
    - important patches from kernel/common for 5.10 (here are more details)
    - CleanSlate Features from @tbalden, big applause here! (s2s, notification booster, battery saver, cleanslate features that work otherwise with rooted devices like kadaway (adblocking) are not implemented on this kernel since I´m running rooted)
    - flashing the kernel will keep root

    Various Optimizations:
    - update several drivers to use power efficient workingqueues (for example wlan driver)
    - kernfs: use buffer from the stack space
    - printk: use buffer from the stack space
    - kthread: use buffer from the stack space
    - bpf: avoid dynamic memory allocation for small value buffers
    - binder: Reserve caches for small, high-frequency memory allocations
    - kernfs: use kmem_cache pool for struct kernfs_open_node/file
    - cgroup: use kmem_cache pool for struct cgrp_cset_link
    - f2fs: reduce timeout for uncongestion
    - f2fs: Demote GC thread to idle scheduler class
    - f2fs: set ioprio of GC kthread to idle
    - mm: vmstat: use power efficient workingqueues
    Wakelock Blocker:
    - advanced wakelock blocker with the ability to block any wakelocks (dangerous, use with caution)
    - please read [URL="https://arstechnica.com/gadgets/2018/08/p-is-for-power-how-google-tests-tracks-and-improves-android-battery-life/"]this for further info

    AK3 Helper Module:
    - restrict little cluster to 1,4ghz, mid cluster to 1,49ghz and big cluster to 1,58ghz during screen off, to reduce battery usage for example during music playback
    - tie pelt multiplier into the powerhal (more info here)


    DOWNLOAD:
    Download is always located in this folder:

    Changelog:
    Android 12

    1.0.0 Initial Release
    1.0.2 https://forum.xda-developers.com/t/...r-pixel-6-pro-aka-raven.4358435/post-85910621
    1.0.5 https://forum.xda-developers.com/t/...r-pixel-6-pro-aka-raven.4358435/post-85924419
    1.3.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-85976139
    1.4.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86109665
    1.5.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86259863


    Requirements

    - unlocked Bootloader
    - USB-Debugging in developer options enabled
    - latest adb and fastboot binaries
    - working adb and fastboot environment so you can flash back to stock in case something goes wrong
    - working magisk environment (a device rooted with magisk, make sure to use latest canary)


    How to flash the Kernel:
    1a. Make sure you tick all the requirements above
    1. Download the correct kernel.zip depending on your device (Pixel 6 = oriole || Pixel 6 Pro = raven)
    (if you´re for whatever reason on November firmware, use 1.3.0 more recent kernels will bootloop)
    2. Flash the correct kernel.zip via EXKM or FKM. Root will be preserved.
    3. Reboot and profit

    Manual installation without relying on paid apps like fkm/exkm:
    Please have a look at the linked post.

    1. Download the images provided in the downloads section to your PC.
    1.a Optional: Download the powerhint magisk module found in downloads section and flash it via Magisk Manager like any other magisk module.
    2. Flash the provided images using fastboot/bootloader and fastbootd (these are seperate modes)
    2a. If you want to stay rooted patch the provided boot.img in magisk manager prior to flashing it via fastboot. Of course you need to adjust your command to flash like you did when rooting the device.
    3. vendor_dlkm.img needs to be flashed in fastbootd, while the other images need to be flashed via fastboot/bootloader
    How to boot to fastbootd
    From running phone:
    Code:
    adb reboot fastboot
    From fastboot/bootloader:
    Code:
    fastboot reboot fastboot

    Once in fastbootd:
    Code:
    fastboot flash vendor_dlkm vendor_dlkm.img

    Boot from fastbootd to fastboot/bootloader to flash dtbo.img and boot.img:
    Either select Reboot to bootloader option via buttons
    or type:
    Code:
    fastboot reboot bootloader

    Now in fastboot flash boot.img and dtbo.img
    Commands:
    Code:
    fastboot flash dtbo dtbo.img
    fastboot flash boot boot.img

    4. Reboot either via buttons
    or by typing
    Code:
    fastboot reboot
    5. Profit!

    @osm0sis for all his work on AK3.
    @tbalden for being the best HTC, Pixel, OnePlus and Asus wingman!
    @LeeDroid and @mwilky for their awesome roms and work I used on multiple devices!
    @Captain_Throwback for all the mentoring and guidance!
    @Eliminater74 for bringing me into the game and the Inspiration
    @nathanchance for his upstream guidance and assistance
    @RenderBroken for helping me out
    @flar2 for all his work
    @joshuous for all the help he provided to me in the past!
    @arter97 for giving me advice
    @kdrag0n for his help and advices!
    @topjohnwu for magisk and his entire work!


    Source Code: https://github.com/freak07/Kirisakura_Raviole
    31
    I wish those who celebrate it Merry Christmas!🎄⛄✨

    I hope everybody has a nice time and is enjoying the holidays with their beloved ones.
    31
    Update to 1.5.0

    Hey guys and girls,

    I hope everybody started into a Happy New Year 2022. I´m very happy how this project turned out so far. The kernel runs absolutely great and despite many complaints I don´t really had a single issue on my pixel 6 pro. Luckily it seems my carrier and the bands that are used for network were unaffected by the bug that plagued a lot of users.
    Aside from that I´m also very happy how this thread turned out so far. There seems to be some sort of community spirit that I´m missing often lately on XDA, people help each other and there´s a friendly constructive atmosphere. Big thanks to @roirraW "edor" ehT who constantly pops up here and helps other users and everybody else contributing one way or the other too.

    I´m giving my best to reply to questions in a timely manner, at least as timely as my time allows, so it´s great to see this thread evolving over time and everybody helping each other. Thank you all for that and keep it up.


    Alright here´s the next update then. :) There were only very minimal changes to this kernel in the January Source drop, but I managed to squeeze out two builds before I have to leave for work. :)

    The mechanism that prevents small tasks to cause frequency spikes is now tied into the powerhal. That means when interaction is needed (app launches, camera launches, interaction) this mechanism is toned back as the device gets boosted anyway.
    In all other cases the mechanism now gets more strict to prevent frequency spikes, videos, audio, navigation etc.

    Next release will probably have a few more very interesting changes that are currently under testing so stay tuned. Didn´t think google would drop this before Monday.

    Several other improvements are included as well. More details in the changelog.
    Download is below.
    Updated instructions in the OP!


    Changelog:
    - January Source update merged
    - linux-stable 5.10.91
    - use latest google prebuilt clang 14.0.1 for compilation
    - improvments from kernel/common
    - tie "prevent frequency spikes caused by small tasks into the powerhal"
    - add latest CleanSlate features and updates (huge thanks to @tbalden, if you enjoy these features maybe buy the apps from the playstore to give a bit of support :) )
    - other changes please look at my github


    Download:


    Instructions can be found in the OP! Please follow the instructions to avoid any issues.
    If you´re coming from another kernel restore stock boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img before flashing. Thank you.
    25
    Update to 1.4.0

    Hey guys and girls,

    Alright here´s the next update and it´s a really big one. There are several significant changes in this release.
    Please read through the whole post to understand the changes.

    Flashable kernel.zip
    I decided to ship the kernel now as a flashable zip. (thanks to @eng_stk and @osm0sis)
    I was hesitant to do this at first, since vendor_dlkm is part of super. That means it´s no ordinary partition, which is the reason vendor_dlkm needs to be flashed in fastbootd. Luckily simply dd´ing vendor_dlkm does still work as a bandaid on a running device, until we find a way to "properly" flash vendor_dlkm to super. But for now that way works and is sufficient. What´s more important, I couldn´t cause havoc when I tried.
    That means no more flashing via fastboot. The kernel can be flashed via EXKM or FKM app. Due to ramdisk in vendor_boot being different on Pixel 6 (oriole) and Pixel 6 Pro (raven) there are two seperate zips now.
    That means this project is now completely like I envisioned it in the beginning. The prior release missed several improvements that ended up in the kernel modules, which sit in vendor_boot.img.
    Since we´re flashing all four images now, module verification can be enforced and I don´t need to force load the kernel modules from the stock vendor_boot any longer.
    Flashing the kernel.zip will preserve root.
    Shipping the kernel.zip will allow for easier flashing and for several other changes to be installed when flashing the kernel.zips, which also brings us to the next change.

    Flashable kernel.zip - AK3 Helper Module
    The kernel.zip flashes now all four images that are related to the kernel. boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img.
    Alongside the kernel.zip a magisk module called AK3 Helper Module will be flashed. It will show up in magisk manager after the reboot following the flash of the kernel.zip. Do not delete this module, it ships a modified powerhal, which is an integral part to the changes in this release.
    The powerhal will also restrict CPU-Freqs when the screen is off to save battery during e.g. music/podcast playback.l
    If you used the old powerhint module, please remove that before flashing the kernel.zip.

    Improvements to the Scheduler/Powerhal - Pelt Multiplier
    Next big change, the pelt multiplier. This commit allows to change pelt half-life during runtime, instead of choosing before compilation as was the only way in the past.
    Straight from the documentation:
    prompt "Utilization's PELT half-Life"
    default PELT_UTIL_HALFLIFE_32
    help
    Allows choosing one of the possible values for the PELT half-life to
    be used for the update of the utilization of tasks and CPUs.
    The half-life is the amount of [ms] required by the PELT signal to
    build up to 50% utilization. The higher the half-life the longer it
    takes for a task to be represented as a big one.

    If not sure, use the default of 32 ms.

    config PELT_UTIL_HALFLIFE_32
    bool "32 ms, default for server"

    config PELT_UTIL_HALFLIFE_16
    bool "16 ms, suggested for interactive workloads"
    help
    Use 16ms as PELT half-life value. This will increase the ramp-up and
    decay of utlization and load twice as fast as for the default
    configuration using 32ms.

    config PELT_UTIL_HALFLIFE_8
    bool "8 ms, very fast"
    help
    Use 8ms as PELT half-life value. This will increase the ramp-up and
    decay of utlization and load four time as fast as for the default
    configuration using 32ms.

    Default is 32ms, however this value was changed for example by @kdrag0n on the pixel 5 kernel to 16ms to improve performance. The downside of this approach is, that this needs to be chosen at compilation time, and can´t be changed during runtime. choosing 16ms or lower can lead to higher energy consumption and less battery life, but also better performance.

    The inclusion of the pelt multiplier, together with an edited powerhal allows this kernel now to change pelt half-life depending on workload and interaction while the device is running. If there are certain events like interaction (scrolling, touching the screen), app launches, camera launches, taking a picture the pelt half-life will get changed dynamically. Interaction will result in 16ms half-life while app launches and camera usage will result in 8ms half-life, resulting in a performance boost when performance is needed.
    If there´s no interaction happening, half-life will bump back to default 32ms as to not waste battery.

    Improvements to the scheduler - Prevent frequency spikes caused by small tasks
    uclamp can cause frequency spikes, by small very frequently occurring tasks (such as binder ), as was identified by a few vendors already. The following commit from the ARM-Developers aims to improve this situation.

    BFQ-IO Scheduler
    BFQ is now on par with linux-mainline as those changes were backported

    TCP - Improvements
    A series of patches was backported for the commit mentioned by this article. It can be found in my kernel tree here

    F2FS-Stable Improvments
    Latest F2FS-Stable was merged and tested extensively.

    Several other improvements are included as well. More details in the changelog.
    Download is below.
    Updated instructions in the OP!


    Changelog:
    - linux-stable 5.10.84
    - kernel/common merged
    - ship kernel as flashable zip
    - ship complete gki kernel (boot, dtbo, vendor_boot, vendor_dlkm)
    - include powerhal module in the flashable zip
    - mainline backports to the scheduler
    - introduce pelt multiplier and tie it into powerhal
    - prevent frequency spikes by small transient tasks
    - tcp backport from mainline
    - bfq backports from mainline
    - f2fs-stable included
    wakelock blocker
    - please read [URL="https://arstechnica.com/gadgets/2018/08/p-is-for-power-how-google-tests-tracks-and-improves-android-battery-life/"]this for further info
    don´t use this to block any kernel wakelocks you think keep the device awake, most are needed for the device to properly function!
    You won´t know about missed notifications until it´s too late. Random other issues might be introduced by blocking wakelocks.
    This is only intended for use cases like, wifi at work causes endless wakelock and the IT admin says, screw you I won´t update the firmware. In that case this might be the only option for your device to sleep.
    - other changes please look at my github


    Download:


    Instructions can be found in the OP! Please follow the instructions to avoid any issues.
    If you´re coming from another kernel restore stock boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img before flashing. Thank you.
    21
    I´d appreciate if we could keep anything "drama", non XDA-related and other topics that are not at all related to the topic of this thread, out of here.

    I´m not really interested in comparing my kernel versus "other kernels". I´m also not really interested in reading comparisons no matter the outcome of the comparison.

    I´m doing all of this during my free time, because I enjoy doing it and share what I´m personally running with everyone here on XDA.
    There needs to be no "rating" of those hours I spent working on my projects as they´re completely free of charge.
    I assume the same is true for others that work on similar projects too.

    If you appreciate the work, drop a thanks, write a few friendly lines, maybe consider a small donation, participate in the thread, report bugs in a proper manner if you encounter any, be friendly and helpful or contribute to the project here as all the source code is up on github.


    Everyones usage differs, everyone has unique usage patterns. So just try what´s available and choose what suits you best and be glad there are options for this device.