Video Tutorial on How to Compile Android and Modify Kernels

video

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.

[CODE]
+ 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
+ AND MORE!
[/CODE]

**** This is an UNOFFICIAL TUTORIAL. Use at your own risk! ****
Download links:
Ogg Vorbis Video GitLab:
[url]https://gitlab.com/alaskalinuxuser/course_android_developer_guide[/url]
Clicking on a video in GitLab will allow you to watch it online.

Ogg Vorbis Video Downloads:
[url]https://gitlab.com/alaskalinuxuser/course_android_developer_guide/-/archive/master/course_android_developer_guide-master.zip[/url]
This download is rather large due to the multiple videos.

MP4 Video GitLab:
[url]https://gitlab.com/alaskalinuxuser/course_android_developer_guide_mp4[/url]
Clicking on a video in GitLab will allow you to watch it online.

MP4 Video Downloads:
[url]https://gitlab.com/alaskalinuxuser/course_android_developer_guide_mp4/-/archive/master/course_android_developer_guide_mp4-master.zip[/url]
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.

Advertisements

New builds! New device! The N915T Galaxy Note Edge!

While I don’t have one yet, I have decided that I will be getting one of these Galaxy Note Edge phones. They are a couple years old, and the price on them is going down significantly. In the meantime, I noticed that there were not very many custom roms available for them. Actually, there are only 2 roms that are not just modifications of stock roms. Those two roms are CM 12.1 (Lollipop) and Resurrection Remix (Marshmallow).

So, I decided to build some of my own. To God be the glory, it worked! Well, sort of.

Working with a group of willing testers, I have put together this rom:

http://www.mediafire.com/download/lccy75jfrx8itmt/pac_tbltetmo__20160909-125802.zip

At this time, it does not have functioning WiFi or Cellular, but it is a start. It is my hope to continue working on this and get it squared away. For now, it is a fun Alpha teaser to try out.

Some of the main problems with custom roms on this phone is the “edge” feature. The curved glass edge has never truly been done justice by a non-touchwiz rom, which I suspect is why most stick with the stock roms, or modifications thereof.

My long term goals are to find a way to put the edge back into play, and to also make the s-pen fully functional. Short term goals are to get the usual hardware working. If you have a N915T, feel free to try out this alpha build, but remember, it is not a daily driver yet.

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/version_defaults.mk, where you should see this line:

[CODE]
ifeq “” “$(PLATFORM_SECURITY_PATCH)”
# 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.
PLATFORM_SECURITY_PATCH := 2016-02-01
endif
[/CODE]

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:
https://source.android.com/security/bulletin/index.html

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:
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-0818

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:
https://android.googlesource.com/platform/external/conscrypt/+/4c9f9c2201116acf790fca25af43995d29980ee0

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:

[CODE]
@@ -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;
+ }
+ }
+ }
}
anchors.add(anchor);
}
[/CODE]

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:

[CODE]
PLATFORM_SECURITY_PATCH := 2016-02-01
[/CODE]

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.

Adding pre-built apps to your build

One of the big things that always comes up is that of adding pre-built apps to your build. Make is so dynamic that you could add these in just about anywhere, provided that you properly add them to your configuration files. For myself, I used to add them into the vendor directory, but this became tedious when I would switch to build something else with the same repository, or when I would update or change to other repositories but wanted the same pre-built apps.

I recently realized that there was an easy way around this, and I wanted to share that with others. Most of you probably already know how to do this, but perhaps someone can benifit from this. Besides, if I ever forget, I can just look here for a reference!

I like to add the Kernel Adiutor app to my JFLTETMO (Samsung Galaxy S4, T-Mobile variant) builds. Like I mentioned above, I used to put it in the vendor directory. What I realized though, is that I can simply add it to my jfltetmo repository under the devices. For my device, I have a jfltetmo repository, which essentially sets a few flags and passes the buck to the jf-common repository for building. So, I actually added the app to my jf-common repository. Now, when I sync, it updates my jf-common directory, and keeps my prebuilt app!

