I recently got the chance to interview XDA Senior Membereng.stk, developer of the blu_spark kernel. It’s available across many devices on our forums, including theNexus 5,OnePlus 3/T and the OnePlus 5T. In this part, we ask eng.stk about his origins in development and how he develops the blu_spark kernel.
I know people sometimes confuse blu_active with blu_spark. blu_active is just a small part compared to all of the rest [of the work] that I do.
The CPU governor basically makes decisions to make CPU frequencies go up or down, according to the needs of the system. The governor has had several changes and mutations since it started. Like everything else I do, I needed something that fulfilled my needs. It is based on my favorite governor, the interactive governor. At the beginning I just put some upstream stuff on it, but then I started adding some other stuff, like CAF updates or logic I had seen in other governors that I find useful. I also added HMP compatibility and some other goodies.
The latest iteration is based on Google’s Linux 4.4 Android branch, with some upstream and CAF fixes also, but much more leaner than before. Simply use what you have to the full, remove what you don’t. I always try to get better battery than with stock settings, reducing drain, while trying to improve performance (real life performance, the one that you feel with your eyes and fingers, not with synthetic tools).
At one point in time, I wanted a simple tunable so people could play around with performance in a simple way. This is how Fastlane was born :). The logic is somewhat similar to the way Honda VTEC works: play with timings from a given threshold. So, with a simple switch and a variable threshold value, people could have a more direct and aggressive cpu freq scaling. Making it enter sooner or later according to system load, bypassing target loads. It’s fully compatible with HMP and can be tweaaked per cluster according to people needs, finely tuned for each device it runs on.
Some userspace boosts and other tunables that are set in HALs (Hardware Abstraction Layers), hardcoded framework stuff etc, can sometimes be annoying. Of course, kernel developers are known to work around some of those On the Nexus 5, for example, most of us got rid of mpdecision and got a custom hotplug – we had blu_plug in place at the time. Some other devices had bad thermal management and a custom thermal control with sysfs for temp levels, mitigation frequency etc. Some more recent devices have some hard policies on battery, unplugging cores and other stuff in “low levels” that didn’t make a real gain in device usage. As a matter of fact, it even ruined user experience sometimes, so it was necessary to tame down CTL and BCL technologies.
I also remember removing encryption in devices when that was a thing, all the changes SELinux iterations introduced changes that made previous hacks done work in a different way… some recent Android security changes are a constant challenge. These include AVB (some parts mostly know as dm-verity). Some other changes have made restrictions for tunables and sysfs places that had to be moved because we don’t have access to the same places we had before. Most of these restrictions are more relevant for stock ROMs (in which I do most of my work), normally it paves the road and makes it easier when it comes to custom ROMs (where restrictions are lower).
In recent SoCs like the Qualcomm Snapdragon 820 and 835, some OEMs have added some boosts from userspace that are welcome and tackle blind spots in the system, not all OEM stuff is bad. When it comes to kernel source, the cleaner and more documented the source is, the better.
I own every phone that I develop for, so any changes are always tested be me. Since I daily drive every device for a long time period, anything I find not fit for me, shouldn’t be fit for anybody else. When I publicly release a build, it has already had lots of testing from me and some other people that I trust to provide useful feedback. I know sometimes some users get bored from constantly having all the things working like it should, but I value stability above all: I always put myself on the shoes of a user in the first place.
I run things towards a real life use case, not synthetic tests. This kind of software is made for humans, not machines in a back office. The start point is always better than stock experience, on all fronts, but I don’t really value the latest Antutu high score that much. My kernels can be tuned to this kind of benchmark, but it’s not my end goal. I do value some benchmarks that are more direct, like IO storage testing for instance. They can give a fast way to assert some changes recently done for example.
I do my testing with stock ROMs so that I can have a stable baseline for things. I do custom builds for custom ROMs, but due to volatile nature of custom ROMs with added extras, nightlies and even implementation difference on some features, it’s impossible to cover them all and give proper support to everybody, unfortunately.
I also sometimes build beta builds to test something specific or for when I launch builds to Beta ROMs or developer previews. I did that on the Nexus and OnePlus devices, people like to test stuff out sometimes