# Whats a good kernel to flash



## searayman (Jun 10, 2011)

I am on the eos rom and am looking for some better battery life. What kernel do you suggest and what tweaks can i make?

Sent from my Galaxy Nexus using Tapatalk 2


----------



## Droidnutz (Oct 14, 2011)

I like the extra butter flavored kernels.... Oh wait.. you dont mean popcorn?


----------



## razorloves (Jun 7, 2011)

Topic moved. Please use development section for releases only.


----------



## kg2128 (Jan 1, 2012)

I have always used Leankernel because I really like the reliability and the battery life/features. Initially the 2 most popular kernels were Leankernel and Franco. Franco early on had issues with crashes/bricking depending on the rom you were on and the kernel version. Because of that I started with leankernel and never looked back. Both are good kernels though, and I heard faux's kernel is good too.


----------



## Forgottenhero86 (Nov 21, 2011)

I get pretty good battery life with Franco 220. I underclock to 1036 max and 384 max screen on settings with the lazy govern. I get through a 8 hour work day with about 60% with moderate to heavy usage. Popcorn is also really good too.

Sent from my Galaxy Nexus using RootzWiki


----------



## Jimmi3_T (Jul 14, 2011)

Imoseyon's Leankernel with Jake's Lean Tweaks!


----------



## searayman (Jun 10, 2011)

Whats a good app to use for setting profiles for clocking?

Sent from my Galaxy Nexus using Tapatalk 2


----------



## TheRoosevelt (Dec 30, 2011)

Trinity is my favorite. I get solid battery life and totally lag-free performance. You can't ask for more. Also, I like the color correction on Trinity a lot more than the yellow tinge of the other kernels, including stock.


----------



## ahjee (Dec 31, 2011)

Trinity kernel.
Best color you'll ever have on your phone.
Runs as smooth and stable as any other kernel if not, better.

Sent from my Galaxy Nexus using Tapatalk 2


----------



## BL4Z3D247 (Dec 17, 2011)

Honestly, the only way to find out what kernel will give you the best results is to flash them and test drive them for a few days. Every phone is different so what might work better for some will produce terrible results for you. For example, I heard great things about Trinity but I got random reboots so I went back to Franco's, although faux's gave me good results as well. If you notice high temps, reboots or bad battery life then flash another kernel, rinse and repeat until you find one your phone likes. Just passing down what I've learned over the years of flashing ROMs and custom kernels.


----------



## AndroidChakra (Apr 14, 2012)

Flash
Them
All

The one that works for your phone is the best one to flash.


----------



## CC16177 (Dec 29, 2011)

Since JB I have had the best luck with Trinity.


----------



## SuperChargedJ (Jun 15, 2011)

TheRoosevelt said:


> Trinity kernel.
> Best color you'll ever have on your phone.
> Runs as smooth and stable as any other kernel if not, better.
> 
> Sent from my Galaxy Nexus using Tapatalk 2


Flashed Trinity months ago and never looked back.


----------



## Joesyr (Feb 7, 2012)

BL4Z3D247 said:


> Honestly, the only way to find out what kernel will give you the best results is to flash them and test drive them for a few days. Every phone is different so what might work better for some will produce terrible results for you. For example, I heard great things about Trinity but I got random reboots so I went back to Franco's, although faux's gave me good results as well. If you notice high temps, reboots or bad battery life then flash another kernel, rinse and repeat until you find one your phone likes. Just passing down what I've learned over the years of flashing ROMs and custom kernels.


I hear people toe the "every phone is different" line a lot with respect to finding compatible kernels, but the only thing that I've ever seen cited as a kernel setting that causes reboots is undervolting settings. As in, people lower their set voltages incrementally until their phone reboots, then they know to set them above that. Smartreflex being sort of a game changer here in that unless you have a reason to disable it, it does this work for you.

I'm left assuming that something in the production process of processors leads to variations in which points a voltage drop will result in data interruption in the CPU sufficient to signal the system to shut down, and that part of the whole manufacturing deal is they identify the safe limits and that's how we get our stock settings, at which point nobody should see reboots.

