Neverallow failures occurred

What does that even mean? Let’s take a look at the code:

libsepol.report_failure: neverallow on line 574 of system/sepolicy/system_server.te (or line 18452 of policy.conf) violated by allow system_server system_server:process { execmem };
libsepol.report_failure: neverallow on line 544 of system/sepolicy/domain.te (or line 9255 of policy.conf) violated by allow mediaserver shell_data_file:dir { search };
libsepol.report_failure: neverallow on line 459 of system/sepolicy/domain.te (or line 9170 of policy.conf) violated by allow mm-qcamerad system_file:file { execmod };
libsepol.report_failure: neverallow on line 459 of system/sepolicy/domain.te (or line 9170 of policy.conf) violated by allow mediaserver system_file:file { execmod };
libsepol.report_failure: neverallow on line 459 of system/sepolicy/domain.te (or line 9170 of policy.conf) violated by allow system_server system_file:file { execmod };
libsepol.report_failure: neverallow on line 433 of system/sepolicy/domain.te (or line 9159 of policy.conf) violated by allow mm-qcamerad system_file:file { execmod };
libsepol.report_failure: neverallow on line 433 of system/sepolicy/domain.te (or line 9159 of policy.conf) violated by allow mediaserver system_file:file { execmod };
libsepol.report_failure: neverallow on line 433 of system/sepolicy/domain.te (or line 9159 of policy.conf) violated by allow system_server system_file:file { execmod };
libsepol.check_assertions: 8 neverallow failures occurred
Error while expanding policy

From the error output, I can only discern that these should never be allowed to happen in a sepolicy configuration. So, to make ammends with the compiler, I edited build_aokp7/device/samsung/jf-common/sepolicy/system_server.te, build_aokp7/device/samsung/jf-common/sepolicy/mm-qcamerad.te, and build_aokp7/device/samsung/jf-common/sepolicy/media_server.te, simply removing the sepolicy rule that was causing the issue, namely

[CODE]system_file:file { execmod };[/CODE]

It is worth noting that they do appear twice in the list of errors, but only once in the file itself. Hopefully that will help me as I compile AOKP 7.0 for the jfltetmo Samsung Galaxy S4, T-Mobile edition.

Linux – keep it simple.


When Jack turns into a Ninja.

Well, Jack doesn’t actually turn into a Ninja. Actually Jack gets beat up by one. On my computer at least.

I’ve used Jack for a while now, when compiling Marshmallow roms. However, Jack keeps having problems while I am building Nougat roms. In fact, Jack seems to sit down and cry every time “Ninja” shows up. I keep getting a “out of memory” error for the Jack server.

Being somewhat used to Jack, I tried setting arguments by exporting them into the environment variables, as I mentioned in a previous post, but that wasn’t helping. So, I went to and read up about Jack. Unfortunately, none of the things that they recommend there are working.

Then I really read that link. Near the top of the page, it says:

“For instructions on using Jack in Android 7.0 (N) and later, see the Jack server documentation. For Android 6.0 (M), use the instructions in this section.”

Ahh, now I see the error of my ways. After going to the new Jack documentation ( ) I found this lovely tidbit:

“If you experience Jack compilations failing on Out of memory error.:

You can improve the situation by reducing the number of jack simultaneous compilations by editing your $HOME/.jack-server/ and changing jack.server.max-service to a lower value and then restarting the server.
If this is not enough, you may change the arguments used to start the server jvm and force a greater maximum Java heap size (“-Xmx”):

Stop the server using jack-admin stop-server, then:
If you start the server manually:
JACK_SERVER_VM_ARGUMENTS=”-Xmx2g -Dfile.encoding=UTF-8 -XX:+TieredCompilation” jack-admin start-server
If you use the jack server in the android tree then
export ANDROID_JACK_VM_ARGS=”-Xmx2g -Dfile.encoding=UTF-8 -XX:+TieredCompilation”
and restart your build command.”

