Hi,
when I compile android (using instructions from source.android.com/download) it does not compile some source files. For example there is external/bluetooth/bluez/sbc/sbc.c which is not compiled. There are also other such files.
It's possible those files need not to be compiled. Or it might be that I need some special configuration to compile them.
Either way, if it is possible, I'd like to compile them all. Is there some way to do it? Maybe some "compile_all" make target? Some additional options that need to be set?
(I believe the reason why I want to compile all source files is not important)
Hi ,
enter to the build directory and do
1) " . envsetup.sh " ( you can read this file to get informations about building )
2) after return to the top of directory and make just " m "
tell me what happened
regards
Hi.
I'm a veteran Android app developer but i am new to building roms, especially in the whole android build system.
It all started when trying to build the secured version of su.... i'm still unable to build it, the build system seems to ignore hte includes and claims there are undefined references to functions like get_property etc...
My main question is, i saw in the android build tree under /external that there are tcpdum, pcap and many nice to have applications i'll be happy to load on my device and compile for it (yes it's rooted)
My main steps in building (after checking out using repo) are:
run the . build/envsetup.sh script
run lunch generic-eng from the root of the srouce
run make
now my question is how do i make sure ALL the applications in the external folder are built ? should i change the build/code.mk to include their LOCAL_SRC name ? or is there a parameter i can pass to 'make' that should do the trick ?
Another question regarding the su itself is that it's Android.mk file did not contain LOCAL_MODULE_TAGS := sentence and i had to add it myself, anyone managed to successfully compile that file ?
Also anybody got some documentation regarding how to use the sqlite3 functions (or is it the std library and the documentation exist in the sqlite3 site ?)
10x
it seems to be a small problem with 2.3, once i checked out 2.2, compiled it using:
. build/envsetup.sh
launch generic-eng
make
all the binaries were built, since target was arm then all the binaries should be ok with the devices that use 2.2.
After the build i downloaded the su-binary from the git to $source_root/external/su-binary
changed the name in the Android.mk to su-binary so it wont collide with the system/external/su and run mm in the $source_root/external/su-binary dir.
Everything was build nicely.
I'll check the sqlite3 docs for refference but i'll appreciate anyone that knows the IBInder interface and the like that can explain the intnet send code (why not use am binary like in prev versions ? )
Short Version: How do I build the android.jar file? I have downloaded the source files from source.android.com already.
Long Version: The Android.jar file you get when you download the SDK contains all the application framework classes for android . . . sort of. Upon examining the actual source files downloaded separately, I have found numerous java source files that are not included in android.jar from the SDK. Obviously they must be included in the android.jar on your phone, otherwise things like VoiceDialer wouldn't work. The only workaround I can think of is to build my own android.jar from source and configure it to include those files.
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
About this guide
I have been building kernels for many machine types and have been fiddling around with custom android kernels for my own phone but to my great frustration the rules changed quite a lot for my new phone. It seems every kernel after 2017 is A LOT harder to build and needs quite some fiddling around te get it to boot. The documentation is terrible the least on the steps and all howtos are all outdated by now. This guide shares with you the secrets to build yourself a modern post 2017 kernel from source. I only own a op7 at this moment but I am pretty sure the rules apply to all devices.
So why do we need to build our own kernel? Well that's simple. I have scrolled through many custom kernels missing a simple module that I need. In my case binfmt. Perhaps you need a specific device driver compiled into your kernel or you want to hack in/patch in some special functions that are only needed by you. Or you love a certain kernel but need that one little adjustment in the configs that this kernel doesn’t have and so on.
Lets get through it step by step but I do assume you know something about Linux, you know how to use the terminal and that you have some knowledge on building binaries from source. Ready? Ok lets get started.
These steps are required to be followed to be successful:
1. Set up a building environment
2. Obtain the kernel source
3. Download the proper tool-chain
4. Adjust configuration files to match your needs
5. Build the actual kernel image
6. Backup your current boot.img!!!
7. Trow the image into a anykernel zip and flash it.
8. Close your eyes prey and run the kernel.
Prerequisites
You will need:
A fairly fast computer with lets say 4 gigs of RAM and a decent CPU.
A workable linux distribution that you can boot into (I prefer ubuntu bionic at this moment).
The kernel sources for your device.
ROOT!!
Lots of spare time.
A attitude that makes you unstoppable.
1. Setting up the building environment
Ok lets first open a terminal. You will need the terminal a lot. As a matter of fact it will be your friend through this guide so better get used to it. Assuming you are on a ubuntu like distribution lets fetch the important packages first
Code:
$sudo apt install build-essential bizon flex git
This command will install some of the prerequisites you need to do anything. More packages will need to be installed on the way but at least you will be able to type $make
Now lets create a working directory. Go into your home folder and create a working directory which will later on contain your kernel sources and tool chain.
Code:
$cd
$mkdir [COLOR="MediumTurquoise"]name-of-your-working-folder[/COLOR]
2. Obtain the kernel source
This one is tricky as my experience have learned me the kernel sources supplied by my own vendor are usually badly documented and contain a few bugs here and there resulting in either build errors or a unbootable kernel. So usually I grab a custom kernel that has minimal changes to the stock kernel and boots by only using a single kernel file without extra kernel modules attached. The custom kernels usually have the nasty building bugs flawed out and thus your chances for success are higher. I used the exkernel in my case and out of respect for the hard work of flang2 I bought the app that came along.
To get the sources google around and find the sources on for example git and click the download or clone button there and copy the link of the depository.
Then simply clone the depository to your working directory so after changing to your working directory type
Code:
$git clone link-you-just-copied
Git will now automatically clone the entire kernel source into the source sub-directory. You can change the name of this directory to make you life easier.
3. Download the proper tool-chain
This is where I lost many days and weeks of my life. Where do we find the proper tool-chain for our kernel?
You basically need 3 compilers
clang
GCC
device-tree-compiler
There are many versions of clang and GCC and you will need to find the one that matches your kernel and builds for your cpu architecture. I will assume in this guide that your CPU is aarch64 or arm64 (both names are used at the same time).
To obtain clang head over to the following address:
"https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86/"
now in the tags and branches you can find the version of android you are looking for. If your kernel is for android 9 then use the android 9 tag. Click on it and then click tgz which will provide you with a huge tarball.
Create a folder in your working directory named toolchain en extract the contents of the tarball into the sub-folder clang.
You can try any subversion of clang there is but I recommend to simply peek into the build.config files located in the root of your kernel source directory which usually specify the exact subversion of clang used.
Time to get GCC which is easier since there is only one version right now.
Head over to
"https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9/"
and use the correct version here as well. In my case I picked the latest build. Then do the same as for clang but name the sub-folder GCC or whatever you please to do.
And then finally get yourself the device-tree-compiler
Head over to
"https://github.com/dgibson/dtc/tree/v1.4.4"
and clone this depository into ~/your-working-directory/toolchain/
and navigate to the subdir you cloned it into
then build by typing
Code:
$make
any missing package errors will need you to install them using
Code:
$sudo apt install missing-package-name
and do make again until the build completes.
If all went well your tool-chain and working directory will look like this:
Code:
/[COLOR="mediumturquoise"]current-working-dir[/COLOR]/[COLOR="mediumturquoise"]kernel-source-dir[/COLOR]/
|
/toolchain/
|
/clang/
/gcc/
/dtc/
4. Adjust configuration files to match your needs
Lets first grab the correct defconfig file and setup the build directory. This defconfig file contains the default kernel configuration parameters which you propably want to adjust.
Head over to ~/working-directory/kernel-source-dir/arch/arm64/configs/
see what you can find there. I found the elementalX_defconfig file which is the file I needed to build the Exkernel from scratch. If you are trying a stock kernel dive a little bit deeper into the vendor folder and see if you can find a good config file there.
Alternatively sometimes the config is hidden on your device itself. Have a look at
/proc/config.gz
the file inside the archive contains a valid defconfig for your device but beware your may need to open it with menuconfig first and save it again to make it workable for the compiler script.
Place the defconfig file you like to use into the configs folder.
(Skip the following step if your are going to build your kernel for the first time because we first want to see it work.)
Now head over to your kernel source dir and type the following command
Code:
$PATH="~/[COLOR="mediumturquoise"]working-dir[/COLOR]/toolchain/clang/[COLOR="mediumturquoise"]clang-r353983c[/COLOR]/bin:~/[COLOR="mediumturquoise"]working-dir[/COLOR]/toolchain/gcc/a[COLOR="mediumturquoise"]arch64-linux-android-4.9[/COLOR]/bin:${PATH}" \
make menuconfig O=out \
ARCH=arm64 \
CC=clang \
CLANG_TRIPLE=aarch64-linux-gnu- \
CROSS_COMPILE=aarch64-linux-android-
now remember to use the correct paths to your tool-chain. In this command I use clang-r353983c but you may use a different version. The same applies for linux-android-4.9.
I would like to thank Nathan Chance for supplying documentation on the clang tool-chain on his github.
If all well you will be presented with a menu in which you can adjust things. First open the defconfig file you wish to use and then save the file after you are done. Now REMEMBER! With this command the menuconfig will save your new file into the /kernel-source-dir/out folder.
(end of the skipped step)
Now it is time to prepare our kernel build using the following command (do this from your kernel source dir) and remember that this command will look in the /kernel-source-dir/arch/arm64/configs/ directory
$make O=out ARCH=arm64 name-of-your-defconfig
If all goes well you will see something like configuration written to .config
Everything is up and ready to go. Your hart will start pounding from this moment on
5. Build the actual kernel image
This is where things get complicated. I hope you have many years to live because this part consumes time, a lot of it.
type
Code:
$PATH="~/[COLOR="mediumturquoise"]working-dir[/COLOR]/toolchain/clang/[COLOR="mediumturquoise"]clang-r353983c[/COLOR]/bin:~/[COLOR="mediumturquoise"]working-dir[/COLOR]/toolchain/gcc/[COLOR="mediumturquoise"]aarch64-linux-android-4.9[/COLOR]/bin:${PATH}" \
make -j$(nproc --all) O=out \
ARCH=arm64 \
CC=clang \
DTC=~/[COLOR="mediumturquoise"]working-directory[/COLOR]/toolchain/dtc/dtc \
CLANG_TRIPLE=aarch64-linux-gnu- \
CROSS_COMPILE=aarch64-linux-android-
ready set GO!
This will depending on your machine take between forever and eternally. You will witness many warnings on the DTC build seems normal these days and a few warnings on the CC part. Most important is that no errors are thrown at you.
If all goes well you will see a normal exit status and you will have a “working” kernel image.
“Error?: Well that happens. Try a different build of clang check your command line. And if all that fails try to find out what is wrong in the source and that means digging through thousands of forum pages until you find out whats wrong. But using the google tools usually goes well.”
Almost there go and check
kernel-source-dir/out/arch/arm64/boot
and there should be a image-dtb or image.gz-dtb file depending on you settings.
That is your kernel image right there. The difference in size between image and image-dtb should not be huge. 10Megs in difference usually means your dtb is not good but trying is the only way to find out if it works.
6. Backup your current boot.img!!!
You know what to do here right? Do not skip this step unless you like bricked devices or want to reflash and lose your data and all that kind of stuff. Not sure what you are doing stop here or backup your entire device including system vendor etc.
7. Trow the image into a anykernel zip and flash it.
Ok something changed in the last few years. Unpacking repacking and booting using fastboot somehow gives me problems. Dm-verity errors and all kind of red screens. Signing the boot image results into new errors. Well this is how I did it.
Get yourself a anykernel zip file. I used the Exkernel.zip because it only contains a kernel image which I like. Open the zip in a good zip tool (I used ark) and replace the image-dtb file with the one you created. Place this new zip you created on a memory stick and then….
Flash it using twrp or any tool of choice.
8. Close your eyes prey and run the kernel.
Two things can happen.
1. Blank screen nothing happens. Only god can help you, repeat all the steps.
2. Your android starts booting. Start crying of joy
Check in your android if this is indeed the kernel you build. If so time to make some adjustments to your configs or happily enjoy your boosted phone.
Now please remember. If you plan to distribute your kernel that you do the correct steps of accrediting the original programmer and trow the source online. If you use a already custom kernel please respect the hard work of the maker and communicate your plans with him/her.