I've never seen something described as a kernel tweak that itself will cause some phones to run too hot, reboot, etc, and other phones to do just fine. So I'm assuming that when someone says a kernel "just didn't work", that kernel uses more experimental default settings than others, and is a bit more advanced package in that you need to know what settings to tweak if some things go wrong. By comparison, some kernels must use relatively safe default settings, so the people that don't know what they're looking at will probably report it as being a "good one".

Then there is the aspect that every phone is different insofar as everyone runs different software which leads to different relative loads on the system, but I can only imagine this feeding into which settings you're using in terms of governors, enabled CPU freqs, and custom voltages. All of these things are settings variable within a kernel package, not necessarily aspects of the kernel itself.


----------



## MistaWolfe (Oct 10, 2011)

^^^^Not true at all.

I've had 4 Nexi in the last week. I tried my default kernel on all of them and one of them wouldn't run it for anything. Ran extremely hot and I could barely hold my phone. Flashed a different kernel (that my old Nexi couldn't handle) and it's my daily driver now.


----------



## Joesyr (Feb 7, 2012)

MistaWolfe said:


> ^^^^Not true at all.
> 
> I've had 4 Nexi in the last week. I tried my default kernel on all of them and one of them wouldn't run it for anything. Ran extremely hot and I could barely hold my phone. Flashed a different kernel (that my old Nexi couldn't handle) and it's my daily driver now.


Well your story sounds more like you're going through refurbs, and makes it sound like maybe these phones are just barely passing QC (or shouldn't be), and it's not that "all phones are different", just "some phones are more broken than others".


----------



## Helmdawg (Feb 6, 2012)

Anyone using trinity with AOKP milestone 6 rom?

Sent from my Galaxy Nexus using Tapatalk 2


----------



## Waffleninja (Sep 3, 2011)

Helmdawg said:


> Anyone using trinity with AOKP milestone 6 rom?
> 
> Sent from my Galaxy Nexus using Tapatalk 2


I'm actually just installed this. The colors are quite amazing.


----------



## searayman (Jun 10, 2011)

Right now I am trying the franco kernel. What is a good governor to run for good battery life?

Sent from my Galaxy Nexus using Tapatalk 2


----------



## Waffleninja (Sep 3, 2011)

searayman said:


> Right now I am trying the franco kernel. What is a good governor to run for good battery life?
> 
> Sent from my Galaxy Nexus using Tapatalk 2


Interactive, Interactive X or Hotplug X. Depends on what your phone likes better.


----------



## BL4Z3D247 (Dec 17, 2011)

Joesyr said:


> Well your story sounds more like you're going through refurbs, and makes it sound like maybe these phones are just barely passing QC (or shouldn't be), and it's not that "all phones are different", just "some phones are more broken than others".


No, all phones(G-Nexii) are different. I'll use motorcycles as an example, the guy I bought my Harley off of told me when he bought it his friend bought the same year, make and model from the same dealership on the same day and his bike never had problems but his friends was a mess from day one. Same goes for cars, electronics, pretty much anything. Nothing is made "the same". Yes we have the same phone(assuming you have a G-Nex) and the components are the same but some components have quirks. For example, my processor might be able to handle overclocking higher than yours or undervolting lower than yours. These default settings in a custom kernel were only tested by a handful of people before a release, this does not mean every G-Nex can handle them. Some G-Nexii will run a bit warmer than others even at stock because every component in the phone has it's individual thresholds. For you to say every phone should be able to run any kernel is like saying everybody should be able to run a mile in less that 5 minutes because you can. It doesn't work that way, even with electronics.


----------



## blaineevans (Jul 11, 2011)

^ What he said.


----------



## 808phoneaddict (Jul 6, 2012)

Forgottenhero86 said:


> I get pretty good battery life with Franco 220. I underclock to 1036 max and 384 max screen on settings with the lazy govern. I get through a 8 hour work day with about 60% with moderate to heavy usage. Popcorn is also really good too.
> 
> Sent from my Galaxy Nexus using RootzWiki


