I recently got to interview flar2, the man behind the famous ElementalX kernel, and his even more popular ElementalX Kernel Manager application. He has released a version of his kernel for a vast array of devices, including OnePlus and Nexus devices.
In this part, we ask about flar2’s thoughts on Android performance bottlenecks and more about his personal life! You can check out part 2 of this interview here.
Hey there! Introduce yourself first of all before we get down to the questions.
My name is Aaron Segaert, also known as flar2. Most people know me as the developer of ElementalX kernel. I also have a few apps.
Had you any experience with computers and development beforehand? Like a computer science degree or something?
I started off with computers when I was very young. My first computer was a Texas Instruments TI-99/4A. I learned how to code in BASIC and saved my programs on a cassette tape (yes, I’m old). Then our family bought a 286 IBM clone, and I got away from coding at that point because this was before the Internet was widely known and I didn’t have any resources or even know anyone else who had a computer. I started computer science at university, but I flunked out in first year. I never really went to class because I was too busy having fun and playing gigs with my band. Later I returned to school and obtained a doctorate in sociology. During my time as a student, I became interested in Linux and open source but never got into much serious programming. I contributed minor bits here and there, but mostly just made scripts and small programs for my own purposes. I probably built my first Linux kernel around 2002. At the time, I wasn’t writing my own code, only experimenting with different patches and build options to boost performance. I was more into building computers, overclocking and generally trying to make hardware do things it wasn’t supposed to.
Has any development other than Android app development and kernel development interested you?
Not really, I’ve found good tools available for almost everything I’ve needed to do on computers. The reason I started working on kernels and apps for Android is because I felt there was a need for certain features and room for improvement on the existing tools. For example, I made Button Mapper because I wanted the home key on Samsung phones to do more, and I didn’t like the reversed back and recents keys. I made DevCheck because other system info apps didn’t show the info I wanted to see in a clear and concise way. ElementalX kernel adds new hardware features and EX Kernel Manager controls those features and adds some tools I use to make development easier. I like to solve problems and it’s a fun challenge to reverse engineer things or add new hardware features to a phone.
How did you come into contact with Android development, specifically kernel development?
I always hated cell phones and resisted them for a long time. My wife and I shared a basic flip phone with a minimal plan that was mainly used for emergencies. In 2012, we had a fire at our home and were out for almost three months. All our utilities were cut off, and we decided not to reconnect our landline, so we got a smartphone, which was an LG P-something I think. I realized it was like a mini-computer and decided I needed my own mini-computer, so I bought an HTC One V.
Since I tinker and mod pretty much everything, I immediately discovered XDA and found that not only did Android phones run Linux, they could be overclocked. I’ve been a Linux user for a long time, so I forked one of the kernels and was hooked. I soon got a cheap Acer tablet and started messing with that hardware and kernel because I wanted it to have USB OTG. Turns out the hardware wasn’t capable, but that’s how I started learning more about mobile hardware. I never publicly released a kernel for the LG, Acer tablet or One V, but built my own kernels for each and installed custom ROMs, which were necessary in those days, since Android was not yet mature.
I soon outgrew the One V and traded up for an HTC One XL and that’s when ElementalX was born.
What was the goal for ElementalX initially, and how has that changed in recent years?
The goal of ElementalX has always been to add useful hardware features, without compromising stability or performance, and release something that people can depend on to just work. I always put stability first because I need my phone to be dependable. No random reboots or things like the camera not working. The philosophy has stayed the same over the years. I keep things simple and add hardware features that I find useful. Things like wake gestures, high brightness mode, vibration adjustment, sound control, support for more filesystems, joysticks, etc.
I work hard to keep my kernels up to date, easy to install and as broadly compatible as possible. Some users are disappointed that I don’t add a lot of patches from CAF or upstream Linux, but my main goal is to deliver a very stable product with no weird issues. Many of my users are not people who post a lot on XDA, they are power users who have a specific need satisfied by a custom kernel, or people who occasionally like to tinker with their hardware but are not hardcore flashaholics. I want people who don’t follow all the latest Android developments to be able to use ElementalX without issue.
There are plenty of other kernels that experiment with upstream patches. In ElementalX, I use a carefully selected set of patches and optimizations. In my career outside Android, I measure things that are difficult to measure and use evidence to build policy and provide advice. I apply the same principles to kernel development and generally do not use patches unless there is a measurable benefit. The battery monitor in EX Kernel Manager is an example of this. It offers a way to objectively measure the effect of battery tweaks and kernel changes. The floating monitors in DevCheck are another tool I use for development, mostly for monitoring CPU frequencies and temperatures during different use cases like gaming or watching videos or web browsing.
How have changes in the last few years to Android affected your work?
Sometimes it’s difficult to deal with the many security changes, but I understand them. If I’m not mistaken, Android is now more widely used than Windows, which makes it a target. Bad people are going to use any angle they can to exploit Android users.
Preventing modification of the system partition is obviously key to protecting the integrity of a device. I remember when HTC starting doing this in 2012 or 2013 and it seemed like the end of the world. At the time, writing to /system was needed for root, editing build.prop, installing privileged apps, removing bloatware and practically every popular mod. Many of the customizations at the time involved things like deodexing and modifying the framework. For a long time, no kernel source was available from HTC, so I made a kernel module to disable system write protection in the stock kernel, for which I first became well-known as a developer. But over time, as protections like verity became a standard part of Android, it forced innovation and better solutions like Chainfire‘s systemless root and now there is Magisk that does all kinds of things systemless-ly.
Another big one is SELinux, which caused a ton of apps to stop working. Many users hated it and still to this day there are people who run with SELinux in permissive mode, which is a very bad idea. I would say SELinux is the single most important security feature of Android. To give an example of the importance of SELinux, when I first got the Pixel XL, there was no root available, but the Dirty Cow exploit was making news. I was eager to start kernel development, which means searching through or modifying sysfs files, which requires root. I compiled one of the Dirty Cow proof-of-concepts and was able to run commands as root, but SELinux prevented me from doing anything interesting. I had to modify the boot.img to make SELinux permissive. I might have achieved full access without modifying the kernel, but it would have taken many, many hours. All this to say, leave SELinux enforcing, it’s the main line of defense against malware. Learn to use sepolicy-inject to change specific policies as-needed.
When Nougat came along, initially almost all of /sys and /proc became invisible to user apps. Root has always been necessary to make changes, but suddenly root was necessary simply to read /sys and /proc. There is definitely information in those filesystems that can be used to exploit a device, so it was necessary to add restrictions. But there is also a lot of info that users should be able to see. Why should root be required to see the current i/o scheduler, or GPU frequency, or the type of panel hardware? I had to make a lot of changes to DevCheck to deal with this, and a lot of users were confused about why information was no longer available after updating to Nougat. Eventually, some of the restrictions on sysfs paths were lifted.
Other than that, from an app development perspective, I like most of the API changes to Android, even though they force me to make a lot of changes to my apps. These changes are usually for the better.
Check out Part 2 of this Interview!
from xda-developers http://ift.tt/2z9UnZs
via IFTTT
Aucun commentaire:
Enregistrer un commentaire