So, now I can get Jack to join the Ninja party.

Linux – keep it simple.

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.

Fixing a problem with video recordings

For those of you who have downloaded the AOKP MM that God graciously allowed me to build, there was a problem with video recordings. It was recently brought to my attention on XDA that my build would take great camera stills, but if you tried to record video, it actually didn’t save the video anywhere! Don’t worry if you are using one of my builds, though, because (Praise God!) the errors are now solved and it works since the 20160716 build. So if you have a build before that, click on the “Homemade Roms” button above and download the latest version, where it is fixed.

Here were the fails from the logcat. I am only focusing on the errors, stops, or fails.

Using the built in Camera app:

07-12 06:43:32.459 244 3766 I MediaCodecSource: encoder (audio) stopped
07-12 06:43:32.459 244 652 I MediaCodecSource: puller (audio) stopping
07-12 06:43:32.461 244 3847 E OMXNodeInstance: setConfig(1d:google.vorbis.decoder, ConfigPriority(0x6f800002)) ERROR: Undefined(0x80001001)
07-12 06:43:32.461 244 3847 I ACodec : codec does not support config priority (err -2147483648)
07-12 06:43:32.462 244 3847 I MediaCodec: MediaCodec will operate in async mode
07-12 06:43:32.467 244 3846 I NuPlayerDecoder: [] resubmitting CSD
07-12 06:43:32.468 244 3846 I NuPlayerDecoder: [] resubmitting CSD
07-12 06:43:32.469 244 3775 D ALSAStreamOps: setParameters(): keyRouting with device 0x0
07-12 06:43:32.469 244 3775 E ALSAStreamOps: must not change mDevices to 0
07-12 06:43:32.470 244 3775 D AudioStreamInALSA: standby
07-12 06:43:32.470 244 3775 D AudioStreamInALSA: standby
07-12 06:43:32.470 244 3775 D ALSADevice: standby: handle 0xb216c1c0 h 0x0
07-12 06:43:32.472 244 3848 W SoftVorbis: vorbis_dsp_synthesis returned -135
07-12 06:43:32.473 244 3848 W SoftVorbis: vorbis_dsp_synthesis returned -135
07-12 06:43:32.500 3612 3612 E MediaRecorder: stop failed: -1007
07-12 06:43:32.502 3612 3612 E CAM_VideoModule: java.lang.RuntimeException: stop failed.
07-12 06:43:33.984 244 3647 W AMessage: failed to post message as target looper for handler 0 is gone.

Using the OpenCamera App for comparison:

07-12 06:50:28.951 244 4439 E ACDB-LOADER: Error: ACDB EC_REF_RX returned = -8
07-12 06:50:28.976 244 4436 E SoftAVCEnc: Error in extractGraphicBuffer
07-12 06:50:28.976 244 4435 E ACodec : [] ERROR(0x80001001)
07-12 06:50:28.976 244 4435 E ACodec : signalError(omxError 0x80001001, internalError -2147483648)
07-12 06:50:28.976 244 4435 E ACodec : [] ERROR(0x80001001)
07-12 06:50:28.976 244 4435 E ACodec : signalError(omxError 0x80001001, internalError -2147483648)
07-12 06:50:28.977 244 4434 E MediaCodec: Codec reported err 0x80001001, actionCode 0, while in state 6
07-12 06:50:28.977 244 4439 D ALSADevice: setHardwareParams: buffer_size 16384, period_size 4096, period_cnt 4
07-12 06:50:28.977 244 4431 E MediaCodecSource: Encoder (video) reported error : 0x80001001
07-12 06:50:29.124 4180 4180 E MediaRecorder: stop failed: -1007

So, the errors or fails that are the same are these:

ACDB-LOADER: Error: ACDB EC_REF_RX returned = -8
MediaRecorder: stop failed: -1007