what is the lazy govern?


----------



## 808phoneaddict (Jul 6, 2012)

nevermind...found a good source to read about kernels - for other newbies....http://www.vikitech.com/8239/beginners-guide-android-kernels


----------



## yarly (Jun 22, 2011)

I like the stock kernel or CM's. I don't like a bunch of fancy, experimental features. Some people like that and like flashing every single day when there's a new update. I prefer only having to flash when there's a good reason (like a ROM has new features). Some features added are not really made for phones either (certain governors for example).

Many will not agree, but I think CM9's kernel is highly underrated. Sure it doesn't have something like fast charging, but they didn't put it in due to it deviating from the standards set for USB (allowing more than 5V charging). That's (fast charge) generally okay as most USB ports can handle that...unless you have a really crappy one that's not wired well and it shorts it out. That's the only reason they don't have it, but I like they think things through in a group consensus for things before they go and add a new feature versus tossing stuff in and seeing what doesn't work when users report back.


----------



## Tybaltus PRIME (Jun 7, 2012)

@yarly..

Dude I'm beginning to become a fan of ur posts..u just make sense .. that being said. Consider the dev that adds a feature and then uses the feedback of users to determine whether or not to maintain and fix or throw it out. Is this instance not similar to that of a group of guys testing features and making decisions on what to add and not... the differences really lie in just a couple of arenas - which mat not be too distinguishing given the knowledge base of the testers in the first scenario - cm is a group of devs so we can assume their testing goes beyond 'halp its broken', far beyond given the work speaks for itself. However, depending on the focus of the ROM you could potentially end up with a winner knowing that your community has already thumbs upped a feature. Additionally, this can add to the overall communal experience one derives from participating in the development and maintenance of their fav ROMS. This could also be achieved without sacrificing stability and performance if balanced in approach... just considerations ..to each their own always

Sorry for the off topic its late .. trinKERN FTW

Sent from my Galaxy Nexus using Tapatalk 2


----------



## yarly (Jun 22, 2011)

> Consider the dev that adds a feature and then uses the feedback of users to determine whether or not to maintain and fix or throw it out. Is this instance not similar to that of a group of guys testing features and making decisions on what to add and not...


This is going to be kind of long, but most of my posts somehow end up that way. I end up feeling like I'm leaving holes in explanations when I cut out parts. Technical stuff related to computers is too hard to just write a snippet about









To answer your quote from above I would say it's kinda like that to a point. It's a group and it's people testing. Some might even go into the deeper debugging the kernel for the developer. Most users though probably aren't giving the kind of feedback though that a developer really needs and it can get ignored. I think it's great that users help out a developer (since many kernel guys are just one person doing this). However, how quick they are to give useful feedback may or may not be as great. Most developers are indeed running their own stuff, but most developers are probably also only testing a semi narrow range of use cases, so in some ways maybe "crowd sourcing" is helpful and some ways it's not. I thing the signal to noise ratio with relying on the community to debug/test for you is worse, but you probably get of a wider range of cases.

Many users are not versed enough to also question all the features being added to a kernel. That's not wrong or anything as many do not want to sit here googling this stuff all day every time there's a change, but a developer can more or less toss in whatever they want and the likelihood that anyone will tell this developer, "Hey, are you sure this is a good idea putting this in here for users?" is lessened. Developers sometimes think they know everything (I know, sometimes it even happens to me, lol). If they think the other person is wrong, they'll just go and do what they want as they presume the other person doesn't know what they're talking about. The other thing that tends to happen is someone questioning a feature and some other user replying, "If you don't like the kernel don't use it." There is a fine line between what is complaining and what is questioning and suggesting, but usually one side or the other words things wrong and that user is ignored or reported for flaming/trolling when there was an actual issue (maybe he was maybe he wasn't). If a developer is working with fellow co-developers they talk to on a regular basis and consider collegues/friends, it's easier to talk to them and have a rational discussion about what is being added without anyone assuming another is negatively complaining.