Here is what I did.

Added some folders:

In my jf-common repository (dev/samsung/jf-common) I added a directory called “prebuilt”. In keeping with Android’s common structures, I then created these two folders: “common” and in that folder, one called “app”.
When you are done making directories, it should have a path like this:

[CODE]
jf-common/prebuilt/common/app
[/CODE]

Now, in the “app” folder, I placed my prebuilt app, the Kernel Adiutor app, which I named “ka.apk”. I then made an Android.mk file in the “prebuilt” folder that looks like this:

[CODE]
# Copyright (C) 2012 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
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an “AS IS” BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

LOCAL_PATH := $(call my-dir)

#
# Prebuilt APKs
#

include $(CLEAR_VARS)
LOCAL_MODULE := ka
LOCAL_MODULE_OWNER := aokp
LOCAL_SRC_FILES := common/app/$(LOCAL_MODULE).apk
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE_SUFFIX := .apk
LOCAL_MODULE_CLASS := APPS
LOCAL_CERTIFICATE := PRESIGNED
include $(BUILD_PREBUILT)
[/CODE]

You can add as many prebuilt apps as you want this way, just make the above block for each app. Then you simply add them to your jf-common.mk file in the jf-common directory. You can substitute your device name here, it should work the same. Notice that the lines which have more than one app have the “\” denoting that there are more files to add. Pretty simple, right?

[CODE]
# WJH adding kernel adiutor apk
PRODUCT_PACKAGES += \
ka \
camera.msm8960
[/CODE]

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:

[CODE]
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:
lollipop
Use the ROOMSERVICE_BRANCHES environment variable to specify a list of fallback branches.
build/core/product_config.mk:234: *** 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?
[/CODE]

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:

[CODE]
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 (http://github.com/LiquidSmooth-Devices).
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
[/CODE]

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.

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:

[CODE]
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: [OMX.google.vorbis.decoder] resubmitting CSD
07-12 06:43:32.468 244 3846 I NuPlayerDecoder: [OMX.google.vorbis.decoder] 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.
[/CODE]

Using the OpenCamera App for comparison:

[CODE]
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 : [OMX.google.h264.encoder] 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 : [OMX.google.h264.encoder] 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
[/CODE]

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

[CODE]
ACDB-LOADER: Error: ACDB EC_REF_RX returned = -8
MediaRecorder: stop failed: -1007
[/CODE]

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:

https://github.com/alaskalinuxuser/android_device_samsung_jf-common/commit/bce04ddbb06bcae14642dfd117860ab291d5026a

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.

 

Error: Exited sync due to fetch errors

Error: Exited sync due to fetch errors

[CODE]
$ repo sync
………EDITED FOR SPACE………
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
$
[/CODE]

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:

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

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

[CODE]

<remote name=”ls”
fetch=”https://github.com/LiquidSmooth/&#8221;
review=”https://gerrit.liquidsmooth.net/”/&gt;

<remote name=”cm”
fetch=”git://github.com/CyanogenMod” />

<default revision=”refs/tags/android-5.1.1_r24″
remote=”aosp”
sync-c=”true”
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/root.mk” dest=”Makefile” />
</project>
<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” />
………….EDITED FOR SPACE…………….
[/CODE]

Which, in this case I edited as so:

[CODE]
<!– 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” />
[/CODE]

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:

[CODE]
$ 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
[/CODE]

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

[CODE]
$ mkdir ~/bin && curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo && chmod a+x ~/bin/repo

$ gedit ~/.bashrc
[/CODE]

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

[CODE]
export PATH=~/bin:$PATH
[/CODE]

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:

[CODE]
$ cd ~
$ mkdir omni6
$ cd omni6
$ repo init -u git://github.com/omnirom/android.git -b android-6.0
$ repo sync
[/CODE]

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:

[CODE]
$ cd ~/omni6/
$ cd device
$ mkdir samsung
$ cd samsung
$ git clone https://github.com/DirtyUnicorns/android_device_samsung_jfltetmo -b m-caf jfltetmo
$ git clone https://github.com/DirtyUnicorns/android_device_samsung_jf-common -b m-caf jf-common
$ git clone https://github.com/DirtyUnicorns/android_device_samsung_msm8960-common -b m-caf msm8960-common
$ git clone https://github.com/DirtyUnicorns/android_device_samsung_qcom-common -b m-caf qcom-common
$ cd ..
$ git clone https://github.com/DirtyUnicorns/android_device_qcom_common -b m-caf qcom-common
$ mkdir qcom
$ cd qcom
$ git clone https://github.com/DirtyUnicorns/android_device_qcom_sepolicy -b m-caf sepolicy
$ cd ~/omni6/
$ mkdir -p kernel/samsung
$ cd kernel/samsung
$ git clone https://github.com/DirtyUnicorns/android_kernel_samsung_jf -b m-caf jf
$ cd ~/omni6/vendor/
$ git clone https://github.com/TheMuppets/proprietary_vendor_samsung -b cm-13.0 samsung
[/CODE]

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:

[CODE]
[
]
[/CODE]

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

[CODE]
$(call inherit-product, device/samsung/jfltetmo/full_jfltetmo.mk)

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

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

PRODUCT_BUILD_PROP_OVERRIDES += \
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
[/CODE]

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

[CODE]
#
# 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
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an “AS IS” BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#

PRODUCT_MAKEFILES := \
$(LOCAL_DIR)/omni_jfltetmo.mk
[/CODE]

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

First Run:

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

============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=6.0.1
TARGET_PRODUCT=omni_jfltetmo
TARGET_BUILD_VARIANT=userdebug
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
TARGET_CPU_VARIANT=krait
TARGET_2ND_ARCH=
TARGET_2ND_ARCH_VARIANT=
TARGET_2ND_CPU_VARIANT=
HOST_ARCH=x86_64
HOST_OS=linux
HOST_OS_EXTRA=Linux-3.16.0-73-generic-x86_64-with-Ubuntu-14.04-trusty
HOST_BUILD_TYPE=release
BUILD_ID=MOB30M
OUT_DIR=/home/alaskalinuxuser/Documents/projects/phones/compile/omni6/out
============================================

============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=6.0.1
TARGET_PRODUCT=omni_jfltetmo
TARGET_BUILD_VARIANT=userdebug
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
TARGET_CPU_VARIANT=krait
TARGET_2ND_ARCH=
TARGET_2ND_ARCH_VARIANT=
TARGET_2ND_CPU_VARIANT=
HOST_ARCH=x86_64
HOST_OS=linux
HOST_OS_EXTRA=Linux-3.16.0-73-generic-x86_64-with-Ubuntu-14.04-trusty
HOST_BUILD_TYPE=release
BUILD_ID=MOB30M
OUT_DIR=/home/alaskalinuxuser/Documents/projects/phones/compile/omni6/out
============================================
including ./abi/cpp/Android.mk …
<<<<<<<<<<EDITED FOR SPACE>>>>>>>>>>>>>
build/core/base_rules.mk:157: *** 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
[/CODE]

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/Android.mk like so:

[CODE]
# 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_PATH := $(TARGET_OUT_SHARED_LIBRARIES)/hw

# WJH LOCAL_SHARED_LIBRARIES := liblog

# WJH LOCAL_MODULE := lights.msm8960

# WJH LOCAL_MODULE_TAGS := optional

# WJH include $(BUILD_SHARED_LIBRARY)
[/CODE]

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:

[CODE]
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….
[/CODE]

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:

/home/alaskalinuxuser/Documents/projects/phones/compile/cm13-working/kernel/samsung/jf/firmware/audience-es325-fw-eur.bin

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.