Develop Bugs

[DEV] Fixing/Updating the HD2 kernel and missing code

Please stay ON TOPIC to kernel DEV and missing code. Don't report every bug the Android build your using is having or it will be deleted as OFF TOPIC
As you all might be knowing that hd2 is pretty much a android native device now. Its just like any another snapdragon device. The current kernel code we are using in HD2 is pretty obsolete and missing a lot of things. It more like something working at its minimal efficiency. While i was porting over all the HD2 board files getting it on par with the other snapdragon devices I found out a lot of code was missing and some was obsolete. Eg. The gsensor code from microp was pretty minimal, a lot of things were missing in microp code. I suspect that it isnt the only code, a lot of bluetooth related stuff was missing and much more. I am not really gonna work on backporting the stuff to .32 kernel so i would like the kernel devs here to backport the stuff to the .32 kernel so a lot of bugs can be fixed and stuff can be made more stable until the .37 kernel is ready. All the commits can be found here
https://github.com/charansingh/cm-kernel/tree/master
There might be some bravo or passion instances in there cuz i am comparing the code with these two devices and taking what is necessary and sometimes i have to leave my work due to some other work and forget which file i was working on so would appreciate the more bugs.
Also Mods can we get this a sticky so we can track the progress here

Yap.. i'm not a really pro developer but i suspected those bugs before.. finally a real developer suspected that.. eager to see who's going to help fixing them

charnsingh_online said:
Also Mods can we get this a sticky so we can track the progress here
Click to expand...
Click to collapse
Ok sticky for the moment to see if it helps.

@charnsingh_online
I am really happy that you put so much power in this project big respect for that.
The reason for the missing code is because most of the drivers are reversed engineerd from winmo by cotulla. Wich make it possible to make working android parts but they don't work optimal by that. Also we miss some skilled active coders. After cotulla almost everything is created by markinus he did a incredible part big credit to him but looks like he isn't that active anymore..
Current development are mostly little things a guy who sees a little part from that and a little part from that like : you, tytung, darkstone, gauner,letama, the guy from the bluetooth fix.
We probaly don't have so much real kernel programmers because they buy a native linux / android phone.

The last two major things left with HD2 Android are buggy speakerphone and missing assisted-gps function.
Speakerphone mode is not usable because mic gain does not change when speakerphone is enabled. Info here:
http://forum.xda-developers.com/showpost.php?p=12698204&postcount=22
GPS works but without assistance so most locks take 1 minute instead of like 15 seconds. Info here: (please read all 25 pages)
http://forum.xda-developers.com/showthread.php?t=1008252

memin1857 said:
The last two major things left with HD2 Android are buggy speakerphone and missing assisted-gps function.
Speakerphone mode is not usable because mic gain does not change when speakerphone is enabled. Info here:
http://forum.xda-developers.com/showpost.php?p=12698204&postcount=22
GPS works but without assistance so most locks take 1 minute instead of like 15 seconds. Info here: (please read all 25 pages)
http://forum.xda-developers.com/showthread.php?t=1008252
Click to expand...
Click to collapse
actually i think the gpu drivers are kinda unstable when comparing to the performance of other phones that carry the similar gpu...

@charnsingh_online
Good start.
After reading the github commits, I still don't understand what kernel devs can do so far.

Just see the microp stuff I added to the file. Also I have updated the board files. See wats the difference between the files. A lot of updated code

hi charansingh,
i am willing to help, but i think it would be helpfull to define packets to take over.
By looking in the kernelsources it looks good to me, but i know from own expiriences with porting that i have to look deep...
best regards
trilu

charnsingh_online said:
Just see the microp stuff I added to the file. Also I have updated the board files. See wats the difference between the files. A lot of updated code
Click to expand...
Click to collapse
It's better to start/clone from pure CM 2.6.37 kernel, then add new commits when adding any new functions.
Would you please add a new commit when adding a new function?
Otherwise, it's very easy to lost the way in the source code.
A commit "Update some board files" doesn't tell the whole story. I want to know why to change.
Comparing the source code manually and guessing its function is not convenient for any kernel devs.
For me, I won't add any code in my 2.6.32 kernel until I know the meaning of the changes of the source code.
Thanks.

Ok I'll do it tomorrow n also maintain the list in the op

I may be wrong, but this thread is not supposed to become a bug fix request thread. It is aimed at developpers, so that they collaborate on a merging of HD2 specific stuff onto a cyanogen 2.6.37 kernel...
This would most likely result in the resolution of a lot of our issues, but in the mean time, [DEV] in the thread title means it is for devs only......

Keep this thread clean please.. there are only a select few devs who actually work on kernels around here. Let them use this as a way of communication to generate a complete kernel, then we can test it for bugs.
Very excited about the prospects of this, if you guys get a working kernel with all the new commits shoot it over and I'll test it out on one of my HD2's.

I looked pushed code and it's ok, at least for first few commits. But it needs some deep cleaning an optimization, also there is some bravo naming convention used in leo specific files. You should put this tree on gitorious so we can do more work on it, but anyway i will clone tree and do some cleaning and porting new stuff.

This could be of interest, and not too much off-topic.
This kernel: http://forum.xda-developers.com/showthread.php?t=966786
is being abandoned and it had some patches for performance that I think are valuable. It had linpack scores that can be achieved only with heavy overclocks on other kernels... The problem is, the source is being distributed by a .zip, no commits, nothing... the only way to get those would be to issue a diff with... something and guess where they are. Staying on topic, I've already adapted cm-kernel for another device so I think I'll be able to help when I get enough free time to spare.

D4rk50ul said:
Keep this thread clean please.. there are only a select few devs who actually work on kernels around here. Let them use this as a way of communication to generate a complete kernel, then we can test it for bugs.
Very excited about the prospects of this, if you guys get a working kernel with all the new commits shoot it over and I'll test it out on one of my HD2's.
Click to expand...
Click to collapse
Yes you are right. Unfortunately many threads like this one get's filled with off topic chatter, complaints etc. I will try to keep my eye on this thread so the dev's can communicate. If your not contributing to the DEV work on the HD2 kernel's, please don't post your wishes and thanks post as this will quickly clog up the thread. I'd hate to lose progress due to this. That's why many DEV's end up not using XDA and reverting to IRC only. Thanks
noellenchris

Hi,
Few days back there are some conversation about libsurfaceflinger.so for color banding issue http://forum.xda-developers.com/showthread.php?t=1012278 . Since Rom is changing continuesly with libs can we port the change for color issue.
HD2 GB-2.33-SENSE-2.1 LOCKSCREEN SENSE-3

tytung said:
It's better to start/clone from pure CM 2.6.37 kernel, then add new commits when adding any new functions.
Would you please add a new commit when adding a new function?
Otherwise, it's very easy to lost the way in the source code.
A commit "Update some board files" doesn't tell the whole story. I want to know why to change.
Comparing the source code manually and guessing its function is not convenient for any kernel devs.
For me, I won't add any code in my 2.6.32 kernel until I know the meaning of the changes of the source code.
Thanks.
Click to expand...
Click to collapse
tytung, has any1 of you done so? please let us know..