On the other hand, if you have a small group of experienced developers and maybe a few highly experienced users thrown in, you get a smaller range of use case, but bugs are most likely quashed and found much quicker. That, plus what I already mentioned that you have the advice of more than one person with development experience for what should or should not go into the kernel configuration. However, at the same time, I would say that someone like CM, who tends to be more conservative on what they toss into the kernel, tends to have more predictable results, so maybe the wide range testing that many rely on is not so needed.

An Individual developer might also have a busy/stressful week outside of his Android Kernel hobby from work/family/etc. Stress can be a killer to concentration in development and maybe a bug or two might slip by that wouldn't if there were a couple other pairs of eyes looking at the code as well. Such things happen from my own experience and peer review of code can be a good way to verify. If you're the only one working on your project, those bugs are more likely to slip by and into the released code and thus users might experience issues that will have to be debugged before the next release.

Some features also look like a great idea, like fast charging. I think it's good and kind of sad that CM didn't go with it. I'm sure that my USB ports will work just fine. However, they just wanted to be safe and not risk having some user going off on them when their USB shorts out. I think that risk is really really low, but they felt as they support so many devices in so many countries that it was not worth it (that was the gist of their discussion on it in their gerrit).

On the other hand, you have features that look great and I think are horrible...like turning off fsync. Many kernel developers make it optional, while some force it on a user like Franco, who didn't even give users a choice to re-enable until a few weeks ago (whom many will go unaware of the dangers). Franco did not even tell users it was off unless you happened to look at his git repository on bitbucket. It's one thing to turn it off and tell users (and explain to them the dangers), but it's kind of a "dick move" to turn it off and not tell them at all. Any kernel that does something like that is not a kernel I would ever consider using.

It's a developer's choice whether they keep fsync enabled or not and turning that off and having your phone not shut down properly (because you had to do a battery pull or whatever), means your data is now most likely gone and not recoverable. Booting up and it'll most likely bootloop until you start from scratch (because it's possible your backups were also screwed). Reason developers add it I guess is because writing to the disk is slowww (much slower than reading as it has to verify that all data has been written to the disk before it all gets committed to it permanently). Turning off fsync turns off this safety check to avoid committing half written data to the disk (and thus stopping corruption). That's just an example of how a seemingly good idea can slip into a kernel without users being aware.

Overall, I think an individual can do a very good job on a kernel if they're careful about what they do, what they add and how they test. From following some of them the past couple years at times, some either feel pressured to do things that are experimental to differentiate their work from others or they push out new updates before they are ready as users keep asking for them. Some users go with a certain one because they added something specifically missing from another. If it's a useful addition that actually helps, then by all means, use it. Other users I think like the individual relationship they get with a kernel developer as they can ask them questions and get feedback easier. CM and of course Google seem far less reachable to most on the forums so it's hard to see changelogs on what is added or removed each version so some users might believe, "Oh, this can't be that good, I'm not really observing progress." It's really hard to make the Linux kernel "better," (at least performance wise) as what any of the forum developers do with one guy (or even a handful of guys with something like CM). Even to an extent, Google changes/additions are far less than what the Linux Foundation in general has done to the kernel over the years.

I know some ROMs also go with a certain kernel because they want to add features to the ROM and stock just won't do anymore. Those cases are also understandable, though I've never really liked a ROM having to depend on a kernel outside of their own control. Mainly just because of the disconnect between the ROM developer and the kernel developer that might occur. ROMs that just add some random kernel past stock because it's the ROM developer's preference without another reason, I'm not so wild about. It's not that hard to just make a user flash something else and generally it's harder for a user to go find the stock kernel instead.

