Firmware Development

1. click on the following link to connect to irc.freenode.net. Use a unique nick while joining. Freenode Web Chat: http://webchat.freenode.net/
2. Enter the following command in the message bar: /msg NickServ register <password> <email-address>
3. You should now recieve an e-mail from NickServ at the email address you provided. Follow the instructions in that email.
4. For future logins you can enter the following command to authenticate your registered nick /msg NickServ identify <password>
5. To join a new channel /join #<channel name> eg to join #cyanogenmod use: /join #cyanogenmod

• #cyanogenmod
• #cyanogenmod-dev
• #cm-wiki

• #teamhacksung-support
• #cyanogenmod-touchpad
• #nookcolor
• #nook-tablet
• #koush
• #teamwin
• #android-root

edify is a simple scripting language that is used to install CyanogenMod (and other software) from a .zip file. The edify script does not necessarily need to be used to flash a firmware however.

Typically, the edify script is run in recovery mode when the user chooses to "flash a zip".

There are typically two parts to an edify script. These two files are usually found within the .zip file in the /META-INF/com/google/android directory.

• update-binary – the binary interpreter that is executed when the user selects the .zip to be flashed, typically from recovery mode. This binary loads the updater-script into memory and follows the instructions contained within.
• updater-script – the script itself, which is a text file.

One way to learn about edify is by examining and modifying existing edify scripts. By looking at the scripts themselves, you may be able to figure out how they work. Then, by modifying the code right on the .zip and flashing it to your device, you can test your custom scripts.

• The main tool used to generate the edify scripts is https://github.com/CyanogenMod/android_build/blob/cm-10.1/tools/releasetools/edify_generator.py
• the source for the language interpreter is https://github.com/CyanogenMod/android_bootable_recovery/tree/jellybean/edify
• README https://github.com/CyanogenMod/android_bootable_recovery/blob/cm-10.1/edify/README

• Intro to edify - Free Your Android's introduction to the edify scripting language http://www.freeyourandroid.com/guide/introdution_to_edify
• XDA's wiki page http://forum.xda-developers.com/wiki/Edify_script_language
• edify scripts in CWM recovery - an XDA thread discussing edify syntax http://forum.xda-developers.com/showthread.php?t=1187313
• Intro to edify-updater - another XDA thread about edify http://forum.xda-developers.com/showthread.php?t=1669489
• edify scripting creation - an XDA tutorial with syntax notes. Be sure to read about how to sign .zips, if you're not familiar with it already (and if it's necessary) http://forum.xda-developers.com/showpost.php?p=25136429&postcount=2

• Android Build System http://www.kandroid.org/online-pdk/guide/build_system.html
• GNU Make manual http://www.gnu.org/software/make/manual/make.html
• The Android-Building Group https://groups.google.com/forum/?fromgroups#!forum/android-building

• How To Build A Kernel http://source.android.com/source/building-kernels.html

• The official Android Developer Site http://developer.android.com/index.html
• Android classes http://developer.android.com/reference/classes.html

ADB ("adb"), or the Android Debug Bridge, is a development tool included with the Android SDK (Software Developer Kit), which allows for communication from an Android device (such as a phone or tablet) to a personal computer, and vice-versa.

Sometimes adb can't find your device. One solution is to run adb kill-server and then adb start-server as root or Administrator to restart the adb daemon with elevated privileges.

Android Debug Bridge version 1.0.31

-d                            - directs command to the only connected USB device
                                returns an error if more than one USB device is present.
-e                            - directs command to the only running emulator.
                                returns an error if more than one emulator is running.
-s <specific device>          - directs command to the device or emulator with the given
                                serial number or qualifier. Overrides ANDROID_SERIAL
                                environment variable.
-p <product name or path>     - simple product name like 'sooner', or
                                a relative/absolute path to a product
                                out directory like 'out/target/product/sooner'.
                                If -p is not specified, the ANDROID_PRODUCT_OUT
                                environment variable is used, which must
                                be an absolute path.
devices [-l]                  - list all connected devices
                                ('-l' will also list device qualifiers)
connect <host>[:<port>]       - connect to a device via TCP/IP
                                Port 5555 is used by default if no port number is specified.
disconnect [<host>[:<port>]]  - disconnect from a TCP/IP device.
                                Port 5555 is used by default if no port number is specified.
                                Using this command with no additional arguments
                                will disconnect from all connected TCP/IP devices.