g30rg10u said:
tytung, has any1 of you done so? please let us know..
Click to expand...
Click to collapse
No, I didn't work on 2.6.37 kernel so far.
I didn't see that charnsingh_online added a TODO list in the OP.

Fried my laptop charger. New one on way. Hd2 arrived

[PROJECT][KERNEL] Join your efforts for HOX kernel development

I already saw a lot of kernel developers here, each of them posting their own version.
I don't think that "download sources / fix them / apply patches" by every one of them is ok.
If all could focus on a single source-tree and fix / apply patches to that we would get to a stable/improved version a lot faster.
I can provide a linux machine for the developers interested by this project.
Hardware: 2 x Xeon X7550, 16GB RAM (can be extended to about 60GB), 300GB of storage (can be extended) - RAID6, FC dedicated storage.
Example:
$ time make ARCH=arm clean
[...]
real 0m2.479s
user 0m0.953s
sys 0m1.151s
$ time make -j32 ARCH=arm CROSS_COMPILE=arm-eabi-
[...]
real 1m4.720s
user 19m11.694s
sys 3m23.190s
Click to expand...
Click to collapse
Software:
Slackware 64bit 13.37, gcc 4.5.2, gcc-arm 4.6.1
OS can be changed if you have good enough arguments.
SSH access, no root.
If any developer is interested by an account, pm me with the desired username.
Have fun!

Ok, if no one is interested, I have to start this alone...
BETA
First release - ALiCE Kernel - with patches/tweaks from eternity/franco/bricked kernels and some of my own. Everything seems to work on my HOX.
- Sweep2wake included
- modules built in kernel, no need to flash anything else but boot.img
Attached:
zImage - for including into your own boot.img
boot.img - InsertCoin 5.3.0 boot.img with this kernel.
DELETED ATTACHMENTS - Kernel was virtually unusable.
You can use zImage injector ( http://forum.xda-developers.com/showthread.php?t=1647398 ) to update your own boot.img

I like the idea of this collaboration of kernels.
And I like how the modules are integrated into the kernel.
I'll be testing this out more tomorrow with a battery test for a work day
Keep up the good work
EDIT:
3G Does not work.
As in it shows 3G/H on the top, but no network connectivity.
WiFi does however work.

Great
I'm not a kernel dev, but this seems like a good idea.
Kernel devs working together to create a solid/stable base kernel.
If they want to add specifics they can always release one aside of this.
Also good to integrate modules into boot.img
Keep up the good work.

+1
Good idea, and go on
Good work.

Well I build kernel in 1 minute on i7 920 @4.2 ghz, no need for you machine ;-)
But common git would be nice.. I have zero time to maintain a kernel for HOX
Sent from my HTC One X

It will be nice if we can have a common github repository for the OneX sense kernel with all the patch applies by the devs.
AliceXES, do you have a git link of your repo ?
Because I currently compiling the franco's repo with some config tweek for my own need. And I would like to compiling yours just for testing.
Anyways, thanks for starting your project

Please send me your twitter account it's for helping you

The biggest problems ain't hosting or building times, just version-control. A common Git would be nice, although it seems most changes get picked by eachothers at github.

What about a GitHub organisation? You can have free ones where everyone is admin if you leave the source open. But then that requires a certain level of trust I suppose, heh.

The problem was with modules - for some strange reason, 3G doesn't work with them built-in the kernel.
Also my laptop crashed. The 2nd HP 4520s dead in my hands.
I will probably won't work on this anymore until it's repaired.
Still, if anyone needs access to the compile-server, the offer is still open.

AliceXES said:
The problem was with modules - for some strange reason, 3G doesn't work with them built-in the kernel.
Also my laptop crashed. The 2nd HP 4520s dead in my hands.
I will probably won't work on this anymore until it's repaired.
Still, if anyone needs access to the compile-server, the offer is still open.
Click to expand...
Click to collapse
Sad happenings. Hopefully it'll be fixed soon so you'll be back on track!

1: 3G problem indeed lies in the modules (linked to one of the binary baseband module)
2: getting collaborators won't be easy; many (apart from a select few) of today's "chefs" (dare not call them devs) prefer to act alone, get the credits, instead of working together, where the progress would've been much faster. This has been discussed too many a time on xda.
It is so much easier to rip someone's work & claim it as your own... Which is why many a dev resorted to "protecting" their roms (for example, from dumping).
Another reason why not many would like to join you, is that then it would come apparent that they don't have any real skills, since they won't be contributing any patches. ;]

Why compare ROMs with Kernels though? Maybe I'm unique at this, I don't know but, I never really cared about moving files around at ROM level or building AOSP ROMs. I prefer the kernel-space just a bit more
If people are afraid that their commits get stolen (which unintently happened just a few days ago, it seems) they should sign-off it properly.
Ányway I'm always interested in collaborating. Atm I'm just foring Franco's kernel and fixing a few compiling warnings.. I think what we really need is one main-maintainer which holds the master-branch, then the rest of our bunch just can push commits to him for reviewing. Who this lad is going to be, is also a tricky one.

