Database Info

[Q] Cross compiling C software for my android

Hi,
I've download the Android source with "repo", and it includes cross compiler toolchains for various architectures.
I want to build a package (for now, mtd-utils) for my android phone (a htc hero), but I'm having limited success understanding how to get this working. I was thinking there was something I could do, like change my $PATH and set up some other environment variables, that would use the tools from the toolchain instead of the system default ones, so that the binaries would be built for the phone instead of for my computer. But it certainly doesn't seem to be that easy...
I've reverted to attempting a "Hello world" program, but when I try to compile even that using the included toolchain tools, I run into trouble:
Code:
$ $HOME/src/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-gcc -static -o hello hello.c
hello.c:1:19: error: stdio.h: No such file or directory
hello.c: In function 'main':
hello.c:5: warning: incompatible implicit declaration of built-in function 'printf'
so I tried a couple of other variants:
Code:
$ $HOME/src/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-gcc -static -I $HOME/src/mydroid/bionic/libc/include -o hello hello.c
$ $HOME/src/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-gcc -static -I $HOME/src/mydroid/ndk/build/platforms/android-8/arch-x86/usr/include/ -o hello hello.c
but they both give (different) errors about what other include files are missing when referenced from somewhere.
Is there some "easy" way to android-ify a source tree, so that I can build sources using the cross compiler toolchains? Or should I fetch a different cross compiler toolchain to use, like benno did in his document from 2007? He uses a codesourcery toolchain and builds with that instead (as referenced in other articles here on the subject).
Would much appreciate any shared tips or experiences on how to accomplish this.

