Putting Android Nougat on a Nook HD+

While there are several guides out there on how to do this, I ran into a slight snag while trying to put Android Nougat on a Nook HD+, so I thought I’d share that with you. I was following this guide: https://nookhdplusandroid7.wordpress.com/

Following through the instructions seemed to go very smoothly, until it didn’t work. Specifically, after putting in the micro SD card, and powering off the device, powering it on would just cause a blank screen. Then, several minutes later, the device would turn on as normal.

Turns out that the Nook just didn’t like my SD card. It was a 4 GB card that I had laying around. When I opened a new package of 16 GB PNY SD cards, the whole process started working.

I don’t want to rehash the excellent write up that was already given, but I thought I would share my small issue, in case someone else runs into that problem. Turns out, there are some newer roms available for the Nook HD+ as well.

Either way, here are a couple of screen shots about showing the outcome:

It seems to work rather nicely. I did notice one slight “glitch” to the screen when I selected MTP for the USB mode, but other than that, it seems to work great! Now I just have to force myself to give it back to it’s owner!

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: https://forum.xda-developers.com/android/general/guide-how-to-build-custom-roms-kernel-t3814251


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]https://forum.xda-developers.com/note-edge/general/guide-build-aosp-roms-kernels-note-edge-t3488840[/url]
Building ROMs for the Galaxy S4: [url]https://forum.xda-developers.com/galaxy-s4-tmobile/general/guide-step-step-instructions-building-t3402637[/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.

Another example of a dirty fix….

[CODE] ninja: error: ‘/home/alaskalinuxuser/compile/build_lineageos/out/target/common/obj/APPS/ValidityService_intermediates/with-local/classes.dex’, needed by ‘/home/alaskalinuxuser/compile/build_lineageos/out/target/common/obj/APPS/ValidityService_intermediates/classes.dex’, missing and no known rule to make it make: *** [ninja_wrapper] Error 1 make: Leaving directory `/home/alaskalinuxuser/compile/build_lineageos’ [/CODE]

That was the error I received. I was trying to build LineageOS (the CyanogenMod replacement) for the TBLTEXX/TBLTETMO Samsung Galaxy Note Edge. There were several ways to fix this, but first let’s understand the problem a little better.

The isse is that the classes.dex file is missing from that location. What is it for? Well, in this case, it is for the ValidityService app. Note that it is under APPS, and ValidityService. Now you may ask, what does that do? Well, my limited understanding is that it is a nessessary component of the fingerprint sensor, for validating that you have the correct fingerprint.

So, what could we do to fix this? Well, we could edit the TBLTEXX device tree and remove the ValidityService folder, and remove the reference to it in the config files. That would definately solve the error issue, but then would prevent you from using the fingerprint sensor.

We could rifle through all of the files and see what is missing that needs to be built in order to make that work. This is the BEST option, but very time consuming.

Or, we could just copy the out/target/common/obj/APPS/ValidityService_intermediates folder from another sucessfull build, if we have one, which, as a matter of fact, I do, AOKP. So, I copied the folder over and continued with the build. No issues there! At least, not with the fingerprint sensor…. Now if I can only make a phone call with my cell phone.

Linux – keep it simple.

When symbolic links don’t work?

Recently, while compiling CM12 for the TBLTETMO, Galaxy Note Edge, I ran into an odd error. I did not get a chance to copy the error message, but essentially it said that the file[CODE]linux/dqblk_qtree.h[/CODE]

did not exist.

Normally, this would not cause concern, nor even a raised eyebrow. However, when I went to the location, the file DID exist. I thought that was really odd. Then I realized that it was a symbolic link to another file. Sometimes, for whatever reason, the symbolic links don’t always work for the compiler. In this case, I simply replaced the file with the linked one. If you don’t have the file, I found it online here: http://lxr.free-electrons.com/source/include/linux/dqblk_qtree.h?v=4.0

The point being, if you find a “missing file” that actually exists, check to see if it is a link to another file. If so, copy the linked file in its entirety to the proper location, as that will work much better.

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/version_defaults.mk, 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/TrustedCertificateIndex.java [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/version_defaults.mk, 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.

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.

Compiling CyanogenMod 13 for the Samsung Galaxy S4 T-Mobile (JFLTETMO SGH-M919)

This morning, when I came back to my computer, I was greeted with some very good news:

running: java -Xmx2048m -jar /home/alaskalinuxuser/Documents/projects/phones/compile/cm13/out/host/linux-x86/framework/signapk.jar -w build/target/product/security/testkey.x509.pem build/target/product/security/testkey.pk8 /tmp/tmp_q_ufQ /home/alaskalinuxuser/Documents/projects/phones/compile/cm13/out/target/product/jfltetmo/cm_jfltetmo-ota-612d9cd77f.zip
Package Complete: /home/alaskalinuxuser/Documents/projects/phones/compile/cm13/out/target/product/jfltetmo/cm-13.0-20160510-UNOFFICIAL-jfltetmo.zip
make: Leaving directory `/home/alaskalinuxuser/Documents/projects/phones/compile/cm13′

