Related
I wanted to start a thread to post ASE scripts. They support three different languages and while gscript is amazing, this seems to have a lot of availability for saving the time of making entire programs for one or two functions that don't need an entire UI. Plus they can run after you close ASE, so its not a once and done environment. I would like to compile scripts here to make them easy to find.
Mods: This is not a build related topic, it spans all builds. It is not a duplicate, as the only searchable post was a link to the program. It is development because while the scripts can replace programs (in which case id post in app forum), I want to use this to do nodding and on-the-fly enhancements (development forum)
Good idea. I'm going to bump this
This just rocked my world.
ASE Blog
ASE Google Code page
ASE Faq
ASE Lua API
ASE Python API
ASE User Guide
Download ASE 0.7a
Am I the only person who thinks that ASE is completely useless ?
Actually, the method used is a HUGE hack (using JSON embedded in a TCP socket is not the cleaner thing I saw) -- ok I'm not so deeply into ASE source code, but still.
... and, the API available is very very lightweight compared to Android's standard library.
Why not having an app which just exports the current Context object into a Beanshell context ? (and maybe having access to the interpreter via adb). Here, we could have access to the whole Java APIs and do nearly exactly what we can do know using plain Java code. It would be clearly awesome !
A better thing would be using Groovy, but it doesn't seem to like dx.
I've already tried to launch the Beanshell interpreter via ASE, but it fails (when the same script works on my computer).
Anyone make (or find) any cool scripts?
I honestly like the idea of the ASE scripting because it gives people the ability to write scripts and learn about it.
Great!
This is great. Just one thing I'd change: It would be nice to split the daemon package and the language support packages.
I, for one, have debian installed and already running a python environment with many extensions installed. I'd prefer to install just the "service" part of ASE, copy android.py to my site-packages directory and integrate it into existing scripts. I'd keep ASE running on a fixed port and start modifying existing scripts to utilize the ASE service.
Mini Howto: Using ASE from debian
I wanted to use ASE from the debian installed on my android phone and did some minor patching to accommodate the fact that debian still uses python 2.5 whereas ASE requires python 2.6.
Here's how you do it:
Install the required packages:
Code:
# if you don't have python already
apt-get install python
# python 2.5 doesn't have json but this package will do.
apt-get install python-simplejson
Copy android.py from ASE to debian:
Code:
cp /data/data/com.google.ase/python/lib/python2.6/android.py /usr/lib/python2.5/site-packages/android.py
Apply this patch to android.py, to remove python 2.6 dependencies:
Code:
cd /
patch -p0 <<EOF
--- /data/data/com.google.ase/python/lib/python2.6/android.py 2009-06-14 22:48:06.000000000 +0000
+++ /usr/lib/python2.5/site-packages/android.py 2009-06-15 00:58:31.000000000 +0000
@@ -14,7 +14,7 @@
__author__ = 'Damon Kohler <[email protected]>'
-import json
+import simplejson as json
import os
import socket
import sys
@@ -25,7 +25,8 @@
class Android(object):
def __init__(self):
- self.conn = socket.create_connection(('localhost', PORT))
+ self.conn = socket.socket()
+ self.conn.connect(('localhost', int(PORT)))
self.client = self.conn.makefile()
self.id = 0
EOF
That's it.
To use it:
Activate ASE and start a terminal. (I hope future versions of ASE will run the service independent of the terminal and will no longer require this).
In your debian terminal:
Code:
export AP_PORT=$(netstat -napt|sed -n 's/^tcp.*127.0.0.1:\([0-9]*\).*LISTEN.*ase$/\1/gp')
python
The above export is required because ASE currently uses a random port. I hope future versions of ASE will allow selecting a fixed one.
Now you can use ASE from your debian's python, the same way you would in ASE's terminal:
Code:
Python 2.5.2 (r252:60911, Nov 15 2008, 00:34:24)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import android
>>> a=android.Android()
>>> a.makeToast('debian')
{u'result': None, u'id': 0, u'error': None}
>>>
Now you can start porting scripts to use ASE
I have been trying to figure out how to reboot my phone using any of the interpreters in ASE.
I have tried the following in Lua.
os.execute("reboot")
and I get permission denied.
I have tried
os.execute("su")
os.execute("reboot")
but then the terminal changes from $ to # and nothing happens.
Get the same results using os.system() commands in python.
Anyone have any ideas on how to make this work? Seems like it ought to be simple but I have no experience in these languages.
Try "su -c /system/bin/reboot".
mod1 said:
Try "su -c /system/bin/reboot".
Click to expand...
Click to collapse
Thanks for the help but I still got "not permitted!"
Script to query Amazon
This isn't much but I'm an Amazon book junkee and I've tried all the bar code scanners in the market and none of them will just take me directly to the Amazon page for an item I scan without having to click several different buttons first.
So, without further adieu:
Code:
import android
"""start barcode scanner and scan barcode"""
droid = android.Android()
code = droid.scanBarcode()
ISBN = (code['result']['SCAN_RESULT'])
"""open browser at the first google i'm feeling lucky link which typically will be the amazon page for the item"""
url = "http://www.google.com/search?hl=de&q=site%3Aamazon.com+" + ISBN + "&meta=lr%3Dlang_en&btnI=I'm+feeling+lucky"
droid.startActivity('android.intent.action.VIEW', url)
The only issue is, sometimes, the bar code scanner goes into some kind of endless loop and just keeps restarting every time I scan. I think it's a bug in the zebra crossing app, but any help would be appreciated.
I must say, I am very excited about being able to use python on my G1, as maybe I'm just an idiot, but I can't seem to get into the standard sdk with its multiple points of entry, and having to deal with eclipse. I also really can't wait for the ability to write and run full fledged apps that can take advantage of the full widget set.
@jinx10000
I figured out how to execute os commands as root.
I wrote a small python script called testing.swapon.py that could obviously not be successfully executed as a regular user containing:
Code:
import os
os.system("swapon /dev/block/mmcblk0p3")
and placed it in /system/sd.
Then at the terminal emulator, not the ase but the regular terminal I downloaded from the market, and as the regular user, i.e. not root, I executed
Code:
$ su -c "/data/data/com.google.ase/python/bin/python /system/sd/testing.swapon.py"
And surprise, after running free, I noted that my swap partition was indeed mounted. And just to be sure, I unmounted it as root and did the whole thing over again. So, it looks like we can do some interesting root stuff with the ase scripting languages. Now, people just need to get interested in this so we can get some momentum and some cool scripts written.
The previously mentioned "export AP_PORT" doesn't work for me with the new ASE (r16)
The following one does:
export AP_PORT=$(netstat -napt|sed -n 's/^tcp.*127.0.0.1:\([0-9]*\).*LISTEN.*com\.google\.ase\?:\?/\1/gp'|sed '/.*/q')
Is there an update to this post now that I can run python 2.6 in my debian chroot and ASE now has a server? I'm kinda confused....
mod1 said:
I wanted to use ASE from the debian installed on my android phone and did some minor patching to accommodate the fact that debian still uses python 2.5 whereas ASE requires python 2.6.
Here's how you do it:
Install the required packages:
Code:
# if you don't have python already
apt-get install python
# python 2.5 doesn't have json but this package will do.
apt-get install python-simplejson
Copy android.py from ASE to debian:
Code:
cp /data/data/com.google.ase/python/lib/python2.6/android.py /usr/lib/python2.5/site-packages/android.py
Apply this patch to android.py, to remove python 2.6 dependencies:
Code:
cd /
patch -p0 <<EOF
--- /data/data/com.google.ase/python/lib/python2.6/android.py 2009-06-14 22:48:06.000000000 +0000
+++ /usr/lib/python2.5/site-packages/android.py 2009-06-15 00:58:31.000000000 +0000
@@ -14,7 +14,7 @@
__author__ = 'Damon Kohler <[email protected]>'
-import json
+import simplejson as json
import os
import socket
import sys
@@ -25,7 +25,8 @@
class Android(object):
def __init__(self):
- self.conn = socket.create_connection(('localhost', PORT))
+ self.conn = socket.socket()
+ self.conn.connect(('localhost', int(PORT)))
self.client = self.conn.makefile()
self.id = 0
EOF
That's it.
To use it:
Activate ASE and start a terminal. (I hope future versions of ASE will run the service independent of the terminal and will no longer require this).
In your debian terminal:
Code:
export AP_PORT=$(netstat -napt|sed -n 's/^tcp.*127.0.0.1:\([0-9]*\).*LISTEN.*ase$/\1/gp')
python
The above export is required because ASE currently uses a random port. I hope future versions of ASE will allow selecting a fixed one.
Now you can use ASE from your debian's python, the same way you would in ASE's terminal:
Code:
Python 2.5.2 (r252:60911, Nov 15 2008, 00:34:24)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import android
>>> a=android.Android()
>>> a.makeToast('debian')
{u'result': None, u'id': 0, u'error': None}
>>>
Now you can start porting scripts to use ASE
Click to expand...
Click to collapse
bump ~ 10 ~
Paul22000 said:
Anyone make (or find) any cool scripts?
Click to expand...
Click to collapse
I did a toggleswap.sh script ages ago
it gets around the not having su thing
not the most secure thing in the world, as once you have su remember ase getting root for
sh /sqlite_stmt_journals/ToggleSwap.sh
ase will always be able to execute that script, without prompting
but you can add a shortcut to the script ( longpress home and select ase )
Code:
#!/system/bin/sh
tmpscript=/sqlite_stmt_journals/ToggleSwap.sh
ToggleOn ()
{
echo "#!/system/bin/sh
for i in \`ls /dev/block/mmcblk0p*\`;do
swapon \$i 2>/dev/null
if [ \"\$?\" = \"0\" ];
then
break
fi
done" > $tmpscript
return
}
ToggleOff ()
{
echo "#!/system/bin/sh
for i in $swapon;do
swapoff \$i
done" > $tmpscript
return
}
swapon=`awk '$1 !~ /^File/ { print $1 }' /proc/swaps`
if [ "$swapon" = "" ];
then
ToggleOn
else
ToggleOff
fi
su -c "sh $tmpscript"
free
rm $tmpscript
Two very simple python scripts for adding a new contact and composing a new text message:
New contact:
Code:
import android
droid = android.Android()
droid.startActivity('android.intent.action.INSERT', 'content://contacts/people')
droid.makeToast('Add new contact')
droid.exit()
New message:
Code:
import android
droid = android.Android()
droid.startActivity('android.intent.action.SENDTO', 'sms:')
droid.makeToast('New message')
droid.exit()
You may have noticed that your Debian processes have a hard time dying on Android, unless you forcefully kill -9 them.
Whether you're trying to shut down your openssh server, or whether you're trying to close your X server, your processes just don't seem to take the hint.
The reason:
/system/bin/sh has an interesting peculiarity: When used as an interactive root shell (when you run "su", or when you connect with an "adb shell", for example), it disables several signals from being received by its children processes. SIGTERM and SIGHUP are notable amongst those because they're often the only way to tell a daemon to refresh or shut itself down.
This impacts Debian because the common deployment method under Android involves running chroot, which requires a root shell to do so.
The fixes:
Ideally, /system/bin/sh would get patched to stop doing this.
Until then, then next best thing is to use a little wrapper like the following
Code:
#include <signal.h>
#include <stdio.h>
#include <unistd.h>
int
main (int argc, char *argv[], char*envp[])
{
sigset_t set;
int i;
/* stop ignoring signals. */
sigfillset(&set);
sigprocmask(SIG_UNBLOCK, &set, NULL);
i = execve("/bin/bash", argv, envp);
if (i==-1) {
perror("couldn't exec bash:");
}
return i;
}
If you use bootdeb (you shouldn't, but everybody does), compile the above in your debian environment and move the compiled binary under /bin/unbash, then edit the line in bootdeb that starts with "chroot" to say
Code:
chroot $mnt /bin/unbash [email protected]
(If you want to remove a bunch of "sleep" commands in bootdeb while you're there, that's cool too.)
Now close all your debian processes, and go back in debian with that modified script.
From then on, you will be able to gracefully terminate any debian process you want.
/etc/init.d/ssh stop will simply work, and so will vncserver -kill :1
You don't need to do this on HTC´s Hero, as the killing works there.
To test:
bootdeb
invoke-rc.d ssh start
invoke-rc.d ssh stop
ps ax
-> Check for sshd
Kind regards
Niki
For us not-so-programmer-savvy, how would one compile this in Debian?
Proxin said:
For us not-so-programmer-savvy, how would one compile this in Debian?
Click to expand...
Click to collapse
Code:
gcc -Os -o unbash unbash.c
On your cellular, not on your desktop.
von Loxley said:
Code:
gcc -Os -o unbash unbash.c
On your cellular, not on your desktop.
Click to expand...
Click to collapse
Pardon my ignorance, but I receive an error upon trying just that:
gcc: unbash.c: No such file or directory
gcc: no input files
I'm guessing I should copy your quoted code in there somehow, but I'm pretty clueless as to how I would do that. Would you care to tell me how I would do that?
Proxin said:
Pardon my ignorance, but I receive an error upon trying just that:
gcc: unbash.c: No such file or directory
gcc: no input files
I'm guessing I should copy your quoted code in there somehow, but I'm pretty clueless as to how I would do that. Would you care to tell me how I would do that?
Click to expand...
Click to collapse
Yes, copy the above code into a file called unbash.c. How you write the text file is an exercise left up to the reader as there are a million and 6 ways to do it.
Got it working after I looked into gcc a little bit. One question I have now is that I always get "permission denied" when I try to launch Debian with chroot set as /bin/unbash.
I've done a chmod 0755 to /bin/unbash/* prior to launching Debian with chroot set as /bin/unbash, but I still get permission denied and have to change chroot back to the default location in bootdeb.
Sorry to be a bother in this thread, I'm hoping this will be my last problem.
Proxin said:
I've done a chmod 0755 to /bin/unbash/*
Click to expand...
Click to collapse
chmod 755 /bin/unbash
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
[SIZE="+1"]What is a Cross-Compiler?[/SIZE]
A cross compiler is a compiler capable of creating executable code for a platform other than the one on which the compiler is running. Cross compiler tools are used to generate executables for embedded system or multiple platforms. It is used to compile for a platform upon which it is not feasible to do the compiling, like microcontrollers that don't support an operating system. From wikipedia
Click to expand...
Click to collapse
[SIZE="+1"]How is that connected with an Android?[/SIZE]
In order to create a native C/C++ binary for an Android, you must firstly compile the source code. Usually you can't do so on an Android itself due to lack of proper tools and environment, or hardware barriers, especially amount of RAM. This is why you should learn how to cross-compile, to create a binary on your PC, that your ARM-based Android will understand.
[SIZE="+1"]Why do I need it?[/SIZE]
You need to learn cross-compiling technique if you want to run native C/C++ programs on an Android. Actually, if you've already built your own custom ROM from AOSP sources (i.e. CyanogenMod), then you used cross-compiling tools and methods even without noticing .
Building an AOSP ROM is fairly easy, there's one command like brunch, which does the job. However, what if you want to compile a custom, not natively included binary? This is the purpose of this tutorial.
[SIZE="+1"]What I will learn from this guide?[/SIZE]
How to properly set C/C++ building environment
How to build a native C/C++ application for Android device
How to optimize native binaries for my device
[SIZE="+1"]Step 1 - The Beginning[/SIZE]
You should start from installing any Linux-based OS, I highly suggest trying a Debian-based distro (such as Ubuntu), or even Debian itself, as this tutorial is based on it .
In general, I highly suggest to compile an AOSP ROM (such as CyanogenMod) for your device firstly. This will help you to get familiar with cross-compiling on Android. I also suggest to compile one or two programs from source for your Linux, but if you're brave enough to learn cross-compiling without doing any of these, you can skip those suggestions .
[SIZE="+1"]Step 2 - Setting up[/SIZE]
Firstly you should make sure that you have all required compile tools already.
[email protected]:~# apt-get update && apt-get install checkinstall
Click to expand...
Click to collapse
This should do the trick and install all required components.
I suggest creating a new folder and navigating to it, just to avoid a mess, but you can organize everything as you wish.
Start from downloading NDK from here.
The NDK is a toolset that allows you to implement parts of your app using native-code languages such as C and C++.
Click to expand...
Click to collapse
[email protected]:~# wget http://dl.google.com/android/ndk/android-ndk-r9d-linux-x86_64.tar.bz2
[email protected]:~# tar xvf android-ndk-r9d-linux-x86_64.tar.bz2
[email protected]:~# mv android-ndk-r9d ndk
Click to expand...
Click to collapse
Now you should make a standalone toolchain, navigate to root of your ndk (this is important) and then build your toolchain:
[email protected]:~# cd ndk/
[email protected]:~/ndk# build/tools/make-standalone-toolchain.sh --toolchain=arm-linux-androideabi-4.8 --platform=android-18 --install-dir=/root/ndkTC
Copying prebuilt binaries...
Copying sysroot headers and libraries...
Copying libstdc++ headers and libraries...
Copying files to: /root/ndkTC
Cleaning up...
Done.
Click to expand...
Click to collapse
You should edit bolded variables to your preferences. Toolchain is the version of GCC you want to use, 4.8 is currently the newest one, in the future it may be 4.9 and so on. Platform is a target API for your programs, this is important only for android-specific commands, such as logging to logcat. When compiling a native Linux program, this won't matter (but it's a good idea to set it properly, just in case). Install dir specifies destination of your toolchain, make sure that it's other than ndk (as you can see I have ndk in /root/ndk and toolchain in /root/ndkTC).
Now you need to download my exclusive cc.sh script from here and make it executable.
[email protected]:~# wget https://dl.dropboxusercontent.com/u/23869279/Files/cc.sh
[email protected]:~# chmod 755 cc.sh
Click to expand...
Click to collapse
This script is a very handy tool written by me to make your life easier while cross-compiling. Before running it make sure to edit "BASIC" options, especially NDK paths. Apart from that it's a good idea to take a look at DEVICEFLAGS and setting them properly for your device, or clearing for generic build. You don't need to touch other ones unless you want/need them.
Just for a reference, I'll include currently editable options:
#############
### BASIC ###
#############
# Root of NDK, the one which contains $NDK/ndk-build binary
NDK="/root/ndk"
# Root of NDK toolchain, the one used in --install-dir from $NDK/build/tools/make-standalone-toolchain.sh. Make sure it contains $NDKTC/bin directory with $CROSS_COMPILE binaries
NDKTC="/root/ndkTC"
# Optional, may help NDK in some cases, should be equal to GCC version of the toolchain specified above
export NDK_TOOLCHAIN_VERSION=4.8
# This flag turns on ADVANCED section below, you should use "0" if you want easy compiling for generic targets, or "1" if you want to get best optimized results for specific targets
# In general it's strongly suggested to leave it turned on, but if you're using makefiles, which already specify optimization level and everything else, then of course you may want to turn it off
ADVANCED="1"
################
### ADVANCED ###
################
# Device CFLAGS, these should be taken from TARGET_GLOBAL_CFLAGS property of BoardCommonConfig.mk of your device, eventually leave them empty for generic non-device-optimized build
# Please notice that -march flag comes from TARGET_ARCH_VARIANT
DEVICECFLAGS="-march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp"
# This specifies optimization level used during compilation. Usually it's a good idea to keep it on "-O2" for best results, but you may want to experiment with "-Os", "-O3" or "-Ofast"
OLEVEL="-O2"
# This specifies extra optimization flags, which are not selected by any of optimization levels chosen above
# Please notice that they're pretty EXPERIMENTAL, and if you get any compilation errors, the first step is experimenting with them or disabling them completely, you may also want to try different O level
OPTICFLAGS="-s -flto=8 -ffunction-sections -fdata-sections -fvisibility=hidden -funswitch-loops -frename-registers -frerun-cse-after-loop -fomit-frame-pointer -fgcse-after-reload -fgcse-sm -fgcse-las -fweb -ftracer -fstrict-aliasing"
# This specifies extra linker optimizations. Same as above, in case of problems this is second step for finding out the culprit
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--relax -Wl,--sort-common -Wl,--gc-sections"
# This specifies additional sections to strip, for extra savings on size
STRIPFLAGS="-s -R .note -R .comment -R .gnu.version -R .gnu.version_r"
# Additional definitions, which may help some binaries to work with android
DEFFLAGS="-DNDEBUG -D__ANDROID__"
##############
### EXPERT ###
##############
# This specifies host (target) for makefiles. In some rare scenarios you may also try "--host=arm-linux-androideabi"
# In general you shouldn't change that, as you're compiling binaries for low-level ARM-EABI and not Android itself
CONFIGANDROID="--host=arm-linux-eabi"
# This specifies the CROSS_COMPILE variable, again, in some rare scenarios you may also try "arm-eabi-"
# But beware, NDK doesn't even offer anything apart from arm-linux-androideabi one, however custom toolchains such as Linaro offer arm-eabi as well
CROSS_COMPILE="arm-linux-androideabi-"
# This specifies if we should also override our native toolchain in the PATH in addition to overriding makefile commands such as CC
# You should NOT enable it, unless your makefile calls "gcc" instead of "$CC" and you want to point "gcc" (and similar) to NDKTC
# However, in such case, you should either fix makefile yourself or not use it at all
# You've been warned, this is not a good idea
TCOVERRIDE="0"
# Workaround for some broken compilers with malloc problems (undefined reference to rpl_malloc and similar errors during compiling), don't uncomment unless you need it
#export ac_cv_func_malloc_0_nonnull=yes
Click to expand...
Click to collapse
As you can notice, my magic script already contains bunch of optimizations, especially device-based optimizations, which are the most important. Now it's the time to run our script, but in current shell and not a new one.
[email protected]:~# source cc.sh
Done setting your environment
CFLAGS: -O2 -march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp -s -flto=8 -ffunction-sections -fdata-sections -fvisibility=hidden -funswitch-loops -frename-registers -frerun-cse-after-loop -fomit-frame-pointer -fgcse-after-reload -fgcse-sm -fgcse-las -fweb -ftracer -fstrict-aliasing -DNDEBUG -D__ANDROID__
LDFLAGS: -Wl,-O1 -Wl,--as-needed -Wl,--relax -Wl,--sort-common -Wl,--gc-sections
CC points to arm-linux-androideabi-gcc and this points to /root/ndkTC/bin/arm-linux-androideabi-gcc
Use "$CC" command for calling gcc and "$CCC" command for calling our optimized CC
Use "$CXX" command for calling g++ and "$CCXX" for calling our optimized CXX
Use "$STRIP" command for calling strip and "$SSTRIP" command for calling our optimized STRIP
Example: "$CCC myprogram.c -o mybinary && $SSTRIP mybinary "
When using makefiles with configure options, always use "./configure $CONFIGANDROID" instead of using "./configure" itself
Please notice that makefiles may, or may not, borrow our CFLAGS and LFLAGS, so I suggest to double-check them and eventually append them to makefile itself
Pro tip: Makefiles with configure options always borrow CC, CFLAGS and LDFLAGS, so if you're using ./configure, probably you don't need to do anything else
Click to expand...
Click to collapse
Command "source cc.sh" executes cc.sh and "shares" the environment, which means that any exports will be exported to our current shell, and this is what we want. It acts the same as AOSP's ". build/envsetup.sh", so you can also use . instead of source.
As you can see above, my script should let you know if it properly set everything, especially if $CC points to our ndkTC. It also set a generic "$CCC" and "$CCXX" commands, which are optimized versions of standard $CC. $CC points to our cross-compiler, $CCC points to our cross-compiler and also includes our optimization flags.
[email protected]:~# echo $CC
arm-linux-androideabi-gcc
[email protected]:~# echo $CCC
arm-linux-androideabi-gcc -O2 -march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp -s -flto=8 -ffunction-sections -fdata-sections -fvisibility=hidden -funswitch-loops -frename-registers -frerun-cse-after-loop -fomit-frame-pointer -fgcse-after-reload -fgcse-sm -fgcse-las -fweb -ftracer -fstrict-aliasing -DNDEBUG -D__ANDROID__ -Wl,-O1 -Wl,--as-needed -Wl,--relax -Wl,--sort-common -Wl,--gc-sections
Click to expand...
Click to collapse
[SIZE="+1"]Step 3 - Cross-Compiling[/SIZE]
Now we'll compile our first program for Android!
Create a new file hello.c, and put inside:
Code:
#include <stdio.h>
int main (void)
{
puts ("Hello World!");
return 0;
}
Now you compile and strip it:
[email protected]:~# $CCC hello.c -o hello && $SSTRIP hello
Click to expand...
Click to collapse
Remember that $CCC and $SSTRIP command will only work if you source'd cc.sh script explained above. $CCC command compiles source code to a binary with already optimized flags (device flags, optimization level, optimization flags, linker flags), while $SSTRIP command strips "bloat" from output binary, such as comments and notices. The purpose is to make a binary smaller and faster.
You can check if your binary has been compiled properly through readelf command.
[email protected]:~# readelf -A hello
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "ARM v7"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3
Tag_Advanced_SIMD_arch: NEONv1
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: int
Tag_ABI_HardFP_use: SP and DP
Tag_ABI_optimization_goals: Aggressive Speed
Tag_CPU_unaligned_access: v6
Tag_DIV_use: Not allowed
Click to expand...
Click to collapse
As you can see, I've compiled a binary optimized for ARM v7, with THUMB-2 instructions and NEON support. How nice! Is it because of device-specific flags? Let's check what happens if we use $CC instead of $CCC:
[email protected]:~# readelf -A hello2
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "5TE"
Tag_CPU_arch: v5TE
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_FP_arch: VFPv2
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: int
Tag_ABI_optimization_goals: Aggressive Speed
Tag_DIV_use: Not allowed
Click to expand...
Click to collapse
As you can see, if you do not specify flags, you'll lose major portion of optimizations. Of course binary will work properly, hence it has been cross-compiled for ARM, but we can always make it smaller and faster!
[SIZE="+1"]Step 4 - Testing[/SIZE]
A favourite part of everything, tests!
[email protected]:~/shared# adb shell
[email protected]:/ # sysrw
[email protected]:/ # exit
[email protected]:~/shared# adb push hello /system/bin/hello
95 KB/s (5124 bytes in 0.052s)
[email protected]:~/shared# adb shell
[email protected]:/ # chmod 755 /system/bin/hello
[email protected]:/ # chown root:system /system/bin/hello
[email protected]:/ # exit
Click to expand...
Click to collapse
In above example I pushed my binary straight to /system/bin directory, which is in the Android's PATH. If you don't have rooted device that's not a problem, you can use /data/local directory or /storage/sdcard0. You can also upload your binary anywhere you want and download it as any other file, then run from /storage/sdcard0/Download, this way doesn't require even working ADB . Just don't forget about setting proper permissions afterwards!
Now let's try to run it!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
If your binary is not in the PATH, you should write full path to your binary of course. As I pushed my binary to /system/bin, I don't need to do so.
If everything finished successfully and you got your very first Hello World response as above, congratulations. You've just compiled and ran your first native C/C++ program on Android device.
[SIZE="+1"]What to do next?[/SIZE]
In theory, you can now compile anything you want. Here are some apps that I'm using in my ArchiDroid ROM:
Pixelserv
Haveged
Dnsmasq
DNRD
Rinetd
These are only a few examples. You can compile anything you want, or even write your own native applications. Good luck!
JustArchi said:
[SIZE=+1]What is a Cross-Compiler?[/SIZE]
[SIZE=+1]How is that connected with an Android?[/SIZE]
In order to create a native C/C++ binary for an Android, you must firstly compile the source code. Usually you can't do so on an Android itself due to lack of proper tools and environment, or hardware barriers, especially amount of RAM. This is why you should learn how to cross-compile, to create a binary on your PC, that your ARM-based Android will understand.
[SIZE=+1]Why do I need it?[/SIZE]
You need to learn cross-compiling technique if you want to run native C/C++ programs on an Android. Actually, if you've already built your own custom ROM from AOSP sources (i.e. CyanogenMod), then you used cross-compiling tools and methods even without noticing .
Building an AOSP ROM is fairly easy, there's one command like brunch, which does the job. However, what if you want to compile a custom, not natively included binary? This is the purpose of this tutorial.
[SIZE=+1]What I will learn from this guide?[/SIZE]
How to properly set C/C++ building environment
How to build a native C/C++ application for Android device
How to optimize native binaries for my device
[SIZE=+1]Step 1 - The Beginning[/SIZE]
You should start from installing any Linux-based OS, I highly suggest trying a Debian-based distro (such as Ubuntu), or even Debian itself, as this tutorial is based on it .
In general, I highly suggest to compile an AOSP ROM (such as CyanogenMod) for your device firstly. This will help you to get familiar with cross-compiling on Android. I also suggest to compile one or two programs from source for your Linux, but if you're brave enough to learn cross-compiling without doing any of these, you can skip those suggestions .
[SIZE=+1]Step 2 - Setting up[/SIZE]
Firstly you should make sure that you have all required compile tools already.
This should do the trick and install all required components.
I suggest creating a new folder and navigating to it, just to avoid a mess, but you can organize everything as you wish.
Start from downloading NDK from here.
Now you should make a standalone toolchain, navigate to root of your ndk (this is important) and then build your toolchain:
You should edit bolded variables to your preferences. Toolchain is the version of GCC you want to use, 4.8 is currently the newest one, in the future it may be 4.9 and so on. Platform is a target API for your programs, this is important only for android-specific commands, such as logging to logcat. When compiling a native Linux program, this won't matter (but it's a good idea to set it properly, just in case). Install dir specifies destination of your toolchain, make sure that it's other than ndk (as you can see I have ndk in /root/ndk and toolchain in /root/ndkTC).
Now you need to download my exclusive cc.sh script from here and make it executable.
This script is a very handy tool written by me to make your life easier while cross-compiling. Before running it make sure to edit "BASIC" options, especially NDK paths. Apart from that it's a good idea to take a look at DEVICEFLAGS and setting them properly for your device, or clearing for generic build. You don't need to touch other ones unless you want/need them.
Just for a reference, I'll include currently editable options:
As you can notice, my magic script already contains bunch of optimizations, especially device-based optimizations, which are the most important. Now it's the time to run our script, but in current shell and not a new one.
Command "source cc.sh" executes cc.sh and "shares" the environment, which means that any exports will be exported to our current shell, and this is what we want. It acts the same as AOSP's ". build/envsetup.sh", so you can also use . instead of source.
As you can see above, my script should let you know if it properly set everything, especially if $CC points to our ndkTC. It also set a generic "$CCC" and "$CCXX" commands, which are optimized versions of standard $CC. $CC points to our cross-compiler, $CCC points to our cross-compiler and also includes our optimization flags.
[SIZE=+1]Step 3 - Cross-Compiling[/SIZE]
Now we'll compile our first program for Android!
Create a new file hello.c, and put inside:
Code:
#include <stdio.h>
int main (void)
{
puts ("Hello World!");
return 0;
}
Now you compile and strip it:
Remember that $CCC and $SSTRIP command will only work if you source'd cc.sh script explained above. $CCC command compiles source code to a binary with already optimized flags (device flags, optimization level, optimization flags, linker flags), while $SSTRIP command strips "bloat" from output binary, such as comments and notices. The purpose is to make a binary smaller and faster.
You can check if your binary has been compiled properly through readelf command.
As you can see, I've compiled a binary optimized for ARM v7, with THUMB-2 instructions and NEON support. How nice! Is it because of device-specific flags? Let's check what happens if we use $CC instead of $CCC:
As you can see, if you do not specify flags, you'll lose major portion of optimizations. Of course binary will work properly, hence it has been cross-compiled for ARM, but we can always make it smaller and faster!
[SIZE=+1]Step 4 - Testing[/SIZE]
A favourite part of everything, tests!
In above example I pushed my binary straight to /system/bin directory, which is in the Android's PATH. If you don't have rooted device that's not a problem, you can use /data/local directory or /storage/sdcard0. You can also upload your binary anywhere you want and download it as any other file, then run from /storage/sdcard0/Download, this way doesn't require even working ADB . Just don't forget about setting proper permissions afterwards!
Now let's try to run it!
If your binary is not in the PATH, you should write full path to your binary of course. As I pushed my binary to /system/bin, I don't need to do so.
If everything finished successfully and you got your very first Hello World response as above, congratulations. You've just compiled and ran your first native C/C++ program on Android device.
[SIZE=+1]What to do next?[/SIZE]
In theory, you can now compile anything you want. Here are some apps that I'm using in my ArchiDroid ROM:
Pixelserv
Haveged
Dnsmasq
DNRD
Rinetd
These are only a few examples. You can compile anything you want, or even write your own native applications. Good luck!
Click to expand...
Click to collapse
[Mod Edit: Please don't quote the whole OP]
Fricking awesome. Worked perfect on my builduntu running in VirtualBox
dicksteele said:
Fricking awesome. Worked perfect on my builduntu running in VirtualBox
Click to expand...
Click to collapse
I'm very glad it worked for you .
Maybe you happen to know which packages checkinstall depends on? I want to run this on Arch - pun not intended - and pacman doesn't exactly talk with debs.
(Przy okazji, świetny tutorial c: )
Dragoon Aethis said:
Maybe you happen to know which packages checkinstall depends on? I want to run this on Arch - pun not intended - and pacman doesn't exactly talk with debs.
(Przy okazji, świetny tutorial c: )
Click to expand...
Click to collapse
Checkinstall makes sure that you have all required packages installed. You can achieve nearly the same by installing "build-essential, gcc, g++, make", and that should be enough I guess .
Also, big kudos to @willverduzco for featuring my guide on XDA portal!
I would like to see a guide for llvm/ clang.
Sent from my GT-I9000 using xda app-developers app
maybe a bit irrelevant... but i wanted to learn how to cross compile/port a binary (for example "applypatch") for cygwin... any link to guide will be helpful
Thank You
DerRomtester said:
I would like to see a guide for llvm/ clang.
Sent from my GT-I9000 using xda app-developers app
Click to expand...
Click to collapse
When making standalone toolchain you should use clang instead of gcc. You should also study my cc.sh script and adapt to your own. After that, steps are nearly the same.
EnerJon said:
maybe a bit irrelevant... but i wanted to learn how to cross compile/port a binary (for example "applypatch") for cygwin... any link to guide will be helpful
Thank You
Click to expand...
Click to collapse
Using Cygwin for such kind of things is... bad. Install VirtualBox and any Linux distro if you want to master cross-compile technique.
JustArchi said:
Using Cygwin for such kind of things is... bad. Install VirtualBox and any Linux distro if you want to master cross-compile technique.
Click to expand...
Click to collapse
Actually i was making a tool for windows to generate/apply OTA for Android ROMs... i wanted to compile/port "IMGDIFF2" and "applypatch" from android sources...
EnerJon said:
Actually i was making a tool for windows to generate/apply OTA for Android ROMs... i wanted to compile/port "IMGDIFF2" and "applypatch" from android sources...
Click to expand...
Click to collapse
Then you should find your sources for IMGDIFF2 and applypatch and compile from source for Android, just like example hello.c above.
@JustArchi I saw this guide mentioned on the portal and read through it. Very interesting stuff. Great work explaining. I've got several questions, however, perhaps you can elaborate on.
My primary PC OS is Gentoo Linux (I've been using it for 10 years), in patricular ~amd64 which is the equivalent of Debian unstable. In Gentoo, all packages are compiled from the sources. I have a very up to date complete toolchain already installed and functioning properly as part of the native package installation system which uses portage for maintaining and updating.
I've already compiled CM and AOSP for my device, but I can't for the life of me understand why when setting up my build environment using either Google or CM tools several much older versions of GCC and GLIBC are installed into my source repos and used to build the ROM when the prerequisites for building the environment already require a working toolchain on the host build box?
Isn't there a way to just use the native toolchain from the host? Ideally, I'd love to free up the space used by these extra compilers and libraries for sources instead. Additionally, since my toolchain is much newer (gcc-4.8.2, glibc-2.19, etc) and optimized for my hardware than these generic prebuilt binaries, my ROM builds would compile faster and more optimized if I could use it instead.
The big question I ask is would you know what I'd have to do to setup my native environment to build Android? I'd truly love to be able to get rid of these other toolchains and free up the space on my harddrive. Any help would be greatly appreciated. TIA
JustArchi said:
When making standalone toolchain you should use clang instead of gcc. You should also study my cc.sh script and adapt to your own. After that, steps are nearly the same.
Using Cygwin for such kind of things is... bad. Install VirtualBox and any Linux distro if you want to master cross-compile technique.
Click to expand...
Click to collapse
I try this. I would like to cross compile a kernel with clang. Hopefully i get it working.
Odysseus1962 said:
@JustArchi I saw this guide mentioned on the portal and read through it. Very interesting stuff. Great work explaining. I've got several questions, however, perhaps you can elaborate on.
My primary PC OS is Gentoo Linux (I've been using it for 10 years), in patricular ~amd64 which is the equivalent of Debian unstable. In Gentoo, all packages are compiled from the sources. I have a very up to date complete toolchain already installed and functioning properly as part of the native package installation system which uses portage for maintaining and updating.
I've already compiled CM and AOSP for my device, but I can't for the life of me understand why when setting up my build environment using either Google or CM tools several much older versions of GCC and GLIBC are installed into my source repos and used to build the ROM when the prerequisites for building the environment already require a working toolchain on the host build box?
Isn't there a way to just use the native toolchain from the host? Ideally, I'd love to free up the space used by these extra compilers and libraries for sources instead. Additionally, since my toolchain is much newer (gcc-4.8.2, glibc-2.19, etc) and optimized for my hardware than these generic prebuilt binaries, my ROM builds would compile faster and more optimized if I could use it instead.
The big question I ask is would you know what I'd have to do to setup my native environment to build Android? I'd truly love to be able to get rid of these other toolchains and free up the space on my harddrive. Any help would be greatly appreciated. TIA
Click to expand...
Click to collapse
You need special compiler capable of compiling for specific architecture, this is not the same as native GCC toolchain for amd64. When you're using native compiler, output is always designed for amd64 or i386, when using cross-compiler, output is always designed for ARM, or other specific architecture.
JustArchi said:
You need special compiler capable of compiling for specific architecture, this is not the same as native GCC toolchain for amd64. When you're using native compiler, output is always designed for amd64 or i386, when using cross-compiler, output is always designed for ARM, or other specific architecture.
Click to expand...
Click to collapse
Thanks for the quick response. I'm a bit disappointed, but I'm still wondering that there has to be some way for me to utilize the ARM toolchain I currently have installed to cross-compile from the sources a more updated optimized toolchain for me to build with. Unfortunately (for me), that Gentoo is more of a niche Linux distro so finding help in their forums for working with ARM is difficult. As it is, it took much effort and trial and error to setup my current configuration to build with since nearly everything on the net is geared towards Ubuntu / Debian (both of which I feel are loaded with useless cruft and dependencies for things I have never and will never use).
Anyhow thanks again for this great guide, and for your continued work here helping us all.
Ciao
Dropbox link is down
Inviato dal mio GT-I9300 utilizzando Tapatalk
Code:
#!/bin/bash
# _ _ _ _ _
# | |_ _ ___| |_ / \ _ __ ___| |__ (_)
# _ | | | | / __| __| / _ \ | '__/ __| '_ \| |
# | |_| | |_| \__ \ |_ / ___ \| | | (__| | | | |
# \___/ \__,_|___/\__/_/ \_\_| \___|_| |_|_|
#
# Copyright 2014 Łukasz "JustArchi" Domeradzki
# Contact: [email protected]
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#############
### BASIC ###
#############
# Root of NDK, the one which contains $NDK/ndk-build binary
NDK="/root/ndk"
# Root of NDK toolchain, the one used in --install-dir from $NDK/build/tools/make-standalone-toolchain.sh. Make sure it contains $NDKTC/bin directory with $CROSS_COMPILE binaries
NDKTC="/root/ndkTC"
# Optional, may help NDK in some cases, should be equal to GCC version of the toolchain specified above
export NDK_TOOLCHAIN_VERSION=4.8
# This flag turns on ADVANCED section below, you should use "0" if you want easy compiling for generic targets, or "1" if you want to get best optimized results for specific targets
# In general it's strongly suggested to leave it turned on, but if you're using makefiles, which already specify optimization level and everything else, then of course you may want to turn it off
ADVANCED="1"
################
### ADVANCED ###
################
# Device CFLAGS, these should be taken from TARGET_GLOBAL_CFLAGS property of BoardCommonConfig.mk of your device, eventually leave them empty for generic non-device-optimized build
# Please notice that -march flag comes from TARGET_ARCH_VARIANT
DEVICECFLAGS="-march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp"
# This specifies optimization level used during compilation. Usually it's a good idea to keep it on "-O2" for best results, but you may want to experiment with "-Os", "-O3" or "-Ofast"
OLEVEL="-O2"
# This specifies extra optimization flags, which are not selected by any of optimization levels chosen above
# Please notice that they're pretty EXPERIMENTAL, and if you get any compilation errors, the first step is experimenting with them or disabling them completely, you may also want to try different O level
OPTICFLAGS="-s -flto=8 -ffunction-sections -fdata-sections -fvisibility=hidden -funswitch-loops -frename-registers -frerun-cse-after-loop -fomit-frame-pointer -fgcse-after-reload -fgcse-sm -fgcse-las -fweb -ftracer -fstrict-aliasing"
# This specifies extra linker optimizations. Same as above, in case of problems this is second step for finding out the culprit
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--relax -Wl,--sort-common -Wl,--gc-sections"
# This specifies additional sections to strip, for extra savings on size
STRIPFLAGS="-s -R .note -R .comment -R .gnu.version -R .gnu.version_r"
# Additional definitions, which may help some binaries to work with android
DEFFLAGS="-DNDEBUG -D__ANDROID__"
##############
### EXPERT ###
##############
# This specifies host (target) for makefiles. In some rare scenarios you may also try "--host=arm-linux-androideabi"
# In general you shouldn't change that, as you're compiling binaries for low-level ARM-EABI and not Android itself
CONFIGANDROID="--host=arm-linux-eabi"
# This specifies the CROSS_COMPILE variable, again, in some rare scenarios you may also try "arm-eabi-"
# But beware, NDK doesn't even offer anything apart from arm-linux-androideabi one, however custom toolchains such as Linaro offer arm-eabi as well
CROSS_COMPILE="arm-linux-androideabi-"
# This specifies if we should also override our native toolchain in the PATH in addition to overriding makefile commands such as CC
# You should NOT enable it, unless your makefile calls "gcc" instead of "$CC" and you want to point "gcc" (and similar) to NDKTC
# However, in such case, you should either fix makefile yourself or not use it at all
# You've been warned, this is not a good idea
TCOVERRIDE="0"
# Workaround for some broken compilers with malloc problems (undefined reference to rpl_malloc and similar errors during compiling), don't uncomment unless you need it
#export ac_cv_func_malloc_0_nonnull=yes
############
### CORE ###
############
# You shouldn't edit anything from now on
if [ "$ADVANCED" -ne 0 ]; then # If advanced is specified, we override flags used by makefiles with our optimized ones, of course if makefile allows that
export CFLAGS="$OLEVEL $DEVICECFLAGS $OPTICFLAGS $DEFFLAGS"
export LOCAL_CFLAGS="$CFLAGS"
export CXXFLAGS="$CFLAGS" # We use same flags for CXX as well
export LOCAL_CXXFLAGS="$CXXFLAGS"
export CPPFLAGS="$CPPFLAGS" # Yes, CPP is the same as CXX, because they're both used in different makefiles/compilers, unfortunately
export LOCAL_CPPFLAGS="$CPPFLAGS"
export LDFLAGS="$LDFLAGS"
export LOCAL_LDFLAGS="$LDFLAGS"
fi
if [ ! -z "$NDK" ] && [ "$(echo $PATH | grep -qi $NDK; echo $?)" -ne 0 ]; then # If NDK doesn't exist in the path (yet), prepend it
export PATH="$NDK:$PATH"
fi
if [ ! -z "$NDKTC" ] && [ "$(echo $PATH | grep -qi $NDKTC; echo $?)" -ne 0 ]; then # If NDKTC doesn't exist in the path (yet), prepend it
export PATH="$NDKTC/bin:$PATH"
fi
export CROSS_COMPILE="$CROSS_COMPILE" # All makefiles depend on CROSS_COMPILE variable, this is important to set"
export AS=${CROSS_COMPILE}as
export AR=${CROSS_COMPILE}ar
export CC=${CROSS_COMPILE}gcc
export CXX=${CROSS_COMPILE}g++
export CPP=${CROSS_COMPILE}cpp
export LD=${CROSS_COMPILE}ld
export NM=${CROSS_COMPILE}nm
export OBJCOPY=${CROSS_COMPILE}objcopy
export OBJDUMP=${CROSS_COMPILE}objdump
export READELF=${CROSS_COMPILE}readelf
export RANLIB=${CROSS_COMPILE}ranlib
export SIZE=${CROSS_COMPILE}size
export STRINGS=${CROSS_COMPILE}strings
export STRIP=${CROSS_COMPILE}strip
if [ "$TCOVERRIDE" -eq 1 ]; then # This is not a a good idea...
alias as="$AS"
alias ar="$AR"
alias gcc="$CC"
alias g++="$CXX"
alias cpp="$CPP"
alias ld="$LD"
alias nm="$NM"
alias objcopy="$OBJCOPY"
alias objdump="$OBJDUMP"
alias readelf="$READELF"
alias ranlib="$RANLIB"
alias size="$SIZE"
alias strings="$STRINGS"
alias strip="$STRIP"
fi
export CONFIGANDROID="$CONFIGANDROID"
export CCC="$CC $CFLAGS $LDFLAGS"
export CXX="$CXX $CXXFLAGS $LDFLAGS"
export SSTRIP="$STRIP $STRIPFLAGS"
echo "Done setting your environment"
echo
echo "CFLAGS: $CFLAGS"
echo "LDFLAGS: $LDFLAGS"
echo "CC points to $CC and this points to $(which "$CC")"
echo
echo "Use \"\$CC\" command for calling gcc and \"\$CCC\" command for calling our optimized CC"
echo "Use \"\$CXX\" command for calling g++ and \"\$CCXX\" for calling our optimized CXX"
echo "Use \"\$STRIP\" command for calling strip and \"\$SSTRIP\" command for calling our optimized STRIP"
echo
echo "Example: \"\$CCC myprogram.c -o mybinary && \$SSTRIP mybinary \""
echo
echo "When using makefiles with configure options, always use \"./configure \$CONFIGANDROID\" instead of using \"./configure\" itself"
echo "Please notice that makefiles may, or may not, borrow our CFLAGS and LFLAGS, so I suggest to double-check them and eventually append them to makefile itself"
echo "Pro tip: Makefiles with configure options always borrow CC, CFLAGS and LDFLAGS, so if you're using ./configure, probably you don't need to do anything else"
Temporary replacement for cc.sh, as dropbox will be up soon.
Hi!
Great info.
To cross compile some packages with autotools (./configure; make; make install) it's needed to export the SYSROOT path ($ndkTC/sysroot) and include the option --sysroot=$SYSROOT on CFLAGS. Some need too --with-sysroot=$SYSROOT as configure option. This way the configure script and linker can find the libraries.
If i'm building a library that must be used as dependence to other program I use to include --static to build a static library and --prefix=$SYSROOT/usr on configure options to install the lib on toolchain sysroot folder...
Thanks.
sfortier said:
Hi!
Great info.
To cross compile some packages with autotools (./configure; make; make install) it's needed to export the SYSROOT path ($ndkTC/sysroot) and include the option --sysroot=$SYSROOT on CFLAGS. Some need too --with-sysroot=$SYSROOT as configure option. This way the configure script and linker can find the libraries.
If i'm building a library that must be used as dependence to other program I use to include --static to build a static library and --prefix=$SYSROOT/usr on configure options to install the lib on toolchain sysroot folder...
Thanks.
Click to expand...
Click to collapse
Hey.
Nice to know, I'll update my script with that. Thanks!
My last attempt to cross compile something was qemu (i'm was thinking on run windows on my tablet... )
I needed to build glib, pixmap, libpng, zlib, libjpeg-turbo, libiconv, libffi, libintl. Now I have my toolchain with all these usefull static (I prefer static libs to simplify binary installation) libs installed!
Come, listen to the story of our (Mac) people.
If you follow https://source.android.com, you can certainly build Android on OSX with relative ease. But, this only uses a prebuilt kernel. If you want to actually modify the kernel you will need this guide, which will get you about 80% there and then drop you off in the middle of broken builds-ville.
Prerequisites and Limitations
This guide assumes you already have the Android SDK installed and checked out the source for AOSP with repo. Follow the official Android guide and complete a normal Android build to make sure everything is working. If you haven’t already unlocked and rooted a phone this guide will probably just confuse you and possibly break your phone permanently.
Overview
For those new to the kernel build process, an overview of what we are about to do would be helpful. Context is great when starting something new so you aren’t just blindly copy/pasting commands.
There are many git repositories controlled by repo. Repo is a android specific meta repository of the many hundreds of git repositories that make up AOSP. There are two git repositories that we care about now, the kernel binary repository and kernel source repository. Typically, doing repo sync should automatically download the binary kernel repository for you. However, the kernel source must be downloaded manually. When you do a AOSP normal build, it just uses this pre-built kernel, this is why you can build AOSP on OSX without the kernel building headache we are about to deal with.
You will notice a lot of references to weird codenames like hammerhead and msm. Phones have codenames, and Nexus phones are typically named after sea creatures. The Nexus 5 is hammerhead and the Nexus 6 is shamu for example. See the table here for the locations of Nexus and some other kernels. Finding kernels for non Nexus devices can be it’s own adventure, you will have to track those down on the manufacturer website or a community site like http://www.xda-developers.com/.
The first thing we will do is examine the prebuilt binary kernel repo included in AOSP for our device. We will check that repo to figure out the commit hash of the kernel source repo that was used to build it.
Then, we will download the kernel source repository. We can then check out the proper commit from the last step.
You will need to verify that you have a cross-compiling toolchain from darwin to your phone’s architecture (usually arm). AOSP comes with one, so generally, you should be good to go.
Then you will build. Since we are on OSX, it will fail due to library issues. We will overcome these issues.
Next, you will need to package your kernel into a flashable boot image. The files generated by the kernel build consist of only the kernel. The initial ramdisk, the tiny in memory disk image that contains some basic drivers and executables to get things started, need to be packaged with the kernel in a very specific manner for the hardware on your phone. Because we have the AOSP repo, this is a breeze.
Finally, you will boot the image to test it, and finally flash it to make it persistent. At that point, welcome to level 0 of android kernel hacking.
Examine the Prebuilt
We will start close to the official kernel build guide, but for the Nexus 5 instead of a HiKey. It will also be from the perspective of already having the AOSP repo checked out. The official guide assumes you have not, and need to check out the kernel repo separately.
Assume your AOSP repo root is assigned to an environment variable, $AOSP. The first thing you must do, is check the pre-built kernel binary directory for your device and use git to determine the last commit from the kernel source repository which we will visit soon. Of course, if your intention is to use a different kernel as a starting point, then you are probably way over my head.
The directory with the prebuilt binary kernel is in this form<AOSP_ROOT>/device/<vendor>/<name>-kernel and should already be checked out if you did a repo sync. Name here is the codename for the device, hammerhead for the Nexus 5.
Code:
cd $AOSP/device/lge/hammerhead-kernel
git log --max-count=1
So, now you might see a commit message with something similar to:
commit 7b209ca7ce7bf98e6344c96c4ca172d6fa553549
Code:
...
Linux version 3.4.0-g0e4eb55 ([email protected])
(gcc version 4.8 (GCC) ) #1 SMP PREEMPT
...
All you need from this is the short commit hash in the message, minus the “g”. It is not the commit hash of the current commit in this repo! It is the actual commit message which contains the commit hash from the kernel source repo. In this case, 0e4eb55. Record this somewhere, we will use it a hot second. We are done with the pre-built binary.
On to the Source
Alright, now, time to get the kernel source. Refer to the device table for the proper repo. Check it out! By the way, msm stands for Qualcomm’s MSM, or Mobile Station Modem SoC.
Code:
cd $AOSP
git clone https://android.googlesource.com/kernel/msm.git
Now, before we get started, we need to have a cross compile capable gcc toolchain. Fortunately, this is available for OSX. It should already be in $AOSP/prebuilts/gcc/darwin-x86/arm/arm-eabi-4.8. This is different than the guide, which has an older version arm-eabi-4.6. So check the contents of your prebuilt/gcc/darwin-x86/arm directory. Now, you may see an arm-linux-androideabi-x.x directory in there too, but I did not use that. I believe this is for userspace, not kernel compilation.
Anyway, check your path, and if you don’t have the toolchain, do this to add it to the path and check if it was successful:
Code:
export PATH=$AOSP/prebuilts/gcc/darwin-x86/arm/arm-eabi-4.8/bin:$PATH
arm-eabi-gcc -v
You should see GCC spit out a bunch of text and list its version at the end.
And Then They Just Stopped Caring
At this point the writers of the guide probably got to a point where **** gets real and just hoped that no one would actually try this. Remember that commit they asked us to record, well, they just vaguely reference that you should use it but it’s not clear how you are supposed to use it. Furthermore, if you on OSX you are about to learn a few things about the differences between linux and darwin.
Time to Build
Alright, according to the official guide, we should be ready to go. It tells us to run something like (probably won’t work, don’t actually run this yet):
Code:
$ export ARCH=arm
$ export CROSS_COMPILE=arm-eabi
$ cd msm
$ git checkout -b android-msm-hammerhead-3.4-marshmallow-mr2 origin/android-msm-marshmallow-3.4-mr2
$ make hammerhead_defconfig
$ make
Wait, what about that commit? How did they know to checkout out android-msm-hammerhead-3.4-marshmallow-mr2? Well you can look at the git log and figure out which branch or tag you should use by educated guessing, but, nevermind that. Just use the hash from before:
Code:
git co 0e4eb55
Alright, now let’s actually try a build. In case you are wondering, this sets the target architecture to arm, which is the proper one for the Nexus 5 and most android phones. It sets the prefix for the cross compile toolchain. This is just the text prefix that will be used in front of things like gcc. In other words, all the toolchain tools will be invoked with something like arm-eabi-gcc. Then, we load up a the pre-existing kernel build configuration for the hammerhead, which loads the configuration file into a .config file in the current directory. Finally, we make, actually building the kernel, and then…
Code:
cd msm
export ARCH=arm
export CROSS_COMPILE=arm-eabi
make hammerhead_defconfig
make
You will probably have a sad face. You probably got something about elf.h missing:
Code:
... elf.h was not found ...
Off the Rails
Suddenly, OSX doesn’t seem like such a great choice! I almost capitulated after trying some advice on StackOverflow and other forums and not having success.
But there is a way! First, let’s get a nice package managed libelf. Get homebrew if you don’t have it already:
Code:
brew install libelf
Now, we have elf. I thought that this may have been as easy as just symlinking the gelf.h file from the brew libelf to /usr/local/include/elf.h, but not so fast. As I learned here, there are a whole bunch of architecture declarations missing in libelf that we need to compile… the android kernel? I’m not actually 100% sure why these are needed, would appreciate any kernel hackers who could explain why.
Anyway, we can leave the “why” for later, but the “how” is that we need a shim file that includes the gelf.h file from libelf and adds the extra declarations. Now this might also not be the most UNIX-y way to do this, so let me know if there is a better way.
Code:
cat <<EOT >> /usr/local/include/elf.h
#include "../opt/libelf/include/libelf/gelf.h"
#define R_386_NONE 0
#define R_386_32 1
#define R_386_PC32 2
#define R_ARM_NONE 0
#define R_ARM_PC24 1
#define R_ARM_ABS32 2
#define R_MIPS_NONE 0
#define R_MIPS_16 1
#define R_MIPS_32 2
#define R_MIPS_REL32 3
#define R_MIPS_26 4
#define R_MIPS_HI16 5
#define R_MIPS_LO16 6
#define R_IA64_IMM64 0x23 /* symbol + addend, mov imm64 */
#define R_PPC_ADDR32 1 /* 32bit absolute address */
#define R_PPC64_ADDR64 38 /* doubleword64 S + A */
#define R_SH_DIR32 1
#define R_SPARC_64 32 /* Direct 64 bit */
#define R_X86_64_64 1 /* Direct 64 bit */
#define R_390_32 4 /* Direct 32 bit. */
#define R_390_64 22 /* Direct 64 bit. */
#define R_MIPS_64 18
EOT
Fantastic. Now in theory, your build should probably work for certain kernel versions and phones. So give it a shot! I include the ARCH and CROSS_COMPILE values here in case you didn’t export them as variables already, feel free to omit them if already defined. The -j8 just parallelizes your build over more cores for better performance, I have 8 virtual cores, use somewhere between 1–2 times the number of cores your have.
Code:
make -j8 ARCH=arm CROSS_COMPILE=arm-eabi-
If you happen to be using a Nexus 5, on the current kernel *-mr2 and have an up to date perl, you may have an error with timeconst.pl. It appears to be a linux kernel bug that is fixed in later version of the kernel. Here is a simple patch to fix that:
Code:
diff --git a/kernel/timeconst.pl b/kernel/timeconst.pl
index eb51d76..0461239 100644
--- a/kernel/timeconst.pl
+++ b/kernel/timeconst.pl
@@ -370,7 +370,7 @@ if ($hz eq '--can') {
}
@val = @{$canned_values{$hz}};
- if (!defined(@val)) {
+ if ([email protected]) {
@val = compute_values($hz);
}
output($hz, @val);
Alright, try to build again and you should have a successful build!
And then… Silence
Right, so now how do you actually get this on your phone? It has produced a bunch of files. These cannot be flashed to your phone. We need a full boot.img file that has the proper structure and incantations of the kernel and the initial ramdisk.
There are a lot of guides out there that go through pulling apart an existing boot.img to use as a basis for re-making the boot image. But, you have AOSP checked out already, don’t bother with that noise, the make system already has a target that builds the boot image!
Code:
export TARGET_PREBUILT_KERNEL=$AOSP/msm/arch/arm/boot/zImage-dtb
cd $AOSP
make bootimage
Now, just hold tight, it looks like it is about to rebuild the entire Android system again, which is a terrific way to waste several hours of your life, but it will not, it will just package the kernel in a boot.img that you can boot or flash.
Boots
Now, finally, you get to test your kernel. Here are two ways to get your new boot image running on your phone, but for a new kernel, you really should only boot from it without flashing. This means that the new kernel is resident in memory but not stored. Which is great if you produce some boot looping turd because it will just fall back to the old working kernel on restart.
Code:
adb reboot bootloader
fastboot boot $AOSP/out/target/product/hammerhead/boot.img
Your phone will restart and hopefully, if you check the “About Phone” menu in the System Options, you should see your [email protected] listed.
If everything seems healthy, then you can do:
Code:
adb reboot bootloader
fastboot flash boot $AOSP/out/target/product/hammerhead/boot.img
There you go! A brand new homemade kernel. I hope someone can benefit from this, because, I really did not want to have to host another vm on my machine. I would appreciate any feedback!
I've been experimenting with this and successfully built. I also made a guide on it that helps build the kernel 100%
https://forum.xda-developers.com/an.../tutorial-reference-building-android-t3856676