These appeared to me to both be audio errors. It appears that the audio is creating an error, so the video will not save. Unless someone out there knows better (be sure to correct me, I’m still learning). So I began looking at MediaRecorder and ACDB-LOADER for audio problems. In the end, I couldn’t quite figure out what was wrong until I downloaded the latest device trees from CM13. Once I merged them with my files on Github, I started seeing all the little details that must have added up to it not working quite right. Here is a link to the commit:

Pay special attention to the audio changes, and the camerawrapper commits. I am too inexperienced to tell you exactly what was wrong with it, but I can definately see a change in these files that make more sense. In either event, the issue was fixed, and everything else still worked! Along the way, I got to learn some great things about cameras, so it was a good thing this happened!

Linux – keep it simple.


The AKLU-Lionheart kernel!

For those of you who are downloading or using the PAC-ROM 6.0.1 or AOKP 6.0.1 that God graciously enabled me to build, I have released a new kernel for them, the AKLU-Lionheart kernel. You can install it in TWRP without having to re-load your rom. This will allow you to keep all of the data you already have. The updated rom links that are on the “Homemade Roms” page include this kernel in it already, but for any who are using an older build that just want to upgrade to the new kernel, here it is:


The first boot the WiFi may not work, but after a reboot it works every time there after! To God be the glory, the new kernel builds are working great!

Changes to the kernel include 2 new governors:

LionHeart – Lionheart is a conservative-based governor which is based on samsung’s update3 source.

SmartMax – By default this is configured for battery saving, so this is NOT a gaming or benchmark governor! Additionally, to make it “snappy”, smartmax has “touch poke”. So input events from the touchscreen will boost the cpu for a specific time to a specific frequency. Developed by XDA user maxwen.

You can still choose ondemand, powersave, performance, conservative, interactive, and userspace, but this allows you to choose two “battery friendlier” options. SmartMax will help your battery the most, and LionHeart is a bit more performance oriented, but still conservative. Enjoy!

Linux – keep it simple.

RWE: Step by step instructions for building AOKP 6.0 for the T-Mobile variant of the Samsung Galaxy S4

I have noticed that the build instructions on the AOKP website are a bit outdated. They date back to JellyBean. I would like to encourage other users to build more custom roms, and I thought that it would help if I show how to build one of the roms wich compiled successfully for me (Praise God!). It is my hope that these instructions are clear and easy to follow. Hey, if I can do it, anybody can do it!

<<<<< Step 1: Setup your system. >>>>>

To be honest, this can be the most daunting part, because if you do not set this up properly, it just will not work. I use Ubuntu 14.04 on a HP Compaq 6715b laptop. I know, not a very ideal compiler, but it is what I’ve got. Here are the suggested packages, just open a terminal and paste this in:

$ 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.

<<<<< Step 2: Download the source. >>>>>

Here is a very short project for you that takes the computer a long time to complete. Open a terminal and start typing:

$ cd ~
$ mkdir aokp6
$ cd aokp6
$ repo init -u -b mm
$ repo sync

You can now go outside, play with the kids, phone a friend, and then go to bed. When you awake the next morning, this might be done, depending on your internet connection!

<<<<< Step 3: Adding the device, kernel, and vendor trees. >>>>>

In some cases, you can simply type the command

[CODE]$ breakfast[/CODE]

and just choose your device, but at this time, the AOKP repository did not include a current device tree for the JFLTETMO phone, so we need to download one. I chose to test out the Dirty Unicorn JFLTETMO devices trees, by going here and choosing to download the zips. Later, perhaps we can learn about adding them as dependencies, but here are the links, be sure to choose the 6.0 branches and click the download button to download the zips:

Once you have downloaded them, unzip each one and rename them:

android_device_samsung_jfltetmo – jfltetmo
android_device_samsung_jf-common – jf-common
android_device_samsung_jflte – jflte
android_device_samsung_msm8960-common – msm8960-common
android_device_samsung_qcom-common – qcom-common

Go to you aokp6/device folder and create a folder called “samsung”. Now put the above folders into it.