#### make completed successfully (06:38:09 (hh:mm:ss)) ####

Particularly that last line that says that the third build attempt was successful! That was good news indeed. However, I tend not to get my hopes up too high. Often when compiling an Android OS I have run into an issue where the rom successfully builds, but doesn’t actually work. There is error checking on the build process, but there is not error checking on the build function. It is like following instructions to build a paper airplane (a really complicated one). You get errors if the instructions are incomplete, or if they don’t make sense, but you don’t get an error if the paper airplane doesn’t actually fly.

In this case, however, the build was not only successful, but it actually booted and most of the functions were working! This is a step in the right direction to say the least. As always, after loading any new rom, mine or someone elses, I perform this less than 10 minutes basic test:

-Cellular 2g/3g/LTE
-MTP USB connection

With this build, everything was functional except the Bluetooth. For some odd reason it will not turn on. Bluetooth is a love it/leave it sort of thing. For most, Bluetooth is an integral part of the Android experience. For others, it is something that they never use. In either event, I would rather that it works than not. That, however, is troubleshooting for another time. For now, I am just excited that the build was successful and functioned realatively well!

For any interested party, here is a download link to my home build:

Linux – Keep it simple.

Compiling CyanogenMod 13 for the Samsung Galaxy S4 T-Mobile (JFLTETMO SGH-M919)

In the continuing adventures of attempting to compile CyanogenMod 13 for the Samsung Galaxy S4 T-Mobile (JFLTETMO SGH-M919), on my second build attempt, I have run into another road-block. Yesterday I had an error due to a command not found, but today we have a new error:

Import includes file: /home/alaskalinuxuser/Documents/projects/phones/compile/cm13/out/target/product/jfltetmo/obj/STATIC_LIBRARIES/libvterm_intermediates/import_includes
Export includes file: packages/apps/Terminal/jni/Android.mk — /home/alaskalinuxuser/Documents/projects/phones/compile/cm13/out/target/product/jfltetmo/obj/SHARED_LIBRARIES/libjni_terminal_intermediates/export_includes
Notice file: external/libvterm/NOTICE — /home/alaskalinuxuser/Documents/projects/phones/compile/cm13/out/target/product/jfltetmo/obj/NOTICE_FILES/src//system/lib/libvterm.a.txt
make: *** No rule to make target `vendor/samsung/jf-common/proprietary/app/TimeService/TimeService.apk’, needed by `/home/alaskalinuxuser/Documents/projects/phones/compile/cm13/out/target/product/jfltetmo/obj/APPS/TimeService_intermediates/package.apk’. Stop.
make: *** Waiting for unfinished jobs….
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
make: Leaving directory `/home/alaskalinuxuser/Documents/projects/phones/compile/cm13′

#### make failed to build some targets (05:21 (mm:ss)) ####

Once again, you can always spot the problems in your compiling logs by looking for 4 key words: Failed, Error, Warning, and Stop. In this case, the key word was Stop. This time, the fault is on the same line as the stop command.

make: *** No rule to make target `vendor/samsung/jf-common/proprietary/app/TimeService/TimeService.apk’, needed by `/home/alaskalinuxuser/Documents/projects/phones/compile/cm13/out/target/product/jfltetmo/obj/APPS/TimeService_intermediates/package.apk’. Stop.
make: *** Waiting for unfinished jobs….

What we see here is a failure to create something that is needed by something else. Essentially, the compiler does not know how to make the TimeService.apk, which is needed by package.apk. Note that we are not clueless as to it’s location. It should be in the “vendor/samsung/jf-common/proprietary/app/TimeService/” directory. Upon going to that directory, which does exist, the directory is empty. There should be some sore of Android.mk file there with instructions for the compiler to follow.

Here is where we come to a crossroad. We have two choices:

1. Find the files that are needed for this apk, and put them where they need to be.


2. Find the file that references building this apk and comment it out.

The first option is technically the best option. There is a reason this apk is called for. However, this may require lots of time, searching, and downloading of material. A quick search of the TimeService.apk revealed several sites that believe it to be in cahoots with the MonkeyService.apk, and the two of them automatically download and install apps on your phone. Or, as most would call it, bloat-ware.

Not being too thrilled with it’s supposed function, I decided to take the lazy route of step 2 and simply comment out the reference to build it. Here is where a little bit of Android compiling know how has to come into play. Or, if your like me, and don’t know anything, just look through all the basic files until you find what you are looking for.

The heirarchy of build seems to go somthing like this: in the device/samsung/jfltetmo folder, it has a boardconfig.mk file. That file calls the device/samsung/jf-common/boardconfig.mk file and the vendor/samsung/jf-gsm-common/BoardConfigVendor.mk file. Since our problem is in the vendor directory, I went to the vendor/samsung/jf-gsm-common/BoardConfigVendor.mk file. Well, that didn’t help. There were 3 files there, and none of them referenced the issue.

However, our error told us that the issue was in the `vendor/samsung/jf-common/proprietary/app/TimeService/TimeService.apk’, so I went to the vendor/samsung/jf-common/ directory and found that there was an Android.mk file that said (among other things):