The tool chain is fine the problem is non of the include/lib are set up correctly to find the needed version of the includes. Remember the default includes under linux depend on glibc and android only supplies bionic.
Have a look here for more info on setting up bionic:
http://android-dls.com/wiki/index.php?title=Compiling_for_Android
Though if you get the full source for glibc (or precompiled arm binaries) you could compile a dependant program staticly (I think that's what busybox does)

Building for older versions of Android
I was actually able to compile a program manually today, specifically one of the programs in the mtd-utils package. After lots of jumping back and forth, I have found out that the 64 bit version of Ubuntu is what I needed, and also sun-java-1.6, contrary to almost all information I found out there. Then I was able to build AOSP, and then I was able to get "agcc" working, the wrapper that sets environment variables automatically as needed.
So I compiled the app, but it didn't work on my Android. Trying to run it in an adb shell gave approximately this error (from memory):
/bin/sh: ./program: No such file or directory
though the program was there. I didn't use strace, but concluded that this is because of a missing shared library. I have a very recent version of AOSP, while the phone is running Android 2.0 or something like that, so that's a plausable reason why this is happening.
I tried to rebuild the program using "agcc -static ...", but that doesn't work because I don't have the static version of libc after building AOSP, so it just dies with a linker error complaining that it can't find -lc.
So now I need to figure out how to build for old Android version using my checked out version of AOSP, or I need to figure out how to check out an old version of AOSP using repo.
Any tips would be much appreciated.

[GUIDE] Understanding the Android Source Code

Hello XDA,
I have been going through many guides over XDA, there were many that taught you how to compile from source, but I didn't found a single guide that could explain how Android source code works or what are so many folders, files and commands for, so here it is, a lengthy yet informative guide for aspiring devs. And yeah, I'm not a dev, just another guy who learns by exploring many things and likes to share it.
Click to expand...
Click to collapse
Note - I own an HTC Explorer(Pico), so many things that are written *might* be exclusive to it, or others with some changes.
Describing the Android Source Code Folders -​
{
"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"
}
I'll take CM11 as an example to explain this.
Now the folders, in alphabetical order-
1. abi - This folder contains a sub folder called cpp which actually contains many C++ files linked to many places.
2. android Remember this?
Code:
repo init -u git://github.com/CyanogenMod/android.git
Yes, it's that android.git folder.
Have a look at this also.
3. art - Yeah, it is the folder that deals with the compilation of the latest android ART runtime. If you're looking into source directories of some other android versions, you won't fins it obviously.
4. bionic - Bionic is mainly a port of the BSD C library to our Linux kernel with the following additions/changes:
- No support for locales.
- No support for wide chars (i.e. multi-byte characters).
- its own smallish implementation of pthreads based on Linux futexes.
- Support for x86, ARM and ARM thumb CPU instruction sets and kernel interfaces.
5. bootable - Boot and startup related code. Some of it is legacy, the fastboot protocol info could be interesting since it is implemented by boot loaders in a number of devices such as the Nexus ones.
6. build - The main entry point of the build system resides here - envsetup.sh, if you follow the instruction in source.android.com you will see that the first step before you do anything to build Android is to use the command source build/envsetup.sh
The script will check few things to make sure all the needed application available in the local machine. It also setup the devices that can be built, which is extracted from the directory device.
7. cts - the compatability tests. The test suite to ensure that a build complies with the Android specification.
8. dalvik - This is the folder responsible for the compilation of the Dalvik runtime for the Android devices.
*Have a look at the difference between the two(art and dalvik) folders and you'll have an idea of how things work in that case*
art -
dalvik -
9. Development - This directory contains application that are not part of the deployed app in the OS. There are some useful application such as widget builder, etc
10. Device - It contains the device specific configurations for many devices.
Note - Many people ask me what, the folders like 'common' and 'generic are for, so here -
> common - This directory contains gps information and also a script that allows you to extract proprietary binary files from your phone to be part of the build process.(You can try to have a look at your device's device tree and then the cm.mk file, where you could find relations of these files. In my case, it shows like this:
Code:
# Include GSM stuff
$(call inherit-product, vendor/cm/config/gsm.mk)
-and-
# Inherit some common cyanogenmod stuff.
$(call inherit-product, device/common/gps/gps_eu_supl.mk)
> generic - This directory contains the generic device configuration that is called ‘goldfish’. This is the device classification used when building the emulator.
> Google - This directory contains the Android Accessories Kit code. It contains a demokit Android app that allows you to control the ADK board. The ADK firmware can be check out here http://code.google.com/p/microbridge/. There is a good article about this here.
> sample - This directory contains a full example of writing your own Android platform shared library, without changing the Android framework. It also shows how to write JNI code for incorporating native code into the library, and a client application that uses the library. This example is ONLY for people working with the open source platform to create a system image that will be delivered on a device which will include a custom library as shown here. It can not be used to create a third party shared library, which is not currently supported in Android.
11. docs - I contains an important sub-folder called source.android.com. Contains tutorials, references, and miscellaneous information relating to the Android Open Source Project (AOSP). The current iteration of this site is fully static HTML (notably lacking in javascript and doxygen content), and is and/or was maintained by skyler (illustrious intern under Dan Morrill and assistant to the almighty JBQ).
12. external - This directory contains source code for all external open source projects such as SQLite, Freetype, webkit and webview.
13. frameworks - Ah, one of the most important directories. it contains the sources for the framework. Here you will find the implementation of key services such as the System Server with the Package- and Activity managers. A lot of the mapping between the java application APIs and the native libraries is also done here.
A special note on this one - I'd recommend new users to not to play with any file/folder inside the frameworks folder, maybe your ROM doesn't boots then.
14. hardware - Hardware related source code such as the Android hardware abstraction layer specification and implementation. This folder also contains the reference Radio Interface Layer(RIL - To communicate with the modem side) implementation.
15. Kernel - It's not a default folder in the source code, but it's a part of device configuration set-up. It contains the kernel source of your device.
16. libcore - I'll explain this one with the important folders inside this, since every folder performs a different function.
dalvik - DalvikVM runtime for Android
dom - Java test classes for DOM
expectations - Contains information about the test cases
include - Some C/C++ include files that used for Array and String handling
json - JSON based Java implementation
luni - Contains test source code for loading .jar and .dex files
support - Contains support class file for testing Dalvik
xml - XML pull and push implementation
17. libnativehelper - I have no idea on this one. If someone knows, share your knowledge. :good:
18. ndk - Contains build scripts and helper files for building the NDK
19. out(Everyone's favorite directory ) - The build output will be placed here after you run make. The folder structure is out/target/product/. In the default build for the emulator the output will be placed in out/target/product/generic. This is where you will find the images used by the emulator to start (or to be downloaded and flashed to a device if you are building for a hardware target).
20. packages - Standard Android application that are available as part of the AOSP - Camera, SMS, Dialer, Launcher, etc
21. pdk - I believe that 'pdk' is the Platform Development Kit, it's basically an SDK/set of tools that Google sends to OEMs to evaluate their framework ahead of each major Android upgrade since Android 4.1.
(Thanks to @yowanvista )
22. prebuilt - Contains files that are distributed in binary form for convenience. Examples include the cross compilations toolchains for different development machines.
23. sdk - This directory contains lots of apps that are not part of operating system. There are quite useful apps that developers can leverage on and can be enhanced further as part of the operating system.
24. system - Source code files for the core Android system. That is the minimal Linux system that is started before the Dalvik VM and any java based services are enabled. This includes the source code for the init process and the default init.rc script that provide the dynamic configuration of the platform.
25. tools - Some external important tools that help in compiling. Not sure though. :/
26. vendor - This directory contains vendors specific libraries. Most of the proprietary binary libraries from non-open source projects are stored here when building AOSP.
One thing - Beyond the above you also have the hidden .repo directory that contains the source for the repo utility. It also holds the manifest specifying what git repositories you want to track for this Android source project. If you have your own additions you could automatically track them by adding a local manifest here. For modifications of the platform framework there are some instructions available in the device/sample folder of the source code tree. That will show you how to add APIs to Android without having to modify the core framework.
Now, many people ask me the difference between the 'Breakfast', 'Lunch' and 'Brunch' command. So, here's what these commands are specific for:​
Breakfast
You may not ever use this command , but in order to explain brunch, we have to explain breakfast first. Breakfast is a function used to configure your build. It keeps track of a list of officially-supported devices to build for, and allows you to choose one.
If you do not put a device, the script will output a list of available devices to build for, and you can then choose yours. Breakfast then goes on to configure your build environment with the correct variables to create your device-specific rom.
Brunch
Defined simply, brunch is equivalent to
Code:
breakfast [device name] && mka bacon
This means that it sets up your build environment to be configured for your device, and then commences the build process. mka bacon is just CyanogenMods’s way of saying build the code for your device. It’s generally only used for officially supported devices (ones that you use can choose through the breakfast menu).
Lunch
This ones also pretty simple to explain. It’s used EXACTLY like breakfast, the only difference being the choices you have to build with it. Using lunch, you can choose non-official or non-standard builds for your device. This includes special debug versions and also allows you to build CyanogenMod for use on the Android Emulator. To build after running lunch, simply issue the command mka.
For other commands and help, I recommend you to read this article.
Few common Terms​Hey, do you ever find few terms on xda, related to development that go over your mind? Well, I recommend you to have a look at this post by Recognized Contributor @TheByteSmasher and give him the Thanks he deserves.
Understanding Android Makefile (Android.mk)​Well, I bet if go through many folders of the Source Code, you might find the file named Android.mk! Here are few important things regarding that -
These Android.mk files defines how to build that source code. There are well defined specific rules for Android.mk files. Let me summarize them.
Name: We need to define a name for our build (LOCAL_MODULE := )
Local Variables: All builds may have some local variables so to start a new build it is good to clear all local variables (include $(CLEAR_VARS))
Files: We need to write all files we want it to be build (LOCAL_SRC_FILES := main.c)
Tags: Define tags for build. (LOCAL_MODULE_TAGS := eng development)
Libraries: If build needs to be linked to other libraries, we need to define them (LOCAL_SHARED_LIBRARIES := cutils)
Template file: We can define whether our build is executable,library or something else by including template file (include $(BUILD_EXECUTABLE))
BUILD_EXECUTABLE, CLEAR_VARS, etc. variables which are the absolute address of the template files are defined in build/core/config.mk.
Now an example -
The following Android.mk builds a simple APK. The codes beginning with a has(#) are the comments to tell you what the lines actually means.
Code:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
# Build all java files in the java subdirectory
LOCAL_SRC_FILES := $(call all-subdir-java-files)
# Name of the APK to build
LOCAL_PACKAGE_NAME := LocalPackage
# Tell it to build an APK
include $(BUILD_PACKAGE)
Last line in Android.mk file builds the APK file. Different source code types must be built differently so we can also use $(BUILD_EXECUTABLE), $(HOST_JAVA_LIBRARY), $(HOST_PREBUILT) etc. variables according to our source code. (Definitions like my-dir, all-subdir-java-files are in build/core/definitions.mk). We can add LOCAL_MODULE_TAGS variable to Android.mk file to determine that module to be installed in that source code built. Here are the some defined tags and their meanings.
Makefile tricks. ​
>Build helper functions
A whole bunch of build helper functions are defined in the file build/core/definitions.mk
Try grep define build/core/definitions.mk for an exhaustive list.
Here are some possibly interesting functions:
print-vars - shall all Makefile variables, for debugging
emit-line - output a line during building, to a file
dump-words-to-file - output a list of words to a file
copy-one-file - copy a file from one place to another
>Add a file directly to the output area
You can copy a file directly to the output area, without building anything, using the add-prebuilt-files function.
The following line, extracted from prebuilt/android-arm/gdbserver/Android.mk copies a list of files to the EXECUTABLES directory in the output area:
Code:
$(call add-prebuilt-files, EXECUTABLES, $(prebuilt_files))
Understanding the Device Tree​Note - This is by no means complete, and there will be omissions as have explained all this top of my head and copied pasted certain bits that I have here on my own device tree.
Android.mk - this will tell the build system to include and to build sources specifically for your device. I have explained a bit of it above as well.
AndroidBoard.mk - this is for the kernel, the build system uses that to drop the kernel image in place.
AndroidProducts.mk - specifies the appropriate device's make file, to use for building. i.e. device/htc/pico/pico.mk(In my case), This is device-specific as well.
device_codename.mk - Every device has a codename, and there is a file named as the codename of device. It specifies the properties and extras to copy over into the final output, in this case, it could be for example, pico.mk
BoardConfig.mk - This is the meat of it all, this is where compiler conditional flags are set, partition layouts, boot addresses, ramdisk size, and so on.
Android.mk
Code:
LOCAL_PATH := $(my-dir)
ifeq ($(TARGET_DEVICE),pico)
include $(call all-makefiles-under,$(LOCAL_PATH))
endif
^This is how the build will use that to build recovery, sensors, lights and camera (of course there will be more), its saying 'Yo Builder, go into each of the directories specified, and build the respective sources'
AndroidBoard.mk:
Code:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
ALL_PREBUILT += $(INSTALLED_KERNEL_TARGET)
# include the non-open-source counterpart to this file
-include vendor/htc/pico/AndroidBoardVendor.mk
^ This one is pretty simple and tells the build system to go to the vendor tree of the device and include AndroidBoardVendor.mk for building.
AndroidProducts.mk
Code:
PRODUCT_MAKEFILES := \
$(LOCAL_DIR)/cm.mk \
$(LOCAL_DIR)/pico.mk
^Just specifying the makefiles of the device.
BoardConfig.mk
Now in this one, I'm taking a BoardConfig.mk file that I found over the internet with a suitable explanation of it. Credits to the post over stackoverflow for the valuable efforts.
Code:
LOCAL_PATH:= $(call my-dir)
TARGET_NO_BOOTLOADER := true
TARGET_PREBUILT_KERNEL := device/lg/gt540/kernel
TARGET_PREBUILT_RECOVERY_KERNEL := device/lg/gt540/recovery_kernel
# This will vary from device!
TARGET_BOARD_PLATFORM := msm7k
TARGET_ARCH_VARIANT := armv6-vfp
TARGET_CPU_ABI := armeabi
TARGET_CPU_ABI := armeabi-v6l
TARGET_CPU_ABI2 := armeabi
# OpenGL drivers config file path
BOARD_EGL_CFG := device/lg/gt540/egl.cfg
# Dependant, not to be taken literally!
BOARD_GLOBAL_CFLAGS += -DHAVE_FM_RADIO
# Dependant, not to be taken literally!
BOARD_KERNEL_BASE := 0x02600000
# this will be device specific, and by doing cat /proc/mtd will give you the correct sizes
BOARD_BOOTIMAGE_PARTITION_SIZE := 0x00480000
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 0x00480000
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 0x0cf80000
BOARD_USERDATAIMAGE_PARTITION_SIZE := 0x0d020000
BOARD_FLASH_BLOCK_SIZE := 131072
^That is an excerpt, notice how we specify kernel's base address, this is how the boot.img gets generated after compilation is done and yet again, gets dropped into out/target/product/lg/gt540/boot.img. Also, more importantly, we're telling the build system to use the target platform for cross-compiling the sources (*TARGET_BOARD_PLATFORM*/*TARGET_CPU_ABI*) There will be more information in there such as conditional flags to pass to the compiler, for an example. we specified the directive HAVE_FM_RADIO to tell it, when it comes to handling the source for the FM radio system, to conditionally compile parts of the source. Again, this is hardware specific and mileage will vary, also this applies to the address for boot. In a nutshell, this is saying 'Yo Builder, read the damn variables and remember them and apply them when cross-compiling those source files!'
Now that the internals of each of those Android build make-files are shown.
Now, onto the vendor/ part of it, in AOSP, simply, once again, correlation and corresponds with the device/ tree, as in continuing with this example, vendor/lg/gt540/ which gets picked up by the lunch. There's more make files in there but the general consensus is there's a directory called proprietary which contains the proprietary libs (due to close-source etc) that gets copied over. The copying over of the libraries gets specified in the file device-vendor-blobs.mk, in this case, gt540-vendor-blobs.mk.
Adding your Own Apps in the Source Code​The following part of the guide will tell you how to make your own apps to compile with the ROM and be a part of it.
1. Add the App's source code to packages/apps/name_of_app
2. Regardless of how you put the source in packages/apps/, assuming that the source for the app has an Android.mk Makefile, you can get it to automatically build and install the resulting file in your $OUT directory (and thus your .zip) by simply determining the name of the project, which is typically defined in Android.mk with this:
Code:
LOCAL_PACKAGE_NAME := PackageName
3. Add the project to device.mk (or whatever .mk) in the device folder.
Have a look at an example here
Compiling specific parts of a ROM​
To compile an app-
Code:
make app_name.apk -j4
Wait, there's some more things you must know for compiling a *specific app* ! Thanks to @thewisenerd head over to this post.
To compile other parts you also need to enter the folder name, here are some examples from /frameworks/base [Credits-XDA University Article]
Code:
make android.policy (the power menu and lockscreen)
make framework (the initial framework files)
make framework-res (the initial framework resources)
make services (the services.jar file)
More examples:
Code:
make sdk (builds the android sdk)
make modules (builds all modules)
make installclean (removes all staging directories, such as out/target/product/boardname/system)
make clean (removes the whole /out directory)
make recoveryimage (builds the recovery from /bootable/recovery, customizable if wanted!)
Configuring a new Product for the AOSP.
Again, I'd recommend you to have a look at this great document.
A detail information about BoardConfig.mk
Well, I believe that BoardConfig.mk is one of the most important files for the device tree. Now, here are few parameters of the file explained-
TARGET_ARCH: set to arm for almost all current Android devices.
BOARD_KERNEL_CMDLINE: not all devices pass boot parameters however if your device does this must be filled out properly in order to boot successfully.
BOARD_KERNEL_PAGESIZE: the pagesize of the stock boot.img and must be set properly in order to boot. Typical values for this are 2048 and 4096 and this information can be extracted from the stock kernel.
BOARD_BOOTIMAGE_PARTITION_SIZE: the number of bytes allocated to the kernel image partition.
BOARD_RECOVERYIMAGE_PARTITION_SIZE: the number of bytes allocated to the recovery image partition.
BOARD_SYSTEMIMAGE_PARTITION_SIZE: the number of bytes allocated to the Android system filesystem partition.
BOARD_USERDATAIMAGE_PARTITION_SIZE: the number of bytes allocated to the Android data filesystem partition.
^The above information can be gathered by multiplying the size from /proc/partitions by the block size, typically 1024.
BOARD_HAS_NO_SELECT_BUTTON: (optional), use this if your device needs to use its Power button to confirm selections in recovery.
BOARD_FORCE_RAMDISK_ADDRESS / BOARD_MKBOOTIMG_ARGS: (optional), use these to force a specific address for the ramdisk. This is usually needed on larger partitions in order for the ramdisk to be loaded properly where it's expected to exist. This value can be obtained from the stock kernel. The former is deprecated as of Android 4.2.x and the latter will now be used in 4.2.x and beyond.
Few *more* external links ​Few great docs that I found over the web-
One
Two
Three
Credits​>Firstly, My parents.
> @Red Devil, @galaxyfreak, @speed_bot, @Nihar.G and my Team for helping me with all my doubts and even answering the most supid questions that I asked them
> @corruptionfreeindia for the idea.
> Helpful and informative posts over-
CyanogenMod Wiki
elinux.org
StackOverflow
Got a query? Ask in the thread. Quote or mention me for quicker replies.
Thanks to @eagleeyetom for featuring it on the portal!

Understanding the Kernel Source Code​Credits for this- Linux.org
I'll basically explain the 'Linux Kernel Source' and since Android is based on the Linux, it's almost same for both.
Now the folders in order-
1. arch - This folder contains a Kconfig which sets up some settings for compiling the source code that belongs in this folder. Each supported processor architecture is in the corresponding folder. So, the source code for Alpha processors belong in the alpha folder. Keep in mind that as time goes on, some new processors will be supported, or some may be dropped.
2. block - This folder holds code for block-device drivers. Block devices are devices that accept and send data in blocks. Data blocks are chunks of data instead of a continual stream.
3. crypto - This folder contains the source code for many encryption algorithms. For example, “sha1_generic.c” is the file that contains the code for the sha1 encryption algorithm.
4. Documentation - This folder contains plain-text documents that provide information on the kernel and many of the files. If a developer needs information, they may be able to find the needed information in here.
See, this folder is just so awesome-
5. drivers - This directory contains the code for the drivers. A driver is software that controls a piece of hardware. For example, for a computer to understand the keyboard and make it usable, a keyboard driver is needed. Many folders exist in this folder. Each folder is named after each piece or type of hardware. For example, the bluetooth folder holds the code for bluetooth drivers. Other obvious drivers are scsi, usb, and firewire. Some drivers may be more difficult to find. For instance, joystick drivers are not in a joystick folder. Instead, they are under ./drivers/input/joystick. Keyboard and mouse drivers are also located in the input folder. The Macintosh folder contains code for hardware made by Apple. The xen folder contains code for the Xen hypervisor. A hypervisor is software or hardware that allows users to run multiple operating systems on a single computer.
6. firmware - The firmware folder contains code that allows the computer to read and understand signals from devices. For illustration, a webcam manages its own hardware, but the computer must understand the signals that the webcam is sending the computer. The Linux system will then use the vicam firmware to understand the webcam. Otherwise, without firmware, the Linux system does not know how to process the information that the webcam is sending. Also, the firmware helps the Linux system to send messages to the device. The Linux system could then tell the webcam to refocus or turnoff.
7. fs - 'fs' stands for File System. All of the code needed to understand and use filesystems is here. Inside this folder, each filesystem's code is in its own folder. For instance, the ext4 filesystem's code is in the ext4 folder. Within the fs folder, developers will see some files not in folders. These files handle filesystems overall. For example, mount.h would contain code for mounting filesystems. A filesystem is a structured way to store and manage files and directories on a storage device. Each filesystem has its own advantages and disadvantages. These are due to the programming of the filesystem. For illustration, the NTFS filesystem supports transparent compression (when enabled, files are automatically compressed without the user noticing). Most filesystems lack this feature, but they could only possess this ability if it is programmed into the files in the fs folder.
8. include - The include folder contains miscellaneous header files that the kernel uses. The name for the folder comes from the C command "include" that is used to import a header into C code upon compilation.
9. init - The init folder has code that deals with the startup of the kernel (INITiation). The main.c file is the core of the kernel. This is the main source code file the connects all of the other files.
10. ipc - IPC stands for Inter-Process Communication. This folder has the code that handles the communication layer between the kernel and processes. The kernel controls the hardware and programs can only ask the kernel to perform a task. Assume a user has a program that opens the DVD tray. The program does not open the tray directly. Instead, the program informs the kernel that the tray should be opened. Then, the kernel opens the tray by sending a signal to the hardware. This code also manages the kill signals. For illustration, when a system administrator opens a process manager to close a program that has locked-up, the signal to close the program is called a kill signal. The kernel receives the signal and then the kernel (depending on which type of kill signal) will ask the program to stop or the kernel will simply take the process out of the memory and CPU. Pipes used in the command-line are also used by the IPC. The pipes tell the kernel to place the output data on a physical page on in memory. The program or command receiving the data is given a pointer to the page on memory.
11. kernel - The code in this folder controls the kernel itself. For instance, if a debugger needed to trace an issue, the kernel would use code that originated from source files in this folder to inform the debugger of all of the actions that the kernel performs. There is also code here for keeping track of time. In the kernel folder is a directory titled "power". Some code in this folder provide the abilities for the computer to restart, power-off, and suspend.
12. lib - the library folder has the code for the kernel's library which is a set of files that that the kernel will need to reference.
13. mm - The Memory Management folder contains the code for managing the memory. Memory is not randomly placed on the RAM. Instead, the kernel places the data on the RAM carefully. The kernel does not overwrite any memory that is being used or that holds important data.
14. net - The network folder contains the code for network protocols. This includes code for IPv6 and Appletalk as well as protocols for Ethernet, wifi, bluetooth, etc. Also, the code for handling network bridges and DNS name resolution is in the net directory.
15. samples - This folder contains programming examples and modules that are being started. Assume a new module with a helpful feature is wanted, but no programmer has announced that they would work on the project. Well, these modules go here. This gives new kernel programmers a chance to help by going through this folder and picking a module they would like to help develop.
16. scripts - This folder has the scripts needed for compiling the kernel. It is best to not change anything in this folder. Otherwise, you may not be able to configure or make a kernel.
17. security - This folder has the code for the security of the kernel. It is important to protect the kernel from computer viruses and hackers. Otherwise, the Linux system(Android in this case ) can be damaged.
18. sound - This directory has sound driver code for sound/audio cards.
19. tools - This directory contains tools that interact with the kernel.
20. usr - The code in this folder creates vmlinuz and similar files after the kernel is compiled.
21. virt - This folder contains code for virtualization which allows users to run multiple operating systems at once. This is different from Xen (mentioned previously). With virtualization, the guest operating system is acting like any other application within the Linux operating system (host system). With a hypervisor like Xen, the two operating systems are managing the hardware together and the same time. In virtualization, the guest OS runs on top of the Linux kernel while in a hypervisor, there is no guest OS and all of the operating systems do not depend on each other.
PS- If I went wrong at any place, please do tell, I'm tend to make mistakes.

Reserved 2

I believe that 'pdk' is the Platform Development Kit, it's basically an SDK/set of tools that Google sends to OEMs to evaluate their framework ahead of each major Android upgrade since Android 4.1.

Good.
Explicit information:thumbup:
Sent from my GT-I9100 using Tapatalk 2

Just some more info (and a small correction...)
To make a particular app, I don't think
Code:
make name_of_app.apk -j'X'
is the right way to do it...
Search for the packages in "packages" directory, and open up the Android.mk file. You'd see a line that states "LOCAL_PACKAGE_NAME". You need to type in:
Code:
make <insert-value-of-local_package_name-here> -j'X'
In case you are doing this for a particular module/shared library, you'd be searching for "LOCAL_MODULE" or "LOCAL_SHARED_LIBRARY" defines.
Also, you could also always rebuild a particular directory, with the
Code:
mmm -B path/to/dir
eg:
Code:
mmm -b packages/apps/Settings
command. This is especially helpful in case of stuff like libaudio, liblights, etc which are device specific.
Also note that some of the defines and variables stick only till the Terminal's closed. There is a workaround for this, i.e. the 'screen' app, which allows you to save a terminal state. Well, that can wait for another day

GOOD ...GOOD...
guidence detailed and understandable
Thanks

great !!
but could you tell me about propietary files and vendor_blobs.mk ? and how to make it for device that using GB (for example) ?

Awesome !!
This is great.
Thank you.

Thanks for this guide op. Really nice one. :good:

Outstanding job on the guide!! Thank you very much sir. :good:

Thank you very much sir for the detailed explanation........

cleverior.ipul said:
great !!
but could you tell me about propietary files and vendor_blobs.mk ? and how to make it for device that using GB (for example) ?
Click to expand...
Click to collapse
Sorry for the wait but I'll answer this after I reach home.
Sent from my HTC Explorer A310e using XDA Premium 4 mobile app

cleverior.ipul said:
great !!
but could you tell me about propietary files and vendor_blobs.mk ? and how to make it for device that using GB (for example) ?
Click to expand...
Click to collapse
Okay, I'll tell this with an example.
Have a look at this vendor tree. This for Galaxy Nexus(Maguro).
Now, the important makefile, vendor-blobs.mk
In this case, it is:
Code:
# Copyright (C) 2010 The Android Open Source Project
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# This file is generated by device/samsung/maguro/extract-files.sh - DO NOT EDIT
# Prebuilt libraries that are needed to build open-source libraries
PRODUCT_COPY_FILES := \
vendor/samsung/maguro/proprietary/libsecril-client.so:obj/lib/libsecril-client.so
# All the blobs necessary for maguro
PRODUCT_COPY_FILES += \
vendor/samsung/maguro/proprietary/fRom:system/bin/fRom \
vendor/samsung/maguro/proprietary/libsecril-client.so:system/lib/libsecril-client.so \
vendor/samsung/maguro/proprietary/pvrsrvinit:system/vendor/bin/pvrsrvinit \
vendor/samsung/maguro/proprietary/sirfgps.conf:system/vendor/etc/sirfgps.conf \
vendor/samsung/maguro/proprietary/bcm4330.hcd:system/vendor/firmware/bcm4330.hcd \
vendor/samsung/maguro/proprietary/ducati-m3.bin:system/vendor/firmware/ducati-m3.bin \
vendor/samsung/maguro/proprietary/libpn544_fw.so:system/vendor/firmware/libpn544_fw.so \
vendor/samsung/maguro/proprietary/libEGL_POWERVR_SGX540_120.so:system/vendor/lib/egl/libEGL_POWERVR_SGX540_120.so \
vendor/samsung/maguro/proprietary/libGLESv1_CM_POWERVR_SGX540_120.so:system/vendor/lib/egl/libGLESv1_CM_POWERVR_SGX540_120.so \
vendor/samsung/maguro/proprietary/libGLESv2_POWERVR_SGX540_120.so:system/vendor/lib/egl/libGLESv2_POWERVR_SGX540_120.so \
vendor/samsung/maguro/proprietary/gps.omap4.so:system/vendor/lib/hw/gps.omap4.so \
vendor/samsung/maguro/proprietary/gralloc.omap4.so:system/vendor/lib/hw/gralloc.omap4.so \
vendor/samsung/maguro/proprietary/libglslcompiler.so:system/vendor/lib/libglslcompiler.so \
vendor/samsung/maguro/proprietary/libIMGegl.so:system/vendor/lib/libIMGegl.so \
vendor/samsung/maguro/proprietary/libinvensense_mpl.so:system/vendor/lib/libinvensense_mpl.so \
vendor/samsung/maguro/proprietary/libpvr2d.so:system/vendor/lib/libpvr2d.so \
vendor/samsung/maguro/proprietary/libpvrANDROID_WSEGL.so:system/vendor/lib/libpvrANDROID_WSEGL.so \
vendor/samsung/maguro/proprietary/libPVRScopeServices.so:system/vendor/lib/libPVRScopeServices.so \
vendor/samsung/maguro/proprietary/libsec-ril.so:system/vendor/lib/libsec-ril.so \
vendor/samsung/maguro/proprietary/libsrv_init.so:system/vendor/lib/libsrv_init.so \
vendor/samsung/maguro/proprietary/libsrv_um.so:system/vendor/lib/libsrv_um.so \
vendor/samsung/maguro/proprietary/libusc.so:system/vendor/lib/libusc.so
So, in the source code, the vendor tree is kept in /source/vendor/manufacturer/codename(vendor/samsung/maguro in this case) and the makefile parameters tell it to copy the proprietary files(that are the files in the vendor tree, for instance, open up the vendor tree's link I gave above) to certain direstories in the ROM's zip, in this case, for example, this line:
Code:
vendor/samsung/maguro/proprietary/gps.omap4.so:system/vendor/lib/hw/gps.omap4.so \
this tells the builder to copy the proprietary file gps.omap4.so to lib/hw folder in the system.
I hope you'll figure out the remaining and this cleared your doubts.
PS- If I went wrong at some place, correct me.

Great job! Congrats on getting featured on the portal!
The guide is great!

Great guide mate! Maybe you can teach us how to track build error's ?

smileydr0id said:
Great guide mate! Maybe you can teach us how to track build error's ?
Click to expand...
Click to collapse
That are mostly easy to track, few can be easily be fixed by seeing the error's line and jumping to that file, and if you are unable to fix, then Google or this thread will help you.

Awesome job man! Keep going

The libnativehelper folder,
README:
Support functions for Android's class libraries
These are VM-agnostic native functions that implement methods for system
class libraries. All code here:
- MUST not be associated with an android.* class (that code lives in
frameworks/base/).
- SHOULD be written in C rather than C++ where possible.
Some helper functions are defined in include/nativehelper/JNIHelp.h.​
:good:

This is Awesome!
Thanks #Superuser

[GUIDE] Learning about the Android Build Process

Introduction​The Android open-source project (AOSP) is quite complex and it can be hard to find a good way to get more familiar with it. I’m going to try a practical approach, by describing the relevant parts of the build process.
Note - I recommend reading my this guide before you through this one just in case you are actually gonna read and learn.
This guide explains the whole android build process right from envsetup.sh to the working and understanding of makefiles to Package complete!
The Beginning(envsetup.sh)​It all gets started with the
Code:
. build/envsetup.sh
command. What it basically does is that it adds a number of commands to your environment which you later use for building Android for your device.
The commands are listed below -
Code:
- lunch: lunch <product_name>-<build_variant>
- tapas: tapas [<App1> <App2> ...] [arm|x86|mips|armv5] [eng|userdebug|user]
- croot: Changes directory to the top of the tree.
- cout: Changes directory to out.
- m: Makes from the top of the tree.
- mm: Builds all of the modules in the current directory.
- mmp: Builds all of the modules in the current directory and pushes them to the device.
- mmm: Builds all of the modules in the supplied directories.
- mmmp: Builds all of the modules in the supplied directories and pushes them to the device.
- mma: Builds all of the modules in the current directory, and their dependencies.
- mmma: Builds all of the modules in the supplied directories, and their dependencies.
- cgrep: Greps on all local C/C++ files.
- jgrep: Greps on all local Java files.
- resgrep: Greps on all local res/*.xml files.
- godir: Go to the directory containing a file.
- cmremote: Add git remote for CM Gerrit Review.
- cmgerrit: A Git wrapper that fetches/pushes patch from/to CM Gerrit Review.
- cmrebase: Rebase a Gerrit change and push it again.
- aospremote: Add git remote for matching AOSP repository.
- cafremote: Add git remote for matching CodeAurora repository.
- mka: Builds using SCHED_BATCH on all processors.
- mkap: Builds the module(s) using mka and pushes them to the device.
- cmka: Cleans and builds using mka.
- repolastsync: Prints date and time of last repo sync.
- reposync: Parallel repo sync using ionice and SCHED_BATCH.
- repopick: Utility to fetch changes from Gerrit.
- installboot: Installs a boot.img to the connected device.
- installrecovery: Installs a recovery.img to the connected device.
It also scans for the 'vendorsetup.sh' files in your source and display them in this form -
Code:
including device/generic/armv7-a-neon/vendorsetup.sh
including device/generic/goldfish/vendorsetup.sh
including device/generic/mips/vendorsetup.sh
including device/generic/x86/vendorsetup.sh
including vendor/cm/vendorsetup.sh
including sdk/bash_completion/adb.bash
including vendor/cm/bash_completion/git.bash
including vendor/cm/bash_completion/repo.bash
The file is responsible for -
All the make device calling, make etc. commands are possible only after you execute the envsetup.sh file.
It also scans and does some magic stuff with the build/core directory.
It also displays choices of variant for the selected device, like 'userdebug', 'user', 'eng'.
It is also responsible for performing the most important step, it sets up the android build paths and and sets up the toolchains for the build process.
It also calls java and sets it parameters for the compilation.
It displays the default device configurations that are -
Code:
add_lunch_combo aosp_arm-eng
add_lunch_combo aosp_x86-eng
add_lunch_combo aosp_mips-eng
add_lunch_combo vbox_x86-eng
It calls the 'roomservice.py' file in build/tools folder which is responsible for finding and downloading the device sources from CyanogenMod's github if they don't exist.
The file also contains the CWM and TWRP commands to sideload the product files into the device.
It also gets bug reports from the device to the machine for the developers to work upon.
The lunch/brunch Command​Next thing is to select target using the lunch menu, which was added to your bash shell environment after sourcing envsetup.sh. After making your selection, the chosen product and variant is verified and environment variables are set, including:
export TARGET_PRODUCT=$product – The chosen product
export TARGET_BUILD_VARIANT=$variant – The chosen variant
export TARGET_BUILD_TYPE=release – Only release type is available. Use choosecombo if you want to select type.
export ANDROID_BUILD_TOP=$(gettop) – The build root directory.
export ANDROID_TOOLCHAIN=... – The toolchain directory for the prebuilt cross-compiler matching the target architecture
export PATH=... – Among other stuff, the prebuilt toolchain is added to PATH.
export ANDROID_PRODUCT_OUT=... – Absolute path to the target product out directory
export ANDROID_HOST_OUT=... – Absolute path to the host out directory
The usage is pretty simply, you can just type 'lunch' and you'll be prompted with the list of devices that you can build for with the sources present or you can just type 'lunch cm_<device_name>-<variant_type>'.
The lunch command actually fixes the target for the build process and is responsible for the paths getting locked and the device configurationto be used and applied to the source.
It actually gets to use only after there is a vendorsetup.sh file in your device tree which is responsible for adding the lunch combo(Which shows up in the list of devices when you simply run lunch) of your device.
The MAKE Command​The purpose of the make utility is to determine automatically which pieces of a large program need to be recompiled, and issue the commands to recompile them. The manual describes the GNU implementation of make, which was written by Richard Stallman and Roland McGrath. The following examples show C programs, since they are most common, but you can use make with any programming language whose compiler can be run with a shell command. In fact, make is not limited to programs. You can use it to describe any task where some files must be updated automatically from others whenever the others change.
To prepare to use make, you must write a file called the makefile that describes the relationships among files in your program, and the states the commands for updating each file. In a program, typically the executable file is updated from object files, which are in turn made by compiling source files.
Once a suitable makefile exists, each time you change some source files, this simple shell command:
Code:
make
suffices to perform all necessary recompilations. The make program uses the makefile data base and the last-modification times of the files to decide which of the files need to be updated. For each of those files, it issues the commands recorded in the data base.
make executes commands in the makefile to update one or more target names, where name is typically a program. If no -f option is present, make will look for the makefiles GNUmakefile, makefile, and Makefile, in that order.
Normally you should call your makefile either makefile or Makefile. (I recommend Makefile because it appears prominently near the beginning of a directory listing, right near other important files such as README.) The first name checked, GNUmakefile, is not recommended for most makefiles. You should use this name if you have a makefile that is specific to GNU make, and will not be understood by other versions of make. If makefile is `-', the standard input is read.
make updates a target if it depends on prerequisite files that have been modified since the target was last modified, or if the target does not exist.
Makefile Execution​
{
"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"
}
The make command executes the commands in the makefile line by line. As make executes each command, it writes the command to standard output (unless otherwise directed, for example, using the -s flag). A makefile must have a Tab in front of the commands on each line.
When a command is executed through the make command, it uses make's execution environment. This includes any macros from the command line to the make command and any environment variables specified in the MAKEFLAGS variable. The make command's environment variables overwrite any variables of the same name in the existing environment.
Note:
When the make command encounters a line beginning with the word include followed by another word that is the name of a makefile (for example, include depend), the make command attempts to open that file and process its contents as if the contents were displayed where the include line occurs. This behavior occurs only if the first noncomment line of the first makefile read by the make command is not the .POSIX target; otherwise, a syntax error occurs.
Comments: Comments begin with a # character, anywhere but in a shell command line, and continue to the end of the line.
Click to expand...
Click to collapse
Environment: The make command uses the MAKEFLAGS environment variable, if it exists.
Target Rules​
Target rules have the following format:
target[target...] : [prerequisite...] [;command]
<Tab>command
Multiple targets and prerequisites are separated by spaces. Any text that follows the ; (semicolon) and all of the subsequent lines that begin with a Tab character are considered commands to be used to update the target. A new target entry is started when a new line does not begin with a Tab or # character.
You can also look up at the Makefile Tutorial here http://mrbook.org/tutorials/make/ !
That was the most important part of the build process, where make files are resposible for compiling almost each of the files in the source and putting them together for the useful apps/binaries/libraries etc.
Build Tricks​Used from wiki.
Seeing the actual commands used to build the software
Use the "showcommands" target on your 'make' line:
$ make -j4 showcommands
This can be used in conjunction with another make target, to see the commands for that build. That is, 'showcommands' is not a target itself, but just a modifier for the specified build.
In the example above, the -j4 is unrelated to the showcommands option, and is used to execute 4 make sessions that run in parallel.
Make targets
Here is a list of different make targets you can use to build different parts of the system:
make sdk - build the tools that are part of an SDK (adb, fastboot, etc.)
make snod - build the system image from the current software binaries
make services
make runtime
make droid - make droid is the normal build.
make all - make everything, whether it is included in the product definition or not
make clean - remove all built files (prepare for a new build). Same as rm -rf out/<configuration>/
make modules - shows a list of submodules that can be built (List of all LOCAL_MODULE definitions)
make <local_module> - make a specific module (note that this is not the same as directory name. It is the LOCAL_MODULE definition in the Android.mk file)
make clean-<local_module> - clean a specific module
Helper macros and functions
There are some helper macros and functions that are installed when you source envsetup.sh. They are documented at the top of envesetup.sh, but here is information about a few of them:
croot - change directory to the top of the tree
Code:
m - execute 'make' from the top of the tree (even if your current directory is somewhere else)
mm - builds all of the modules in the current directory
mmm <dir1> ... - build all of the modules in the supplied directories
cgrep <pattern> - grep on all local C/C++ files
jgrep <pattern> - grep on all local Java files
resgrep <pattern> - grep on all local res/*.xml files
godir <filename> - go to the directory containing a file
Speeding up the build​You can use the '-j' option with make, to start multiple threads of make execution concurrently.
In my experience, you should specify about 2 more threads than you have processors on your machine. If you have 2 processors, use 'make -j4', If they are hyperthreaded (meaning you have 4 virtual processors), try 'make -j6.
You can also specify to use the 'ccache' compiler cache, which will speed up things once you have built things a first time. To do this, specify 'export USE_CCACHE=1' at your shell command line. (Note that ccache is included in the prebuilt section of the repository, and does not have to be installed on your host separately.)
Building only an individual program or module
If you use build/envsetup.sh, you can use some of the defined functions to build only a part of the tree. Use the 'mm' or 'mmm' commands to do this.
The 'mm' command makes stuff in the current directory (and sub-directories, I believe). With the 'mmm' command, you specify a directory or list of directories, and it builds those.
To install your changes, do 'make snod' from the top of tree. 'make snod' builds a new system image from current binaries.
Setting module-specific build parameters
Some code in Android system can be customized in the way they are built (separate from the build variant and release vs. debug options). You can set variables that control individual build options, either by setting them in the environment or by passing them directly to 'make' (or the 'm...' functions which call 'make'.)
For example, the 'init' program can be built with support for bootchart logging by setting the INIT_BOOTCHART variable. (See Using Bootchart on Android for why you might want to do this.)
You can accomplish either with:
$ touch system/init/init.c
$ export INIT_BOOTCHART=true
$ make
or
$ touch system/init/init.c
$ m INIT_BOOTCHART=true
At last, after makefiles optimize all the processes and build the device specific parts including binaries and libs and apps necessary for it to get booted, the 'system' folder and the 'boot.img' folder are prepared in the out/target/product/device. The META-INF folder is prepared at instance and the system and boot.img are packed into a zip file(whose name is also processed by the makefiles ) and md5 sum prepared. The flashable zip gets prepared only if you run the "brunch" command or "lunch + mka" command.
The Build Tricks aren't *for fun*. This stuff is always gonna help you in the long run!
Credits -
>Firstly, my parents.
>Google, for Android!
>All the people over xda who have written awesome guides and done great works(Because that's what inspires me)
> @galaxyfreak , @speed_bot, @Red Devil, @thewisenerd, @vishal_android freak and all others who helped me every time and answered every(sensible) question of mine.
>The CyanogenMod, AOKP and OmniROM team!
> All those whom I missed.
Have a Happy time learning! ​

Reserved.

Good work. Another guide to feature in portal (?) Tipped
Cheers,
AJ

Awesome. Tipped second. All the best
Sent from my Nexus 5 using Tapatalk

Great work.. Nice guide
Thanks
Sent from xt1033, India

Another great one man!

thanks very useful

Noobs become a developer, is it possible?!
Could I be a developer by following this tutorial incredible? By the way thank you very much for the guidance.

Very good guide. Well written and easy to understand.

Really good guide bro.
Easy to understand and very helpful, thanks for writing it.

AWSM guide!!!
superb guide thread, beautifully explained with diagrams:good:...
got to know some new build tricks u mentioned...

Good work..!
Tipped..
Nice guide... Informative... :good:

This is what I've always wanted :laugh::laugh::laugh: Thanks my friend!

TPD-21 said:
Could I be a developer by following this tutorial incredible? By the way thank you very much for the guidance.
Click to expand...
Click to collapse
Even with all the guides and RTFM sessions, you'd need to go on the path of self-learning (documentation, experimenting, etc), to get better
@v_superuser, Nice guide You always make things easier for n00bs, don't you?

thewisenerd said:
Even with all the guides and RTFM sessions, you'd need to go on the path of self-learning (documentation, experimenting, etc), to get better
@v_superuser, Nice guide You always make things easier for n00bs, don't you?
Click to expand...
Click to collapse
I know the feel, I was one some time back. Thanks Google. Haha!

Nice guide. Thanks for sharing!

Superb guide I believe this is going to be my guide to RoM development... Thanks :good:
Sent from an open source device

Bump!

Bumping this guide. Just simply excellent.

Still relavent
Thanks for the guide,
I waas doing a build for oreo, and came across this guide by google search.
This will get a mention and a link in my how to article
Some lines need an update for oreo and but its really good

[Scripting][ARM][Installer][Port] Python (static) 2.7.9 and 3.4.2

(Check out https://www.python.org for information on what python is.)
Yes you read that correctly, static python for Android! It took a while to figure out how to get this compiled, but I finally did it. I present you with an installer and a little bit of testing. The second post contains information on compilation and the sources. Btw, any cool python scripts are welcomed!
INSTALLATION
Recovery flash installers are attached that will install python 2.7.9 and/or 3.4.2 to /system/pythonX.X.X. You can install both if you want. Installation size is about 41MB, 43MB, and 49MB respectively for python 2.7.8, python 2.7.9, and python 3.4.2.
After installation, the python director(ies) in /system will contain the static python binary, some scripts, and a bunch of modules and documents. Separate scripted executables will be installed to /system/bin/python or /system/bin/python3 depending on which one is installed. These basically just set the PYTHONHOME environment variable and execute the python binary.
TESTING
When you boot up to Android after installation, you should be able to just open up a terminal and fire off some python commands.
Test using python 2.7.9:
Code:
python -c 'print "Hello World!"'
Test using python 3.4.2:
Code:
python3 -c 'print("Hello World!")'
You can also write scripts shelled with python:
Code:
#!/system/bin/python
print "Hello World!"
Make sure to set them as executable with "chmod +x".
Adjust your screen brightness via /sys (root required, tested on Galaxy Nexus):
Code:
python -c 'f=open("/sys/devices/omapdss/display0/backlight/s6e8aa0/brightness","w"); f.write("40"); f.close()'
A cool script I made to tweak file system I/O like rq_affinity, rotational, etc for I/O blocks:
Code:
#!/system/bin/python
import os,re,sys
list=[]
# find all directories containing rq_affinity
for roots, dirs, files in os.walk('/sys'):
for file in files:
match=re.search(r'\S+/rq_affinity',os.path.join(roots,file))
if match:
list.append(match.group().replace('rq_affinity',''))
# write specific values to files in each directory found before
for dir in list:
for name in 'rq_affinity', 'rotational', 'read_ahead_kb', 'nr_requests', 'iostats', 'nomerges', 'add_random':
try:
f=open(dir+name,'w')
if name is 'rq_affinity': f.write('1')
elif name is 'read_ahead_kb': f.write('512')
elif name is 'nr_requests': f.write('512')
else: f.write('0')
f.close()
except IOError:
sys.stderr.write('Problem writing to ' + dir+name + '\n')
Or execute "python" or "python3" without any parameters to open up the interpreter and go from there. When you start for example "python" (python 2.7.8), you should see something like:
Code:
Python 2.7.8 (default, Dec 2 2014, 05:15:18)
[GCC 4.9.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
***I haven't fully tested this yet, so let me know how it goes. I know basic commands work, but there are still some complexities in the compilation that may need to be figured out.***
(update) -- Install Extra Packages/Modules via "easy_install" -- (root required)
1) In a shell, remount /system read-writable with:
Code:
mount -o remount,rw /system
2) Change directory to /system/pythonX.X.X, i.e.,
Code:
cd /system/pythonX.X.X
3) Execute easy_install followed by a package name, i.e.,
Code:
./easy_install [i]package_name[/i]
4) Let it download and install! Then test it out.
5) Remount /system read-only with:
Code:
mount -o remount,ro /system
Also, to remove a package, execute:
Code:
./easy_install -m [i]package_name[/i]
rm -r ../lib/pythonX.X/site-packages/[i]package_name[/i]*.egg
*** Flashing the resolv.conf patch may be required to make an internet connection to download modules.
Also, a few things need to be done to get easy_install working:
1) For python 2.7.8 or 2.7.9 you need to link python2.7 to python like this:
Code:
ln -s /system/python2.7.9/bin/python2.7 /system/python2.7.9/bin/python
I'll make sure this is automatically done in future installs.
2) SSL certificates need to be added to "/etc/pki/tls/certs/" to use SSL with easy_install.
Code:
mkdir -p /etc/pki/tls/certs
curl http://curl.haxx.se/ca/cacert.pem -o /etc/pki/tls/certs/ca-bundle.crt
ISSUES
The python installations have the following modules compiled in with external dependencies such as libraries not included at this point:
Code:
--------------PYTHON 2.7.8-2.7.9----------------------
_hashlib _multiprocessing _ssl
_testcapi bz2 crypt
dbm
Code:
--------------PYTHON 3.4.2-----------------------------
_crypt _dbm _decimal
_hashlib _multiprocessing _ssl
_testcapi
I will look into this more.
As @bubbleguuum points out, name resolution with python 3.4.2's urllib wasn't working. I found a workaround by adding the line
Code:
options single-request-reopen
to /system/etc/resolv.conf. This still needs some testing but seemed to work for me. I've included a recovery flash zip to patch /system/etc/resolv.conf if the line is not there since this is a root operation.
UPDATES
* 2014-12-02 * Compiled in more modules for each installation. This makes the installation a bit bigger, but it's worth it. You get a more complete python! To get stuff like help functions and math and readline modules, you need the larger installations linked below under "DOWNLOADS".
* 2014-12-03 * Thanks @cybojenix for pointing out some incapatibility issues with the original edify installer I was using. I have now updated the installers to use SuperSU's great non-edify sh-script installer.
* 2014-12-05 * Some updates to the installers to include more modules, plus size reduction for python 3.4.2. Modules added to python 2.7.8 : _bsddb _ctypes, _ctypes_test, _hotshot, _json, _lsprof, _sqlite3, future_builtins, and ossaudiodev, easy_install, pip(broken for now). Modules added to python 3.4.2: _bz2, _ctypes, _ctypes_test, _gdbm, _json, _lsprof, _opcode, _sqlite3, _testbuffer, _testimportmultiple, ossaudiodev, xxlimited
* 2014-12-05 * Some big updates to the installer to include almost the rest of the modules that wouldn't compile. Also easy_install is working on my end with these new experimental builds. With a little effort, should be able to get pip working as well. I had to use some hacky flags to get it to compile, ignore unresolved-symbols and such, so it definitely needs some testing. Another thing I did was tweak the install script to write over previous installations from these installations. I recommend downloading the experimental builds if you read this. The worst thing that might happen is one of the new modules I've included won't work completely.
* 2014-12-14 * Added python 2.7.9. Trimmed the installation sizes down to the much more reasonable 41MB, 43MB, and 49MB respectively for python 2.7.8, python 2.7.9, and python 3.4.2.
* 2014-12-24 * Attached a recovery flash.zip to patch resolv.conf to try and fix a urllib name resolution error.
* 2014-12-26 * A couple updates: Tweaked python installations so that modules looks for "/system/bin/sh" instead of "/bin/sh" when needed. Also a few "#!" corrections for scripts in the python bin directory. This shouldn't break anything from what I've tested, only make Android python more capable, but I'll keep the old installations attached for now just in case since the modifications involved using "sed". The second update is nice. I've added a little section on installing extra modules with easy_install(included and working with all installations).

Compiling
The environment I compiled in was a debian "wheezy" image mounted as a loop device on Android. The reason I compile this way is so I have full access to the arm environment tools, gcc compiler, etc. without having to go through the trouble of using a cross-compiler (which doesn't work in this case from my testing with uClibc, or eglibc. Code sourcery's might work but I didn't feel like booting an x86 linux installation to try). You can recreate the same environment pretty easily by using either Complete Linux Installer or Linux Deploy apps. I use both.
To get a static python compiled, I first downloaded the following packages with APT:
Code:
[i]apt-get build-dep python python3[/i]
build-essential gcc make # building tools
binutils-gold # awesome gold linker
zlib1g-dev # zlib
libreadline-dev, libncurses5-dev # readline, curses
libbz2-dev # bz2
libsqlite3-dev # sqlite3
python-bsddb3, python3-bsddb3
libgdbm-dev # gdb
libssl-dev # ssl
python-tk, python3-tk # tkinter
libdb-dev # db
python-gdbm python-bsddb3
libffi-dev # _ctypes
tcl8.6-dev # tkinter
libx11-dev # tkinter
libmpdec-dev # decimal
Then I manually installed binutils-gold by unpacking the rpm for armv7h (this isn't available with APT yet). You can get it here though. (Update: this should be available in the debian repositories now.)
For static compilation, you need to make some changes to Modules/Setup from the python source directory. Specifically, you need to add
Code:
*static*
to the top of the file. Then you need to uncomment any commented modules you would like compiled in. When you compile and see a list of failed modules, search for each of these in Modules/Setup and uncomment them. For example, change
Code:
#math mathmodule.c _math.c
to
Code:
math mathmodule.c _math.c
. Then recompile. There may be some shared dependencies and packages as well you need to figure out to get them to compile. Take a look at the attached "Setup" files for more detail.
The actually compile steps look like this:
(1)
Code:
./configure --build=arm --prefix="$PWD"/out LDFLAGS="-static -static-libgcc -Wl,--unresolved-symbols=ignore-all -Wl,--export-dynamic" CPPFLAGS=-static CXXFLAGS=-static CFLAGS="-Os -static" LDFLAGS=-static LD=ld.gold
(2) Modify the Modules/Setup file.
(3)
Code:
make clean; make install
After compiling, there are some things you can do to make your installation in "./out" smaller. Strip the large binaries in "out/bin", i.e.
Code:
strip -s ./out/bin/python2.7
Also remove the python archive library, *.o's, etc. with:
Code:
make clean
This might seem kind of weird, but it works and cleans out unnecessary files from your installation.
**Make sure to backup your Modules/Setup file if you run "make distclean". I lost my 3.4.2 Modules/Setup file after doing this. :silly: Now I gotta recreate it, dammit.
**I should also mention that compile time is very fast given the amount of data generated. It takes about 10 minutes to get python and all it's modules compiled on my Galaxy Nexus.**
:EDITS:
: Updated some configure parameters. Removed unnecessary, extra "./configure". Also added some updates to the included "Setup" files.
: Hacky update to "./conifgure" to ignore unresolved symbols, export dynamic. This allows certain modules to be compiled which have shared dependencies.
: Update to trimming down the installation size after "make". Use another "make clean".
Downloads - Extract in the source directory
Setup (python 2.7.8)
Setup (python 3.4.2)
Setup (Experimental) (python 2.7.8)
Setup (Experimental) (python 3.4.2)

Something that would be interesting to look in to would be to have pip/easy_install running, so you can install extra non c packages onto the sdcard/data/wherever.
Would you also consider opening up the sources please? There is a project I'm interested in doing involving python on Android, however a lack of time meant I couldn't finish building it.
Give me a shout if you need anything. I hope to see even more come out of this thread
Edit:
I've just looked at the updater-script. The mount command won't work on the majority of devices. Can you turn the update-binary in to a shell script please? See the SuperSU updater for reference

cybojenix said:
Something that would be interesting to look in to would be to have pip/easy_install running, so you can install extra non c packages onto the sdcard/data/wherever.
Would you also consider opening up the sources please? There is a project I'm interested in doing involving python on Android, however a lack of time meant I couldn't finish building it.
Give me a shout if you need anything. I hope to see even more come out of this thread
Edit:
I've just looked at the updater-script. The mount command won't work on the majority of devices. Can you turn the update-binary in to a shell script please? See the SuperSU updater for reference
Click to expand...
Click to collapse
Thanks for your reply! I've changed the installer to use SuperSU's no-edify sh-scripted updater. I tested on my device, but let me know if there are any issues though. I kept it pretty basic.
I added some stuff on the source modifications and compilation to the 2nd post. The only file I've actually modified so far in the source is the generated Modules/Setup file, and I've included the one I used for python 2.7.8. Unfortunately, I over-cleaned the python 3.4.2 directory, which deleted my modified Modules/Setup there, so I'll have to add it later when I re-edit it.
That's a great idea on pip/easy_install. I did download the pip_installer and tried out installing on the static python I made. Got some errors though pointing to a few modules I haven't gotten compiled into the static python installation (listed in the OP near the bottom, specifically _ctypes). I'll see what I can do about that. The line for compiling the module might just need to be added to Modules/Setup. Hopefully that's the case.

@7175
Thank you very much for these binaries.
There is however a problem: name resolution (DNS) doesn't seem to work at all (with both python 2 and 3 downloads).
All attempts to use urllib.request.urlopen('http://somehost.com') fail with "<urlopen error [Errno -2] Name or service not known>" (running python as root but it doesn't matter, and a rooted Nexus 4 running 4.4.4 stock ROM):
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/system/python3.4.2/lib/python3.4/urllib/request.py", line 153, in urlopen
return opener.open(url, data, timeout)
File "/system/python3.4.2/lib/python3.4/urllib/request.py", line 455, in open
response = self._open(req, data)
File "/system/python3.4.2/lib/python3.4/urllib/request.py", line 473, in _open
'_open', req)
File "/system/python3.4.2/lib/python3.4/urllib/request.py", line 433, in _call_chain
result = func(*args)
File "/system/python3.4.2/lib/python3.4/urllib/request.py", line 1202, in http_open
return self.do_open(http.client.HTTPConnection, req)
File "/system/python3.4.2/lib/python3.4/urllib/request.py", line 1176, in do_open
raise URLError(err)
urllib.error.URLError: <urlopen error [Errno -2] Name or service not known>
Click to expand...
Click to collapse
it works if replacing somehost.com by its ip address.
To reproduce above stack trace with python 3:
import urllib.request
urllib.request.urlopen('http://www.google.com')
while this work:
urllib.request.urlopen('http://173.194.45.229')
nslookup and general name resolution work anywhere else:
[email protected]:/ # nslookup www.google.com
nslookup wwwgoogle.com
Server: 8.8.4.4
Address 1: 8.8.4.4 google-public-dns-b.google.com
Name: wwwgoogle.com
Address 1: 2a00:1450:4007:80c::1014 par03s15-in-x14.1e100.net
Address 2: 173.194.45.242 par03s15-in-f18.1e100.net
Address 3: 173.194.45.240 par03s15-in-f16.1e100.net
Address 4: 173.194.45.244 par03s15-in-f20.1e100.net
Address 5: 173.194.45.241 par03s15-in-f17.1e100.net
Address 6: 173.194.45.243 par03s15-in-f19.1e100.net
Click to expand...
Click to collapse
This issue has probably something to do with how python was compiled to do name resolution. I remember vaguely a similar issue
on Ubuntu 12.04, with a ffmpeg compile that would always fail to resolve hostnames in URLs. No sure what the exact fix was but it had something to do with the libc and its name resolution mechanism. Or maybe something ipv6 related ?

@bubbleguuum : Thanks for checking out that important issue.
I did a little research and it seems there is some issue with DNS name resolution related to ipv6. I recompiled with "--disable-ipv6" and that seemed to fix the issue. I also found that adding the line
Code:
options single-request-reopen
to /etc/resolv.conf did the trick as well. Apparently this tells the resolver to use a new socket for ipv6 resolution instead of same one as ipv4. It thereby reduces wait-time as well. Maybe check on your end and see if that works. Otherwise I'll upload ipv4-only installations since this issue at least needs to be side-stepped.
EDIT: Hmm, looks like re-compiling with "--disable-ipv6" didn't fix the problem. Will have to look more into this issue and hold off on uploading ipv4-only python3 since it didn't fix it. In the meantime, I've attached a recovery flash.zip to the OP to add the above mentioned line to /system/etc/resolv.conf if needed, which seems to fix the issue for me.

7175 said:
@bubbleguuum : Thanks for checking out that important issue.
I did a little research and it seems there is some issue with DNS name resolution related to ipv6. I recompiled with "--disable-ipv6" and that seemed to fix the issue. I also found that adding the line
Code:
options single-request-reopen
to /etc/resolv.conf did the trick as well. Apparently this tells the resolver to use a new socket for ipv6 resolution instead of same one as ipv4. It thereby reduces wait-time as well. Maybe check on your end and see if that works. Otherwise I'll upload ipv4-only installations since this issue at least needs to be side-stepped.
Click to expand...
Click to collapse
Thank you for looking into this so fast.
My intended usage is for running the python binary from a regular non-root app (which works great!), so editing resolv.conf is not an option.

I've been researching that DNS resolving issue and could not find a clear explanation on why it fails on Android and not on other systems, and why exactly the added line in resolv.conf fixes (or rather workaround) it.
All seems to point to socket.getaddrinfo() failing for an unknown reason.
Is Python compiled with HAVE_GETADDRINFO defined ? If that's the case it uses the libc definition of getaddrinfo, otherwise
it uses an emulation function found in getaddrinfo.c.
My guess is that it is the latter, and what is causing this issue on Android.
It's probable this issue has already been solved on Android since other Python binaries exists, but Googling around do not give
much answer.

I get this error when trying to install anything with easy_install (using /system/python3.4.2/bin/easy_install-3.4 because /system/python3.4.2/easy_install doesn't seem to exist like in the OP):
Code:
# ./easy_install-3.4 feedparser
Searching for feedparser
Reading https://pypi.python.org/simple/feedparser/
Download error on https://pypi.python.org/simple/feedparser/: [Errno -2] Name or service not known -- Some packages may not be found!
Couldn't find index page for 'feedparser' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading https://pypi.python.org/simple/
Download error on https://pypi.python.org/simple/: [Errno -2] Name or service not known -- Some packages may not be found!
No local packages or download links found for feedparser
error: Could not find suitable distribution for Requirement.parse('feedparser')
i got curl and the certs installed in /etc/pki/tls/certs/ as per instrucions in the OP, any help?

Thoughts on PIL?

Hmm... new problems here. Android Lollipop have no /system/etc/resolv.conf by-default and urllib patch is no more works.
How it can be fixed?

http://qpython.net/index.php

Where I can find source code and related documents for project

Pratik Raj said:
Where I can find source code and related documents for project
Click to expand...
Click to collapse
I would like to know the same, as well as what license it is under... Also, I don't care about the network, but does it work on Oreo? Also, do you think I could customise the installer to install to a non-system location (/tmp) so that my flashable zip can use python?

hackintosh5 said:
I would like to know the same, as well as what license it is under... Also, I don't care about the network, but does it work on Oreo? Also, do you think I could customise the installer to install to a non-system location (/tmp) so that my flashable zip can use python?
Click to expand...
Click to collapse
Idk about OP, but I can surely post my source for python 2.7 on arm/arm64. I compiled it like a year ago, but it wasn't too bad, just required a bunch of patches and code for dlopen

I just want to say thank you so much.

[TOOL][LINUX/MAC]One Step to Initialize the Android Build Environment

Journey through the build process
Android is based on the Linux Kernel. Read on Wikipedia .
Before we get started, I created a binary long ago and thought I'd share it which helps you quickly setup your environment. If you're new to this, select option 3 and it should setup the environment for you. make sure to run it with `sudo` perms something like
Bash:
sudo ./setupEnv
. This will basically install library dependencies and set CCACHE=1 also size of ccache to a max of 15GiB(recommended). It should set your swappiness to 10 so that kernel doesnt swap out memory and lesser IO access == faster compile times. Now that that's over. Let's get into business!
Before we begin you must know at least the slightest of :
1. Java
2. C/C++
3. Makefiles
Knowing these will help you debug the ROM as well as solve any compile issues.
Short description about the folders present:
ART: Default Runtime used in lollipop
Bionic - the C-runtime for Android. It's mostly on BSD-derived sources. In this folder you will find the source for the c-library, math and other core runtime libraries.
Bootable: Contains the source for recovery.
Build - the build system implementation including all the core make file templates.
Device - product specific code for different devices.
External - contains source code for all external open source projects such as SQLite, Freetype and webkit.
Frameworks - this folder is essential to Android since it contains the sources for the framework. Consists of native libraries and core Java classes required for android. Example(ListView,TextView) classes are present here.
Hardware - hardware related source code such as the Android hardware abstraction layer specification and implementation. Also contains RIL implementations.
Kernel- Contains the sources for the Android version of the Linux kernel.
Packages - contains the source code for the default applications
Prebuilt - contains files that are distributed in binary form for convenience. Examples include the cross compilations toolchains for different development machines.
System - source code files for the core Android system. That is the minimal Linux system that is started before the VM and any java based services are enabled. This includes the source code for the init process and the default init.rc script that provide the dynamic configuration of the platform.
Read more about it at http://elinux.org/Android-4.0.3_r1. It's ICS but still gives a understanding of what each folder contains.
setupEnv
You should be able to setup build environment and initialise repository needed through my binary.
The device tree
.Contains the necessary PRODUCT_PACKAGES specified by your makefile which suits your device.
.CPU architecture, Partition size everything is set here.
.A skeleton tree can be created using
Code:
./build/tools/device/mkvendor.sh vendor devicename pathtoboot.img
.Doing this will provide a prebuilt kernel and not an inline kernel build process. using a prebuilt kernel is deprecated since it might not work correctly with the ROM you're building
.Custom init files are set here(Different radio types)
.Custom overlays for your device is set here.
.Custom init scripts are set here
Lets examine each of these files:
BoardConfig.mk
This file contains vital architectual and build information about the architecture of your device's motherboard, CPU, and other hardware. Getting this file right is essential.
To get a basic recovery booting, a few parameters need to be set in this file.
The following parameters must be set properly in BoardConfig to compile a working recovery image:
TARGET_ARCH: this is the architecture of the device it is usually something like arm or omap3.
BOARD_KERNEL_CMDLINE: not all devices pass boot parameters however if your device does this must be filled out properly in order to boot successfully. You can find this information in the ramdisk.img. (You can learn more about configuring the integrated kernel build-from-source here.)
BOARD_KERNEL_PAGESIZE: the pagesize of the stock boot.img and must be set properly in order to boot. Typical values for this are 2048 and 4096 and this information can be extracted from the stock kernel.
BOARD_BOOTIMAGE_PARTITION_SIZE: the number of bytes allocated to the kernel image partition.
BOARD_RECOVERYIMAGE_PARTITION_SIZE: the number of bytes allocated to the recovery image partition.
BOARD_SYSTEMIMAGE_PARTITION_SIZE: the number of bytes allocated to the Android system filesystem partition.
BOARD_USERDATAIMAGE_PARTITION_SIZE: the number of bytes allocated to the Android data filesystem partition.
Note:
The above information can be obtained by multiplying the size from /proc/partitions or /proc/mtd by the block size, typically 1024.
BOARD_HAS_NO_SELECT_BUTTON: (optional), use this if your device needs to use its Power button to confirm selections in recovery.
BOARD_FORCE_RAMDISK_ADDRESS / BOARD_MKBOOTIMG_ARGS: (optional), use these to force a specific address for the ramdisk. This is usually needed on larger partitions in order for the ramdisk to be loaded properly where it's expected to exist. This value can be obtained from the stock kernel. The former is deprecated as of Android 4.2.x and the latter will now be used in 4.2.x and beyond.
device_[codename].mk
The device_codename.mk makefile contains instructions about which Android packages to build , and where to copy specific files and packages, or specific properties to set during your compilation .
This file can be used to copy vital files into the ramdisk at compilation time.
PRODUCT_COPY_FILES: used to copy files during compilation into the ramdisk, which will be located at $OUT/recovery/root.
Example:
$(LOCAL_PATH)/sbin/offmode_charging:recovery/root/sbin/offmode_charging \
This will copy the file offmode_charging binary into the sbin folder within the ramdisk.
PRODUCT_NAME / PRODUCT_DEVICE: used for setting the value of your codename. This is the name of the device you load with Lunch.
This is simply the prebuilt kernel image or a kernel you built yourself used to boot the device. The format of the kernel may be in a zImage or uImage , depending on the requirements of the architecture of your device.
cm.mk
You'll need to make a few changes to this file to integrate with the lunch , brunch , and breakfast commands, so that your device shows up on the list and builds properly. You'll also set some variables (see other devices) to indicate what size splash animation should be used, whether this is a tablet or phone, etc.
Some of these settings aren't used for building just the recovery, but you may as well set them now because once recovery is done and working, the settings here will be important.
Again, take a look at a similar device to yours to get an idea of what the settings here should be. It's fairly intuitive.
recovery.fstab
recovery.fstab defines the file system mount point , file system type , and block device for each of the partitions in your device. It works almost exactly like /etc/fstab in a standard Linux operating system.
Example:
/system ext4 /dev/block/mmcblk0p32
This sets the block device at mmcblk0p32 to be mounted on /system as filesystem type ext4
All mountpoints should exist in this file and it is crucial this information be correct or else very bad things can happen, such as a recovery flash writing to the wrong location.
Note:
The filesystem type datamedia can be used for internal sdcards as well as setting the block device to /dev/null.
vendorsetup.sh
vendorsetup.sh is called when setupenv.sh is run. It is used to add non-standard lunch combos to the lunch menu.
To add your device to the lunch menu:
add_lunch_combo cm_<codename>-userdebug
Then build a test recovery image
wiki.cyanogenmod.org/w/Doc:_porting_intro
Vendor tree.
.Contains proprietary files/libraries
Examples: Vendor RIL, camera libraries
Once you have all this set up, you need to
Bash:
cd pathToSource
. build/envsetup.sh
lunch device_lunch_name
make recoveryimage/bacon/bootimage/Package/framework/library...
# Output generated in the out/target/product/devicename/
Download executable here : https://github.com/MasterAwesome/environment_setup/blob/master/Release/setupEnv?raw=true
I have added only Cyanogenmod and AOSP to my executable for creating a repository, for others someone fork my repo and create a pull request, if its suitable i'll merge and upload a newer version.
AOSP Guide : https://source.android.com/source/building.html
Cyanogenmod Docs : http://wiki.cyanogenmod.org/w/Development

Debugging
Debugging
This can be done using an IDE or by logcats.
Option 1(logcats) :
These provide logs which are created by android.util.log which is used in the Java Classes. They are used to log information as well as errors at runtime. Logcats and dmesg help debug most of the issues.
Option 2(IDE):
Setup a particular IDE(Eclipse or IntelliJ Idea)
Intellij: http://wiki.cyanogenmod.org/w/Doc:_import_to_intellij, https://shuhaowu.com/blog/setting_up_intellij_with_aosp_development.html
Eclipse: http://wiki.cyanogenmod.org/w/Doc:_eclipse
Once you've done that
1)https://software.intel.com/en-us/articles/android-system-level-javac-code-debugging
OR
Once you've imported your source code, you can add breakpoints to your modifications(if any) and then Remote debug it
Code:
Right-click "Remote Java Application", select "New".
Pick a name, i.e. "android-debug" or anything you like.
Set the "Project" to your android project name.
Keep the Host set to "localhost", but change Port to 8700.
Click the "Debug" button and you should be all set.
Then go to DDMS perspective and select a process you want to debug (select the process in the list of processes and then click on green bug icon).
Now you can switch to debug perspective.
.
I personally prefer eclipse for debugging maybe because I'm used to it, you should go with which ever is easier for you.

FAQ
FAQ
Will this tool work with all Linux distros?
No. It'll work with everything which uses apt-get(Debian based Distros){Ubuntu,Linux Mint,Elementary OS are some}
Once the tool completes installing and setting up what do I need to do?
Assuming you also initialised the repo using the tool, you could go to the folder and repo sync to start downloading the source code. Follow the build instructions after downloading(In post #1)
Why does this executable required elevated permissions
apt-get install can only install if elevated permissions are given, also, changing sysctl(/proc) also require `sudo` permissions.
How do I trust the tool with sudo permissions, can't that ruin my OS?
Since the executable uses system() calls, I've uploaded the source at GitHub and you can build it yourself. Instructions for building : README.md
Any other questions? post a reply and please dont quote the entire post.
Have a great day

Mac support is on the way...
Sent from my Moto G using XDA Free mobile app

.Mac support added.
.makefile added to provide a simpler build process
Using for Mac
.Download the source code.
.You need to install Xcode from App Store.
.type make make mac
./setupEnvMac to execute it.