AudioPolicyManager.cpp:2240:65: error: member reference type ‘android::AudioMix *’ is a pointer

Well, that was a new one to me! I had just build LineageOS and Resurrection Remix for the XA2 Ultra, and now I got this error in the first minute of trying to build AOKP. Here’s the full error:

vendor/qcom/opensource/audio/policy_hal/AudioPolicyManager.cpp:2240:65: error: member reference type ‘android::AudioMix *’ is a pointer; did you mean to use ‘->’?
sp<AudioPolicyMix> policyMix = inputDesc->mPolicyMix.promote();
vendor/qcom/opensource/audio/policy_hal/AudioPolicyManager.cpp:2240:66: error: no member named ‘promote’ in ‘android::AudioMix’
sp<AudioPolicyMix> policyMix = inputDesc->mPolicyMix.promote();
~~~~~~~~~~~~~~~~~~~~~ ^
vendor/qcom/opensource/audio/policy_hal/AudioPolicyManager.cpp:2243:37: error: no member named ‘mCbFlags’ in ‘android::AudioPolicyMix’
&& ((policyMix->mCbFlags & AudioMix::kCbFlagNotifyActivity) != 0)) {
~~~~~~~~~ ^
vendor/qcom/opensource/audio/policy_hal/AudioPolicyManager.cpp:2244:77: error: no member named ‘mDeviceAddress’ in ‘android::AudioPolicyMix’
~~~~~~~~~ ^
vendor/qcom/opensource/audio/policy_hal/AudioPolicyManager.cpp:2265:39: error: no member named ‘mMixType’ in ‘android::AudioPolicyMix’
} else if (policyMix->mMixType == MIX_TYPE_PLAYERS) {
~~~~~~~~~ ^
vendor/qcom/opensource/audio/policy_hal/AudioPolicyManager.cpp:2266:42: error: no member named ‘mDeviceAddress’ in ‘android::AudioPolicyMix’
address = policyMix->mDeviceAddress;
~~~~~~~~~ ^
6 errors generated.

Ironically, the vendor/qcom/opensource/audio/policy_hal/AudioPolicyManager.cpp file is common to all three ROMs, Lineage, RR, and AOKP. So how is it that it fails on AOKP, but gives me no errors on Lineage or RR? As it turns out, there was a commit to /frameworks/av in Lineage and RR that was not performed on AOKP. You can take a look at the commit yourself if you’d like.

Essentially, you have a situation where the target ROM (AOKP) has dependencies mixed from the source ROM (LineageOS). Some of these dependencies were updated with the new code, and some were not, making a half done product that didn’t build. This is one of the problems when you are working on the latest versions of custom ROMs, is that there may be a few errors that are due to dependencies being changed.

So, there were two options for fixing this:

  1. Update /frameworks/av to match LineageOS.
  2. Rollback the changes in qcom’s audio policy.

The first is the most progressive, as the changes will probably come to that anyways, but it may require making other changes to more and more files. Just perusing the files looked like changing 10 files on about 80 different lines, but these may affect other files or lines as well.

That said, the simpler answer was to go with the second option and roll back the changes in the qcom audio policy. This only required changing about 6 or 7 lines in one file, which was much easier to accomplish.

If you look at the commit that made the changes, you can see the few lines that are edited to make this work properly. Fortunately the quick rollback fixed the issue and allows the build to continue.


Linux – keep it simple.

Engineering Pie Build for the Sony Xperia XA2 Ultra!

So it’s been a rough start for me, stepping into the modern world with a modern phone that has a/b partitioning and was Android 8.0+. I’ve built dozens of roms for dozens of phones, some that were even unsupported, and to God be the glory, I was moderately successful, but these modern phones have been a different story. My first attempt with the Xperia XA2 Ultra ended up hard bricked. Then, I built a pie version of AOKP, which did boot, but would immediately crash after getting to the home screen.

Today, however, was off to a much better start. I successfully tested my engineering build of LineageOS 16.0 (pie) for my XA2 Ultra (discovery). Everything seems to work well, and you are welcome to try it out. Keep in mind, though, it is an engineering build as opposed to a user build. Also note that this is for the 50.1.x firmware variants.

Granted, a lineage build is already available, and most of the work was done by Luke. I like to compile a build on my own, though, to make sure my system is set up properly and that the source material does work before I get started on my own roms.

Now to get back to that AOKP build…. Or should I start on a Resurrection Remix build instead?

Linux – keep it simple.

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.

Resurrection Remix 5.7.4 for the JFLTETMO

In my continuing quest to provide more roms and kernels for the Samsung Galaxy S4, T-Mobile variant, God has graciously blessed, allowing me to complete the latest addition of Resurrection Remix 5.7.4! Below you can see a link for the Rom and Kernel.

Resurrection Remix 5.7.4 JFLTETMO only.

AKLU-mm-jf-ResurrectionRemix5.7.4 kernel!
A kernel specifically built for RR 5.7.4! Can be flashed to any jf variant phone. Good for JFLTETMO, JFLTEXX, and possibly others!

-Lionheart and many other governors
-CPU overclocked to 1998MHz
-GPU overclocked to 487Mhz
-GPU/CPU voltage control
-Fast charge
-Psudo file system encryption support
-Fauxsound 2.1

Testers requested for AOKP 6.0.1 on the Note Edge, T-Mobile variant.

Testers requested for AOKP 6.0.1 on the Note Edge, T-Mobile variant.

Hi, I have built several roms for other phones, both personally, and shared here on my website, or on XDA.

The Note Edge N915T is getting pretty cheap to buy off of Swappa, Ebay, and Amazon, and I was thinking about picking one up. I am a dad, so I have to be frugal and stick with older/cheaper phones. I can’t afford to buy everybody in the family a new cell phone! As I save up a few bucks for it, I was thumbing through the forums and noticed that there were not many non-stock based roms available for it. So, I built one. By God’s grace it compiled after a few tries of error fixing. I would like to ask for any volunteers to assist me with testing it out.

The applicants would need a little bit of knowledge:

– Have a N915T variant
– Have TWRP installed
– Know how to make a backup
– Know how to wipe and flash roms
– Preferably be able to use adb (I can help with that)
– Know how to recover back to stock rom or TWRP in the event of a failure
– Know how to take screenshots/pictures (common sense is in fact a super power)

Essentially, if interested, click on the “contact” link in the bar at the top. Fill out the contact form with a valid email address, and I will email you a reply with a link to Media-Fire for the download and I would include instructions.

If it fails, well, you can just jump back into TWRP and restore your daily driver.

If it passes, I can  list you as an Alpha/Beta tester!

I never charge money for my rom work, I do not accept donations, so this is not a ploy to exploit cash from anyone. I just like building custom roms, and I am really interested in building one for this phone.


You can click on the “Homemade Roms” link above if you would like to check out some of my other work.

Linux – keep it simple.

How to manually update your custom rom source code with security updates

For those of you who compile your own custom roms directly using AOSP source, the latest security updates are always added in as soon as they occure. For those of us using custom roms, such as SlimRoms, AOKP, PAC roms, and others, this is not always the case.

Because the custom rom community downloads AOSP source, and then manipulates it to their needs/tastes, they cannot always directly integrate AOSP security updates. Some of these updates may not apply. Others, if unedited, may cause some features not to function.

For this reason, custom roms can sometimes fall behind, because one of the developers on that team needs to manually apply a lot of the fixes. This can be quite tedious. For instance, the libvpx security issue found in March of 2016 changed over 800 files. For the most part, the custom rom teams do a great job updating the security patches for the current version of their rom. The question is, what do you do to update the security patches of older versions of the roms?

This is actually a problem that I ran into with my build of SlimLP for the SGH-M919, T-Mobile Galaxy S4. I am mainting a current build of SlimLP for that phone, because the Marshmallow builds have some Bluetooth issues on these phones. Thus, users who still want to use Lollipop roms still need up to date security. But how do I fix this problem? The SlimRom’s team has moved on to work on Slim6, and there is almost no activity on SlimLP. Well, by God’s grace, I figured it out, and I thought I would share that here with you, in case you face a similar problem.

First, you could apply these same methods to all levels of security, however, since there are so many security updates, I have decided to only manually update my SlimLP source code with Critical security updates. Yes, that does mean that I am skipping the High, Moderate, and Low security threats. As I mentioned before, some of the updates are over 800 files, and that would be a new full time job for me, which I don’t have time for. So, hopefully, these Critical updates will strike the balance between keeping my rom users safe, and allowing me to still have time for important things like family, work, and sleeping!

The first thing I noticed as I started building SlimLP in May was that the security updates had stopped in February. After syncing in August, I found that the security updates had still not changed. You can verify in your source (if it is Lollipop or later) by looking at /build/core/, where you should see this line:

# Used to indicate the security patch that has been applied to the device.
# Can be an arbitrary string, but must be a single word.
# If there is no $PLATFORM_SECURITY_PATCH set, keep it empty.

Obviously, if it is now August, then the security patches are 6 months out of date. That is pretty old, and there were a lot of big security threats found since then, some of which are specific to Qualcomm phones. This prompted me to start the process of updating my source by hand.

Granted, you could also join the team of your favorite rom and help others by updating thier security patches too, but as I pointed out, I am only updating the Critical security updates, not all of them, so it would not meet all of the official requirements to push my source upstream. If that is something you are interested in doing, that is great!

The next thing I did was look at the current security updates by going here:

I decided to work on one month at a time, and compile inbetween to make sure that each update did not break anything that is in my SlimLP rom. So, I clicked on March, 2016. There were 19 CVE’s, or Common Vulnerability and Exposures ID’s for that month, 7 of which were marked Critical. Those are the ones I decided to work on.

There are many different ways to go about this, but here is what worked best for me. I copied the CVE number, in this case, CVE-2016-0818, and punched it into Google. Google brought up several options, but I found a good one to click on is the NVD detail, which is teh National Vulnerability Database. In this case, it took me here:

The website has a poor color scheme, but is very informative. It tells you what type of threat this is, how it can be used, and other great information. There is also a section called “References to Advisories, Solutions, and Tools”, below which I found several hyperlinks, including this one, which contains the fixes:

This Google Git page shows us where the file is located, and how many, and exactly which file(s) have been changed. For this particular CVE, it is a really small change of just one file:

src/platform/java/org/conscrypt/ [diff]

By clicking on the word [diff], you are brought to the next page, that shows you exactly which lines of code need to change, like so:

@@ -68,6 +68,15 @@
if (anchors == null) {
anchors = new ArrayList<TrustAnchor>(1);
subjectToTrustAnchors.put(subject, anchors);
+ } else {
+ // Avoid indexing the same certificate multiple times
+ if (cert != null) {
+ for (TrustAnchor entry : anchors) {
+ if (cert.equals(entry.getTrustedCert())) {
+ return;
+ }
+ }
+ }

If you have never read these before, the + signs tell you to add these lines. Any – signs tell you to delete those lines. At the top, the @@ -68,6 +68,15 @@ is used to tell you which line numbers to look for, such as the case here, of line 68. Pretty straightforward. So, in this case, I found that file, and made these changes of adding these new lines. Note, in some of the files I changed, the line numbers were not correct for where to find this portion of code. The easy thing to do is copy a snipit of the code and do a search in the file, corrolating that with the surounding code and approximate line numbers for guidance. This is especially true if that file has been hacked to add some function or feature to your rom.

The next step is to go back to where we started. If you recall, we looked in /build/core/, where we saw this line:


Now we can update it if we desire. Granted, if you are not doing all of the updates, you may not wish to change this, as you do not want to intentionally mislead anyone. In my case, I did update it, but was very sure to write in my rom’s long description that the security updates are only the Critical updates that I applied by hand, as of 2016-02-01. How you handle this is up to you.

Obviously, the last step is to go ahead and compile your new code, and see if it still works right! Hopefully, you now have a more secure rom for your phones.

Linux – keep it simple.

Using a fallback branch to overcome poor choice of repository branch names

I know that we have looked at fallback branches before, but this really is worth looking at again. Last time, we saw an instance where there was not a branch available that was new enough for what we were trying to build. E.g., building a Lollipop version of Android, with only KitKat trees available. This time, however, we have a case of “mistaken” identity. Check it out:

Calculated revision: lp5.1-layers
Default revision: android-5.1.1_r24
Default revision android-5.1.1_r24 not found in android_device_samsung_jfltetmo. Bailing.
Branches found:
Use the ROOMSERVICE_BRANCHES environment variable to specify a list of fallback branches.
build/core/ *** Can not locate config makefile for product “liquid_jfltetmo”. Stop.

** Don’t have a product spec for: ‘liquid_jfltetmo’
** Do you have the right repo manifest?

Here we are trying to build a Lollipop version of Android, and it is looking for a branch called lp5.1-layers, but will use the default of android-5.1.1_r24 if it is available. It couldn’t find it, however, because in the source I am refering too, the branch is called lollipop instead. Now, you and I know that Lollipop and 5.1.1 are the same thing, but the compiler and repo tools do not. So, here’s how we fix it, by using a fallback branch option, except instead of “falling back” to an old revision, we are “falling back” to the current revision under a different name:

alaskalinuxuser@AlaskaLinuxUser-HP-Compaq-6715b:~/Documents/projects/phones/compile/Liquid5$ export ROOMSERVICE_BRANCHES=lollipop
alaskalinuxuser@AlaskaLinuxUser-HP-Compaq-6715b:~/Documents/projects/phones/compile/Liquid5$ brunch jfltetmo
————Edited for space————-
Device jfltetmo not found. Attempting to retrieve device repository from LiquidSmooth-Devices Github (
Found repository: android_device_samsung_jfltetmo
Checking branch info
Calculated revision: lp5.1-layers
Default revision: android-5.1.1_r24
Using fallback branch: lollipop
Adding dependency: LiquidSmooth-Devices/android_device_samsung_jfltetmo -> device/samsung/jfltetmo
Syncing repository to retrieve project.
Fetching project LiquidSmooth-Devices/android_device_samsung_jfltetmo
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 –:–:– –:–:– –:–:– 0

Now it “found” it! Using the fallback branch is a great way to overcome all of the different naming conventions out there.

Linux – keep it simple.

Error: Exited sync due to fetch errors

Error: Exited sync due to fetch errors

$ repo sync
Fetching project SlimRoms/android_external_qrngd
error: Cannot fetch UBERTC/arm-eabi-5.2
Fetching project platform/external/chromium_org/third_party/libphonenumber/src/phonenumbers
Fetching projects: 86% (419/487) Fetching project SlimRoms/hardware_qcom_display
Fetching projects: 87% (424/487) Fetching project SlimRoms/hardware_qcom_display
Fetching project SlimRoms/hardware_qcom_display
Fetching projects: 89% (434/487)
error: Exited sync due to fetch errors

Sometimes, while syncing various sources, you might run into this error. If you don’t know a way to fix it or to get around it, then this can be debilitating! There are four principle ways to fix this problem, and I would like to explore those here. First and foremost, though, what is the problem? The overal problem is that while syncing the source code, there was something missing or misplaced that cannot be found by the repo tool. In this case, while syncing LiquidSmooth 5.1-Layers, the error is that the repo tool cannot find the UBERTC/arm-eabi-5.2 repository.

As I mentioned a moment ago, there are four things that you can do about this. Lets take a quick look at those options:

1. Wait and try again.
Sometimes there are little glitches or hangups that can happen due to a server being down, or your internet dropping off, or power outages, etc. Perhaps your local network went down for a while and the sync stopped, or maybe someone was moving that repository while they made some changes, or something like that. An easy thing to do is try repo sync again and see if the problem is resolved. To add validity to this option, you could go look to see if that repository does in fact exist.

2. Remove that repository from your manifest.
There are a lot of repositories on your manifest that will not have anything to do with what you are building. For instance, in this very case, I will not be using the UBERTC arm 5.2 tool chain, so I do not really care to download this repository anyways. An easy fix here is to simply remove it from my manifest, like so:

$ cd [to your folder where you were running repo sync]
$ gedit ./.repo/manifests/default.xml

You should now be presented with a file that looks like this:


<remote name=”ls”

<remote name=”cm”
fetch=”git://” />

<default revision=”refs/tags/android-5.1.1_r24″
sync-j=”4″ />

<project path=”android” name=”android” remote=”ls” revision=”lp5.1-layers” />
<project path=”build” name=”android_build” remote=”ls” revision=”lp5.1-layers” >
<copyfile src=”core/” dest=”Makefile” />
<project path=”abi/cpp” name=”platform/abi/cpp” groups=”pdk” />
<project path=”art” name=”SlimRoms/android_art” remote=”github” revision=”lp5.1″ />
<project path=”bionic” name=”SlimRoms/android_bionic” remote=”github” revision=”lp5.1″ />
<project path=”bootable/bootloader/legacy” name=”platform/bootable/bootloader/legacy” />
<project path=”bootable/recovery” name=”SlimRoms/bootable_recovery” remote=”github” revision=”lp5.1″ />
<project path=”cts” name=”platform/cts” groups=”cts,pdk-cw-fs” />
<project path=”dalvik” name=”platform/dalvik” groups=”pdk-cw-fs” />

Which, in this case I edited as so:

<!– arm toolchains –>
<project path=”prebuilts/gcc/linux-x86/arm/arm-eabi-4.8″ name=”UBERTC/arm-eabi-4.8″ remote=”bb” revision=”master” />
<project path=”prebuilts/gcc/linux-x86/arm/arm-eabi-4.9″ name=”UBERTC/arm-eabi-4.9″ remote=”bb” revision=”master” />
<!– <project path=”prebuilts/gcc/linux-x86/arm/arm-eabi-5.2″ name=”UBERTC/arm-eabi-5.2″ remote=”bb” revision=”master” /> WJH –>
<project path=”prebuilts/gcc/linux-x86/arm/arm-eabi-6.0″ name=”UBERTC/arm-eabi-6.0″ remote=”bb” revision=”master” />
<project path=”prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8″ name=”UBERTC/arm-linux-androideabi-4.8″ remote=”bb” revision=”master” />
<project path=”prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9″ name=”UBERTC/arm-linux-androideabi-4.9″ remote=”bb” revision=”master” />

As you can see, I used the “<!– –>” tokens to comment out the repository that caused the error. This will make repo skip that line of the file, and will solve my problem. However, what do you do if you need that repository? Well, that brings us to our next option.

3. Replace or repair the repository.

It could be that the repository is not actually missing, but that it is improperly typed in your manifest. Try to go to that repository on github, or where ever the “<remote” flags at the start of your file point to, and see if that repository does in fact exist. If it does exist, is there a spelling difference between it and your manifest?

If you can’t find it there, is there another place that you can find it? For instance if the “<remote” flag pointed to a bitbucket repository, is there a github repository that has the same name, and perhaps the same files you need? If so, change the project path and remote flags to match that other repository. after making the change, run repo sync again and see the results.

4. An unofficial option that works really well.

A simple, effective, yet cumbersome way to fix this problem is to mix option #2 with #3. For instance, if you need the UBERTC 5.2 tool chain for arm devices, but you can’t get option #3 to work, you could use option #2 to remove that repository from syncing. THen you can manually download the UBERTC arm 5.2 toolchain and manually place it in your files where it needs to be. This is a pretty fast way to do things, but it will cause you greif later. Particularly, you will always have to update those files manually, and you will need to know exactly where they go and what their folders should be named. But it is a good “last resort” fix.

Linux – keep it simple.


Setting up your compile environment for OmniRom 6.0.1

I’ve talked about how to compile Android variants before, and for the most part, it works the same no matter what variant you build. One caveat to that, however, is OmniRom. When I setup to build OmniRom 6.0.1, I have to set it up differently than the other builds that I do. It took me a while to figure it out (probably because I’m not very smart), so I thought I would share my findings with others, in the event that they couldn’t figure it out either.

So I want to compile OmniRom 6.0.1 for my Samsung Galaxy S4 T-Mobile phone (SGH-M919, JFLTETMO). God has graciously enabled me to build other roms for this phone, and I thought that it would be pretty straightforward to build the ol’ trusty OmniRom. Was I ever wrong! The setup was not intuitive and was unlike the setup for LiquidSmooth, AOKP, CM, PAC, and so forth. So here is what I did, and perhaps by looking at that, if you have the same problem you can fix it too.

Of course, you need to set up your compile environment by getting all the right programs and tools to run the compiler. I have already done this on my machine, but here is how you can do that too:

$ sudo apt-get install bison build-essential bzip2 curl dpkg-dev flex g++-multilib git git-review gnupg gperf lib32ncurses5-dev lib32readline-gplv2-dev lib32z1-dev openjdk-7-jdk libbz2-1.0 libbz2-dev libc6-dev libghc-bzlib-dev libgl1-mesa-dev libgl1-mesa-glx:i386 libncurses5-dev libreadline6-dev libreadline6-dev:i386 libx11-dev:i386 libxml2-utils lzop maven pngcrush pngquant python-markdown schedtool squashfs-tools tofrodos x11proto-core-dev xsltproc zip zlib1g-dev zlib1g-dev:i386

This will take a while. Once it is done, do this:

$ mkdir ~/bin && curl > ~/bin/repo && chmod a+x ~/bin/repo

$ gedit ~/.bashrc

Now you should see gedit open up your .bashrc file, to which you should add this at the very end, and save it:

export PATH=~/bin:$PATH

Now you need to close your terminal and open a new one to get the PATH variables to stick. Actually, it wouldn’t hurt to reboot your system after installing all of those programs we just installed. Your computer should now be primed and ready to go.

So once that is done, you can now get started. First things first, I downloaded the source:

$ cd ~
$ mkdir omni6
$ cd omni6
$ repo init -u git:// -b android-6.0
$ repo sync

As I have pointed out before, this sync takes a long time to download the files. We are talking about 10+ GB of files, so it will depend on your internet connection, but that is a lot of source code!

Next, I download the device trees, kernel source, and vendor blobs. You could choose any source for these that you want, CyanogenMod’s source is usually pretty good. AOKP, Slimroms, and others have trees available also. One group that has been less of a hassle to borrow trees from is DU, and here is how you can do that:

$ cd ~/omni6/
$ cd device
$ mkdir samsung
$ cd samsung
$ git clone -b m-caf jfltetmo
$ git clone -b m-caf jf-common
$ git clone -b m-caf msm8960-common
$ git clone -b m-caf qcom-common
$ cd ..
$ git clone -b m-caf qcom-common
$ mkdir qcom
$ cd qcom
$ git clone -b m-caf sepolicy
$ cd ~/omni6/
$ mkdir -p kernel/samsung
$ cd kernel/samsung
$ git clone -b m-caf jf
$ cd ~/omni6/vendor/
$ git clone -b cm-13.0 samsung

Now you have all of the kernel source for the JFLTETMO/JF cell phones, and you have the device trees and vendor blobs to match! But if you run the build commands now, it will simply error out stating that it cannot find “omni_jfltetmo” and ask you if you have the right repo manifest. So here is what we need to do to make the Dirty Unicorn trees buildable in OmniRom: go to the omni6/device/samsung/jfltetmo folder and rename du.dependencies to omni.dependencies. Now open the file and edit it to say this:


Yes, I realize that says nothing. But the file is needed and must be a valid file with those brackets in it. Now rename to and edit it like so:

$(call inherit-product, device/samsung/jfltetmo/

# Enhanced NFC
# WJH not present in omni $(call inherit-product, vendor/omni/config/

# Inherit some common DU stuff.
$(call inherit-product, vendor/omni/config/

PRODUCT_NAME=jfltetmo \
TARGET_DEVICE=jfltetmo \
BUILD_FINGERPRINT=”samsung/jfltetmo/jfltetmo:4.4.4/KTU84P/M919UVUFNK2:user/release-keys” \
PRIVATE_BUILD_DESC=”jfltetmo-user 4.4.4 KTU84P M919UVUFNK2 release-keys”

PRODUCT_NAME := omni_jfltetmo
PRODUCT_DEVICE := jfltetmo

Now make a new file called and put this in it:

# Copyright (C) 2011 The Android Open-Source Project
# Licensed under the Apache License, Version 2.0 (the “License”);
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an “AS IS” BASIS,
# See the License for the specific language governing permissions and
# limitations under the License.


Now your trees are “pruned” and ready for a build! Let’s give it a try:

First Run:

omni6$ . build/
including sdk/bash_completion/adb.bash
omni6$ brunch jfltetmo
WARNING: Trying to fetch a device that’s already there
found the jfltetmo device repo


including ./abi/cpp/ …
<<<<<<<<<<EDITED FOR SPACE>>>>>>>>>>>>>
build/core/ *** hardware/qcom/display/msm8960/liblight: MODULE.TARGET.SHARED_LIBRARIES.lights.msm8960 already defined by device/samsung/jf-common/liblights. Stop.

real 2m42.540s
user 0m54.729s
sys 0m24.030s

Not an uncommon problem, I have run into this before. You cannot have something defined twice, or make will not know who is right or wrong when they differ. So the easy fix here was to edit device/samsung/jf-common/liblights/ like so:

# WJH LOCAL_PATH:= $(call my-dir)
# HAL module implemenation stored in
# hw/<COPYPIX_HARDWARE_MODULE_ID>.<ro.board.platform>.so
# WJH include $(CLEAR_VARS)

# WJH LOCAL_SRC_FILES := lights.c



# WJH LOCAL_MODULE := lights.msm8960



So, now you are off and running! I included this first error, which showed up only 2 minutes into the build to show you that just having all the “right stuff” doesn’t mean that you will have a successfull build. Hopefully this will get you pointed in the right direction though!

Linux – Keep it simple.


Error: File not found – The problem with using absolute paths.

While attemtping to add the Lionheart governor to my previously built kernel, I ran into an interesting problem:

firmware/audience-es325-fw-eur.bin.gen.S: Assembler messages:
firmware/audience-es325-fw-eur.bin.gen.S:5: Error: file not found: /home/alaskalinuxuser/Documents/projects/phones/compile/cm13/kernel/samsung/jf/firmware/audience-es325-fw-eur.bin
make[3]: *** [firmware/audience-es325-fw-eur.bin.gen.o] Error 1
make[2]: *** [firmware] Error 2
make[2]: *** Waiting for unfinished jobs….

The file was right where it was supposed to be. I looked it over six times. It was right there. Then I realized the problem. It wasn’t right there, it was right here:


See the difference? It took me a minute as well. When I made a sucessful build of CM13, I then changed the folder to “cm13-working” to make it easy for me to distinguish which folders had good builds in them, and which folders were still a work in progress. Might sound strange, but I build for about 6 different roms in a round robbin sort of style, so a simpleton like myself can quickly become confused.

Ordinarily, this would not be a problem. Make, the program used to “make” things, is pretty smart, and usually all of the paths are dynamic, changing to the current folder. What had happened, however, was that somewhere along the line, I had a problem with a dynamic path, and as a quick and simple fix, I edited the file to have an absolute, or full, path. So, now that I had taken away the dynamic ability, the folders have to retain their original name to keep all of the files right where they are supposed to be.

Long story short, fix your dynamic paths if they have an error. If you use an absolute path, be sure you don’t ever rename or move anything. Ever. Or at least take good notes so you know what to change.

Linux – keep it simple.