Video Tutorial on How to Compile Android and Modify Kernels


For those interested, I have just posted a video tutorial series on XDA for building Android Oreo, Nougat, Marshmallow, and Lollipop on 5 different phones, the emulator, and 5 different ROMs. Also included are custom kernel editing, adding apps, changing source code, backgrounds, and more. Here’s what I posted:

From XDA:


Praise God! Finally a video tutorial of how to build Android and modify kernels!

I have created a video tutorial and guide for how to compile Android, from Lollipop through Marshmallow, Nougat, and Oreo. The video series covers several different phones, the emulator, kernel and rom editing, app source code editing, and much more!

Who is this video series for?
Well, this video tutorial is a step by step guide built primarily for the beginner. This is written for those who already know how to flash TWRP, CWM, or the like, and who have installed a custom rom before. This is designed to help those who are ready to move up from flashing and installing other peoples custom rom to actually start making their own custom roms. I recommend that a beginner watch the entire series in numerical/alphabetical order (the videos are marked).

That said, I believe that an intermediate developer may find a useful trick here and there, and they should just skip ahead to videos of interest. Perhaps kernel development, or something along those lines.

An advanced rom/kernel developer will probably far exceed my feeble abilities, and will not likely find much useful information here. Perhaps if you are an advanced developer, you would consider continuing the tutorial or making an advanced video series! (See further posts for recommendations on contributing videos.)

Why did you put this together?
Well, after building roms for several different devices, I started receiving requests from users who wanted to start building their own roms, but didn’t know how. I didn’t have enough time to answer everyones questions, so I wrote a few guides, pointed others to guides that were available, but there are some things that you just need to see to understand. Hence, the video tutorial. I just hope that someone finds it useful.

This course was written in order! While Lollipop and Marshmallow are old by today’s standards, there is still good learning value in building them, and there are topics covered there that really make them worth watching.

What’s in the videos?
During the series, we will be building for the emulator, as well as 5 different phones of various brands, and 5 different roms. I hope that this will give the viewer a good idea of how to build for their own specific phone as they see the differences and similarities across the phones and custom roms.

+ Ubuntu installation
+ Java installations
+ Using Git, GitHub, GitKraken, and the command line
+ Fastboot and ADB
+ Heimdall/Odin
+ QFIL, QPST, SALT, and other tools
+ AOSP, SlimRoms, PACrom, AOKP, AOSCP
+ Lollipop, Marshmallow, Nougat, Oreo
+ Errors
+ Overclocking CPU/GPU
+ Adding Governors and I/O Schedulers
+ Sound modifications
+ Changing app colors, text, and icons
+ Adding prebuilt apps
+ Adding source code
+ Converting device from one rom to another

**** This is an UNOFFICIAL TUTORIAL. Use at your own risk! ****
Download links:
Ogg Vorbis Video GitLab:
Clicking on a video in GitLab will allow you to watch it online.

Ogg Vorbis Video Downloads:
This download is rather large due to the multiple videos.

MP4 Video GitLab:
Clicking on a video in GitLab will allow you to watch it online.

MP4 Video Downloads:
This download is rather large due to the multiple videos.

I also have several written guides available on XDA, here are a few:

Building ROMs for the Galaxy Note Edge: [url][/url]
Building ROMs for the Galaxy S4: [url][/url]


Be sure to check out the videos or the XDA thread! I hope that these will help some of the aspiring Android developers out there!

Linux – keep it simple.

Critical Velocity – an open source libGDX game that was crashing on small screens is now fixed!

Critical Velocity is a fun little open source arcade style scrolling game that I made after finishing my Android developer class. It was my first released game using the libGDX engine, an open source graphics engine that is great for making games. Due to my inexperience, however, I didn’t take into account that all screens are not created equal. Some screens are bigger than others, and some have lower resolution than the phone I built the game on.

This caused a problem. After releasing the game, I quickly was alerted to the issue through the GitHub issue tracker, where several players let me know that it was crashing on startup with their phones. It took a little bit of time to figure out, but I came to realize that the app was crashing on phones that were smaller than 800×480 screen resolution.

At first I thought there were all sorts of problems with graphic asset sizes, and memory issues. I tried numerous things to fix it, but nothing worked. Finally, I gave up. But, a few days ago, I decided to take another look. By God’s grace, this time I got it figured out! Before, I was working off of the information provided by people with smaller resolution screens, but I decided that I should load up the game in an emulator with a 320×240 resolution screen, and watch the logs. That’s when I found the problem.

The issue didn’t have anything to do with libGDX, the graphic assets, or the amount of memory the game takes (about 15 MB). As it turns out, the math just didn’t add up. Literally!

