Database Info

[DEV] Kernel development HOWTO and Interactive menu

I havent yet found a simple guide for compiling kernels. Some of them assume too much, and some are just outdated. So I thought I'd write my own for devs/budding devs. Here you go!
Note:
This is not a guide for newbies. It's a dev guide for devs.
Research before asking questions, please
For The Menu driven interactive kernel build script, see Post #31
I will be developing this guide as I go, so it will be incomplete initially, or lacking in detailed explanations.
Essentials:
Ubuntu Box (By this I mean a PC with a Ubuntu installation, not a live CD)
A toolchain-Either the Android NDK, or your own toolchain
HTC Desire GB/Froyo source from htcdevs.com, or sources from github
Familiarity with the linux shell and basic linux commands.
The will to learn
First things first,
1. Getting the sources
The HTC Desire source is available from two kinds of resources-you can either get it from htcdevs.com (official HTC Dev site), or from source code uploaded from someone else. For the purpose of this tutorial, I'll assume we're working on the official HTC GB source code. So download bravo_2.6.35_gb-mr.tar.gz from htcdevs.com.
2. Setting up the compilation box and preparing source code
2.1 Install some essential linux packages from the Linux terminal:
Code:
sudo apt-get install libncurses5-dev
2.2 Extract the source code
The file you downloaded is a tar archive (like a zip file), so you need to extract it to a convenient location. Let's hit the linux shell-open a terminal window in linux (Accessories->Terminal)
Type:
Let's go to our home directory:
Code:
cd ~/
Now, create the directories for our kernel compilation box.
Code:
mkdir -p ~/android/kernel
Now you need to copy the tar.gz file from wherever you downloaded it to, to this dir.
Extract the archive:
Code:
tar -xvf ~/android/kernel/bravo_2.6.35_gb-mr.tar.gz
cd ~/android/kernel/bravo_2.6.35_gb-mr
Now we can view the extracted files within the directory ~/android/kernel/bravo_2.6.35_gb-mr/
2.3 Set up the toolchain
A toolchain is a set of programs which allow you to compile source code (any source code, not just kernels). The toolchain is specific for the processor and hardware, so we need a toolchain specific for Android and especially the Desire. If you're a semiadvanced-pro user, you may consider compiling your own toolchain (See theGanymedes' guide for doing so). If compilation of kernels is all that you require, fortunately for you, there is an easy way-the Android NDK - v7 (latest as of now) is available here
Get the NDK for Linux - android-ndk-r7-linux-x86.tar.bz2
Code:
mkdir -p ~/android/ndk
Now copy the NDK file to ~/android/ndk
Whenever I say copy, you have to manually copy the file with any file manager. Nautilus comes with Ubuntu, and Dolphin with Kubuntu. You may also use the shell of course with
Code:
cp [sourcefile] [destination]
Extract it:
Code:
tar -jvxf android-ndk-r7-linux-x86.tar.bz2
Now add the path for your toolchain to the env variable:
Code:
gedit ~/.bashrc
At the end of the file, add this line:
Code:
PATH=$PATH:~/android/ndk/android-ndk-r7-linux-x86/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin
3. Setting up kernel parameters
Kernels are compiled with a program called gnu make, and use a set of configuration options specified within a file called Makefile.
A vital point to note is that kernels are compiled with a program called gcc (basically the gnu C compiler), and our NDK itself has its own optimized version of gcc. While compiling, we're actually cross compiling it (meaning compiling a binary package on a system which is different from the actual system which is meant to run it- you're compiling it on your PC while it's actually meant to run on your Desire)
This means that when you compile it, you have to make sure that you compile it with the NDK's version of gcc instead of the system version. Otherwise you end up with a kernel meant to run on your pc, duh! Specifying which gcc to use is by the CROSS_COMPILE variable. You can set it up with this command:
Code:
CROSS_COMPILE=arm-linux-androideabi-
Note the hyphen (-) at the end, and do not forget to include it! At compilation time, system will actually use this variable to find all the programs it needs. Eg: The path for gcc will become arm-linux-androideabi-gcc
We can compile kernels with many different options, like with ext4 support, or without; ext4 support as part of the kernel zImage (in which case it makes the kernel larger), or as a loadable module (of the form somename.ko, which is loaded at init.d/init.rc with the command insmod modulename.ko)
We specify the exact options we require with the help of a useful configuration program called menuconfig (which as the name suggests, is a menu for configuration of make options).
An important thing to note is that as far as kernel compilation is concerned, there are a vast amount of options to setup, and unless you're thorough with kernel compilation, you wont be able to set up the options correctly and get your kernel to boot. Fortunately for us, the kernel source already comes with a default set of parameters which can be easily set up.
Note that all make commands must be executed within the directory bravo_2.6.35_gb-mr. Let's go there now:
Code:
cd ~/android/kernel/bravo_2.6.35_gb-mr
make ARCH=arm CROSS_COMPILE=arm-linux-androideabi- bravo_defconfig
This produces a .config file (used by the menuconfig) containing essential parameters to produce a booting kernel for the Desire.
Note: There is a simpler way to get the basic .config file, and this is to get it from a running kernel built by someone else. You can extract the .config from a running kernel with these commands:
Code:
cd ~/android/kernel/bravo_2.6.35_gb-mr
adb pull /proc/config.gz
zcat config.gz > .config
Now we can open menuconfig and add anything we need in addition.
Code:
make ARCH=arm CROSS_COMPILE=arm-linux-androideabi- menuconfig
You can view the huge amount of options available in menuconfig.
You can add ext4 support for example (See image above)
Once you're done choosing options, you can exit menuconfig.
4. Compiling it
This is simple. The basic command is:
make ARCH=arm CROSS_COMPILE=arm-linux-androideabi- -j10
The -j10 specifies the number of jobs to execute per operation. I can usually go upto 50 on my Quad core CPU. Beware, this can bring a slow CPU to a crawl and freeze up linux itself.
During compilation, you will see all sorts of messages, which may include warnings too. In most cases, its safe to ignore warnings. If there are errors, the compilation will stop, and you will have to fix the issues.
5. Distributing your kernel to users
At the end of compilation, it generates files named zImage, and various .ko files.
You have to copy them from their default location to a zip file. The best way is to use my variant of koush's Anykernel, and copy the files to it. Then, you can zip the whole folder and lo and behold-you have your flashable kernel zip which you can distribute to others.
You can also remove the zImage and the modules from /system/lib/modules of any kernel zip available with you, and copy over your files to it, at the correct location.
So, let's say that you have extracted an existing kernel zip to the location ~/flashable
The file structure should be like this:
Code:
|-- kernel
| |-- dump_image
| |-- mkbootimg
| |-- mkbootimg.sh
| |-- unpackbootimg
| `-- zImage
|-- META-INF
| |-- CERT.RSA
| |-- CERT.SF
| |-- com
| | `-- google
| | `-- android
| | |-- update-binary
| | `-- updater-script
| `-- MANIFEST.MF
`-- system
`-- lib
`-- modules
`-- bcm4329.ko
8 directories, 11 files
I've included my flashable zip directory along with this post. Download file kernel_flashable.tar.bz2.zip to ~/
Code:
cd ~/
tar -jvxf kernel_flashable.tar.bz2.zip
This will create the directory structure outlined above.
Now after every compilation of the kernel, execute these commands from where you executed make:
Code:
cp arch/arm/boot/zImage ~/kernel_flashable
find . -name '*ko' -exec cp '{}' ~/kernel_flashable/system/lib/modules/ \;
cd ~/kernel_flashable
zip -r mykernel ./
This will create mykernel.zip at ~/kernel_flashable. You can distribute this to your users to flash. Make sure you edit updater-script before though

Common errors and other stuff
Ok, post #1 was simple stuff. Now, supposing you get errors while compiling. Post #2 is about that, and ups the level of knowledge a bit..
Some kernel compilation errors:
Treat warnings as errors-Solved by removing the string "-Werror" from all Makefiles of the file which failed to compile. Some people had said that the real error (Array out of bounds warning) was because of gcc optimizations. But putting -O2 to -O0 didnt do a thing.
No of jobs - ought not to exceed 50.
"warning: variable set but not used [-Wunused-but-set-variable]"-Look at KBUILD_CFLAGS in the main Makefile. Add -Wno-error=unused-but-set-variable to the existing set of flags.
Note the following from gcc manual:
-WerrorMake all warnings into hard errors. Source code which triggers warnings will be rejected.
-w Inhibit all warning messages. If you're familiar with C code and like to fix stuff, rather than ignoring potential bugs, use this only as a last resort- A 'brahmastram' (most powerful weapon in your time of gravest need) as the epics would say
-WerrorMake all warnings into errors.
-Werror=Make the specified warning into an error. The specifier for a warning is appended, for example -Werror=switch turns the warnings controlled by -Wswitch into errors. This switch takes a negative form, to be used to negate -Werror for specific warnings, for example -Wno-error=switch makes -Wswitch warnings not be errors, even when -Werror is in effect. You can use the -fdiagnostics-show-option option to have each controllable warning amended with the option which controls it, to determine what to use with this option.
So what I did to suppress errors was to add:
Code:
KBUILD_CFLAGS += -w
KBUILD_CFLAGS += -Wno-error=unused-but-set-variable
Though the -Wunused-but-set-variable is not a real issue in itself, it generates so much "noise" that you may miss actual make errors.
This is the error what I was talking about..
Code:
drivers/net/wireless/bcm4329_204/wl_iw.c: In function 'wl_iw_set_pmksa':
drivers/net/wireless/bcm4329_204/wl_iw.c:5075:5: error: array subscript is above array bounds [-Werror=array-bounds]
drivers/net/wireless/bcm4329_204/wl_iw.c:5078:5: error: array subscript is above array bounds [-Werror=array-bounds]
Solution:
Edit drivers/net/wireless/bcm4329_204/Makefile
Locate -Werror within DHDCFLAGS, and delete it.
Code:
DHDCFLAGS = -DLINUX -DBCMDRIVER -DBCMDONGLEHOST -DDHDTHREAD -DBCMWPA2 \
-DUNRELEASEDCHIP -Dlinux -DDHD_SDALIGN=64 -DMAX_HDR_READ=64 \
-DDHD_FIRSTREAD=64 -DDHD_GPL -DDHD_SCHED -DBDC -DTOE -DDHD_BCMEVENTS \
-DSHOW_EVENTS -DBCMSDIO -DDHD_GPL -DBCMLXSDMMC -DBCMPLATFORM_BUS \
-Wall -Wstrict-prototypes -Werror -DOOB_INTR_ONLY -DCUSTOMER_HW2 \
-DDHD_USE_STATIC_BUF -DMMC_SDIO_ABORT -DWLAN_PFN -DWLAN_PROTECT \
-DBCMWAPI_WPI \
This will prevent gcc from treating mere warnings as errors.

How to modify kernels by applying mods - Applying Kernel Patches
Ok, you have compiled a simple stock kernel. Now what? Would you like to add fixes/mods developed by other kernel devs? This post explains patches and how exactly to do this.
Patches to the kernel are applied via patch files. Patch files are simple text files generated by the linux diff program which takes two text files, compares them and writes the differences (hence called diff) to another text file which by convention has the extension .patch
Attached to this post is a patch containing my "Extended battery" fix with Sibere's battfix. I'll explain patching with this. Let's understand the patch file. Open it up in any text editor.
Code:
diff -rupN -X /home/droidzone/android/kernel/exclude.opts bravo_2.6.35_gb-mr/drivers/power/ds2784_battery.c bravo_2.6.35_gb-mr.main//drivers/power/ds2784_battery.c
--- bravo_2.6.35_gb-mr/drivers/power/ds2784_battery.c 2011-08-25 13:16:53.000000000 +0530
+++ bravo_2.6.35_gb-mr.main//drivers/power/ds2784_battery.c 2011-11-06 16:43:21.544317342 +0530
@@ -118,8 +118,11 @@ PS. 0 or other battery ID use the same p
/* Battery ID = 1: HT-E/Formosa 1400mAh */
#define BATT_ID_A 1
#define BATT_FULL_MAH_A 1400
-
#define BATT_FULL_MAH_DEFAULT 1500
+#define BATT_FULL_MAH_CAMERONSINO 2400
+#define BATT_ID_CAMERONSINO
+#define BATT_TYPE 0
+
Note the first line:
Code:
diff -rupN -X /home/droidzone/android/kernel/exclude.opts bravo_2.6.35_gb-mr/drivers/power/ds2784_battery.c bravo_2.6.35_gb-mr.main//drivers/power/ds2784_battery.c
diff -rupN basically describes the command that was used to generate this patch. The -u means that the patch file is something called a universal patch
bravo_2.6.35_gb-mr/drivers/power/ds2784_battery.c was the original file, and bravo_2.6.35_gb-mr.main//drivers/power/ds2784_battery.c was the target file or file which contains the mod..
How to apply patch files?
The command depends on where your current directory is. If you're in ~/android/kernel/bravo_2.6.35_gb-mr/ and your current directory contains the directory 'drivers', you can apply this patch with this command:
Code:
patch -p1<extended_battfix.patch
If you're within drivers, then you have to modify the command like this:
Code:
patch -p2<extended_battfix.patch
Hope you get the gist. Basically, as you move into the source tree, you have to increment the patch level by the number of directories you've moved down into. Very simple, isnt it?

Sharing and Collaborating - Using Github and Commits
Kernel compilation is a group effort (at least it ought to be). When different devs work on different parts of the code and create their own mods, development progresses. For this purpose, it is important that you share your code with other devs. The best way to do this to upload your sources to github.
First, create a github account.
Next you can view other devs' github sources and examine their commits. Commits are basically patches applies to the previous source uploaded. Github commits use the universal patch format and can be viewed directly, downloaded as patch files, and applied to your code. You can also choose to download the whole source tree uploaded by another dev and examine it.

Kernel Build Interactive Menu system
This saves quite a lot of time if you make kernels a lot..
See post #22

Ok, the basic guide is done, guys... If you have doubts, I'll try to clear them

yeah....yeah....yeah...so nice...big thx...will try this as soon as possible..
that is what i searchd so long
edit: rated with 5 stars
with kind regards

Thank you very much droidzone.
I was waiting for a n00b guide.
Tapatalking

good job droidzone
[+1] [ i like]

Added a Howto on how to apply kernel source patch files, to post #3

lol now i understand how patching works.. i write all this **** by myself.. lol

Midian666 said:
lol now i understand how patching works.. i write all this **** by myself.. lol
Click to expand...
Click to collapse
Ha ha.. that would not have been so easy

Droidzone said:
Added a Howto on how to apply kernel source patch files, to post #3
Click to expand...
Click to collapse
sorry for offtopic but nice again and you see many people thought like me with the how to..
with kind regards...Alex

Alex-V said:
sorry for offtopic but nice again and you see many people thought like me with the how to..
with kind regards...Alex
Click to expand...
Click to collapse
I like explaining stuff and sharing..
This guide was written specifically because of your request, and I have never forgotten how you helped when I was a newbie to development.. I wouldnt probably have started developing if not for good responses from Firerat and you.

Droidzone said:
I like explaining stuff and sharing..
This guide was written specifically because of your request, and I have never forgotten how you helped when I was a newbie to development.. I wouldnt probably have started developing if not for good responses from Firerat and you.
Click to expand...
Click to collapse
and now i learn from you lol thx
with kind regards..Alex

Fantastic guide!!!!!!!

Did some more work on the first post. It now includes a flashable zip template and instructions on how to easily create your own flashable zip after compilation is over.

maybe some improvments to your making a flashable zip.
i did this with my kernels.. it took the version infos from the config files.. and put it into a folder... after this u can make zip.
ive stolen this from manus source
Code:
localVersion=`cat .your-config | fgrep CONFIG_LOCALVERSION= | cut -f 2 -d= | sed s/\"//g`
linuxVersion=`cat .your-config | fgrep "Linux kernel version:" | cut -d: -f 2 | cut -c2-`
VERSION=$linuxVersion$localVersion
echo "Kernel version=$VERSION"
rm -rf flash/system/lib/modules/*
mkdir flash/system/lib/modules/$VERSION
mkdir flash/system/lib/modules/$VERSION/kernel
tar czf modules.tgz `find . -name '*.ko'`
cd flash/system/lib/modules/$VERSION/kernel
tar xzf ../../../../../../modules.tgz
cd - > /dev/null
rm modules.tgz

This is good..Actually when I generate kernels I test too many versions that I dont usually change the local version number in the menuconfig. Instead I use the date and time (including second) to name the kernel dir and kernel zip name...
Like this..
Code:
date_str=`date '+%d%m%y_%H%M%S'`
dirname="kernel_"$nameflag"_"$date_str
pckdir="$packagedir/$dirname"
mkdir $pckdir
lastfolder=$pckdir
cd $outdir/
echo
zipnoname="kbase_"$nameflag"_"$date_str
zipaddnoname="kmods_"$nameflag"_"$date_str
zipname=$zipnoname".zip"
zipaddname=$zipaddnoname".zip"
zip -r $zipnoname ./
mv $zipname $pckdir/
As you can see, its part of my script which does a lot of things..
But getting the localversion too is a good thing..I'd put it into a textfile in the zip which users can read..

Great guide. Thanks a lot
Sent from my HTC Desire using Tapatalk

[GUIDE][HACK]Cross Compiling for OSX on Linux with AOSP

Hi Folks
I wasn't sure where this should belong but as it is a bit of an Hack this forum is probably the most appropriate
Introduction
This short tutorial will show you how to patch the Android Build System to allow you to cross-compile Android AOSP host tools ( adb, fastboot etc ) for OSX using a linux based machine. This is something Google said was impossible or at the very least unsupported.
Assumptions
You have a linux based machine and working copy of the AOSP source tree.
You can/have successfully compile(d) a full Android Release from this tree.
A basic idea of how the Android Build System works is beneficial.
Getting Started
I've set-up a git repository which contains a binary copy of the OSX SDK 10.6 and the apple-darwin10-gcc cross compiler. So first things first. open a terminal and set the root of the AOSP sources tree to the current directory.
STAGE 1: Copy the OSX SDK
Step 1.
Clone the repo with the SDK and toolchain
Code:
git clone https://github.com/trevd/android_platform_build2.git build2
Step 2.
Create /Developer directory at your filesystem root, this is a known location for the SDKs
Code:
sudo mkdir /Developer
sudo chown $USER.$USER /Developer
Step 3.
Copy and unpack the SDK package
Code:
cp build2/osxsdks10.6.tar.gz /Developer
cd /Developer
tar -zxvf osxsdks10.6.tar.gz
rm osxsdks10.6.tar.gz
cd - # back to aosp root
STAGE 2 : Swapping the Toolchain
This is where the fun begins :laugh:
The Android Build system has the majority of the infrastructure in place already to build for OSX, the only problem is that you need OSX to build for OSX. However we can remedy that with a couple of dirty hacks :laugh:.
The prebuilts/gcc/darwin-x86 directory contains a toolchain compatible with osx ( mach-o binaries ). We are going to swap this for a linux compatible ( elf ) executables.
Step 4:
Copy and unpack the elf compatible darwin cross toolchain
Code:
cp build2/i686-apple-darwin-4.2.1.tar.gz prebuilts/gcc/linux-x86/host
cd prebuilts/gcc/linux-x86/host
tar -zxvf i686-apple-darwin-4.2.1.tar.gz
cd - # back to aosp root
Step 5:
Remove the mach-o binaries and symlink the elf binaries in it's place
Code:
cd prebuilts/gcc
rm -rf darwin-x86
ln -s linux-x86 darwin-x86
cd - # back to aosp root
Step 6:
We also need to replace the mach-o version of the ccache executable which live in the prebuilt/misc directory
Code:
cd prebuilts/misc
rm -rf darwin-x86
ln -s linux-x86 darwin-x86
cd - # back to aosp root
STAGE 3: Patching the build system .mk files
We need to patch a couple of files in the build directory namely the build/core/combo/HOST_darwin-x86.mk the main crux of this is swapping the ar tool for libtool so static libraries can be created without error.
Code:
patch -p1 < build2/build.patch
If the patch has been applied successfully you should see the following
Code:
patching file system/core/adb/Android.mk
patching file build/core/combo/HOST_darwin-x86.mk
patching file build/core/combo/select.mk
patching file build/core/envsetup.mk
patching file build/envsetup.sh
You are now ready to cross compile!! :good: ..... well not quite, but nearly.... here's why!
The Android Build System will attempt to build both the Target and Host files for most modules so I'd advise using a lunch option which already has a full target built for it or alternatively you can build the generic sdk using the following commands at the AOSP source tree root.
Code:
. build/envsetup.sh
lunch sdk-eng
make sdk
This will stop target dependency errors occurring when you build individual modules.
NOW we're ready to cross compile.
STAGE 4: Building Modules
At present module build is very much a piecemeal process. To build adb for example we need to build the dependencies first. This is not too onerous as most host modules have very few dependencies.
Building adb
adb has dependencies on the following libraries
Code:
external/zlib
external/openssl
system/core/liblog
system/core/libcutils
system/core/libzipfile
I've found the easiest way to compile the dependencies is to navigate to each directory in turn an use to "mm" build system command to compile the individual module. the commands I run to compile adb are as follows.
From AOSP Source Root
Code:
cd external/zlib
USE_DARWIN=true mm -j8
cd ../openssl
USE_DARWIN=true mm -j8
croot # go back to the AOSP root
cd system/core/liblog
USE_DARWIN=true mm -j8
cd ../libcutils
USE_DARWIN=true mm -j8
cd ../libzipfile/
USE_DARWIN=true mm -j8
cd ../adb
USE_DARWIN=true mm -j8
All being well you should now have and adb binary located at out/host/darwin-x86/bin/adb. running the file command on this binary should produce the following output
Code:
adb: Mach-O executable i386
Conclusion
Although this method is a little rough and ready, it should produce the desired results if you need to cross compile for OSX. The eventual goal would be to compile a full OSX Android SDK on linux in a similar manner to the way the windows-sdk is currently compiled. This requires more investigation as compiling the windows sdk on linux employs a little bit of trickery on the part of the build system.
Final Notes and FAQs:
Why can't I just type make <module> from the root?
Doing this triggers building of additional modules such as LLVM and clang which are to deployed out/host/darwin-x86/bin the build system then attempts to use binary later on. These are obviously built for the Mach-o architecture and as such are incompatible with the linux. This results in a build error which can and would be resolved by the above mentioned trickery ( see conclusion )

I use OSX binaries (along with Windows and my native Linux) in one of my projects. Thanks, I have always relied on finding compiled binaries elsewhere. Lack of an OSX aapt held up an update at one point.
One of those things that you don't really use until you need it, but I will try to remember to give it a shot. I don't have any doubt that it works.

mateorod said:
I use OSX binaries (along with Windows and my native Linux) in one of my projects. Thanks, I have always relied on finding compiled binaries elsewhere. Lack of an OSX aapt held up an update at one point.
One of those things that you don't really use until you need it, but I will try to remember to give it a shot. I don't have any doubt that it works.
Click to expand...
Click to collapse
Thanks. Yes this really is an edge case. Hopefully It will help some folks out.
Regarding aapt in particular.... It's perfectly possible to build aapt, however, we need to do some slight of hand with the clang and clang++ executables as libpng on which aapt depends uses these 2 binaries as part of it's build process.
Here's the build list and the clang trick if you want to try it some time.
Code:
build/libs/host
external/expat
external/zlib
system/core/liblog
system/core/libcutils
mkdir out/host/darwin-x86/bin
cp out/host/linux-x86/bin/clang out/host/darwin-x86/bin
cp out/host/linux-x86/bin/clang++ out/host/darwin-x86/bin
external/libpng
frameworks/base/libs/androidfw
frameworks/native/libs/utils
frameworks/base/tools/aapt
I started off with a clean out/host/darwin-x86 directory so I didn't miss any dependencies.
like I mentioned the clang "swap out" is something the make win_sdk option does automatically so with it a little more research I should be able to get the mac build to do the same but you'll have to "fill yer boots" with the ghetto method for now
For reference here's a link to the sdk building instructions http://tools.android.com/build which describes how to cross compile the windows sdk on linux ( in case anyone was wondering what the hell i'm on about)

My use case has come up
I will be cross-compiling for OSX today...specifically with aapt in mind. I will report back, but I fully expect it to work as described.

mateorod said:
My use case has come up
I will be cross-compiling for OSX today...specifically with aapt in mind. I will report back, but I fully expect it to work as described.
Click to expand...
Click to collapse
Cheers Man!
Hopefully no bitrot has crept in since april and now. I know I've changed my OS version since to Lubuntu 13.04, not like the OS version really matters any.
mateorod said:
but I fully expect it to work as described.
Click to expand...
Click to collapse
Then you Sir, are either Drunk or a Fool! LOL Keep expectations Quantum and only decided when the result is observed a'la Schrodinger Cat

okay...So I was trying to compile SlimRom (so as to get an OSX aapt binary with the SlimRom changes) and things did not necessarily go as planned. There were enough changes to the SlimRom android_build that your build/build.patch does not apply cleanly. I spent some time and tried to modify the patch so that it would work for both SlimRom, AOSP and probably others, but each android_build repo has some differences in surrounding the HOST_AR line, so commenting that just was not portable between flavors. Not cool.
Anyway, turns out that this method does not quite work out of the box for non-AOSP versions (not that you claimed that it did). I got some unfamiliar errors related to (I believe) some OSX toolchains. But in both times I tried this, I actually had to pretty immediately swap out of that flavor and so I was unable to do much debugging. (I keep all the flavors I build {CM, AOKP, SlimRom, PAC, PA, OpenPDroid, etc, etc, etc} all layered in one android/system/jellybean directory. It saves a ton of space, but only allows me to do one thing at a time.)
So the only feedback I have is nothing...I even formatted my hard drive in-between and forgot to put up a paste, so the errors are currently lost to history.
Things that I noticed, for better or worse
You recommend putting the SDKs in the root dir. I believe the documentation is recommending the Developer be placed in home (as per the SDK/ADT bundle docs).
You might want a
Code:
mv android_platform_build2 build2
line. I normally wouldn't bother, but it looks like you are trying to post a line-by-line guide.
I would put the recommendation that a full build be available to the out folder (or a built generic sdk) right at the top, since it is a preliminary step. I had to revert my handwritten changes, then build, then reapply the changes and rebuild since I thought it needed a clean out dir.
Did you have any trouble with git reverting the toolchain swap? On two separate machines, I had to go so far as to delete .repo/projects/prebuilts/gcc/* and prebuilts/gcc/darwin-x86/arm/arm-eabi-4.6. It kept complaining of that the project in the .repo folder was a bad match. No amount of git trickery (which I am not terrible at) let me back out more easily.
I am willing to try again...but I have some other small things to attend to first. It is an admirable hack you have here sir. I will return to it soon and report back once more.

mateorod said:
okay...So I was trying to compile SlimRom (so as to get an OSX aapt binary with the SlimRom changes) and things did not necessarily go as planned. There were enough changes to the SlimRom android_build that your build/build.patch does not apply cleanly. I spent some time and tried to modify the patch so that it would work for both SlimRom, AOSP and probably others, but each android_build repo has some differences in surrounding the HOST_AR line, so commenting that just was not portable between flavors. Not cool.
Anyway, turns out that this method does not quite work out of the box for non-AOSP versions (not that you claimed that it did). I got some unfamiliar errors related to (I believe) some OSX toolchains. But in both times I tried this, I actually had to pretty immediately swap out of that flavor and so I was unable to do much debugging. (I keep all the flavors I build {CM, AOKP, SlimRom, PAC, PA, OpenPDroid, etc, etc, etc} all layered in one android/system/jellybean directory. It saves a ton of space, but only allows me to do one thing at a time.)
So the only feedback I have is nothing...I even formatted my hard drive in-between and forgot to put up a paste, so the errors are currently lost to history.
Things that I noticed, for better or worse
You recommend putting the SDKs in the root dir. I believe the documentation is recommending the Developer be placed in home (as per the SDK/ADT bundle docs).
You might want a
Code:
mv android_platform_build2 build2
line. I normally wouldn't bother, but it looks like you are trying to post a line-by-line guide.
I would put the recommendation that a full build be available to the out folder (or a built generic sdk) right at the top, since it is a preliminary step. I had to revert my handwritten changes, then build, then reapply the changes and rebuild since I thought it needed a clean out dir.
Did you have any trouble with git reverting the toolchain swap? On two separate machines, I had to go so far as to delete .repo/projects/prebuilts/gcc/* and prebuilts/gcc/darwin-x86/arm/arm-eabi-4.6. It kept complaining of that the project in the .repo folder was a bad match. No amount of git trickery (which I am not terrible at) let me back out more easily.
I am willing to try again...but I have some other small things to attend to first. It is an admirable hack you have here sir. I will return to it soon and report back once more.
Click to expand...
Click to collapse
Hi
Thanks for this, It sounds like you've suffered an exercise in frustration there. I wasn't aware that "SlimRom" had a different aapt ( just out of general ignorance and not having paid any attention )
SDK - My Tree last time I used this was /Developer directory in the root - I think It comes from what the toolchain is expecting, I just gave it what it wants
mv android_platform_build2 build2 - Yep I did mean that it's the git clone line which wants changing
Code:
git clone https://github.com/trevd/android_platform_build2.git build2
SDK Recommendation - I shall move that to the top, even though it is already in there, It should probably be highlighted better and possible it's own "Stage"
Reverting the toolchain - Ahh , It appears I work slightly different from most in this respect. I have a general mistrust of SCM's ( I lost too much code on too many different SCM's, Probably through my own inability to use them correctly but ) what I do to revert to change is
Code:
cd prebuilts/gcc/darwin-x86/host/
rm -rf i686-apple-darwin-4.2.1
repo sync i686-apple-darwin-4.2.1
You can do this "trick" on any project in the source tree it's only on rare occasions where I screwed up badly that I have to delete anything in .repo/projects but I also have my distro in their own individual directories with there own full git trees, which is a massive waste of space and has a ton of redundancy due to the AOSP repositories being mirror by every single one but switching between them is a lot easier
If SlimRom's changes are localized to aapt, I'd be more inclined to drop it into the AOSP build and try that... If you have a link to slimrom's frameworks/base repository I'll grab it and try it myself.
On a final note there's a "full version" of the HOST_darwin make file in the build2/core/combo directory the changes to envsetup.mk and select.mk are minimal and can easily be applied manually. You don't need to patch the adb makefile if your not building it.
Again Thanks for the feedback

Successful CM 10.1 build on Kali Linux x64 (Guide work-in-progress)

After much frustration with getting things to work on Ubuntu, I switched back to Kali Linux and attempted the same procedure described here ... http://wiki.cyanogenmod.org/w/Build_for_d2spr ... as well as for Ubuntu here ...http://source.android.com/source/initializing.html .... When a step for Ubuntu 10 didn't work I tried the Ubuntu 11 or 12 approach and something always went through regarding setting up the build environment.
***Update-3: Sat Nov 9, 9:59 AM 2013 (Building CM_10.2 : Android_4.3 in progress as of 10:33 AM)***​
Well I screwed up my Linux installation last night trying to put my /usr dir on a seperate partition and some file permission issues broke out with sudo, though everyone suggest 04755, thats what it was at. Kinda trippy, anyways so I found myself having to go through these steps again which gave me a chance to update this:good:...
***These are the packages I installed***​​
Code:
sudo apt-get install git git-core gnupg flex bison gperf \
build-essential zip curl lib32ncurses5-dev libc6-dev libgl1-mesa-dev \
lib32readline-gplv2-dev g++-multilib gcc-multilib mingw32 tofrodos \
python-markdown lib32z1-dev libxml2-utils xsltproc \
libesd0-dev libsdl1.2-dev libwxgtk2.8-dev lzop \
pngcrush schedtool squashfs-tools
The next thing you need to do after getting the build packages to install^^^ is install sun-java6-jdk which you can do following the "kind-of" instructions below regarding debian packages, unixodbc es la pinche problema, (If you see anything I am missing please please inform me).
or
You can install the *.bin file/s from Oracle here http://www.oracle.com/technetwork/j...ds/java-archive-downloads-javase6-419409.html and follow their instructions for getting it installed.
***Notes on sun-java6-jdk debian packages***​I just finished installig sun-java6-jdk and it's dependencies, I downloaded the packages from here ... http://packages.debian.org/squeeze/sun-java6-bin ... all packages were installed using 'sudo dpkg -i [./the/package/was/a.deb]' . For 'unixodbc' I used the dpkg but got an error and ended up using 'sudo apt-get install unixodbc', but that gave a warning about breaking and needing to remove other packages, I did not do that. Then 'sudo apt-get -f install' because it asked me to unless there was another solution. Becarefull and you should be fine. Due to not installing the packages in a specific order I had a run around of a time doing this but it was not too bad, plan ahead and it will be easier. [Note- Makes sure you get all the packages, ie the *-common, *-bin, *-jre, *-jdk etc, etc ]
***Update-3:Continued***​Once you have your new jdk installed don't forget to update alternatives, the alternative manager is basically a really useful tool for keeping track of links in your $PATH to different program versions, for instance if you have two versions of Java, then one will be linked to /usr/bin/java and that link points to the executable with a particular version usually maintained by the "alternatives" program. When you update this 'alternative' java version what you are doing is changing the link /usr/bin/java to point to the executable installed by the sun-java6-jdk package instead of the open-java6-jdk executable. I also like to repoint Eclipse to use sun-java6-jdk as well just to keep it all the same. You can update Eclipse's JDK location from within Eclipse, but I won't go into that here. If you installed java6 with the debian packages as I did, then your sun-java6-jdk installation should be located in "/usr/lib/jvm/java-6-sun-1.6.0.26". If its not there, try issuing this command...
Code:
dpkg -L sun-java6-jdk
...the output may be long, but it will tell you where everything got installed to, you can replace the package name with any other package whenever you need to know where all of it's files get installed, very useful.
Updating alternatives should look something like this depending on which version of the JDK you installed
Code:
sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/java-6-sun-1.6.0.26/bin/java"
, so Google "how to update alternatives for java" or something like that, I might be forgeting something, I have just been trying **** out till it works. You can varify that indeed you are using the correct java executable by issuing the following command...
Code:
[COLOR="Red"][email protected][/COLOR][COLOR="Navy"]:~/cyandekali/system$[/COLOR] java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
[COLOR="Red"][email protected][/COLOR][COLOR="Navy"]:~/cyandekali/system$[/COLOR]
p.s. If thats not the correct output, please let me know.
While your checking version numbers, go ahead and check Git, Python, and Make.
from http://source.android.com/source/initializing.html
Python 2.6 -- 2.7, which you can download from python.org.
GNU Make 3.81 -- 3.82, which you can download from gnu.org,
JDK 6 if you wish to build Gingerbread or newer; JDK 5 for Froyo or older. You can download both from java.sun.com.
Git 1.7 or newer. You can find it at git-scm.com.
Click to expand...
Click to collapse
Checking the versions should look something like this...
Code:
[COLOR="Red"][email protected][/COLOR][COLOR="Navy"]:~/cyandekali/system$ [/COLOR]python --version
Python 2.7.3
[COLOR="Red"][email protected][/COLOR][COLOR="Navy"]:~/cyandekali/system$[/COLOR] make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for x86_64-pc-linux-gnu
[COLOR="Red"][email protected][/COLOR][COLOR="Navy"]:~/cyandekali/system$[/COLOR] git --version
git version 1.7.10.4
[COLOR="Red"][email protected][/COLOR][COLOR="Navy"]:~/cyandekali/system$[/COLOR]
***Notes on Android SDK***​ The Android SDK should already be installed on Kali Linux or at least is when I install using a mirror to get extra packages. All you have to do is this, (I never build as root so you should create another user before doing building.):
Code:
echo "" >> ~/.bashrc
echo "#OURCHANGES" >> ~/.bashrc
echo "export ANDROID_SDK=\"/usr/share/android-sdk\"" >> ~/.bashrc
echo "export PATH=\"\${PATH}:\${ANDROID_SDK}:\${ANDROID_SDK}/tools:\${ANDROID_SDK}/platform-tools\"" >> ~/.bashrc
and then "cat ~/.bashrc" to make sure the changes went as planed.
Code:
cat ~/.bashrc
then "source ~/.bashrc"
Code:
source ~/.bashrc
then "android" and the gui should pop up and you can install all the lates updates or older ones if you want.
Code:
android
Then execute "which adb" it should result in this output "/usr/share/android-sdk/platform-tools/adb"
Code:
which adb
***Notes on USB and ADB***​
Also, don't forget the USB rules for your device. I just used the sytax from source.android.com/source/initializing.html but make sure to add your username that you build with to the OWNER=<"some-user-name-here-is-important"> and I usually change 600 to 666. Also, you don't need all the enteries, just the ones for the device you have you can find the idVendor and idProduct by using the command "lsusb" with your device plugged in, it will look like this.
Code:
[COLOR="Red"][email protected][/COLOR][COLOR="Navy"]:~$[/COLOR] lsusb
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 007: ID [COLOR="Red"]04e8:6860[/COLOR] Samsung Electronics Co., Ltd GT-I9100 Phone [Galaxy S II], GT-P7500 [Galaxy Tab 10.1]
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 004: ID 0489:e04e Foxconn / Hon Hai
Bus 002 Device 003: ID 1bcf:2c17 Sunplus Innovation Technology Inc.
What is in red above ^^^ are the {idVendor}:{idProduct}. I am not sure what to do with fastboot, I am still also learning.
The following is exactly as I have it in my "/etc/udev/rules.d/51-android.rules" file...
Code:
[COLOR="Red"][email protected][/COLOR][COLOR="Navy"]:~/cyandekali/system$[/COLOR] sudo cat /etc/udev/rules.d/51-android.rules
[sudo] password for edge-case:
# adb protocol on maguro/toro (Galaxy Nexus)
SUBSYSTEM=="usb", ATTR{idVendor}=="[COLOR="Red"]04e8[/COLOR]", ATTR{idProduct}=="[COLOR="Red"]6860[/COLOR]", MODE="0666", OWNER="<edge-case>"
# fastboot protocol on maguro/toro (Galaxy Nexus)
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e30", MODE="0666", OWNER="<edge-case>"
Once you have your build enviroment set up you can build CyanogenMod for your device by initializing repo to your chosen repository and then sync'ing it up, most ROMs have their own little tweaks and optimizations so the guide can branch off into many directions at this point. (as far as I know it should work with most if not any other ROM, it worked with ReVolt). If you have any questions what so ever just ask, we all starte somewhere, and vise versa, if I need to be corrected anywhere please take the minute to post a reply, everyone will benifit from it.
And after a long day:
Code:
Package Complete: /home/edge-case/cyandekali/system/out/target/product/d2spr/cm-10.2-20131109-UNOFFICIAL-d2spr.zip
***The rest is history***​Eventually I am going to modify this all so that Android and Kali will become one, I really really want to test my nfs server with my phone as a client
Edit/Update 1: I installed the .zip I built on Kali and it got stuck during boot or init, right before the spinning circle usually comes up. I will try again with sun-java6-jdk and libgeofence.so and report back.
Edit/Update 2: I initialized 'brunch d2spr' without the 'libgeofence.so', I have no idea how vital it is, I am assuming it is only needed for gps. If this fails to boot, then I will add the blob manually and test again.
A question I do have though. Should I be worried about "warning"'s? They come up every now and again it seems like they are C variables or something that get set to UCHAR or unsigned char and warnnings like that, are there any caveats I need to look out for?
The following is what I am refering to, how worried should I be about stuff like this, this build is missing libgeofence.so as stated.
Code:
external/webkit/Source/WebCore/platform/sql/SQLiteDatabase.cpp: In member function 'void WebCore::SQLiteDatabase::setSynchronous(WebCore::SQLiteDatabase::SynchronousPragma)':
external/webkit/Source/WebCore/platform/sql/SQLiteDatabase.cpp:229:75: warning: passing 'WebCore::SQLiteDatabase::SynchronousPragma' chooses 'int' over 'long unsigned int' [-Wsign-promo]
external/webkit/Source/WebCore/platform/sql/SQLiteDatabase.cpp:229:75: warning: in call to 'static WTF::String WTF::String::number(int)' [-Wsign-promo]
external/webkit/Source/WebCore/platform/sql/SQLiteDatabase.cpp:229:75: warning: passing 'WebCore::SQLiteDatabase::SynchronousPragma' chooses 'int' over 'long int' [-Wsign-promo]
external/webkit/Source/WebCore/platform/sql/SQLiteDatabase.cpp:229:75: warning: in call to 'static WTF::String WTF::String::number(int)' [-Wsign-promo]
external/webkit/Source/WebCore/platform/sql/SQLiteDatabase.cpp:229:75: warning: passing 'WebCore::SQLiteDatabase::SynchronousPragma' chooses 'int' over 'unsigned int' [-Wsign-promo]
external/webkit/Source/WebCore/platform/sql/SQLiteDatabase.cpp:229:75: warning: in call to 'static WTF::String WTF::String::number(int)' [-Wsign-promo]
In hindsight, the above ^^^ just meant it was working, just in case your wondering the same thing, if you see that kind of output after starting your build, you probably can go make some dinner or take a nap espescially if it's the first build, then you might want to go out to the movies or something, unless your like me and like trying to read stdout as it flys up the screen :good::good::cyclops:
I used Open-Java6-JDK and at the initialization of the 'brunch d2spr' command it complained about the Java Version but continued to build, I haven't installed the zip as I also on a rush built without 'libgeofence.so' or some such 'glob'.
Also, I am having trouble finding an official source to download 'libgeofence.so' , does anyone have a link they can point me to?
I did get this one but I have no idea about it's trust worthyness....http://downloads.codefi.re/houstonn/lgog_pro/unzipped/lib/libgeofence.so

Actually CM 10.2 but I need 10.1 [Reason 4 Failure?]
Ok so I built the second zip using sun-java6-jdk with no libgeofence.so, it installed but did not boot properly as did the first try with open-java6-jdk.
I did a 'make clean' and this was the output :
Code:
[COLOR="Red"]PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=[B][COLOR="Blue"]4.3.1[/COLOR][/B]
CM_VERSION=[B][COLOR="Blue"]10.2[/COLOR][/B]-20131013-UNOFFICIAL-d2spr
TARGET_PRODUCT=cm_d2spr
TARGET_BUILD_VARIANT=userdebug
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
TARGET_CPU_VARIANT=krait
HOST_ARCH=x86
HOST_OS=linux
HOST_OS_EXTRA=Linux-3.7-trunk-amd64-x86_64-with-debian-1.0
HOST_BUILD_TYPE=release
BUILD_ID=JLS36I
OUT_DIR=/home/edge-case/CyAnDeKaLi/system/out
[/COLOR]
It may vary well be that it is trying to build for Android 4.3.x , what do you think?
I am thinking it was from the 'repo sync -j4 -c', what can I execute to clean my repo and re-sync it with 4.2.1 or 4.2.2 ?
Which I guess would be CM 10.1.x instead of CM 10.2.x (which may not be compatible with my phone's firmware)
Edit/Update: As I was looking through the nightlies at the CM website I noticed a "fix boot hang" version of CM 10.2 this may be a known issue with 10.2, also I guess the command is during the repo init:
Code:
[COLOR="Indigo"]repo init -u git://github.com/CyanogenMod/android.git -b [COLOR="Red"][B]cm-10.2[/B][/COLOR][/COLOR]
I guess I will just delete everything and start fresh replacing 10.2 with 10.1 and see how things go. Maybe the build was more "successful" than I thought after it didn't boot (ie the build went fine but the code just isn't there yet), or missing that libgeofence.so is fatal.
I had an idea that kinda relates to the topic, what if people where able to donate their C-CACHE's to the "cloud" so that other developers could speed up theirs, like a kind of high availability cluster. Though some kind of algorithm would need to be developed to identify whats what and what different and more than I can think of right now.

It really did work!
It is confirmed, the build is working on Kali Linux, I suppose I could write a step by step guide if any body asks.
Now the next step...Sewing CyanogenMod Android Debian Kali Linux into CyAnDeKaLi.
Sent from Samsung Galaxy SIII SPH-L10 running CyanogenMod 10.1 built on Kali Linux.

Cleaned it up a bit, more of a guide, this would probably work on most Debian distros.
If the Orange is too much, let me know but for now it is all the new stuff in case you were following along, most of the other stuff is just me talking to myself in public.
peace,
Edge-Case

I successfully built CM 10.2 on Kali Linux by following CyanogenMod's instructions on their wiki.
I thought I was the only one who was building ROM on Kali linux, But I was wrong
KALI LINUX FTW!!

mzahmed95 said:
I successfully built CM 10.2 on Kali Linux by following CyanogenMod's instructions on their wiki.
I thought I was the only one who was building ROM on Kali linux, But I was wrong
KALI LINUX FTW!!
Click to expand...
Click to collapse
Run Kali with Cyanogenmod (no chroot)?

Edge-Case said:
Run Kali with Cyanogenmod (no chroot)?
Click to expand...
Click to collapse
Sorry, But I didn't get your question....
Sent from my GT-N7100 using Tapatalk

mzahmed95 said:
Sorry, But I didn't get your question....
Sent from my GT-N7100 using Tapatalk
Click to expand...
Click to collapse
Ah, just a lil' project I decided to torture myself with. It's CyanogenMod with added Linux executables I picked from Kali's and Debian's armhf repos. It requires glibc to be placed in /lib of the Android file system hierarchy, which is normally not there. Also, a few tweaks to file and directory permissions need to be done, with out those tweaks to Android before the build, /lib and everything in it won't be executable and the owner:group gets changed to something like root:shell 644 or something. It has to do with the sticky bit that I am still trying to fully comprehend as Android implements it as a security feature. I heard removing a configuration flag to the kernel when building will get rid of the whole paranoid feature and allow more access to thing like file/socket creation.
Basically, Android with apt, nmap, wireshark-cli, aircranck-ng, tcpdump(which comes from the Android ports), and what ever else anyone wants really, even the whole (what works on arm that is) Kali pentesting suite if desired.
Though one caveat is that both glibc and bionic have to be loaded up into memory (RAM) from what I understand, and the amount of that resource varies, as well as /system storage (which is about 2g on sph-l710), but bind mounting from .img file or extSdCard also works (so long as owner:group and sticky bit has been adjusted correctly before build). Though I am having trouble mounting during init, so I just run a script when I turn my phone on, about to auto script it as a service or just use sl4a's feature. I got one builld that is a bit of a skeloton working, but all my attempts to tweak init.rc to mount what I want have resulted in failure to boot.
I am almosted tempted to take a BSD rootfs and try to hack together something that will boot BSD with Android as the "window server" taking the place of kde4 or gnome2. It would be an endever, maybe I should stick with debian based linux because it alsready runs on Android so long as glibc is available.
Edit: Interestingly enough I found this in FreeBSD's "/usr/ports/devel/android-tools-adb"
Code:
[email protected]:/usr/ports/devel/android-tools-adb$ cat pkg-descr
Android Debug Bridge (adb) is a versatile command line tool that
lets you communicate with an emulator instance or connected
Android-powered device.
WWW: http://developer.android.com/tools/help/adb.html
[email protected]:/usr/ports/devel/android-tools-adb$
I just got done building openjdk6, I saw bison, gcc, I have git, python27.... hmm....I heard about a Linux compatability layer... It might be more possible than I thought to build on FreeBSD. I searched "Build Android on FreeBSD" and saw some projects such as BroidSD, BSDroid (which looks like its bit rotting), GnatDroid. I think BSDroid even wanted to get Android running on the FreeBSD kernel!
I think watchdog needs to be picked out of NetBSD's arm rootfs though.
edit 2: Taada
Code:
[email protected]:/usr/ports/devel/android-tools-adb #make install
.....
.....
.....
===> Installing for android-tools-adb-4.3
===> Generating temporary packing list
===> Checking if devel/android-tools-adb already installed
install -s -o root -g wheel -m 555 adb /usr/local/bin/
===> Registering installation for android-tools-adb-4.3
===> SECURITY REPORT:
This port has installed the following files which may act as network
servers and may therefore pose a remote security risk to the system.
/usr/local/bin/adb
If there are vulnerabilities in these programs there may be a security
risk to the system. FreeBSD makes no guarantee about the security of
ports included in the Ports Collection. Please type 'make deinstall'
to deinstall the port if this is a concern.
For more information, and contact details about the security
status of this software, see the following webpage:
http://developer.android.com/tools/help/adb.html
[email protected]:/usr/ports/devel/android-tools-adb #
Not quite a build environment on FreeBSD yet, but hey, adb is a good start. As long as the dependencies are there it should work. I might need to set some enviroment variables if I do try to build on FreeBSD.
Code:
[email protected]:/etc/devd # adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
c90855ae device
[email protected]:/etc/devd #
Just make sure to accept the rsa key on the phone/tablet... I almost thought I had more configuration to do but no, it works.
Update: Fri Nov 22, 2013
Well of all the build-tools I have these installed on FreeBSD:
bison, curl, flex, git, gperf, gnugp, open-jdk-6, open-jre-6, pngcrush, squashfs-tools, xsltproc, and zip.​
These I don't have or don't know if I do have and they are named differently:
build-essential, lzop, schedtools, zlib1g-dev, libesd0-dev, libncurses5-dev, libsdl1.2-dev, libwxgtk2.8-dev, libxmil2-utils, g++-multilib, gcc-multilib, lib32ncurses5-dev, lib32readline-gplv2-dev, and lib32z1-dev.​
If anyone has any knowledge they'd like to share regarding the packages I can't find and their possible counterparts for FreeBSD, please do share.
Note: It may be easier to build within a debian chroot/jail. -> ( http://blog.vx.sk/archives/22-Updated-Tutorial-Debian-GNUkFreeBSD-in-a-FreeBSD-jail.html )
BSDeb Chroot notes:
- I couldn't access the internet to apt-get at first in the jail, so I exited and then chrooted back into it and networking worked.
- squeeze's dpkg is old, upgrade to wheezy to get multi-arch support. -> ( http://www.howtoforge.com/how-to-upgrade-debian-squeeze-to-wheezy )
- I ran into this error while upgrading:
Code:
[....] Mounting kernel filesystems...mount: fdescfs : No such file or directory
invoke-rc.d: initscript freebsd-utils, action "start" failed.
dpkg: error processing freebsd-utils (--configure):
subprocess installed post-installation script returned error exit status 1
configured to not write apport reports
Errors were encountered while processing:
freebsd-utils
E: Sub-process /usr/bin/dpkg returned an error code (1)
This fixed that:
Code:
mount -t fdescfs fdescfs /jail/debian/dev/fd/
Update on FreeBSD Debian chroot:
I couldn't install some packages, with squeeze because dpkg doesn't support multiarch at version 1.5. After upgrading to Wheezy, libc6-dev or libc6-dev:i386 could not be installed, was using libc0.1 for KFreeBSD Debian. Also lib32ncurses5-dev and lib32readline-gplv2-dev could not be installed with Wheezy. Perhaps with Jesse or Sid.
Oh well, enough of that, time to study.

Guide: Compile /system/bin binaries for your device from AOSP source code

Now tested up to downloading AOSP and make toolbox you should be all set
Please give thanks to this thread: https://forum.xda-developers.com/newreply.php?do=newreply&p=43622764
Warning: I hacked my way through this stuff a few weeks ago I am not an expert!
How to compile Android Open Source Code modules​
I don't compile C code on Windows machines I have no idea about that.
Notice
This guide is a quick and dirty how to make a module. It will not cover finalizing setting up the source codes for your device. It is only my goal to enable you to compile binaries such as grep, toolbox, dumpstate, dalvikvm, jack and etc.
===>] Setup Ubuntu 64bit [<===​Unplug that Windows drive, plug in a fresh hard drive and install Ubuntu latest/greatest. Ignore the recommendation to downgrade gnu make!, for now.
Open a terminal and issue these commands (warning ppa repository for OpenJDK 7 is said to have a security issue?, isn't being updated?.. whatevs it works)
Code:
sudo apt-get update
sudo apt-get upgrade
sudo add-apt-repository ppa:openjdk-r/ppa
sudo apt-get install openjdk-7-jdk
sudo apt-get install openjdk-8-jdk
sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386 lib32z1 libbz2-1.0:i386
sudo apt-get install git ccache automake lzop bison gperf build-essential zip curl zlib1g-dev zlib1g-dev:i386 g++-multilib python-networkx libxml2-utils bzip2 libbz2-dev libbz2-1.0 libghc-bzlib-dev squashfs-tools pngcrush schedtool dpkg-dev liblz4-tool make optipng
(choose Java 1.7 in the following way)
Code:
sudo update-alternatives --config java
(let me know if I missed anything please)
"Tried the Android SDK only it is missing too many things we need as a developer"
===>] Setup Android Studio SDK & NDK [<===​Installation Paths:
*** I install to /home/username/Android and /home/username/Android/Sdk and /home/username/Android/Sdk/ndk-bundle ***
NOTE: from here forward username will == droidvoider
Note: Android Studio IDE isn't necessary only the SDK & NDK are needed to compile AOSP.
Install Android Studio Proper: (don't worry about setting up paths we will cover that, just install it)
https://developer.android.com/studio/install.html
or
SDK Only:
Typically we install these things manually by creating the directory then just unzipping the files there.
https://developer.android.com/studio/index.html#linux-bundle (scroll down for sdk only)
Code:
mkdir /home/droidvoider/Android
mkdir /home/droidvoider/Android/Sdk
(then unzip the sdk zip to that directory. I recommend the file explorer copy/paste right click uncompress and done.)
https://dl.google.com/android/repository/tools_r25.2.3-linux.zip
Install NDK through the SDK Manger:
(from terminal 'studio.sh' and then configure, and then sdk manger --- if this is hard to figure out tell me I will elaborate)
or
Manually Install Native Development Kit -- 'c programming support'
Download the Native Development Kit from Google: https://developer.android.com/ndk/downloads/index.html
Code:
mkdir /home/droidvoider/Android/Sdk/ndk-bundle
Then just unzip the ndk files into the directory we created above.
===>] Setup your toolchain [<===​** This example is arm64-v8a aarch64 **
1. Navigate to /home/droidvoider/Android/Sdk/ndk-bundle/build/tools and then open a terminal "right click open area"
2. mkdir /home/droidvoider/toolchains
3. ./make_standalone_toolchain.py --arch arm64 --api 23 --stl=libc++ --install-dir /home/mm/toolchains/aarch64-linux-android-4.9
4. cd /home/droidvoider
5. gedit .bashrc and morph this in at the bottom.. (AND edit or replace the existing PATH variable)
DON'T just PASTE IN *my* $PATH export!! I included my entire path statements to show you.
Code:
export PATH=$PATH:/usr/local/android-studio/bin:/home/droidvoider/Android/Sdk/platform-tools:/home/droidvoider/Android/Sdk/ndk-bundle:/home/droidvoider/Android/Sdk/tools
I feel this is human readable, for example change Android_Build_Out to be on your desktop instead if you want.
Code:
export PATH=$PATH:/home/droidvoider/toolchains/aarch64-linux-android-4.9
export NDK=/home/droidvoider/Android/Sdk/ndk-bundle
export SYSROOT=$NDK/platforms/android-23/arch-arm64
export TARGET=aarch64-linux-android
export HOST=$TARGET
export BUILD=x86_64-linux
export ANDROID_NDK_BIN=/home/droidvoider/toolchains/aarch64-linux-android-4.9/bin
export CC=$ANDROID_NDK_BIN/aarch64-linux-android-gcc-4.9
export CPP=$ANDROID_NDK_BIN/aarch64-linux-android-g++
export AR=$ANDROID_NDK_BIN/aarch64-linux-android-ar
export OUT_DIR_COMMON_BASE=/home/droidvoider/Android_Build_Out
Note: You might want to setup an alternate toolchain also but this is all of the puzzle pieces.
===>] Google's version of this How To -- Just for reference [<===​https://source.android.com/source/requirements.html
https://source.android.com/source/initializing.html
===>] Install the repo tool [<===​https://source.android.com/source/downloading.html
(don't type repo init or repo sync --- I will be taking back over from there on the next page)
Added Repair Notes -- Not part of the install!
Have you accidentally installed or removed something you shouldn't have? (welcome to development, here try this before reinstall)
sudo apt-get clean
sudo apt-get update
sudo apt-get install -f
sudo dpkg -a --configure
sudo apt-get dist-upgrade
sudo apt-get install -f
sudo dpkg -a --configure

Selecting the correct AOSP branch and downloading it.
Tested up to downloading AOSP and make toolbox -- you should be all set
===>] Match your build number to it's AOSP sources [<===​preface: You can get this from your device if you're on the same build id as your the available source code from your vendor for your device. Otherwise you need to open the AP file from the firmware that matches those available sources to extract the system.img, to extract build.prop. I explain how to open a system.img file below under retrieving your hardware drivers. build.prop is in the main directory of system.img
(Many times the build number is the same. For me I believe all of MM builds are using this number.)
Assumes sources match current device, worked out true in my case
1. Plug in your device and get it connected. (DEVELOPER OPTIONS|USB DEBUGGING) and select allow on device
2. Retrieve the build number that matches the available sources for your device.
From your ubuntu terminal retrieve the build id using this command:
Code:
adb shell getprop | grep 'ro.build.id'
Yields something similar to this: [ro.build.id]: [MMB29K]
3. Match it up to the Nexus build numbers (This info is for AT&T Note 5 Marshmallow MMB29K, get your specific build number!)
https://source.android.com/source/build-numbers.html#source-code-tags-and-builds
MMB29K android-6.0.1_r1 Marshmallow Nexus 5, Nexus 5X, Nexus 6, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg)
===>] Bring down a specific AOSP source branch [<===​
4. Make a directory for the source code.
Code:
mkdir /home/droidvoider/Desktop/AOSP_Android_6.01_r1
5.
Code:
cd /home/droidvoider/Desktop/AOSP_Android_6.01_r1
6. Bring down the sources, this one is approximately 13 gigabytes
Code:
repo init --depth=1 -u https://android.googlesource.com/platform/manifest -b android-6.0.1_r1
repo sync
===>] I'm not sure the rest of this is needed [<===​For compiling toolbox the remainder wasn't needed.. But I have a large list of things to do so I can't test each item. If you can't compile a specific module continue reading.
===>] Merge Vendor sources & AOSP sources [<===​
7. Download the available sources for your device. In this example I downloaded PE6 Marshmallow sources for AT&T Note 5:
http://opensource.samsung.com/reception/receptionSub.do?method=sub&sub=F&searchValue=SM-N920A
8. Read the readme file from the sources platform zip to understand how to merge them into the AOSP sources. For the 2 Samsungs I've worked with the idea is to replace any directory that already exists. But if there is just one file such as core.mk only replace the one file. Then edit the .mk files as described in your readme. (and/or take info from cyanogen/lineagos) -- <I can help more, ask>
note: you probably don't need to take the configs from LineageOS and put them into your .mk files. However, if you do need to get more configs then you should get a big fat message when you type make 'modulename'. At first only edit .mk files as described by vendor device source readme file.
===>] Merge in Hardware drivers and etc [<===​possibly unnecessary depends what you're doing
9. Obtain a copy of the firmware for your device that matches the version of the source code you are able to download from your vendor.
for me that was Build Number: MMB29K.N920AUCU2BPE6 but your mileage will almost certainly vary!
10. Download https://github.com/anestisb/android-simg2img
11. Unzip it right in your download folder, open the folder and then 'open in terminal'
12. Make it and then move it a directory in your path. Warning: My command puts in in the Ubuntu default /bin folder.
Code:
make
sudo mv append2simg img2simg simg2img simg2simg simg_dump.py /bin
13. Uncompress the AP file from the matching firmware and extract the system.img into it's own directory
then select that folder, right click, open in terminal
Code:
simg2img system.img sys.raw
mkdir sys
sudo mount -t ext4 -o loop sys.raw sys/
14. A drive mounted, look on your task bar it should've wiggled too. Copy the etc and vendor folders into the main folder of the sources we are merging

===>] Listing and building modules [<===​Navigate to the folder where you download the sources "/home/droidvoider/Desktop/AOSP_Android_6.01_r1" and open in terminal.
Code:
make modules -- list the available modules
make <module name> -- builds a specific module
example: make dumpstate
description: Will build everything needed for dumpstate and place it in the folder we specified in our export (above step). The final build line will read install and detail the final output folder
Example successful output:
[CODE]
Install: /home/droidvoider/Android_Build_Out/Android_6.01_r1/target/product/generic/system/bin/dumpstate
===>] Android Build System, basic intro [<===​Notice: I built this how to to answer the same question from 3 people regarding working with toolbox and the dirtycow exploit. So I decided to give a direct example of using toolbox.c from farm-root
#ifdef
Our makefile is Android.mk and that's where we link things together. If you look at the Android.mk file for farm-root you will notice bridge.c is used 3 different times called different 'module' names. bridge_pull, bridge_push, bridge_pull_boot. Each of these will be binaries of those names.
Inside bridge.c you will see #ifdef FARM_PULL and then you will see #else and further you will see #endif which you may have noticed matches inside the Android.mk file for the bridge modules -DFARM_PULL -DFARM_BOOT <== Notice the double define on bridge_pull_boot
toolbox.c
toolbox.c is going to be the same way. You will need to copy shared.h and shared.c into the directory where toolbox.c resides. Then edit the Android.mk, in our example:
1. Navigate to this directory and open: system/core/toolbox/Android.mk
2. CTRL + F and search for "LOCAL_MODULE := toolbox"
3. Add: LOCAL_CFLAGS += -DFARM_PULL -DFARM_BOOT (in this example add one, both or even new ones you created)
4. Navigate to the main directory of the sources, you should see a Makefile and a build_64bit.sh
5. from terminal: make toolbox
Note: I think from here you can Google it out in a few minutes if that is not the case please let me know.

Working with C cross platform​Ubuntu is Linux based just like Android and this makes testing blocks of code extremely easy. You of course can't use Android headers and in some rare cases you can't test the code on Ubuntu at all but in most cases you can. When I want to design something for Android I open gedit and save it as a .c file. Then I compile it using gcc -o mycode mycode.c There's plenty of examples on using gcc with linux but just understand you can do it all. Then before too much work test it on Android. (helpful commands at end of post)
My advice really is to build out your small blocks of code on your linux box but then paste them into your Android program folder, edit your Android.mk, add it to your Makefile including your 'push' section so that you can simply type make push to test it.
I am in fact trying to encourage you to learn C and not so much trying to encourage you to hack things. But I know that interest/passion is what teaches, not my words and not someone else's curriculum. So in that spirit I will do my best to give examples to help you with 'whatever' it is you are passionate about. Let me know what's missing.
Don't forget to compile for Android first
Before you can test your code you will have compiled it using the cross compiler for Android. ndk-build, or the correct gcc cross compiler. (Personally I put the .c file into a directory with Android.mk and a Makefile then just type make to build it to Android)
see examples section I will add a couple examples.
Android Developer Bridge -- a developers tool
adb is included with the Android SDK along with some other tools. Some of those tools are fastboot for unlocking bootloaders and another way of flashing. There is monitor which is a cool tool for remotely viewing processes, logcat, memory dumps and etc.
But pointedly what we will use the most is simply adb.
Using adb to test your code on locked down Android systems
Shell has fairly high privileges, you may not be aware but you can execute binaries and bash scripts. We use /data/local/tmp/ for these things. You can create a directory, add or remove files, execute your binaries and even execute shell scripts using sh script.sh
ndk-build places the binary in libs/(arch type) .. For a quick test you can just open a terminal in that directory then:
Code:
adb push mybinary /data/local/tmp/
adb shell
cd data/local/tmp
chmod 777 mybinary
./mybinary

Added:
Examples of basic make files for Android.
happy coding
If you get an error​Please reissue the command but pipe the output to a file.
make toolbox > /home/droidvoider/Desktop/build_toolbox-output.txt
zip that up with your source code, including your customized header files and attach it to this thread.
puzzles are fun but I like all the pieces

droidvoider said:
Tested up to downloading AOSP and make toolbox -- you should be all set
===>] Match your build number to it's AOSP sources [<===​preface: You can get this from your device if you're on the same build id as your the available source code from your vendor for your device. Otherwise you need to open the AP file from the firmware that matches those available sources to extract the system.img, to extract build.prop. I explain how to open a system.img file below under retrieving your hardware drivers. build.prop is in the main directory of system.img
(Many times the build number is the same. For me I believe all of MM builds are using this number.)
Assumes sources match current device, worked out true in my case
1. Plug in your device and get it connected. (DEVELOPER OPTIONS|USB DEBUGGING) and select allow on device
2. Retrieve the build number that matches the available sources for your device.
From your ubuntu terminal retrieve the build id using this command:
Code:
adb shell getprop | grep 'ro.build.id'
Yields something similar to this: [ro.build.id]: [MMB29K]
3. Match it up to the Nexus build numbers (This info is for AT&T Note 5 Marshmallow MMB29K, get your specific build number!)
https://source.android.com/source/build-numbers.html#source-code-tags-and-builds
MMB29K android-6.0.1_r1 Marshmallow Nexus 5, Nexus 5X, Nexus 6, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg)
===>] Bring down a specific AOSP source branch [<===​
4. Make a directory for the source code.
Code:
mkdir /home/droidvoider/Desktop/AOSP_Android_6.01_r1
5.
Code:
cd /home/droidvoider/Desktop/AOSP_Android_6.01_r1
6. Bring down the sources, this one is approximately 13 gigabytes
Code:
repo init --depth=1 -u https://android.googlesource.com/platform/manifest -b android-6.0.1_r1
repo sync
===>] I'm not sure the rest of this is needed [<===​For compiling toolbox the remainder wasn't needed.. But I have a large list of things to do so I can't test each item. If you can't compile a specific module continue reading.
===>] Merge Vendor sources & AOSP sources [<===​
7. Download the available sources for your device. In this example I downloaded PE6 Marshmallow sources for AT&T Note 5:
http://opensource.samsung.com/reception/receptionSub.do?method=sub&sub=F&searchValue=SM-N920A
8. Read the readme file from the sources platform zip to understand how to merge them into the AOSP sources. For the 2 Samsungs I've worked with the idea is to replace any directory that already exists. But if there is just one file such as core.mk only replace the one file. Then edit the .mk files as described in your readme. (and/or take info from cyanogen/lineagos) -- <I can help more, ask>
note: you probably don't need to take the configs from LineageOS and put them into your .mk files. However, if you do need to get more configs then you should get a big fat message when you type make 'modulename'. At first only edit .mk files as described by vendor device source readme file.
===>] Merge in Hardware drivers and etc [<===​possibly unnecessary depends what you're doing
9. Obtain a copy of the firmware for your device that matches the version of the source code you are able to download from your vendor.
for me that was Build Number: MMB29K.N920AUCU2BPE6 but your mileage will almost certainly vary!
10. Download https://github.com/anestisb/android-simg2img
11. Unzip it right in your download folder, open the folder and then 'open in terminal'
12. Make it and then move it a directory in your path. Warning: My command puts in in the Ubuntu default /bin folder.
Code:
make
sudo mv append2simg img2simg simg2img simg2simg simg_dump.py /bin
13. Uncompress the AP file from the matching firmware and extract the system.img into it's own directory
then select that folder, right click, open in terminal
Code:
simg2img system.img sys.raw
mkdir sys
sudo mount -t ext4 -o loop sys.raw sys/
14. A drive mounted, look on your task bar it should've wiggled too. Copy the etc and vendor folders into the main folder of the sources we are merging
Click to expand...
Click to collapse
And where is exactly the main folder? Sorry, Im just confused

DigitalDoraemon said:
And where is exactly the main folder? Sorry, Im just confused
Click to expand...
Click to collapse
it's no problem this stuff isn't easy to just figure out on your own. remember to substitute droidvoider for your ubuntu user name
In this example my sources are on my desktop in a folder named Android_6.01_r1
Sources for toolbox for example:
/home/droidvoider/Desktop/Android_6.01_r1/system/core/toolbox/<sources will be here including Android.mk>
Script for modules, including toolbox
/home/droidvoider/Desktop/Android_6.01_r1/Makefile <--- this is our modules script, if you will
<open a terminal in the above folder then use that Makefile like so>
make toolbox <---- this will compile only what is needed to compile the module 'toolbox' (this takes a minute)
Out export folder we decided in ./home/droidvoider/bashrc
/home/droidvoider/Android_Build_Out/Android_6.01_r1/target/product/generic/system/bin

Anybody, please compile grep utility for arm and x86... Minimum Platform Version Android 4.0.3, API Level - 15
Thanks

Great & useful .

A noob tries his hand at ROM development for the MiA1 tissot

The problem with reading the articles on XDA is that eventually you want to try out some of the things described in these pages. I am no exception. After reading the superb article https://forum.xda-developers.com/mi-a1/how-to/guide-build-rom-source-tissot-t3754723 I decided to try my hand at developing the ROM for the Xiaomi MiA1. This is my daily driver and that in itself was a strong reason for motivation.
I tried replicating the steps given in the article on my Dell Inspiron and immediately ran into issues. The basic requirements mentioned are a linux or Mac computer. So to start with I formatted my laptop. Removed windows 10 and installed Ubuntu's latest 18.04 LTS.
I believed I had the next set of requirements for custom ROM development which were
• A basic understanding of Linux based OS specifically Ubuntu.
• Ability to type and use the command line. Write or copy paste commands in the Ubuntu konsole.
• A basic understanding of programming concepts, read and update XML files, understand error messages.
• Fast internet access.
• Steady electricity supply.
• Lots and lots of patience.
This still did not solve my problem. The build would crash repeatedly. Then I read the https://source.android.com/setup/. A whole new set of requirement came up. The article said that ideally the build system should exceed these conditions
• 64 bit environment
• 100 GB of free hard disk space
• 16 GB RAM / swap space.
At home my son was about to buy a new PC and this made his old PC available. I upgrade the RAM and added a new hard disk. Now my hardware configuration was as under :
• Intel i5 processor
• 16 GB RAM
• 1 TB hard disk.
With a new hard disk I had to create a boot-able USB drive. This I achieved with Rufus. My old laptop which again had its Windows 10 installation was used to install Rufus based on the instructions i got from https://rufus.akeo.ie/
The latest version of Ubuntu I downloaded from https://www.ubuntu.com/download/desktop
Setting Ubuntu from scratch for someone used to the world of windows is not exactly easy. I found the tutorial at https://tutorials.ubuntu.com/tutorial/tutorial-install-ubuntu-desktop#0 extremely helpful.
I wrote down the steps I took in reaching the final goal of a Lineage ROM for my Mi A1.
Step 1: Setup Ubuntu - already completed
I chose the default settings as recommended in the setup.
Step 2: Installation of Java Development Kit
Once Ubuntu was up and running I opened a konsole window and typed the following commands
PHP:
sudo apt-get update
sudo apt-get install openjdk-8-jdk
Ubuntu did all the installing as I looked on.
Step 3: Installing required packages
PHP:
sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev libgl1-mesa-dev libxml2-utils xsltproc unzip
Step 4: Configure your smart phone access
I next installed the tools required to access the phone. This access would be required to later flash the phone or access its internals with ADB.
PHP:
sudo apt-get install android-tools-adb
sudo apt-get install fastboot
Step 5: To creating the work directories i typed the following commands. I was following the instructions from the above two articles alternately.
PHP:
mkdir -p ~/bin
mkdir -p ~//lineage
Step 6: Installing repo
I was informed that the Android source tree is located in a Git repository which is hosted by Google. The Git repository includes metadata for the Android source. Repo is a tool that makes it easier to work with Git .
PHP:
curl [url]https://storage.googleapis.com/git-repo-downloads/repo[/url] > ~/bin/repo
Once the repo was downloaded I had to make it executable
PHP:
chmod a+x ~/bin/repo
Step 7: The next step was to initialize the lineage source
This required to change to the directory created in step number 5 above. As someone coming from the world of windows I preferred to use the GUI and open the lineage folder created by using the mouse click. There right click brings up the option of ' Open in Terminal' . Those who prefer to type commands can use the below command
PHP:
cd ~//lineage
Once I had made sure that I was in the newly created lineage folder I moved ahead.
Step 8: Now i was required to configure my Git user
PHP:
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
I replaced the text within the " " with my creadentials, which I had created on https://github.com/
Step 9: Now we moved on to initializing the repo
PHP:
repo init -u [url]https://github.com/LineageOS/android.git[/url] -b lineage-15.1
A successful initialization showed a message stating that Repo is initialized in your working directory. The lineage directory now contain a .repo folder. To check hidden folder I used control + H key.
Step 8: Download the source code
This is the step where you will realize the importance of having a fast internet connection. The source code size is about 30 – 35 GB. I have a 10 mbps line and at times the download speed shoots up to 20- 25 mbps!!!* Yet it takes me anything from 4 – 10 hours to download the entire code!
My suggestion is check the time when your local ISP download speeds are at its best. For me it is during the night. I set the download up at night and go to sleep!
The command to get the source code is :
PHP:
repo sync -c -f --force-sync --no-clone-bundle --no-tags --optimized-fetch –prune
Optional Step 8 a: Making a backup of your source code
I copied the entire folder and kept a copy on an external device. This is just in case there is any need for me to format my hard disk. While copying I do not copy the .Repo and .Cache folders on to my backup. To check hidden folders press control + H keys.
Step 9: Get the source code for your specific device.
This is where I was stuck numerous times. As I understood the code which was downloaded is generic in nature. For your particular device you would need to get files which are specific to your device.
The source for all these files is github. You are targeting three sets of folders – Device, Kernel and vendor.
The git clone commands given below are for the tissot or Xiaomi MiA1 phone. Similarly other phones have their locations on GitHub from where you can get files specific to them.
PHP:
git clone [url]https://github.com/TheScarastic/andr...msm8953-common[/url] -b lineage-15.1 device/xiaomi/msm8953
git clone [url]https://github.com/TheScarastic/andr..._xiaomi_tissot[/url] -b lineage-15.1 device/xiaomi/tissot
git clone [url]https://github.com/TheScarastic/prop..._vendor_xiaomi[/url] -b lineage-15.1 vendor/xiaomi
git clone [url]https://github.com/Tissot-Developmen..._xiaomi_tissot[/url] -b 8.1 kernel/xiaomi/msm8953
Step 10: Modify Caching to speed up the build process.
PHP:
export CCACHE_DIR=./.ccache
ccache -C
export USE_CCACHE=1
export CCACHE_COMPRESS=1
prebuilts/misc/linux-x86/ccache/ccache -M 50G
Step 11: Configure JACK
JACK is the java compiler and can cause crashes – believe me! A simple fix is this command which you type next
PHP:
export _JACK_VM_ARGS="-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4G"
Step 12: Cleaning up the build folder
PHP:
make clean
Step 13: Initializing the build
PHP:
source build/envsetup.sh
Step 14: Starting the build
PHP:
croot
brunch tissot
Watching the build on the screen is an interesting phase. It can get a bit tedious. In my case it took about 3 hours to complete the build. There were numerous errors that were thrown up. Files were declared as missing. After a couple of failures I realized I could search for them and then paste the file in the appropriate folders.
The one good thing about the build errors is googling for them usually gets you the right help. There would definitely be someone in some part of the world who would have run into a similar issue.
Finally after a 3 hour wait I got my zip file which when i flashed through TWRP on my MiA1. The sheer joy of having a ROM you created on your phone is indeed beyond words. It took me about a week of sitting for about ten to fifteen hours to get the various combination right, but believe me when I tell you the results are worth it.
My thanks to arunassain https://forum.xda-developers.com/member.php?u=6768248 from whose article I was able to understand the basics. He helped me with responses to my queries when I was stuck.
I further picked up from the excellent articles under the title Establishing a build Environment at https://source.android.com/setup/build/initializing
A great video that helped me was available on the topic How to build your own custom Android ROM at https://www.androidauthority.com/build-custom-android-rom-720453/
To check out the ROM's built for the MiA1 please click here
Now coming to the question if I have understood everything that is to learn about ROM development, well the answer is no. This was just the first build by a noob of a ROM which somehow worked. I have been using the ROM on my daily driver for the past one day and it is working perfectly. Having said that I still need to understand more of what happens behind the scenes in this wonder world of Custom ROM development.

Don't tell me you thought that you could build a rom on x86 processor/OS

Give him a break, he admitted that he is new to this building ROM world, I can understand that some people can think that if a proc is powerful enough they can use it to build no matter if it's a x64 or x86.
Thanks for you story mate! And don't hesitate to ask dev on telegrams or G+ to explain you some what you don't understand :good: I'm pretty sure that would love to finally have someone like you, who is truly interested in this whole world