include $(CLEAR_VARS)
LOCAL_MODULE := TimeService
LOCAL_SRC_FILES := proprietary/app/TimeService/TimeService.apk

Which I changed to:

#include $(CLEAR_VARS)
#LOCAL_MODULE := TimeService
#LOCAL_SRC_FILES := proprietary/app/TimeService/TimeService.apk
#LOCAL_MODULE_TAGS := optional

Now, when I re-run the build, it will not attempt to build this package. So, let’s give it a try! I’ll let you know how it goes.

Linux – Keep it simple.

Compiling CyanogenMod 13 for the Samsung Galaxy S4 T-Mobile (JFLTETMO SGH-M919)

So I have been attempting to compile CM13 for my Samsung Galaxy S4 T-Mobile (JFLTETMO SGH-M919) phone. The first thing I did was read the entire guide here:


Which looked very helpful and promissing. I followed the instructions to a proverbial “T”. I even reloaded my machine with Ubuntu 14.04 just like what was used in the guide. However, the process stoped and I ran into this error:

Export includes file: packages/apps/Terminal/jni/Android.mk — /home/alaskalinuxuser/Documents/projects/phones/compile/cm13/out/target/product/jfltetmo/obj/SHARED_LIBRARIES/libjni_terminal_intermediates/export_includes
Notice file: external/libvterm/NOTICE — /home/alaskalinuxuser/Documents/projects/phones/compile/cm13/out/target/product/jfltetmo/obj/NOTICE_FILES/src//system/lib/libvterm.a.txt
Notice file: packages/providers/UserDictionaryProvider/NOTICE — /home/alaskalinuxuser/Documents/projects/phones/compile/cm13/out/target/product/jfltetmo/obj/NOTICE_FILES/src//system/app/UserDictionaryProvider/UserDictionaryProvider.apk.txt
Notice file: frameworks/base/packages/WAPPushManager/NOTICE — /home/alaskalinuxuser/Documents/projects/phones/compile/cm13/out/target/product/jfltetmo/obj/NOTICE_FILES/src//system/app/WAPPushManager/WAPPushManager.apk.txt
/bin/bash: mvn: command not found
make: *** [/home/alaskalinuxuser/Documents/projects/phones/compile/cm13/out/target/common/obj/JAVA_LIBRARIES/ambientsdk_intermediates/com.cyngn.ambient.ambientsdk-1.5.8.aar] Error 127
make: *** Waiting for unfinished jobs….
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
make: Leaving directory `/home/alaskalinuxuser/Documents/projects/phones/compile/cm13′

#### make failed to build some targets (04:26 (mm:ss)) ####

Note that the compile failed 4 hours and 26 minutes after I started it. So what failed? Well, apparently, these line are the key:

/bin/bash: mvn: command not found
make: *** [/home/alaskalinuxuser/Documents/projects/phones/compile/cm13/out/target/common/obj/JAVA_LIBRARIES/ambientsdk_intermediates/com.cyngn.ambient.ambientsdk-1.5.8.aar] Error 127

Whenevery you are compiling, you can always spot the problems in your logs by looking for 4 key words: Failed, Error, Warning, and Stop. In this case, the key word was Error. Simply trace that path backwards, or in our case, up one line, and you see what looks like an error in the form of “command not found”. In this case, it cannot find the mvn command, which is a command to start the Maven system. The Maven system is a tool to build Java-based projects. If you didn’t know that, don’t feel bad, I had to look it up, too.
The question was, how do I fix it? Here I spent some time at the terminal.

$ mvn
The program ‘mvn’ is currently not installed. You can install it by typing:
sudo apt-get install maven2

$ sudo apt-get install maven2

This required a lot of dependencies, which proves that the guide does not actually include all of the needed pre-requisites. It makes me wonder, however, if there are more missing programs or files that I need which are not put into the instructions. So, back to work, and we will see what happens when we run the compiler again.

Linux – Keep it simple.