In the game, the upper and lower walls are separated by a gap. The size of the screen and the size of the gap is used to determine where the next set of walls opening can be (up or down) from the previous wall. The idea was that as you went faster, an opening at the top of the screen followed by an opening at the bottom of the screen is technically impossible to reach, so this math would keep it “near” the other opening within reason, but still allow it to be randomly placed, up or down from the previous one.

The math looked like this:

Place of the next wall opening = randomly based off of (1/2 of the screen height – the size of the gap) from the center of the screen.

This worked great on my test phone that had a screen resolution of 1920×1080. With the standard gap that I set of 450, the math looked like this:

Place of the next wall opening = randomly based off of (960 – 450 = 510) from the center of the screen.

But it didn’t work for a screen as small as 320×240 because:

Place of the next wall opening = randomly based off of (160 – 450 = -290) from the center of the screen.

For a random number, you can have a negative outcome, but you cannot put in a negative input. The random number is based on starting at 0, and create UP TO X random numbers. So if X is negative, then the random number generator doesn’t know what to do!

So I had to invent a way to fix this problem. Fortunately, that was easy. I used an if/then statement to ask what the screen size was, and then changed the gap size to be less than 1/2 of the screen size. I also had to edit a few parameters, such as thrust, speed, and distance also based on screen size. You can check out my code and commits here and here, if you’d like.

Long story short: Don’t make assumptions, check the logs and they WILL lead right to the problem! If I had run the emulator myself before, not having a small screen phone anymore, I hopefully would have seen this right away. Here are some screen shots of the game on different phones. Unfortunately, I still have a lot to learn to make sure that the game LOOKS the same on different sized screens, but at least now it doesn’t crash!

Linux – keep it simple.

A real GitHub client for Android!

GitHub. Android. They should be friends. At least, that’s what I thought. Yet time and time again, I was settling for less than fully functional GitHub apps. Sure ForkHub and other similar apps are great for BROWSING GitHub, but I wanted an app to actually CONTROL GitHub. Finally, I found one!


It’s called MGit, which is the sequel to SGit.

You see, the problem with the other apps was that they are basically browsers. Now, browsers are important. Without browsers, it is really cumbersome to deal with searching through GitHub. However, what I wanted was a way to have source code on my phone, and sync it with GitHub when I work on it. Particularly when working on Android app development.  That is where MGit comes in.

I can see why this may not be useful for everyone. I am making apps on my phone using the AIDE app. Then, I have GitHub code that I want to edit or sync. At the same time, I am also working on phone device trees to add/edit features, of which I also need to sync with GitHub. With the advent of better cell phones, and SD card slots, we can now have multiple gigabytes of data in our pocket. I want to leverage all of that, and to do it, I need a way to push/pull/commit/delete/etc., to and from GitHub.

Fortunately, that is just what MGit is made for.

It has a simple interface with very few aesthetic options. The material themes are Dark or Light, you can set your root storage location for your repos, and manage your SSH keys, username, and email address with which you access GitHub. That’s it. That is all the settings. However, I find that robust simplicity very appealing, because it leaves the focus on what actually needs to be done: managing your GitHub repos.

You can add new repos or import existing ones, all within a few clicks. It is very tidy and then, with a single tap, you enter that repo to start working. It has all the usual suspects, make a new branch, push/pull, stage, commit, merge, etc., that you would expect from a fully functional program that works with repos on GitHub.

Actually, I have been really impressed with this app, and I recommend it to anyone who actually works with GitHub from their phone. The only thing it lacks, is a browsing type of interface, like ForkHub, which I use to view and comment on repos. If it had that, it would be the only GitHub app I would use.

Linux – keep it simple.

How to add an I/O Scheduler to your kernel

How to add an I/O Scheduler to your kernel:

Praise God, another succesful addition to the TBLTE kernel was that of adding the FIOPS I/O scheduler to the kernel. What is an I/O scheduler? Well it is the part of the kernel that handles, or schedules, input and output. Particularly, this has to do with writing and reading to and from media, like your hard drive, flash drive, etc.

So, how do we do that? How do we add I/O schedulers to our kernel?

Well, for the TBLTE kernel, I will show you what I did, and you can add to your kernel similarly.

Go to the block folder in your kernel source. The first thing that you need to do is add the fiops-iosched.c file. Whatever I/O scheduler you want to add will be named like this: {NAME-iosched.c} you can search Google or github for them, or take them from my source if you would like.

Once you put your fiops-iosched.c file in your kernel’s ./block/ folder, you can now edit two other files in that folder. You need to add the new scheduler to the make file, so it knows to make it, you can do that like so:

Open ./block/Makefile and add this line after the other *-iosched.o lines:

obj-$(CONFIG_IOSCHED_FIOPS) += fiops-iosched.o

Notice that it just uses the name of the iosched file, but with an “.o” extension instead of a “.c” extension. The “.c” file you added earlier will create a “.o” (object) file that the Kernel needs to use to “make” the kernel.

Now edit the ./block/Kconfig.iosched file like so:

tristate “FIOPS I/O scheduler”
default y
The FIOPS I/O scheduler. WJH.

This way, when you are moddifying your configuration, you can select to build it. Notice that it is a “default y”, essentially, I am telling the config file creator to allways assume I want to build this, unless I choose not to. You can also eddit the “—help—” portion to say anything you want. I put my initials in there so I can find it easily with the search tool.

Now open your configuration file. For the stock builds, that would be ./arch/arm/configs/ap88084_sec_defconfig, and add this line:


Note that you could also do this through

[CODE]$ make menuconfig [/CODE]

You may also note, since we gave it a “default y” in the Kconfig.iosched file, we don’t actually need to add this to our configs, as it will be built by default, but I like to declare what I am building in my configs so I remember what I am doing.

There you go! Now when you build your kernel again, the FIOPS I/O scheduler will be added in. It is remarkably simple, just the way I like it. You can read the commit here: [url][/url]

Linux – keep it simple.


Adding a new I/O scheduler to your Kernel

In my continuing effort to learn about kernel modification, I was blessed to be able to add a new I/O scheduler to my kernel. To be honest, the ArcTeam kernel that I started with was already well equiped in the I/O scheduler department, but as this is a learning experience, I just had to add one more!

The kernel already included noop, deadline, row, cfq, fiops, sio, and bfq. There really were not many options left of what to add, and of the few that remained there was some ambiguity of quality. However, I chose the VR I/O scheduler, and got to work.

First, I added the new I/O scheduler to block/Kconfig.iosched, like so:

tristate “VR I/O scheduler”
default y
The VR I/O scheduler gives the best benchmark readings, but is
somewhat unstable/unreliable for daily use.

This makes it an option that can be selected when you are compiling the kernel, such as when using

[CODE]$ make menuconfig[/CODE]


Next on the agenda was adding it into the block/Makefile:

+obj-$(CONFIG_IOSCHED_VR) += vr-iosched.o

Note that the file here is an .o (object file) but the actual file we will add is the block/vr-iosched.c file. That is because the makefile needs the object made FROM the c file, not the c file itself.

Finally, we copy our block/vr-iosched.c file into the block directory. It is over 400 lines long, or I would post it here. Surprisingly simple! I like to keep things simple!

You can even check it out on my github at:

Linux – keep it simple.



As I continue to be blessed in the work of compiling roms and kernels, I have had to take a few new steps for me. One of those steps was Github. I am not very Github savvy, and I really struggled with how to push/pull/commit, etc. In fact, it was so daunting that I didn’t start posting source code and the like for my kernels or device trees, because I was unable to figure out how to make it work! Then I found a tool that actually made sense to me, Gitkraken.

Gitkraken is a program for your computer which allows you to easily work with Github repositories and files. Originally, I had forked an ArcTeam kernel repository for my personal edits, but I was strugling with the Github web interface. It was extreamly teadious to delete 30+ files, one at a time, online. Finally, I couldn’t take the web gui any more, and I began searching for computer programs that would make the interface easier. That’s when I found Gitkraken.

All I had to do was download the program from Gitkraken’s website: , and intall it like any other Linux program from the command line:

[CODE]sudo dpkg -i gitkraken-amd64.deb [/CODE]

Note that they do not maintain a 32 bit version for Linux. They do have older versions of Gitkraken that are 32 bit, but those versions I tried do not look or work anything like the current version. Fortunately, my computer is 64 bit, so this was not a problem. Gitkraken is available for Windows and Macintosh also.

In either event, opening the program brought me to a somewhat straight forward setup screen, to which I filled in all of my Github account information. After getting set up, I wanted to open my repo. Gitkraken works with local repositories, and can push/pull them to the online Github, so the first thing I needed was my kernel repository. So I downloaded the zip file from Github for my repository (you don’t need to download each branch, just the master worked for me). I put it in a folder I appropriately named “github”, and unzipped it. I then realized I could simply choose to clone repo, and download it in one fell swoop!

Once that was done, I then opened that repository with Gitkraken, and that’s where things got a whole lot easier! Things that confused me before were now made so simple to comprehend, as I could visually see what was going on. Want to make a pull request? Sure, there’s a button for that. Want to compare each commit and see the code that changed? No problem, just click on one. It was that simple! Need to create a new branch? Absolutely, just click the button!

What really made a difference, though, was how easy it was to edit my files. Essentially, I just used a regular browser, made edits in my “github/kernelsource” folder directly to the files. Then, when I opened Gitkraken, it automatically parsed the files and found all of the new changes! All I needed to do was click the “stage”, “commit”, and “push” buttons, in that order, and presto, my online Github repository was up to date with my new changes!

Finally, a Github tool that is made the way it should be! Sleek, smooth, easy, with lots of functionality, but none of the technical heartburn!

Linux – keep it simple.