Then unzip the kernel_samsung_jf folder and rename it “jf”. Go to the aokp6 folder and create a folder called “kernel”, go into the kernel folder and make a new folder called “samsung”, enter that folder, and put your “jf” folder here. Don’t worry, we are almost done.

Now go to your aokp6/vendor folder. Create a new folder called “samsung”. Enter the samsung folder and copy the contents of your unzipped proprietary_vendor_samsung folder. This should be a bunch of folders like jf-gsm-common, jf-common, etc. You actually don’t need all of these folders right now, but it will not hurt to have them, and there are two folders in there that you need.

Now you should probably take a break before going on to the next step!

<<<<< Step 4: Editing the device, kernel, and vendor trees. >>>>>

Now, go to the device/samsung/jfltetmo folder and rename to and edit it as follows:

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

# Enhanced NFC
$(call inherit-product, vendor/aokp/configs/

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

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 := aokp_jfltetmo
PRODUCT_DEVICE := jfltetmo

NOTE: the original file said “vendor/du/config/*” you must change it to “configs” or there will be an error!

Then, in the jfltetmo folder, delete the cm.dependencies file. Do the same deletion in all of the device/samsung/* directories. You don’t want to download CM dependencies, because you already have them here.

Note: Because repositories are constantly updated, I can only garuntee that this will work based on the files as they were the day of this writing. However, with all of this in place, if you follow this guide, it should work realatively the same as what happened for me.

You can actually just run the compiler right now, however, you will have several stop errors that we plan to address here before you do that. All of these edits are due to errors that cropped up when running the compiler.

The first error was relating to libhealthd. Android and AOKP source already has a built in libhealthd for the qcom motherboards, and it is a duplication of efforts (which causes an error) to have both the device tree libhealthd and the source libhealthd. So here is how we fix it. Now, go to the device/samsung/qcom-common/libhealthd folder, and make the following changes to the file:

# WJH LOCAL_PATH := $(call my-dir)

# WJH include $(CLEAR_VARS)
# WJH LOCAL_SRC_FILES := healthd_board_default.cpp
# WJH LOCAL_MODULE := libhealthd.qcom
# WJH LOCAL_C_INCLUDES := system/core/healthd bootable/recovery

Another error that will crop up if you run the compiler now, is that your multi-media video will have a problem setting the picture order, and the compiler will get confused and stop with an error. So we can fix that here before we begin. We need to edit one of the hardware files. Go to hardware/qcom/media-caf/msm8960/mm-video/vidc/venc/src, and edit the video_encoder_device.cpp file as follows (this is the last few lines of the file):

bool venc_dev::venc_set_picture_order_count_type(OMX_U32 type)
// WJH venc_poctype temp;
// WJH venc_ioctl_msg ioctl_msg = {&temp, NULL};

// WJH temp.poc_type = type;
// WJH DEBUG_PRINT_HIGH(“Setting poc type: %d”, type);
// WJH if(ioctl(m_nDriver_fd, VEN_IOCTL_SET_PIC_ORDER_CNT_TYPE, (void *)&ioctl_msg) < 0)
// WJH {
// WJH DEBUG_PRINT_ERROR(“Request for setting poc type failed”);
// WJH return false;
// WJH }
return true;

And finaly, there is an error that will pop up and stop your compiler because of a conflict over the “ambientIsAvailable” portion of this file: packages/apps/InCallUI/src/com/android/incallui/ at line 404. So we will just go ahead and edit it here before we begin.

final boolean showNote = isProvisioned &&
// WJH DeepLinkIntegrationManager.getInstance().ambientIsAvailable(getUi().getContext()) &&
mNoteDeepLink != null;

Now that all of the hard work is done, it is time to actually build something!

<<<<< Step 5: Start your build! >>>>>

Phew! You have invested a lot of hours into this project, now it is time to actually put those files and time to use! Open up a terminal in your aokp6 folder and start typing:

aokp6$ . build/

Which will output something like this:

including vendor/aokp/
including sdk/bash_completion/adb.bash
including vendor/aokp/bash_completion/git.bash
including vendor/aokp/bash_completion/repo.bash

Now type:

aokp6$ brunch jfltetmo

Which will start the long build process, it will output this:

including vendor/aokp/
Got local manifest
Got local manifest
Checked dependency tree over :
NO_DEPS: device/*/jfltetmo

AOKP_VERSION = aokp_jfltetmo_mm_unofficial_2016-06-20_1015
TARGET_PRODUCT = aokp_jfltetmo
TARGET_ARCH_VARIANT = armv7-a-neon
HOST_ARCH = x86_64
HOST_OS = linux
HOST_OS_EXTRA = Linux-3.16.0-73-generic-x86_64-with-Ubuntu-14.04-trusty
OUT_DIR = /home/alaskalinuxuser/Documents/projects/phones/compile/aokp6/out

And this:

…..edited for space…..

Import includes file: /home/alaskalinuxuser/Documents/projects/phones/compile/aokp6/out/host/linux-x86/obj/EXECUTABLES/acp_intermediates/import_includes
host C: libhost <= build/libs/host/CopyFile.c
build/libs/host/CopyFile.c:86:43: warning: unused parameter ‘pSrcStat’ [-Wunused-parameter]
static bool isSameFile(const struct stat* pSrcStat, const struct stat* pDstStat)
build/libs/host/CopyFile.c:86:72: warning: unused parameter ‘pDstStat’ [-Wunused-parameter]
static bool isSameFile(const struct stat* pSrcStat, const struct stat* pDstStat)
build/libs/host/CopyFile.c:104:42: warning: unused parameter ‘src’ [-Wunused-parameter]
static void printNotNewerMsg(const char* src, const char* dst, unsigned int options)
build/libs/host/CopyFile.c:531:69: warning: unused parameter ‘isCmdLine’ [-Wunused-parameter]
static int copyFileRecursive(const char* src, const char* dst, bool isCmdLine, unsigned int options)

…..edited for space….. Stuff like this will scroll by …..

Copy: /home/alaskalinuxuser/Documents/projects/phones/compile/aokp6/out/target/product/jfltetmo/obj/STATIC_LIBRARIES/libext4_intermediates/libipt_LOG.c
Copy: /home/alaskalinuxuser/Documents/projects/phones/compile/aokp6/out/target/product/jfltetmo/obj/STATIC_LIBRARIES/libext4_intermediates/libipt_MASQUERADE.c
Copy: /home/alaskalinuxuser/Documents/projects/phones/compile/aokp6/out/target/product/jfltetmo/obj/STATIC_LIBRARIES/libext4_intermediates/libipt_MIRROR.c
Copy: /home/alaskalinuxuser/Documents/projects/phones/compile/aokp6/out/target/product/jfltetmo/obj/STATIC_LIBRARIES/libext4_intermediates/libipt_NETMAP.c
target StaticLib: libip4tc (/home/alaskalinuxuser/Documents/projects/phones/compile/aokp6/out/target/product/jfltetmo/obj/STATIC_LIBRARIES/libip4tc_intermediates/libip4tc.a)
target thumb C++: keystore <= system/security/keystore/keystore.cpp
target thumb C++: keystore <= system/security/keystore/keyblob_utils.cpp
target thumb C++: keystore <= system/security/keystore/operation.cpp

…..edited for space…..


Notice that there were some “warning” flags in there. Warnings are not all bad, but they can be. In this case it works out okay. Hopefully, after many hours, you should see this:

______ _____ __ __ _____
/\ _ \/\ __`\/\ \/\ \ /\ _ `\
\ \ \L\ \ \ \/\ \ \ \/’/’\ \ \L\ \
\ \ __ \ \ \ \ \ \ , < \ \ ,__/
\ \ \/\ \ \ \_\ \ \ \\`\ \ \ \/
\ \_\ \_\ \_____\ \_\ \_\\ \_\
\/_/\/_/\/_____/\/_/\/_/ \/_/

===========-Package complete-===========
zip: /home/alaskalinuxuser/Documents/projects/phones/compile/aokp6/out/target/product/jfltetmo/
md5: 46bc18249c61988e75aba813464692a3
size: 320M

Success! Praise God! Now you can put this on your phone and test it out! Hopefully everything will be working! For future use, now you can start making changes or edits, from backgrounds to kernels! Have fun and make lots of backups. Remember, sometimes it is really hard to undo a change that you make.

Hopefully we learned how to set up our system, get the source, add devices and kernels that are not in the source, make proper edits, and run the compiler. Like I said, this works on my machine, as of this writing. You may notice, that if you make this build, it will not be identical to the one that I have posted on XDA. That is because I have made a few edits, additions, and/or subtractions here and there. That is the great thing about Android and open source! It is now up to you to make it better, to make it unique, or to make it you. Good luck with those builds, and be sure to share and help the next guy or gal with thier projects too!

Linux – keep it simple.


Adding Governors to your kernel

While building AOKP MM for my Samsung Galaxy S4, T-Mobile phone (SGH-M919 JFLTETMO), I made a rookie mistake. In my mind, AOKP users are the type to want the maximum performance out of their devices at all times. So, when I put AOKP 6 together, I figured that a good default parameter to set the governor to was Performance. This really makes AOKP MM pretty snappy. Not only does it make it snappy, but the CPU frequency is always near max while the screen is on, causing a tremendous waste of battery power. So, as an alternative, I set the CPU governor to Interactive, which was better, but still not very battery friendly.

In a constant quest to make things better, and to understand more about how things work, I decided to do something that I have never done before. I decided to add more governors to the kernel. Sure, I have compiled kernels before, it was part of my LPIC exams. To be honest, I was compiling kernels before I was compiling Android. Governors, however, was never something that I changed on a kernel before. For a desktop computer it is actually quite irrelevant in my opinion, because you are plugged in, you might as well use the best performance governor and disregard any sort of power saving settings. Of course, that doesn’t work very well for cell phones, and my inexperience showed in my last build.

So, on to the task at hand. The CPU frequency is set by the governor. A driver is needed to control the governor, so go to the proper folder:

$ cd ./kernel/samsung/jf/drivers/cpufreq

In this folder, you will do several things. The first is paste your new “.c” files for your new governor. You can find these files by breaking down or looking in source code for your kernel which is specific to your device (in the phone sense). In this case, I added BioShock and Yankactive governors to my system with these two files:


Then I modified the kconfig file from that same folder by adding these lines:

bool “BioShock”
Use the CPUFreq governor ‘BioShock’ as default.

bool “yankactive”
Use the CPUFreq governor ‘yankactive’ as default.

and these lines:

tristate “‘bioshock’ cpufreq bioshock”
depends on CPU_FREQ
‘bioshock’ – Mixing Lionheart and ConservitiveX

tristate “‘yankactive’ cpufreq policy governor”
depends on CPU_FREQ
‘yankactive’ – dynamic cpufreq policy governor

And edited the Makefile in that folder to say:

# CPUfreq governors
obj-$(CONFIG_CPU_FREQ_GOV_PERFORMANCE) += cpufreq_performance.o
obj-$(CONFIG_CPU_FREQ_GOV_POWERSAVE) += cpufreq_powersave.o
obj-$(CONFIG_CPU_FREQ_GOV_USERSPACE) += cpufreq_userspace.o
obj-$(CONFIG_CPU_FREQ_GOV_ONDEMAND) += cpufreq_ondemand.o
obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE) += cpufreq_conservative.o
obj-$(CONFIG_CPU_FREQ_GOV_INTERACTIVE) += cpufreq_interactive.o
obj-$(CONFIG_CPU_FREQ_GOV_YANKACTIVE) += cpufreq_yankactive.o
obj-$(CONFIG_CPU_FREQ_GOV_BIOSHOCK) += cpufreq_bioshock.o

And finaly, I added these lines to the ./kernel/samsung/jf/include/linux/cpufreq.h file:

extern struct cpufreq_governor cpufreq_gov_bioshock;
#define CPUFREQ_DEFAULT_GOVERNOR (&cpufreq_gov_bioshock)
extern struct cpufreq_governor cpufreq_gov_yankactive;
#define CPUFREQ_DEFAULT_GOVERNOR (&cpufreq_gov_yankactive)

The only thing left is to check your “.c” files to make sure that all dependencies are met! Lest you think that I am really, really smart, I will clue you in. While I have compiled kernels before, this was new to me. God graciously gave me a brain and fingers, which I used to look it up online. There are some really great guides about overclocking, under-volting, etc., and if you are interested, it will not take long to find them.

Bioshock is supposed to be a good “balance” between battery savings and performance, while yankactive is supposed to be even more battery conscious. Hopefully between these two kernel governors we can find one that will help with the battery consumption. For my next build, I set BioShock to be the new default kernel governor, as opposed to my old choice of Performance. Only time will tell if it actually makes a difference.

Linux – Keep it simple.

Error: recovery.img is too large!

Since I was having a spot of trouble with the SlimRoms 6.0 rom, I decided to give AOKP 6.0 a quick and dirty try. After syncing the source and adding the vendor/device trees, I gave it a whirl. Here was the first failure output to my terminal.

target Pack Relocations: camera.msm8960 (/home/alaskalinuxuser/Documents/projects/phones/compile/aokp6/out/target/product/jfltetmo/obj/SHARED_LIBRARIES/camera.msm8960_intermediates/PACKED/
INFO: Compaction : 0 bytes
INFO: Too few relocations to pack after alignment
target Symbolic: libexternal (/home/alaskalinuxuser/Documents/projects/phones/compile/aokp6/out/target/product/jfltetmo/symbols/system/lib/
target Symbolic: libvirtual (/home/alaskalinuxuser/Documents/projects/phones/compile/aokp6/out/target/product/jfltetmo/symbols/system/lib/
target Symbolic: libRSCpuRef (/home/alaskalinuxuser/Documents/projects/phones/compile/aokp6/out/target/product/jfltetmo/symbols/system/lib/
—– Making recovery image ——
+/home/alaskalinuxuser/Documents/projects/phones/compile/aokp6/out/target/product/jfltetmo/recovery.img maxsize=10543104 blocksize=135168 total=10633216 reserve=270336
error: +/home/alaskalinuxuser/Documents/projects/phones/compile/aokp6/out/target/product/jfltetmo/recovery.img too large (10633216 > [10813440 – 270336])
make: *** [/home/alaskalinuxuser/Documents/projects/phones/compile/aokp6/out/target/product/jfltetmo/recovery.img] Error 1
make: *** Deleting file `/home/alaskalinuxuser/Documents/projects/phones/compile/aokp6/out/target/product/jfltetmo/recovery.img’
make: *** Waiting for unfinished jobs….
make: Leaving directory `/home/alaskalinuxuser/Documents/projects/phones/compile/aokp6′

#### make failed to build some targets (09:11:54 (hh:mm:ss)) ####

This was actually strange and encouraging. The entire build ran up to the point of making the recovery image. The issue was that the recovery image was bigger than the recovery space available. Seems odd to me, but I am not overly concerned with it. The main reason that this issue does not cause me concern is that none of the builds I am making actually include the recovery image in the zip file that is built. So, I edited device/samsung/jf-common/ to have a “larger” recovery drive, since the recovery image would not actually be loaded in the rom. Another option is to comment out the recovery size altogether, giving the compiler permission to make a recover image as large as it would like to.

Linux – Keep it simple.