device commands:
 adb push <local> <remote>    - copy file/dir to device
 adb pull <remote> [<local>]  - copy file/dir from device
 adb sync [ <directory> ]     - copy host->device only if changed
                                (-l means list but don't copy)
                                (see 'adb help all')
 adb shell                    - run remote shell interactively
 adb shell <command>          - run remote shell command
 adb emu <command>            - run emulator console command
 adb logcat [ <filter-spec> ] - View device log
 adb forward <local> <remote> - forward socket connections
                                forward specs are one of: 
                                  tcp:<port>
                                  localabstract:<unix domain socket name>
                                  localreserved:<unix domain socket name>
                                  localfilesystem:<unix domain socket name>
                                  dev:<character device name>
                                  jdwp:<process pid> (remote only)
 adb jdwp                     - list PIDs of processes hosting a JDWP transport
 adb install [-l] [-r] [-s] [--algo <algorithm name> --key <hex-encoded key> --iv <hex-encoded iv>] <file>
                              - push this package file to the device and install it
                                ('-l' means forward-lock the app)
                                ('-r' means reinstall the app, keeping its data)
                                ('-s' means install on SD card instead of internal storage)
                                ('--algo', '--key', and '--iv' mean the file is encrypted already)
 adb uninstall [-k] <package> - remove this app package from the device
                                ('-k' means keep the data and cache directories)
 adb bugreport                - return all information from the device
                                that should be included in a bug report.

 adb backup [-f <file>] [-apk|-noapk] [-shared|-noshared] [-all] [-system|-nosystem] [<packages...>]
                              - write an archive of the device's data to <file>.
                                If no -f option is supplied then the data is written
                                to "backup.ab" in the current directory.
                                (-apk|-noapk enable/disable backup of the .apks themselves
                                   in the archive; the default is noapk.)
                                (-shared|-noshared enable/disable backup of the device's
                                   shared storage / SD card contents; the default is noshared.)
                                (-all means to back up all installed applications)
                                (-system|-nosystem toggles whether -all automatically includes
                                   system applications; the default is to include system apps)
                                (<packages...> is the list of applications to be backed up.  If
                                   the -all or -shared flags are passed, then the package
                                   list is optional.  Applications explicitly given on the
                                   command line will be included even if -nosystem would
                                   ordinarily cause them to be omitted.)


 adb restore <file>           - restore device contents from the <file> backup archive

adb help                     - show this help message
 adb version                  - show version num

scripting:
 adb wait-for-device          - block until device is online
 adb start-server             - ensure that there is a server running
 adb kill-server              - kill the server if it is running
 adb get-state                - prints: offline | bootloader | device
 adb get-serialno             - prints: <serial-number>
 adb get-devpath              - prints: <device-path>
 adb status-window            - continuously print device status for a specified device
 adb remount                  - remounts the /system partition on the device read-write
 adb reboot [bootloader|recovery] - reboots the device, optionally into the bootloader or recovery program
 adb reboot-bootloader        - reboots the device into the bootloader
 adb root                     - restarts the adbd daemon with root permissions
 adb usb                      - restarts the adbd daemon listening on USB
 adb tcpip <port>             - restarts the adbd daemon listening on TCP on the specified port

networking:
 adb ppp <tty> [parameters]   - Run PPP over USB.
Note: you should not automatically start a PPP connection.
<tty> refers to the tty for PPP stream. Eg. dev:/dev/omap_csmi_tty1
[parameters] - Eg. defaultroute debug dump local notty usepeerdns

adb sync notes: adb sync [ <directory> ]
 <localdir> can be interpreted in several ways:
 - If <directory> is not specified, both /system and /data partitions will be updated.
 - If it is "system" or "data", only the corresponding partition
   is updated.

environmental variables:
 ADB_TRACE                    - Print debug information. A comma separated list of the following values
                                1 or all, adb, sockets, packets, rwx, usb, sync, sysdeps, transport, jdwp
 ANDROID_SERIAL               - The serial number to connect to. -s takes priority over this if given.
 ANDROID_LOG_TAGS             - When used with the logcat option, only these debug tags are printed.

fastboot is a small tool that comes with the Android SDK (software developer kit) that can be used to re-flash partitions on your device. It is an alternative to the recovery mode for doing installations and updates.

Please note that fastboot commands will ONLY work while the device is in fastboot mode.

Installing ClockworkMod Recovery on the device

1. Connect the device to the computer via USB.
2. Make sure the fastboot binary is in your PATH or that you place the downloaded image in the same directory as fastboot.
3. Open a terminal on your PC and reboot the device into fastboot mode by typing adb reboot bootloader or by using the hardware key combination.
4. Once the device is in fastboot mode, verify your PC sees the device by typing fastboot devices If you don't see your device serial number, and instead see "<waiting for device>", fastboot is not configured properly on your machine. See fastboot documentation for more info.
5. Flash ClockworkMod Recovery onto your device by entering the following command: fastboot flash recovery your_{recoveryimage}.img where the latter part is the name of the file you downloaded.
6. Once the flash completes successfully, reboot the device into recovery to verify the installation. Note: Some ROMs overwrite recovery at boot time so if you do not plan to immediately boot into recovery to install CyanogenMod, please be aware that this may overwrite your custom recovery with the stock one.

When Android is running, it's generating all kinds of system messages. You see, programmers/developers can optionally output status information (or errors or debugging notes) in real-time to a system log, and Android itself sends all kinds of useful information out that way.

db logcat offers extra functionality to filter logs based on priority. The usage is adb logcat *:# where # is one of the following.

V    Verbose (show all possibly useless logs, default level)
D    Debug (show all reasonable debug logs)
I    Info (show expected logs for regular usage)
W    Warn (show possible issues that are not yet errors)
E    Error (show issues that have caused errors)
F    Fatal (show issues that are fatal to runtime and will often result in rebooting)

• Colored logcat by Jeff Sharkey https://code.google.com/p/colored-logcat/ http://jsharkey.org/blog/2009/04/22/modifying-the-android-logcat-stream-for-full-color-debugging/
• logcat-color by Marshall Culpepper https://github.com/marshall/logcat-color

On device

This will generate a logcat on your sdcard which you can then attatch to a bug you want to report.

• Open Console Application of your choice (CM comes with 'Terminal Emulator' preinstalled)
• type logcat -d -f /sdcard/logcat.log *:V
• alternatively the radio buffer can be viewed with logcat -b radio

-d    makes it dump the logcat
-f    tell it where to save the log to
*:V   gets all Logs in Verbose mode

Software or 'apps' that you don't need, but come preinstalled to a device's /system partition, meaning that you cannot remove them unless the device has been rooted. Usually, these are apps are sponsored by a company and included by a carrier for profit.

Brain Fuck Scheduler for Linux was created by veteran kernel programmer Con Kolivas and has been reported to improve responsiveness on light-NUMA (non-uniform memory access) Linux mobile devices and desktop computers with fewer than 16 cores.

SuperCID is a special code, 11111111, which means that software from any region can be installed. See superCID: http://wiki.cyanogenmod.org/w/Basic_concepts#superCID

A clean, unmodified version of something. In the context of Android ROMs, vanilla refers to the stock ROM that came pre-installed on the device.

• 32A PVT32A handsets have 288MB total RAM (192MB usable by OS - same as Hero handsets) and use the Qualcomm MSM7200A CPU.
• 32B PVT32B handsets have 192MB total RAM (96MB usable by OS) and use the Qualcomm MSM7201A CPU.
• ADP Android Developer Phone. The first ADP was a "development" version of the HTC Dream. The current ADP is the Samsung Nexus S.
• CWM Short for ClockworkMod Recovery. Not to be confused with CM (Cyanogenmod).
• Dalvik-Cache The dalvik-cache directory holds all of the pre-compiled .dex files created from installed apps. These files are static and do not change unless the app is updated.
• flash_image A small utility to be used on the device that allows you to re-write system partitions with image files. If you don't have it, it can be found here.
• NANDroid A set of tools that will enable anyone who has root on their Android device to make FULL system backups, in case something goes wrong or you want to try out that new experimental ROM/theme. NANDroid will backup (and restore) /system, /data, /cache, and /boot partitions.
• NVFlash is a low-level flash utility for nVidia based devices which gives you low level access to the system to flash, format, recover, repartition and do many more functions. It is a very powerful tool and should be used with caution. Read and follow all instruction carefully when using nvflash. See http://rootzwiki.com/topic/35086-guide-nvflash-general-users-guide-unbrickrecoverdowngradeupgrade-tf201/#entry982736
• Recovery Mode A special environment that you can boot into for troubleshooting and upgrading purposes.
• SPL Second Program Loader, in conjunction with the IPL comprise a device's bootloader. Aside from bootstrapping Android, the bootloader also fulfills various diagnostic functions. One of these functions is the manipulation of data in the device's internal flash ram. Depending on the SPL installed, the user might be able to flash signed NBH files, flash nand images, and more. Note that the SPL is installed and operates independently of the Android build that runs atop it. Generally speaking, there are two variants of the SPL: Stock, which is 'locked' and is installed on most devices from the factory, and Engineering, which is 'unlocked' and has to be manually flashed - usually after 'rooting'.
• S-OFF Usually a property of HTC devices. S-OFF allows the user to modify any partition on the device. Signature checking is disabled for zips, allowing the user to flash otapackages and custom kernels from recovery. S-ON prevents the user to allow these actions. See http://forum.xda-developers.com/showthread.php?p=26732440
• Zipalign Reduces the amount of RAM consumed when running the application by allowing data to be mmap'd in; which causes all uncompressed data within the .apk, such as images or raw files, to be aligned on 4-byte boundaries.

Aftermarket generally refers to any product or service applied or requisitioned by end-users to add usability or functionality to the original product. Many aftermarket modifications can void the manufacturer's warranty. From a manufacturer's perspective, the after-market is any goods or services offered by the manufacturer directly to end-users of a given product or service. After-market services include support for warranties, contracts, and parts and accessories sales.

A proof of concept local root exploit utilizing hotplug. Allows installation of a "rootshell" program on many Android 1.x and 2.x devices.

The process of applying a firmware image (or ROM) to a device. It generally entails a very specific order of steps. Failing to complete any one of these steps properly may result in bricking the device.

The process of creating a code based off someone else's code or reapplying code that someone else created into your own code (e.g. git cherry-pick). The term "kang" or "kanging" can have a pejorative connotation, especially if one adopts code from someone else without giving due credit. However the term can also be used with a certain sense of irony; sometimes one will claim to have "kanged" with some tongue-in-cheek.

Unlike breakfast, lunch makes no assumptions with regard to device configuration locations and formats, so it will scan the entire tree for matching options (depending on the number of locally available devices, this may take a significant amount of time). To build after running lunch, simply issue the command mka. No bacon here

Defined simply, brunch is equivalent to

$ 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

Some bootloaders include a "Security ON" (AKA "S-ON") mode, whereby certain operational restrictions are imposed on the boot. On some devices (such as the T-Mobile G2), the S-ON bootloader may put the operating system partition in a "read-only" mode. For others, S-ON may cause the device to adopt behavior similar to a fully-locked bootloader.

Switching the bootloader to S-OFF mode is therefore a prerequisite on some devices to allow the operating system to be modified or replaced.

recovery mode is, is a special "second boot" mode, independent of the normal boot, that you can start into that allows you to troubleshoot or update your device. Recovery mode lets you re-flash an entirely new operating system, clear out problematic cache partitions, and can "factory reset" your device, clearing out non-system data. The recovery can also let you back up and restore your Android installation. As if that wasn't enough, the recovery mode often will allow you to access your device from your computer via adb.

• ClockworkMod Recovery: https://github.com/koush
• TWRP: http://teamw.in/project/twrp2 https://github.com/Dees-Troy

• /boot This partition stores the kernel and ramdisk. The kernel can be thought of as the "core" of the device's software. It is what allows the hardware to "talk" to the software, and vice versa. It also controls other aspects of the operating system on the device, such as what file formats the device is able to support. The ramdisk contains the very first bits of Android that are loaded. It's the software that loads everything else.
• /recovery This partition holds the device's recovery software, which gives the user access to special functions, such as upgrading the operating system or making a backup of the device's software.
• /system This is the main directory where the device's essential software, the operating system itself, is stored. When CyanogenMod is installed, this is where it goes. Generally speaking, this partition is loaded into "read only" mode so that you don't accidentally overwrite portions of Android, and it's only able to be modified under special circumstances.
• /cache This directory stores temporary files used by Android. Generally, files on this partition are not usually critical to the operation of the device, and can be "cleared out" by wiping its contents, especially during every major upgrade.
• /data This directory is where much of your personal data is stored. So if you download an app from the Android Market, it goes here. If you change a setting, that change is also stored here. If you receive a SMS, it too is stored here.

• /system – this contains all the stuff that will become the /system folder on Android.
• /root – these files contain the files that are turned into the ram disk loaded and run by the kernel. The first program to be run by the kernel is called init, and it uses the init.rc and init.CODENAME.rc files to determine what happens next. See an discussion of that here.
• /recovery/root The ramdisk that contains the recovery mode is here.

Make

• make modules – this command will show all available targets. You can build a single one by make my_target.
• make showcommands – this command will enable the verbose build mode.

ADB

• adb remount – If you've gotten errors trying to push files to /system due to it being in read-only mode, adb remount will remount /system into read-write mode— provided that the shell has the correct root permissions to do so. This replaces having to type a longer command by hand such as mount -o rw,remount /system (as root) or something.
• adb sync system – assuming you have adb installed, this little-known, but powerful command will sync the contents of $OUT/system with the /system directory on your device. It does require that you have write access to /system. This command is very useful for making and testing quick changes to your device. Note though that adb sync system sometimes has problems with permissions and symlinks.

1. Setup an account on Gerrit, you can register at review.cyanogenmod.com
2. If you already have SSH keys set up (e.g. for Github), skip the following steps

1. First, you need to start a topic branch. repo start <branch name> <project path>
2. After you make your changes, you can commit them just as you would normally:

git add <file you edited>
git commit
ctop (Same as moving to top/root of tree using cd)

1. upload your changes to the CyanogenMod server: repo upload <project path>

create a folder called local_manifests and put that inside the .repo directory, then put your XML inside that directory. You can place as many override files in .repo/local_manifests as you like and repo will pick them up during the next sync. You can call the files anything you like as long as they end in .xml.

<?xml version="1.0" encoding="UTF-8"?>
   <manifest>
     <remote name="omap" fetch="git://git.omapzoom.org/" />
     <remove-project name="CyanogenMod/android_hardware_ti_omap3" />
     <project path="hardware/ti/omap3" name="repo/android/hardware/ti/omap3" remote="omap" revision="jellybean"/>
   </manifest>

Note that when adding new projects, there are at least three parts defined:

• remote – the name of the remote. this can be one that was defined in either the regular manifest or local_manifest.xml.
• name – the name of the git project– for github it has the format account_name/project_name
• path – where the git repository should go in your local copy of the source code.
• revision – (OPTIONAL) which branch or tag to use in the repository.

make clean deletes all of the output and intermediate files for this configuration. This is the same as:

rm -rf $OUT (where $OUT is set to the build directory of your device in out/target/product/[CODENAME])

make clobber deletes all of the output and intermediate files for all configurations. This is the same as: rm -rf out/

(So this removes not only out/target/product/CODENAME but the entire /out directory.)

You might want to do make clobber when you want to be absolutely, positively sure you are starting a fresh build from scratch. One time you almost certainly want to do this is if changes are made to the BoardConfig.mk file in device/asus/grouper.

Some Makefiles such as BoardConfig.mk may contain flags in it that actually affect the build system-wide, and the Makefile system doesn't really check the actual source code to see if a variable change in one place may affect the build in the code somewhere else.

bionic/ is the Android mobile-friendly version of libc

The scripts and various files that are used for the actual build process. Take a look in here if you're curious what steps are taken to make all the parts of Android compile, as well as various "make" commands

Among other things, the source for ClockworkMod recovery is in here.

This is the virtual machine that runs the java apps. It's how you can write an app and it'll run on any android machine, regardless of the underlying architecture.

device/ contains part (if not all) of the board support package for a device, and is organized as device/<vendor>/<codename>. So the files for Nexus 7 are under device/asus/grouper/, the files for Nexus 4 are under device/lge/mako/.

Contains the source code for the Android Open Source website.

This is where non-android specific utilities go. Lots of the stuff in here are just regular open source projects that are used by Android (or CyanogenMod) and just have the Android.mk make files to work with the Android build system.

This refers to the core Android frameworks. It's the stuff that makes Android, Android. The frameworks contain the Android user experience and the abstracted "hooks" that programmers use to build Android apps. So, for example, this folder contains the Java windows-manipulation and activity stuff and java sound support and Android graphics layers and Android media stuff and UI as well as services and basically the Android API in general. There are also some platform-specific optimization here as well that CyanogenMod adds for Qualcomm, OMAP, and other manufacturers to get the best performance out of specific architectures.

Platform/hardware-specific libraries and such go in this folder.

Like device/ ,kernel/ is organized like kernel/<vendor>/>codename> and inside there you'll find the source for the kernel. This source may be downloaded "on the fly" by the CyanogenMod build system.

See here. Tools for allowing cross-platform C code to be included in Android apps (as JNI shared libraries, apparently). Used if you're writing C-based apps, but I've never used any of this or even poked my nose in there. See /ndk/docs/OVERVIEW.html for more.

The output of your build will go in here by default. When you type cd $OUT after building, you're actually getting a shortcut to out/target/product/<devicename>. This is the only folder that should have stuff added to it (or changed) when you're doing a build.

packages/apps/ is where Android standalone apps, such as the Settings app, the Browser, the Launcher (in CM10's case it's called Trebuchet),

These folders contain prebuilt toolchains for cross-compiling on linux and darwin (MacOS X) and a few tools for Windows. Cross-compiling allows you to build Android for an architecture (such as ARM-based CPU) from another architecture (such as x86₆₄).

Lower-level linuxy system stuff such as netd, fastboot support, the shell (which you can use to type commands into your device), etc. are here.

The /vendor folder contains stuff particular to a vendor build such as CyanogenMod. It's also the place where proprietary blobs are extracted from the device, again using the same vendor/device codename convention as under device/.

One way to do this is to simply add the .apk into the .zip and then edit the recovery installation script (written in a simple scripting language called "edify") to copy the file from the .zip to the device.

nearly everything you need to do will be in the /device/[vendor]/[codename], /vendor/[vendor]/[codename], and /kernel/[vendor]/[codename] directories.

Go to wikipedia and identify the product name, code name, architecture, memory size, internal storage size, and platform architecture. Put this information in a file for easy retrieval.

there should be a file, /system/build.prop, This file contains definitions for various parameters and settings used by Android.

• Write down the value of the ro.product.manufacturer parameter. This will be your vendor name.
• Write down the value of the ro.product.device parameter. This will be your device codename.
• Note: Sometimes a device is identified in other parameters such as ro.product.board

Keep the build.prop file handy, as you may refer to it later.

Note:

The ramdisk is a tiny group of files and directories that are loaded into memory along with the kernel. The kernel then runs one of the files in the ramdisk called init, which then runs a script (init.rc, init.[codename].rc, etc.) that in turns loads the rest of Android. The ramdisk and kernel can be packaged together in a number of different ways using tools with names like mkbootimg, mkimage, and other methods.

It is important to ascertain the partition scheme of the device. know which partitions are assigned to /system, /data, /cache, and /sdcard.

You want to know which partitions exist, on what device, how they are mounted, as well as the size of the partitions. This information may be transferred later to the BoardConfig.mk file in your /vendor directory.

If you're lucky, a recovery.fstab file can be located in a recovery.img file, speeding up the process of figuring out what goes where. Also, the init.[codename].rc file in the ramdisk may have the information. Look for the lines near the top where the partitions are mounted.

Also, the command: $ cat /proc/partitions

from a running device can also help you identify the partitions. Also see /proc/emmc, /proc/mounts or /proc/mtd. You may also get some information from the command mount (run as root).

Also check /cache/recovery.log or /tmp/recovery.log.

Finally, if you have source code to the bootloader, , you will likely find the information there as well.

1. device/[vendor]/[codename]/ – this is where the installation files specific to your device will go. The device/ directory contain 99-100% of the configuration settings and other code for particular devices. You'll get to know this directory pretty well.
2. vendor/[vendor]/[codename]/ – The vendor/ directory contains proprietary, binary "blobs" that are backed up from the original device
3. kernel/[vendor]/[codename]/ – the kernel source goes here. When you first start your porting effort, you may wish to simplify things by using a pre-built kernel (such as the one that came with the stock installation) rather than building the kernel from scratch. The trick to that will be extracting the kernel out of the stock system from whatever format it may be in, and then re-packaging it, along with a new ramdisk, into a form that your device can use.

There are many files in the device/ folders. We will start by focusing on four files BoardConfig.mk, device_[codename].mk, cm.mk, recovery.fstab, and kernel to get recovery working for your device.

To build only the recovery, set up lunch as with a regular build, and say make recoveryimage

You may discover that although the recovery image runs, some of the hardware buttons, such as the volume buttons or power buttons, which would normally be used to scroll through the options, don't work.

You may need to adjust the GPIO values to get the buttons to be recognized. Similarly, you may wish to include/exclude options or modify other UI elements.

To do this, you may wish to create and edit the /device/[vendor]/[codename]/recovery/recovery_ui.cpp. You can find ample examples of this file, the associated recovery/Android.mk file that builds it, and how it is used.

Helpful Tip: The GPIO values for your device may be found in the kernel source.

When naming your repository, use the format android_device_VENDOR_CODENAME, where VENDOR and CODENAME use the new device's values. So, let's say your GitHub account name is "fat-tire" and your device codename is "encore", manufactured by Barnes and Noble. You should call your repository android_{devicebnencore}. It would be accessible at https://github.com/fat-tire/android_device_bn_encore. Similarly, the kernel repository would be called android_{kernelbnencore}. It would be accessible at https://github.com/fat-tire/android_kernel_bn_encore.

The last thing to do is create a local manifest for other people to use to automatically download and their keep up-to-date with your changes. Here's an example, using the above scenario:

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <project name="fat-tire/android_device_bn_encore" path="device/bn/encore" remote="github" revision="cm-10.1" />
  <project name="fat-tire/android_kernel_bn_encore" path="kernel/bn/encore" remote="github" revision="cm-10.1" />
</manifest>

This requires three steps:

1. Create extract-files.sh and setup-makefiles.sh scripts to pull those blob files from the device using adb and put them in the right vendor directory. There are plenty of examples available for other devices.
2. Create an .mk Makefile to copy those files to the $OUT folder during the build process and put them in the right place. Again, use other devices as a guide for what this Makefile should look like. An example filename might be BoardConfigVendor.mk
3. Make sure that the Makefile you just created is included from your main BoardConfig.mk via a command such as -include vendor/[vendor]/[codename]/BoardConfigVendor.mk. Again, existing devices can illustrate how this is done.

Since you have a working recovery, go back and start modifying the files in the device/ folder. As always, use other similar devices as a reference.

• Google Google's Git Repository https://android.googlesource.com/ , Nexus binary blobs https://developers.google.com/android/nexus/drivers
• HTC Dev Center http://www.htcdev.com/devcenter/
• Nvidia Tegra Tegra's GitWeb http://nv-tegra.nvidia.com/gitweb/
• Qualcomm MSM/QSD www.codeaurora.org
• Texas Instruments OMAP www.omapzoom.com , Omappedia: http://www.omappedia.org/wiki/Main_Page

It's very likely in your device_[codename].mk file, there's a line that looks like this:

DEVICE_PACKAGE_OVERLAYS := \
    device/[vendor]/[codename]/overlay

What this does is set the overlay/ folder to allow you to override any XML file used by Android frameworks or apps, just for this device. To do so, create a directory structure which mirrors the path leading to an XML file, starting from the root of your source. Then replace the file you want to overlay.

Example: Let's say you want to override some standard Android settings. Look at the file in frameworks/base/core/res/res/values/config.xml. Then copy it to device/[vendor]/[codename]/overlay/frameworks/base/core/res/res/values/config.xml. Now YOUR version will be used instead of the other one. You only need to include the settings you wish to override– not all of them, so you can pare down the file to those few that change from the default.

You can overlay any XML file, affecting layouts, settings, preferences, translations, and more.

The minimal requirement is that the kernel's source tree for that device be present at kernel/vendor-name/device-name.

Just add the TARGET_KERNELCONFIG variable to your BoardConfig.mk file, pointing to the configuration file name for your device (as present in arch/arm/configs). For example:

TARGET_KERNEL_CONFIG := cyanogenmod_mydevice_defconfig

Any modules built will be deployed at /system/lib/modules/ in the final image

If your device requires uImage, also ensure the following is present in your 'BoardConfig.mk'

BOARD_USES_UBOOT := true

To build these modules, the TARGET_KERNEL_MODULES variable can be used, pointing to a make target that will build and install such modules. Definition of such a target is the device author's responsibility, the only restriction is that it is a normal makefile recipe. To include, for example, the TI WLAN modules, this can be used:

TIWLAN_MODULES:
       make -C hardware/ti/wlan/wl1283/platforms/os/linux/ KERNEL_DIR=$(KERNEL_OUT) ARCH="arm" CROSS_COMPILE="arm-eabi-" TNETW=1273 RANDOM_MAC=n REPORT_LOG=n
       mv hardware/ti/wlan/wl1283/platforms/os/linux/tiwlan_drv.ko $(KERNEL_MODULES_OUT)
       make -C hardware/ti/wlan/wl1283_softAP/platforms/os/linux/ KERNEL_DIR=$(KERNEL_OUT) ARCH="arm" CROSS_COMPILE="arm-eabi-" TNETW=1273 REPORT_LOG=n
       mv hardware/ti/wlan/wl1283_softAP/platforms/os/linux/tiap_drv.ko $(KERNEL_MODULES_OUT)

TARGET_KERNEL_MODULES := TIWLAN_MODULES

you can just paste your current standalone build commands into a make recipe, replacing the kernel source path with the $(KERNEL_OUT) variable.

If for some reason the kernel source can't be present, you can still fall back to prebuilt binaries, by defining the TARGET_PREBUILT_KERNEL variable, like this:

TARGET_PREBUILT_KERNEL := device/<vendor>/<device>/kernel

The following is the p920's configuration, which attempts to build the kernel, uses external modules, and has a prebuilt fallback:

# Try to build the kernel
TARGET_KERNEL_CONFIG := cyanogenmod_cosmo_defconfig
# Keep this as a fallback
TARGET_PREBUILT_KERNEL := device/lge/p920/kernel

KERNEL_EXTERNAL_MODULES:
        make -C hardware/ti/wlan/wl1283/platforms/os/linux/ KERNEL_DIR=$(KERNEL_OUT) ARCH="arm" CROSS_COMPILE="arm-eabi-" TNETW=1273 RANDOM_MAC=n REPORT_LOG=n
        mv hardware/ti/wlan/wl1283/platforms/os/linux/tiwlan_drv.ko $(KERNEL_MODULES_OUT)
        make -C hardware/ti/wlan/wl1283_softAP/platforms/os/linux/ KERNEL_DIR=$(KERNEL_OUT) ARCH="arm" CROSS_COMPILE="arm-eabi-" TNETW=1273 REPORT_LOG=n
        mv hardware/ti/wlan/wl1283_softAP/platforms/os/linux/tiap_drv.ko $(KERNEL_MODULES_OUT)

TARGET_KERNEL_MODULES := KERNEL_EXTERNAL_MODULES

• Full hardware support – Everything– every peripheral, every wireless feature– that is supported by stock must be supported by CyanogenMod.
• Passed the CTS – The Android Compatibility Test Suite(http://source.android.com/compatibility/cts-intro.html) will ensure that your port is functional. If it doesn't pass, get back to work until it does.
• Stability – Nothing should crash. Ever. CyanogenMod has a reputation for stability and your port must be rock-solid. This means no "sleep of deaths" either.
• No overclock by default – While overclocking options in the Performance menu is well and good, leave the default speeds at stock.
• Do not over-volt either – Do not go outside of the spec for power consumption. If you want to provide sysfs methods for upping the voltage, that's up to you. But it must not be a default setting.
• You have designated at least one device maintainer and at least one person to be responsible for the device's wiki information. The former will evaluate submissions to the device's repositories. The latter will ensure that the information/documentation about the device on the wiki is always up-to-date and correct. These people must be identified when applying for official recognition.

Send an email to devrel@cyanogenmod.org

• This email must contain links to your github repositories for your device
• This email must contain gtalk and email addresses for contacting you
• If a team worked on your device, all team members must be listed in the email

http://matt.ucc.asn.au/dropbear/dropbear.html Dropbear is a relatively small SSH server and client.

In linux:

ssh-keygen -t rsa The output should look something like this:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in <Filename>.
Your public key has been saved in <Filename>.
adb push <Filename> /sdcard/authorized_keys

In Windows: If using puttygen, paste the string from the puttygen window (looks like "ssh-rsa AAAAB3...hclQ==rsa-key-20100227") in authorized_keys.

On the computer, open terminal and run the following commands:

adb shell
mkdir /data/dropbear
chmod 755 /data/dropbear
mkdir /data/dropbear/.ssh
chmod 700 /data/dropbear/.ssh
mv /sdcard/authorized_keys /data/dropbear/.ssh/
chown root: /data/dropbear/.ssh/authorized_keys
chmod 600 /data/dropbear/.ssh/authorized_keys
dropbearkey -t rsa -f /data/dropbear/dropbear_rsa_host_key
dropbearkey -t dss -f /data/dropbear/dropbear_dss_host_key

The end result should look something like this:

# ls -la /data/dropbear
drwxr-xr-x    1 root     root          2048 Sep  5 14:55 .
drwxrwx--x    1 system   system        2048 Sep  5 14:08 ..
drwx------    1 root     root          2048 Sep  5 14:51 .ssh
-rw-------    1 root     root           458 Sep  5 14:09 dropbear_dss_host_key
-rw-------    1 root     root           427 Sep  5 14:09 dropbear_rsa_host_key
# ls -la /data/dropbear/.ssh
drwx------    1 root     root          2048 Sep  5 14:51 .
drwxr-xr-x    1 root     root          2048 Sep  5 14:55 ..
-rw-------    1 root     root           406 Sep  5 14:01
authorized_keys

Creating directories and generating rsa/dsa keys is required even if you plan to use password login.

ifconfig eth0 ifconfig rmnet0

If that doesn't work run cat /proc/net/dev to see the possible interfaces and use ifconfig with the appropriate interface.

Use either adb shell or terminal emulator to do the following.

dropbear -s -v -F

(You can use the -Y option to specify a master password for login into any account, if not using key based authentication)

The output should look something like this:

...
TRACE (3220): listening on ':22'
TRACE (3220): enter dropbear_listen
TRACE (3220): dropbear_listen: all interfaces
TRACE (3220): bind(22) failed
TRACE (3220): leave dropbear_listen: success, 1 socks bound
[3220] Sep 05 15:16:43 Not backgrounding

Now, on the computer, we will try to login to the Android device. Replace the path to your SSH private key and IP address as appropriate. On the computer's terminal, do the following.

ssh -i ./The previously selected name for this key -l root 192.168.1.64 The output should look something like this:

Enter passphrase for key '/home/user/<Filename>':
TRACE (3229): entering fake-getpwnam
TRACE (3229): leaving fake-getpwnam
TRACE (3229): enter sign_key_free
TRACE (3229): enter dsa_key_free
TRACE (3229): leave dsa_key_free
TRACE (3229): enter rsa_key_free
TRACE (3229): leave rsa_key_free
TRACE (3229): leave sign_key_free

If it didn't run ssh with the -v option to get verbose debugging output to try and see what went wrong.

If you get authentication errors, run this to show the device's public rsa key

dropbearkey -y -f /data/dropbear/dropbear_rsa_host_key

• the key is formatted like 'ssh-rsa Som3Rand0mStr1n6 root@localhost'
• copy and paste it to your PCs known_hosts file, ~/.ssh/known_hosts
• and try connecting from your PC again

Assuming everything worked, dropbear can be turned off by running:

killall dropbear

NOTE: For Windows (PuTTY with SSH keyfile) you need to configure putty as follows:

• Connection » Data » Auto-login Username = root
• Connection » SSH » Auth » Private key file = Previously selected key file

To run dropbear, from the Android device, run:

su
dropbear -s

Dropbear can be turned off by running:

killall dropbear

To modify the file in system/etc you need to remount the partition to read/write mode using

mount -o remount,rw /system

To run Dropbear on start up, edit the /etc/init.local.rc file (Your preferred editor can be used, as long as it doesn't introduce Windows/DOS line breaks), and add the following snippet to the end of the file

# start Dropbear (ssh server) service on boot
service sshd /system/xbin/dropbear -s
   user  root
   group root
   oneshot

The `oneshot` option instructs Android that the service should not be restarted if it is killed. For a full understanding of the Android Init system see here.

1. repo sync
2. branch the repository to anything.
3. In the new branch, add your commits (or merge from another branch, git pull from AOSP, or whatever gets your changes in)
4. Next, enter cmremote. This command will add the remote (use git remote -v to see it.)
5. To bypass gerrit, type git push cmremote HEAD:refs/heads/cm-10.1 (assuming cm-10.1 is the branch to which you are pushing.

1. Repeat steps 1-4 above.
2. Then, to mass-push TO Gerrit, use refs/for/branch instead of refs/heads/branch

1. Repeat steps 1-4 above.
2. Then, to create a new (remote) branch, type git push -u cmremote HEAD:refs/heads/new-branch-name

$ adb pull /system/app/ ~/Desktop/app/

• ADB

#/system apps
$ adb remount
$ adb shell rm -f /system/app/<apk name>.apk

#/data apps
$ adb uninstall <package name>

• Term (on device)

#/system apps
$ su
$ mount -o rw,remount /system
$ rm -f /system/app/<apk name>.apk

#/data apps
$ su
$ mount -o rw,remount /data
$ rm -f /data/app/<apk name>.apk
$ pm uninstall <package name>

Note:

ClockworkMod's backup/restore feature will generally only back up the /system, /data, /cache, /sd-ext, and /dalvik-cache areas. Other partitions such as emmc, /sdcard, and /media won't be backed up. In fact, the backed up system will typically be saved to the /sdcard partition in the clockworkmod/backup directory, which, depending on your device, may or may not be actually located on a physical removable SD card.