I don't think I will have any success with this project
I started my own kernel thread (here: http://forum.xda-developers.com/showthread.php?t=1662781 ), sorry.
Anyway, the invitation is still open.

[Q] Kernel Source

I've been around these forums for over 6 months now, and we've all been anxiously waiting for the source code of ICS kernels. Everyone always says that it's not the OTA we want, but the kernel source. Even I have been really excited to get it... but recently I've been wondering... why? What exactly does the kernel source allow us to do? I'm not a developer by any means, but from the limited knowledge I have, these are the features the source will allow us to do:
- OC/UV without having to use Tegrak
- Custom kernels
What else? This post isn't mean to criticize or anything... I'm just genuinely curious how the kernel source will help us on ROMs. If you know anything, please post.

Kernel source gives us the opportunity to add a variety of things like:
OV/UV
More/different CPU Governors
A variety of I/O Schedulers
Different kernel modules
Support for more/different filesystems
And the big one we are hoping for with GSII is a fix to that dang ICS recovery bug! :/

MandaNick said:
Kernel source gives us the opportunity to add a variety of things like:
OV/UV
More/different CPU Governors
A variety of I/O Schedulers
Different kernel modules
Support for more/different filesystems
And the big one we are hoping for with GSII is a fix to that dang ICS recovery bug! :/
Click to expand...
Click to collapse
Thanks for the informative response. Yeah I was gonna mention the superbrick bug but I think developers found a workaround using TWRP and Agat's recoveries these days.
Sorry for being a noob, but what are different kernel modules?

Hahaha don't be sorry man, we are all noobs in some way! They did find a workaround for it, but they are also not sure that their workaround will work in 100% of all use cases. If you read their first post there is some worry about "super wipe" packages over-riding their safe binary.
A kernel module is a piece of functionality written after the kernel is compiled. It is compiled into what is called the module, and then loaded into the kernel. This allows developers to add bits of functionality without having to rebuild their whole kernel.

The kernel is like the motor that helps our phone run. When tuned properly, it will purr, give us good gas mileage and make the driving experience more enjoyable.
Sent from my SPH-D710 using XDA

Hahaha well that's one way of putting it! The kernel sits in-between the hardware and the software, and essentially enables them to interact together. I guess you could call it the middle-man, putting things into a language both the application's and then hardware itself will understand

Source code is the map to put the engine together correctly. Given enough time a dev might be able to build the kernel from scratch, but what's the point of driving yourself mad like that. Right now it's like they're tinkering with a demo engine but can't be fully sure that they're putting the parts in the right place.

It's more like all the parts to put the correct engine for your device together(The map would be the make files ). Right now they are using different parts from various different engines to try and assemble one that works for our "car".

Haha thanks for the responses. I forgot about this thread for some reason but I'm back to give you guys thanks And yeah I know what a kernel is heh but just the basics... I know basically next to nothing about development of kernels at least

Since is up I will add the all important to some of us reason. CyanogenMod9. I always knew I would one day ditch Samsung firmware for CM9 but i didnt know our phone would get it so soon. Once we have kernel source our developers will be able to write a proper CM kernel easier than it has been for developers like sbrissen to do one from scratch. Once that is done we can get rolled into official CM releases.
Other than PRL updates I am never going back to Stock firmware.

[ROM][5.0.2/LRX22G][AOSP][LINARO/OPTIMIZED] FML: Fork My Life (2015/01/08)

[#Intro]
Oh, and now there's these Lollipops I'm handing out. They are free as always, and they are very very delicious.
[#Why]
[#Info]
I need people testing and finding bugs if anything is going to be fixed. I might not have the Bluetooth devices you have, I might not use the camera as much as you, I might not use mobile data as much as you; you get the idea.
NOTE: FML is built and tested on the Verizon Galaxy Nexus variant, also known as toro. The GSM Galaxy Nexus variant (the one pertaining to the forum section you're currently in), also known as maguro, is extremely similar in hardware to the Verizon Galaxy Nexus, however I'm not able to test these builds personally. There aren't any code changes between builds for toro and maguro so that I know there shouldn't be any huge issues, but things specific to maguro I'll need feedback on to make sure they're working OK.
[#HowTo]
Latest Build​KitKat/ROM Stable: omni-4.4.4-20140705-maguro-FML.zip (159.07 MB)
KitKat/TWRP Stable: fml-twrp-2.7.1.0-20140705-maguro.img (8.58 MB)
KitKat/ROM Beta: omni-4.4.4-20141015-maguro-FML.zip (160.13 MB)
KitKat/ROM Beta Hotfix: boot.img (4.83MB)
Hotfix Info: The latest beta had a bug on maguro causing the radio to be a jerk and not work. Flashing this boot.img will resolve that issue. If you'd rather not flash it with fastboot like is normally done for .img files, you can use the Flashify app for it, or you can open up the ROM zip and replace the boot.img in there with the hotfix.
Lollipop/ROM Beta: FML-AOSP-5.0-20150108-maguro.zip (194.45 MB)
LOLLIPOP INFO:
USE THESE GAPPS: FML-GApps-5.0.x-20150101-tuna.zip (167.81 MB)
They are based on PA's GApps, huge thank you to them!
Known Issues:
- Camera can be a little touchy, but it generally works.
- Long SMS messages fail to send, fix is on-the-way though.
Lollipop Changelogs can be found in the post below!
(KitKat) BETA INFO:
Beta builds are using updated GPU drivers (and an updated kernel to go with them) courtesy of @Ziyan, as well as being up to date with the latest stuff from OmniROM. NOTE: YOU CANNOT FLASH A DIFFERENT KERNEL WITH THESE BUILDS.
Currently broken with the new GPU drivers:
- Hardware Video Decoding FIXED 2014/10/06
- Hardware Video Encoding(?) FIXED 2014/10/08
- Camera (PARTIALLY) FIXED 2014/10/08
- The stock camera app (as well as Google Camera) has this weird quirk of crashing when pressing the shutter button to take a picture, however many different camera apps on the Play Store (in particular Camera ZOOM FX) work flawlessly. Video recording is generally OK, however I've been getting some reports of the audio and video being a little out of sync, so your mileage may vary...
See the Changelog post below for..... well..... changelogs.
[#GApps]
Known Issues​- The screenrecord command does not work directly, however it does work via the Power menu.
- There can be a slight (noticeable, but not huge) delay when pressing the Recents or Home button.
[#Thanks]
[#Donations]
XDA:DevDB Information
FML: Fork My Life, ROM for the Samsung Galaxy Nexus
Contributors
MWisBest
Source Code: https://github.com/MWisBest/
ROM OS Version: 5.0.x Lollipop
ROM Kernel: Linux 3.0.x
Based On: AOSP
Version Information
Status: Beta
Stable Release Date: 2014-07-05
Beta Release Date: 2015-01-08
Created 2014-05-27
Last Updated 2015-01-08

Changelog, News, Etc.​
Lollipop Beta Changelogs:
2015/01/08
- Updated the camera HAL.
This is going to be a little... fragile, at first, but in the long run it's needed. Stock camera app saves pictures now at least.
You may also notice that there's a 5.1MP resolution now (clear your camera app's data if you don't see it), despite our camera supposedly being 5.0MP all these years. Turns out the sensor's native resolution is indeed a whopping 16 pixels taller and 16 pixels wider than we've been using.
2015/01/04
- Added back some of the classic FML optimizations and more.
Built with -fstrict-aliasing flag, C++11, and the Linaro GCC 4.9 toolchain.
- Updated to AOSP "android-5.0.2_r1" tag.
As usual, the only real change was them bumping the version number.
- Improved flashing.
The speed of flashing the ROM zip is now much faster.
- Superuser is now built-in.
There's no need to flash SuperSU. You can find Superuser in the Settings app. You may have to enable the "Development Settings" menu to see it.
Some apps are a little sketchy with this Superuser though, most notably Titanium Backup. If you have issues, try flashing SuperSU.
- Video playback should be fixed.
YouTube in particular seems OK. If you have some weird format you're playing back locally I cannot make any guarantees though.
- The camera situation has improved and also regressed.
The stock camera is kinda back to the point of where it was with the KitKat Beta builds:
---- Preview works. Saving photos does not work. Video recording kinda works.
--- However:
---- The camera calibration is a little messed up. Long story, but it'll be fixed soon. So your white balance may look kinda funky, among other things.
- Audio quality is improved, with support for 192kHz FLAC as well.
This is possible thanks to a new audio resampler, which doesn't impose the same sample rate restrictions of the stock Android ones. It also has far better quality than the stock Android resamplers.
- WiiMotes can now be paired via Bluetooth.
I used to be a bit of a Wii hacking enthusiast... I think I still need to add some more stuff to make it useable as a gamepad or something, but yeah.
- Fixed location services issues.
- (toro) Fixed switching between 4G/LTE and 3G/CDMA network settings.
- Kernel changes:
Reclaimed 38MB of RAM from the carveout stuff.
Removed HDMI's framebuffer, saving an additional ~16MB of RAM. With Lollipop, MHL/HDMI out isn't working with our old HWComposer, so might as well save some RAM in the mean time.
Added overclocking support, as well as adjusted the stock frequencies a little.
Added the GPU kernel driver back into the kernel, rather than building it as a separate module.
Switched to LZO compression for the kernel. It results in a slightly larger size to the kernel, but it boots faster.
Added the "purple tint fix".
Added compiler flag to tune code for Cortex-A9 CPU.
Built with Linaro GCC 4.9 toolchain.
(v3): Fixed VYL00M eMMC bootlooping.
Older Builds:
2014/11/16
- Fixed the RIL.
There were a few things that went into this, and I can't really take much credit for it other than being persistent in trying to fix it.
1. rild needed a little fix-up to somewhat return it to pre-Lollipop form. Basically Google is forcing Qualcomm's junk upon the world. @dhiru1602 pointed me in the direction of some commits from rmcc to hardware/ril that fixed this part of the problem.
2. The kernel needed a commit to support some new junk related to networking in Lollipop. @Ziyan linked me to the change in question.
- Updated to AOSP "android-5.0.0_r6" tag.
Really the only change is that the build number is bumped to LRX21T.
- Switched out a couple small proprietary binaries with a reverse-engineered open-source version.
Thanks to @stargo who has really been killin' it for the Motorola OMAP devices recently, we now have a reverse-engineered pvrsrvinit binary (the executable that fires up the GPU drivers on boot-up). This is especially important because the proprietary pvrsrvinit wasn't compiled as PIE (position-independent executable). With Lollipop, they're forcing everything to be PIE, which is good because PIE is better from a security stand-point. Previously I had been adding a workaround to enable support for non-PIE, which I now don't need.
- Built the ROM with "WITH_DEXPREOPT" set to true.
This basically just adds the ".odex" files to /system. With ART this is important because it cuts down on those lengthy boot-up times because instead of compiling the apps' code on the device, it now compiles it on my computer when I build the ROM instead.
- Changed the "Android is upgrading..." screen to prevent burn-in.
Rather than use Lollipop's eye-hurting bright white theme on this screen, I've switched it back to the classic, darker theme.
2014/11/09
- Switched back to the old OTA package format.
With Lollipop they're now, by default, flashing something similar to a system.img. I switched back to the old format. THIS IS CAUSING VERY LENGTHY FLASH TIMES NOW HOWEVER, I HOPE TO FIX THESE SOON.
- Changed the kernel to build with GCC 4.7.
With Lollipop, Google switched to GCC 4.8. GCC 4.8 has never been kind to the Galaxy Nexus kernel, I'm surprised it was booting at all in the first place... or not, for some people. I'm fairly confident this should fix the VYL00M eMMC issue.
- Added "Ambient Display".
Apparently I need to add a "pick-up" or "significant motion" sensor for it though, so it displays something when the phone is picked up.
- Fixed chromium crashing.
This fixes Browser crashing upon open, among other things. This fix has been in chromium itself for nearly 4 months now, I don't know what the heck Google is doing to AOSP to make it so FUBAR lately...
- Fixed lag in Recents menu.
Now it's smoother than KitKat's, in my opinion.
- Added back F2FS support.
F2FS is now supported again, HOWEVER, it is NOT supported on the /system partition. It really didn't do any good for /system anyway.
- Updated various icons.
The Dialer icon in particular was bothering me. Other things that aren't visible in the launcher, e.g. SettingsProvider, have been fixed as well.
- Fixed FLAC playback, among other media decoding issues.
Just needed a sync-up in the device tree with one thing that I think Google DID do a nice job of with Lollipop actually.
KitKat Beta Changelogs:
2014/10/15
- Cleaned up the kernel.
Ziyan went over all his work not long ago and cleaned up the commit history and whatnot. He's letting me do the task of merging in the GPU driver stuff, so I'm currently just getting the kernel to a "clean slate" of sorts for other kernel devs to fork and build off of. Basically this should hopefully be the new "stock" or "Google" kernel. As a result, there's some bells and whistles missing from this build. It does however include some new audio updates that weren't in the previous kernel, which leads me to this...
- Changed audio sampling rate to 48kHz.
Previously the sampling rate has been 44.1kHz. The Galaxy Nexus supports 48kHz though! Here's what mainly sparked this change: since KitKat, the UI audio effects (e.x. touch sounds) have been switching over to 48kHz. With the Galaxy Nexus still using 44.1kHz, UI sound playback became kinda sluggish, and this was a big contributor to it. The UI sounds use the "fast track" audio path (where it tries to do as little processing as it can to the audio in order to play it with a minimum amount of latency), however a requirement of using this is that no resampling (e.g. converting 48kHz to 44.1kHz, like it has been doing currently with KitKat) can be required on the audio being played. Therefore the UI sounds were taking the "deep buffer" audio path, which has a delay to it. In switching to 48kHz, the "fast track" path is actually even faster now than it has ever been previously, and the Galaxy Nexus was already TOP OF THE LINE when it comes to audio latency believe it or not!
Another thing about this is that there is now support for playback of 96kHz audio files.
- Some updates to the camera HAL.
This hasn't fixed the situation of stock and stock-based camera apps crashing when taking a picture, but it's a start on it though.
NOTICE: Poweramp (and probably most other media players that use their own native code for audio playback rather than straight-up using the built-in Android APIs) is being pissy about the sampling rate change. If you experience issues with music playing, especially things like popping or crackling, please try Play Music or Apollo and see if your issue is still present. I know the UIs for Play Music and Apollo are pretty awful, but I can't write my own media player because I'm dealing with this camera stuff!
KitKat Stable Changelogs:
2014/07/05 (Operation: Streamline)
ROM: Synced with OmniROM's latest changes as of around 6:30 AM 2014/07/05 UTC.
ROM/Build: Fully updated to AOSP 4.4.4 (specifically, the android-4.4.4_r1 tag), which really doesn't change much though...
ROM/Build: Stopped including the unused (as far as I can tell) dock.png in /system/vendor/res/images/dock/
ROM/Build: Leveraged a feature added to updater-script creation by OmniROM which coincidentally makes the ROM flashable on any format of /system partition, beit F2FS, EXT4, exFAT, whatever.
ROM/Build: Stopped including Voice Dialer. Voice Dialer is just an unpolished piece of junk which really isn't used ever since Google Now.
ROM/Build: Stopped including 0xBenchmark.
ROM/Core: A number of changes added for completely seamless and simultaneous F2FS and EXT4 support.
ROM/General: Switched to the Android KitKat boot animation, which takes up nearly 4MB less space than OmniROM's boot animation.
ROM/General: Used OptiPNG heavily on numerous things in an effort to save space.
ROM/Kernel: Added F2FS support, nearly 500 commits were merged in for this.
ROM/Kernel: Relaxed BIGMEM a bit to hopefully fix Camera crashing for some users. (Only a 4MB difference BTW)
ROM/Kernel: Optimized CPU L2 cache settings slightly.
TWRP: Added support for seamless and simultaneous F2FS and EXT4.
I'm forgetting a number of things and I'm not going into as much detail on some of this as I'd like to. Frankly, I'm exhausted. Maybe I'll expand on this tomorrow. Maybe.
Oh I also submitted 8 things to the OmniROM Gerrit. One has been merged so far, the others probably will probably be merged in the next day or two.
Older Builds:
2014/06/05 v2 (Operation: Chocoholic)
ROM: Synced with OmniROM's latest changes as of around 10:00 PM 2014/06/05 UTC.
V2 just fixes a bug where Dialer would crash upon entering the Call Log.
2014/06/05 (Operation: Chocoholic)
ROM: Synced with OmniROM's latest changes as of around 7:00 AM 2014/06/05 UTC.
ROM: Fully updated to AOSP 4.4.3 (specifically, the android-4.4.3_r1.1 tag).
ROM/Build: Removed some duplicate alarm and notification sounds in my never-ending effort to slim down the build size.
ROM/General: A few things were added to accommodate building for the Kindle Fire HD 7" that might spill over into the Galaxy Nexus builds (no harm, if anything an improvement).
Wanted to get an Android 4.4.3 build out ASAP, so this build doesn't have much in terms of changes/fixes from myself. This weekend I'll be going on vacation, and after I get back I'm planning on adding F2FS support finally. :good:
BTW, you might want to make sure you have the 4.4.3 GApps.
2014/05/31 (Operation: Jackpot)
ROM: Synced with OmniROM's latest changes as of around 11:30 PM 2014/05/31 UTC.
ROM/ART: Pulled in some things from AOSP's master branch to hopefully decrease initial boot-up time for ART.
ROM/Build: Fixed some more instances of code being compiled/optimized for a generic ARM CPU instead of the Cortex-A9 specifically.
ROM/Build: Included some requested translations.
ROM/Build: Found a fix by PrimeDirective to build frameworks/base/core with -fstrict-aliasing.
ROM/Dalvik: Pulled in some things from AOSP's master branch to increase overall speed for Dalvik.
ROM/General: Fixed a bug where overclocking would revert when the screen was turned off.
ROM/General: Added battery charging LED support.
ROM/General: Fixed notification LED flash interval being way too long by default.
ROM/General: Experimental improvements for GPS. (See: GitHub Commit)
ROM/Kernel: Added the "purple tint fix" commit.
ROM/Settings: Fixed Settings not being translated.
Quite the changelog here! ART is feeling a little snappier in this build but Dalvik might still be faster!
2014/05/26 (Operation: Maguro)
ROM: Initial maguro build.
After the great number of improvements I made in the most recent build I did for toro, I figured it was perfect timing to get maguro up and running.
If you'd like to have a look at the toro stuff, it's here: http://forum.xda-developers.com/devdb/project/?id=1098
Let me know if there's any issues!
To-Do.​Slim down the build by putting less used stock applications into a separate flashable .zip, such as Browser.
Experiments I'm Looking Into​Creating Black Holes with my phone's ridiculously awesome speed.

Developer Info​This is a little section I'm gonna set up explaining things in more technicalish and "down-and-dirty" details of sorts for developers interested in this project and potentially incorporating it into their projects.
The only thing I ask is to make a little "Thank You" section in your main post like I have here and credit at least me and Linaro, and also credit anybody else's work I have used if you use it as well. I'd also appreciate it if you could maybe link my name to this thread or my user profile here on XDA, but that part isn't a requirement.
All of my work can be found on my GitHub. Please note that any commits on my GitHub that are after the most recent build of FML should be considered experimental and potentially not working at all. I develop on the fly and often times things on my GitHub aren't finished and fully tested unless they have made their way into an official build of FML.
Please pay no attention to where it says a repository was forked from. Often times I'll have forks that I just re-use to avoid duplicate and unnecessary extra repos. For example, in repos forked from CyanogenMod you might notice the default branch is actually something like "omni-4.4" indicating that branch is based from OmniROM and not CyanogenMod.
The best place to keep track of what parts of the Android source code that needs patches is the manifest.
All About Strict Aliasing!​One of the big things Linaro does with improving Android's performance is fixing violations of what's known as "the strict aliasing rule."
A pointer is said to alias another pointer when they both refer to the same location of memory. This is OK and not an uncommon thing to do. The strict aliasing rule is that pointers of different types should never refer to the same location of memory (aka alias each other). Things like this are just fine and dandy:
Code:
void pointlessFunction( uint32_t foo )
{
uint32_t* const bar = (uint32_t*)&foo;
}
That's alright, as foo and bar are the same type. Note that it's also OK if the only difference between foo and bar is signedness (e.x. uint32_t and int32_t).
Now this...
Code:
void anotherPointlessFunction( uint32_t foo )
{
uint16_t* const bar = (uint16_t*)&foo;
}
...this is a problem. foo and bar are NOT the same type. This is a violation of strict aliasing.
Strict aliasing allows a compiler to make some assumptions when compiling and optimizing code that it otherwise couldn't. This is a good read about the benefits of it.
Here's a few examples of fixing strict aliasing violations:
DSPManager
frameworks/av
bionic
Note that not everything is fixable, or worth fixing. Sometimes you'll just have to add -fno-strict-aliasing to the problematic section and call it a day:
frameworks/base
Of Unicorns and Compilers...​This section will delve into compilers and flags for them. The "Of Unicorns" part is in reference to the amount of false information, misconceptions, and mythical beliefs regarding these things. One thing in particular is the common belief that throwing every flag possible at the compiler results in better/faster binaries. That couldn't be further from the truth, and is something that actually took me quite some time to properly understand myself (in part because the misconceptions are more common than the actual truth!). In this section I will mainly be referencing the GCC compiler, as that's what is currently used for the majority of Android and most Linux systems as a whole. The other compiler that is making quite a run at GCC is Clang, so first I will talk about GCC vs Clang quickly:
GCC vs. Clang
GCC is currently (~May 2014) the most common compiler used for Linux and Linux-based systems (which includes Android). GCC was first released in 1987, as the "GNU C Compiler." Not long after its release, it was extended to support C++ as well, and over time many different languages and platforms became supported by GCC so it is now called the "GNU Compiler Collection." Over all this time, GCC became more and more difficult to maintain. As time passes on, fewer and fewer people have been able to get their foot in the door to work on GCC as it just became so... bloated.
Eventually, somebody finally got the guts (or resources, rather) to take on GCC and make a competing compiler. Clang was born.
Clang is a front-end for LLVM. Initially, LLVM was going to make use of GCC's front-end for making a C/C++/etc. compiler using LLVM's back-end, however this was just too cumbersome of a task due to GCC's difficult-to-work-with codebase, which was what sparked Clang instead.
Fun fact: Clang 1.0 was released in 2009. It was first open-sourced in 2007. That's 20 years after GCC's inception, but yet Clang has managed to tear GCC's usage apart. However to be fair, LLVM's initial release was 2003, but that's still a decade and a half head-start given to GCC!
As of GCC 4.8 vs. LLVM/Clang 3.4, it's kind of a toss-up between the two. In some cases GCC has better binary results and in other cases Clang has better binary results, however Clang outshines GCC in areas other than the resulting compiled code:
1. Clang is faster and uses fewer resources than GCC when compiling. It's usually a safe bet that Clang is going to be at least 50% (1.5x) faster than GCC when compiling, whilst also somehow using less RAM and disk space than GCC. For those of you that like being eco-friendly, just imagine the amount of energy this saves!
2. Clang has generally been ahead-of-the-game when it comes to supporting C++ standards. Current example: Clang has been C++14 feature-complete since the end of 2013, while GCC (even in 4.9!) is not.
Thanks to the competition from Clang, GCC has also been stepping up its game as well too. All-in-all this has been a win-win for everybody so far.
Flags.
Aaand here we go on compiler flags. For this I'll be referencing the GCC documentation on "GCC command options", here: https://gcc.gnu.org/onlinedocs/gcc/index.html#toc_Invoking-GCC
Of particular interest in this section will be "Options That Control Optimization", but other sections are often overlooked which can be of use, I'll explain those later though.
The first thing you'll see in the "Options That Control Optimization" section are the -O options. These are general optimization levels that give you a sensible default to work with.
First off is -O0. This is the default, and doesn't turn on any optimization options. This is generally only used for debugging code, as some optimizations can interfere with that.
Next would be -O1. This enables some optimizations to reduce code size and improve speed, without increasing the time it takes to compile code significantly.
After that is -O2. This is what is generally used for most program compiling, as it enables plenty of optimizations and these ones generally don't cause problems/bugs with the resulting binaries whilst greatly improving speed.
Then there are some non-numbered ones which I'll go over:
-Os is somewhere between -O1 and -O2. It enables most of -O2's options, but disables some that can increase the size of the resulting binaries. This can be of great use when dealing with smaller embedded systems where space is generally preferred over speed. It's closer to -O2 than -O1...
-Og is useful for debugging purposes. It enables a few optimizations that generally don't effect ability to debug code, so devs don't have to deal with the slowness of -O0 as much as usual.
And then there's the almighty -O3...
-O3 enables some extra optimizations that -O2 does not. The drawbacks are increased compile time, increased binary size, and the possibility for some bugs. In many cases, -O3 might not improve speed over -O2 whatsoever. In other cases it can be helpful, but it is nothing compared to the differences between -O1 and -O2.
Android generally uses -O2 by default. It's safe and fast enough for most cases. -Os is also used for any Thumb instruction-set code for ARM, as Thumb is generally meant for reduced size and complexity from what I can tell.
There's also a flag kinda above -O3, which is -Ofast. The problem with -Ofast is that it can cause huge problems for any code that makes the (correct!) assumption about some math stuff, so it is generally avoided.
Then there are some flags that aren't enabled by any optimization level. This is not without reason: these flags are, generally, useless. They increase compile time by a ridiculous amount, and their effects on the resulting binaries might be absolutely nothing. Zilch. Nadda. Even for something as large as Android, these flags can still do nothing. If these flags can have a speed-up, it's generally not without risk, and they should be kept to specific use-cases rather than used on every single thing.
These flags can be considered about the equivalent of using the "placebo" profile for h264 video encoding. It has a less-than 1% improvement in the resulting quality, yet can take twice as long to render (or, in this case, compile). And they are pretty much exactly what the placebo profile for h264 encoding is, a placebo effect. You will not find a measurable increase in speed, and the risks associated with it are generally not worth it!
There is an exception to that though: -flto. This enables Link-Time Optimization, and can have huge impacts on both the speed of the binaries as well as even a reduction in their size! LTO can be viewed as this: when the compiler is truckin along compiling things, it generally only sees bits and pieces of the project at hand. LTO allows the compiler to view how everything works together rather than just each individual part, and in doing so it can find HUGE improvements! When LTO was in its infancy with GCC, it was pretty unstable, but with GCC 4.8 and above it can be used reliably. It's also advised to use the -fuse-linker-plugin flag when using LTO as well (read the docs on that).
Here is my work on using LTO with Android, it's more involved than simply adding it with all the other flags which is why you'll generally hear the people that are making use of the "unicorn flags" say it doesn't work...
https://github.com/MWisBest/android_build/commit/c1b041c32572b6ee1bbb17b1fa8c038c5e9fde1f
https://github.com/MWisBest/android_build/commit/95bb49b613424b70af3e820748724fb92ef35b5e
https://github.com/MWisBest/android_build/commit/d2c13f1c35cfa9c114a69c74cfb1c2631643eebc
Ignore the things in the last couple commits there that aren't related to LTO...
But like I said, it's more involved than just throwing the flags blindly at the compiler, there are a few other fixes required to get a successful build with LTO:
https://github.com/MWisBest/android_bionic/commit/3b3f59a173a7cc4ff3a1cec4456a99108ce08092
And then it also has to be disabled in ART, that fix courtesy of @metalspring : https://github.com/MWisBest/android_art/commit/9ed3774fcba75077e098720406d261b79bd9baa9
// To be continued.
Small but Helpful Things​I thought I'd put some simple little things here that can be immensely helpful to devs. Most of these they'll probably know already, but some won't and when I learned these things they had a profound impact on development. At the very least it can be a helpful reminder/reference sort of thing.
Properly Logging Builds
This is something I finally figured out not long ago that has had a huge impact on debugging problems...
I'm not all that great with bash but I generally understood redirecting the output of a program to a file. However, when I tried the usual:
Code:
make -jX otapackage > buildlog.txt
, not everything was going to the file. Eventually I learned that just using ">" only redirects stdout, and not stderr which was where all the warnings and errors went to. To get around that, there's a couple options. One, you can redirect stdout and stderr to separate files, like so:
Code:
make -jX otapackage 1> buildstdout.txt 2> buildstderr.txt
, or the other option is to just lump them all into a single file using:
Code:
make -jX otapackage > buildlog.txt 2>&1
This post is a WIP...

As you may or may not have read in the OP, this ROM was built and tested on the Verizon Galaxy Nexus only for about 9 months. I don't own a GSM Galaxy Nexus, so I'm not able to fully test these GSM builds, however the differences between the two are minimal and everything should work OK.
As the Verizon Galaxy Nexus is pretty much only in the USA, one thing I did to reduce the size of the ROM was to cut back on some of the translations. I've kept what I thought were fairly common languages (including outside the USA). Since I've now expanded to the GSM Galaxy Nexus, which is more international, there's a chance that a language you need might be missing. Please just let me know what you need and I'll be more than happy to include it.

Downloading....perfect timing...i am rom hopping for a while and excited to try this, skimmed last few pages of your toro thread :good:
why not take a look at the recent thumb flag optimisation commits that claimed 6x speeds recently...

You have written that you have built CM 10.2 FML version. Is it compatible with maguro? Where can I find it and flash it over my phone just to see it?

pvkiniyan95 said:
Downloading....perfect timing...i am rom hopping for a while and excited to try this, skimmed last few pages of your toro thread :good:
why not take a look at the recent thumb flag optimisation commits that claimed 6x speeds recently...
Click to expand...
Click to collapse
Yeah I replied to that thread... it's bogus, unsafe, and unprofessional. FML was far beyond that stuff since its inception and it has only gotten better since.
qtoo941 said:
You have written that you have built CM 10.2 FML version. Is it compatible with maguro? Where can I find it and flash it over my phone just to see it?
Click to expand...
Click to collapse
This right here is the first build I've done that's maguro compatible, and there's been lots of improvements since when this ROM was based off of CM so even if it'd work on maguro it's not really worth trying at this point. Sorry!

Wow, amazing, i was waiting for this! OmniMetal is a wonderful ROM but we can't except that metalspring will be doing regulary updates since he has a new phone.

This might be the quickest ROM my maguro has ever seen. I can't even believe how fast Chrome opens.

Downloading!
What do you recommend guys, Dalvik or ART?
I've been always using ART before and then I read replies in toro thread, most likely chooses Dalvik eh?
Thank you

ahmadairfan said:
Downloading!
What do you recommend guys, Dalvik or ART?
I've been always using ART before and then I read replies in toro thread, most likely chooses Dalvik eh?
Thank you
Click to expand...
Click to collapse
Only ART! Feel the smoothness

ahmadairfan said:
Downloading!
What do you recommend guys, Dalvik or ART?
I've been always using ART before and then I read replies in toro thread, most likely chooses Dalvik eh?
Thank you
Click to expand...
Click to collapse
pianistaPL said:
Only ART! Feel the smoothness
Click to expand...
Click to collapse
Dalvik! MWis pimped it the **** out!
MWisBest said:
I'm extremely impressed with ART and I know it's Android's future. They will not be including Dalvik in 4.5 based on what I'm seeing in AOSP's master branch currently. I don't think ART will be the default in 4.4.3, there's a number of changes they'd need for that to happen and at this point in 4.4's lifecycle I think it's too late for a major change such as that, but 4.5 and onwards it will be the go-to thing yes.
I'm also extremely happy with how fast Dalvik is in this last build though... here's my observations on it:
Going from a previous build to the new build (after running Dalvik on both), it feels as if I switched from Dalvik to ART but with a 10x faster bootup due to not going through all the ART compilation, not to mention the space saved over ART too.
After that experience, I think this whole ART thing might've been unnecessary or at least would've been delayed if Android wasn't compiled like it's the stone age.
Funny you mention the dalvik-cache thing, it's actually multi-threaded so it is indeed about a 2x speed improvement, nice observation.
Click to expand...
Click to collapse

Ok, end of speaking, phone charged, let's try this ROM!
Wysłane z mojego Galaxy Nexus przy użyciu Tapatalka
@MWisBest Can i let set DexOpt to /cache if i use Banks Core Gapps and i want change to ART?
---------- Post added at 03:29 PM ---------- Previous post was at 03:10 PM ----------
OK, i guess i can't, after boot with ART i get pernamently SystemUI FC So this is a good reason to try this super fast dalvik

pianistaPL said:
Ok, end of speaking, phone charged, let's try this ROM!
Wysłane z mojego Galaxy Nexus przy użyciu Tapatalka
@MWisBest Can i let set DexOpt to /cache if i use Banks Core Gapps and i want change to ART?
---------- Post added at 03:29 PM ---------- Previous post was at 03:10 PM ----------
OK, i guess i can't, after boot with ART i get pernamently SystemUI FC So this is a good reason to try this super fast dalvik
Click to expand...
Click to collapse
thanks for that...u saved my time

gonna flash this B*tch tonite! the changelog looks impressive. one question though do i need to flash the twrp recovery in the OP as well before flashing the ROM. Thanks!

Very fast on dalvik but phone gets mini freeze when i tap recent apps button and when i tap home button (when i have some app opened)
I haven't recent apps buttom freeze/lag only when i am on home screen.
Wysłane z mojego Galaxy Nexus przy użyciu Tapatalka

Hi MWisBest, could you please add Spanish language support for this ROM? I'm very impressed with your work, and I'd like to have it translated.
Thank you very much in advance!.
Enviado desde mi Nexus 7 mediante Tapatalk

ahmadairfan said:
Downloading!
What do you recommend guys, Dalvik or ART?
I've been always using ART before and then I read replies in toro thread, most likely chooses Dalvik eh?
Thank you
Click to expand...
Click to collapse
pianistaPL said:
Only ART! Feel the smoothness
Click to expand...
Click to collapse
osm0sis said:
Dalvik! MWis pimped it the **** out!
Click to expand...
Click to collapse
^What he said. At the very least give Dalvik a try.
pianistaPL said:
Ok, end of speaking, phone charged, let's try this ROM!
Wysłane z mojego Galaxy Nexus przy użyciu Tapatalka
@MWisBest Can i let set DexOpt to /cache if i use Banks Core Gapps and i want change to ART?
---------- Post added at 03:29 PM ---------- Previous post was at 03:10 PM ----------
OK, i guess i can't, after boot with ART i get pernamently SystemUI FC So this is a good reason to try this super fast dalvik
Click to expand...
Click to collapse
That sounds like the issue you'd run into with a GApps package that's too large, if you want to use a GApps package that large with ART you'll have to disable the DexOpt to /cache thing before switching to ART.
pvkiniyan95 said:
thanks for that...u saved my time
Click to expand...
Click to collapse
See above.
gautam_nexus said:
gonna flash this B*tch tonite! the changelog looks impressive. one question though do i need to flash the twrp recovery in the OP as well before flashing the ROM. Thanks!
Click to expand...
Click to collapse
The recovery build is not required, I just figured I'd start uploading them as 1. It's built automatically, and 2. I use it myself.
pianistaPL said:
Very fast on dalvik but phone gets mini freeze when i tap recent apps button and when i tap home button (when i have some app opened)
I haven't recent apps buttom freeze/lag only when i am on home screen.
Click to expand...
Click to collapse
I'll certainly have a look at that and see what's causing it. The Recents issue might be due to the code regarding if OmniSwitch should be opened instead of the usual Recents, as I'm not getting that lag with OmniSwitch enabled as Recents.
mosca_ said:
Hi MWisBest, could you please add Spanish language support for this ROM? I'm very impressed with your work, and I'd like to have it translated.
Thank you very much in advance!.
Click to expand...
Click to collapse
Crap! I do have Spanish included, but the furthest I had gone with testing that stuff was to simply make sure they were listed in "Settings --> Language & input --> Language", which does have Español listed, however I clicked on it now after your post and there are some things that are missing translations, most notably: Settings!!
The good news is that I recently figured out how to properly log my builds, and sure enough I've found some warnings about translations not being included, so I should be able to track down what's causing this and have it fixed for the next build.

MWisBest said:
^What he said. At the very least give Dalvik a try.
That sounds like the issue you'd run into with a GApps package that's too large, if you want to use a GApps package that large with ART you'll have to disable the DexOpt to /cache thing before switching to ART.
See above.
The recovery build is not required, I just figured I'd start uploading them as 1. It's built automatically, and 2. I use it myself.
I'll certainly have a look at that and see what's causing it. The Recents issue might be due to the code regarding if OmniSwitch should be opened instead of the usual Recents, as I'm not getting that lag with OmniSwitch enabled as Recents.
Crap! I do have Spanish included, but the furthest I had gone with testing that stuff was to simply make sure they were listed in "Settings --> Language & input --> Language", which does have Español listed, however I clicked on it now after your post and there are some things that are missing translations, most notably: Settings!!
The good news is that I recently figured out how to properly log my builds, and sure enough I've found some warnings about translations not being included, so I should be able to track down what's causing this and have it fixed for the next build.
Click to expand...
Click to collapse
Polish language doesn't have translated settings too So i'm waiting for new version, thanks

pianistaPL said:
Polish language doesn't have translated settings too So i'm waiting for new version, thanks
Click to expand...
Click to collapse
Thanks for the heads-up, looks like it's ALL the translations for Settings, dang!

[KERNEL] [Linux 4.4.127] [2018.04.08] Kang Kernel

Kang Kernel
About
First with my story, ~4-5 years ago in the GB/ICS/JB/KK era I used to work on AOKP, a ROM for Android devices offering a lot of features. As time went on, we all got a bit burnt out from the project, and stopped actively working on it (though if this sounds interesting, the ROM is still kicking with new developers). I worked on a few projects for a bunch of devices (HP Touchpad, HTC One X, LG G2, LG Optimus G, Nexus 4). After taking a few years off and working for an Android OEM, I got the development itch again and snagged a Pixel 2 XL, and wanted to run a kernel I built.
This is a kernel I built for my own personal use, and it will probably evolve greatly as time passes (right now it is not incredibly different from stock). My personal priorities are always battery life and responsiveness under heavy load conditions. I am a big fan of doing a quantitative analysis on various performance-related aspects of the system.
Features
Updated to Linux v4.4.127
Safetynet passing
kcal color control
Undervolted CPU steps
MAC address randomization
CFQ upstreamed to latest
CRC disabled
fsync disabled (user controllable)
Wireguard support
Support and Installation
This should be compatible with any AOSP/Stock 8.1-based ROM, though I have only tested this on the Stock 8.1 April security update.
To install this, flash the ZIP in TWRP.
I usually wipe my Dalvik/ART cache after I flash as well, so give this a go if you're experiencing excessive battery drain/other issues.
Download
Download here
Check the Downloads section of this post
Donations
I am not accepting donations for this, and I don't ever plan on accepting donations. If you would like to donate, please instead throw a couple bucks at the people listed in the "Additional Contributors" section, or donate it to a charity of your choice. I don't need money and I am simply releasing a kernel that I have built for my own personal use.
Thanks
nathanchance and the android-linux-stable project for providing a great updated base, and AnyKernel setup + being a great reference
flar2 for kcal color control
sultanxda for his Safetynet patches
franciscofranco/faux123/frap129/freak07 for other random patches
the original #teamkang for introducing me to Android development
Source
Source code
Uses kang_defconfig and the default AOSP gcc toolchain
XDA:DevDB Information
Kang Kernel, Kernel for the Google Pixel 2 XL
Contributors
rohan32, nathanchance, flar2, frap129, franciscofranco, faux123, sultanxda, freak07
Source Code: https://github.com/mathur/wahoo
Kernel Special Features: Linux v4.4.127, kcal control, Safetynet passing, Undervolted, MAC Address randomization, CFQ upstreamed, fsync/crc disabled, wireguard support
Version Information
Status: Testing
Current Beta Version: 2018.04.08
Beta Release Date: 2018-04-08
Created 2018-04-08
Last Updated 2018-04-08

Almost feel obligated to flash this. ?

akellar said:
Almost feel obligated to flash this. ?
Click to expand...
Click to collapse
Hahaha good to see you here buddy, been a long time

OMG I remember you from htc one x I think. This is amazing. Thank you good sir and welcome back.

Welcome @rohan32 :highfive:

Going stock on my replacement device tomorrow so I'll be giving this a whirl. Appreciate you sharing it and working on it. Sure do miss me some AOKP though

Nice to see you here! Kudos

How do I go from Flash kernel to this? I am on Android P stock.

trizzv said:
How do I go from Flash kernel to this? I am on Android P stock.
Click to expand...
Click to collapse
Assuming this works on P, I just flashed in twrp over flash kernel and it worked fine.

rohan32 said:
Hahaha good to see you here buddy, been a long time
Click to expand...
Click to collapse
Does this work on Android P?

Is there any reason you disabled fsync? I thought that can be potentially dangerous?

Yeah I m using it on P @trizzvt

dukat0s said:
Yeah I m using it on P @trizzvt
Click to expand...
Click to collapse
Thanks! Did you just flash over another kernel?
Also does wiping dalvik/art wipe memory?

trizzv said:
Does this work on Android P?
Click to expand...
Click to collapse
trizzv said:
Thanks! Did you just flash over another kernel?
Also does wiping dalvik/art wipe memory?
Click to expand...
Click to collapse
This might work on P, but I haven't tested it on P at all, and it doesn't include the latest updates from the P branch from Google, so there might be some compatibility issues (or might not, totally depends on the scope of the changes Google pushed with P that isnt present in the April security update branch, and I haven't gotten the chance to peek at those changes just yet ).
Wiping dalvik/ART caches does not affect memory, it basically just clears the cache that your phone builds over time launching these apps. Totally not strictly necessary though.
mykenyc said:
Is there any reason you disabled fsync? I thought that can be potentially dangerous?
Click to expand...
Click to collapse
Indeed, fsync flushes the file buffers contents to disk immediately, but incurs a small performance hit. With fsync disabled, the buffers are still flushed to disk, but just not as frequently, so there is a potential for data loss in some rare conditions, but most likely not. I definitely get someone's concern about disabling it though which is why you can toggle it via a kernel manager app .

Flashed this on my backup p2xl yesterday and the battery life has been great. I think I might move it over to my daily driver and give it a full run. Thanks!
@rohan32 - didn't you Dev for a some Nexus devices as well? I remember the name.

Great kernel. Really impressed with performance and battery life
Sent from my Pixel 2 XL using Tapatalk

piyush7243 said:
Great kernel. Really impressed with performance and battery life
Click to expand...
Click to collapse
This kernal is very good for battery life and smooth performance. Thanks to Mr Rohan for such nice kernal.

Nice so far. I just flashed over Flash. I was happy with Flash so I am sure this will be just as good. Kernel feels smooth, battery feels like it is improving, even slightly better intimacy at home which makes the wife happy. What a kernel!
Thank you @rohan32

@rohan32 i just flashed your kernel and fast charging doesn't work for me
I reported the same issue in flash kernel thread and @nathanchance figured the issue and was related to pixel having two different battery cells or like that and he fixed that.
Can you please update it?
Cheers ?
Sent from my Google Pixel 2 XL using XDA Labs

Thanks for the nice kernel. Love especially the mac randomation! Only thing missing is dtw. Would be great if you can add this gesture maybe in mai release.