In the end if you're looking for performance, they're all going to be more or less the same as long as the developer didn't make something worse. A developer can overclock the GPU and you'll probably get a few more FPS in games or your launcher at the risk of making the GPU a bit warmer (and shortening its total life a bit). The Nexus has a slightly weaker GPU so eventually doing so might be a good thing as it gets older. If you're looking for features one has over another, then I can totally understand why someone would go with whatever kernel, but just make sure those features are relatively safe . Google those features/changes if needed and ask questions if a feature seems odd in a changelog/update (but obviously do it in a polite way that helps both you and him).

My preference sides with features when they're stable and flashing only when I need to. I just want a phone that works when expected and not be stuck in a testing pool at the sake of staying on the bleeding edge of things. If you're a user that wants consistency, pick who builds your kernel well. There are most certainly more than just Google and CM that can. However, I can vouch that your phone will be stable and predicable if one uses those two without the need of constant updating.

Also, you can build the CM kernel and use it in other ROMs, so if you're not a Cyanogen ROM fan, it does not mean you cannot use their kernel elsewhere if you want something with more features than stock, but still favors being on the conservative side of development . If there's interest in having it, I can post it up for anyone to use as a standalone from the ROM.


----------



## Joesyr (Feb 7, 2012)

BL4Z3D247 said:


> No, all phones(G-Nexii) are different. I'll use motorcycles as an example, the guy I bought my Harley off of told me when he bought it his friend bought the same year, make and model from the same dealership on the same day and his bike never had problems but his friends was a mess from day one. Same goes for cars, electronics, pretty much anything. Nothing is made "the same". Yes we have the same phone(assuming you have a G-Nex) and the components are the same but some components have quirks. For example, my processor might be able to handle overclocking higher than yours or undervolting lower than yours. These default settings in a custom kernel were only tested by a handful of people before a release, this does not mean every G-Nex can handle them. Some G-Nexii will run a bit warmer than others even at stock because every component in the phone has it's individual thresholds. For you to say every phone should be able to run any kernel is like saying everybody should be able to run a mile in less that 5 minutes because you can. It doesn't work that way, even with electronics.


Well I understand your point but I think you're only agreeing with what I said, so far. I basically just gave the same example without analogy concerning undervolting.

Are there kernels that offer things like "overclocked to 1.5 GHz" as a feature, without any ability to change these settings? I only have experience with a few kernels and I use Leankernel as my daily driver. Partially because it's always been stable for me, partially because I think I learn a little here and there by following Imo's changelogs. And it seems like Imoseyon, for his work, collects reports like "latest exp makes the phone run hot/random reboots/etc" and will revert commits based on it. Do other devs basically develop along the lines of "it works on my phone, so if it doesn't on yours, this is going to be the last version you can use"? It seems like a strange standard to me, that a kernel dev's test phone's individual quirks will come to define what code they put into their kernel. If the actual kernel code will cause problems for some phones and not others though, I don't see how that couldn't be the case.

My point was more that it's the individual settings that all seem to be available across kernels that make some phones overheat/reboot/whatever. So if you flash one kernel and your phone starts rebooting, doesn't it make more sense to look at what the kernel's default undervolt settings are, and consider raising them? Or de-overclock the CPU if the phone is running hot? Without examples of static features of a kernel, not it's settings, I still don't buy the argument that it's ineffable whether a given collection of kernel code will "just work".

When you talk about flashing different kernels to find ones that work for you, are you going through and flashing the latest versions available for each, or do you only seek out named stable versions only? If you sift through these threads I think that a lot of them are used for active development, and reports of problems on the default settings may indeed lead to revisions and reverts in later versions of the kernel.


----------



## APeaceOfStrange (Jul 24, 2011)

yarly said:


> If there's interest in having it, I can post it up for anyone to use as a standalone from the ROM.


I'd like to give CMs kernel a go. 
Sent from my Galaxy Nexus using Tapatalk 2


----------



## Tidefan22 (Aug 13, 2011)

. If there's interest in having it, I can post it up for anyone to use as a standalone from the ROM)

I would also

Roll Tide!!!


----------



## Art Vandelay (Jan 4, 2012)

Try our Supa Dupa.

Sent from my Galaxy Nexus using RootzWiki


----------

