Please remember to add a category to the bottom of each page that you create.
See categories help for further details, but most will probably be [[Category:HTC ModelName]].

Samsung Galaxy S/SGH-T959V/Building From Source

From XDA-Developers
Jump to: navigation, search

Contents

The Easy Way

m4xm4n created a tool called Acidify which is designed to automate the process of setting up the android build environment and making it easy and quick to get straight into building CyanogenMod 7, CyanogenMod 9, or Android Open Kang Project (AOKP).

Getting Acidify

As per the official XDA thread, you may get it by fetching it from Github:

$ curl https://raw.github.com/teamacid/acidify/master/acidify > acidify

You may also clone the Github repository

$ git clone https://github.com/teamacid/acidify.git

Updating Acidify

acidify is still under active development. Keeping it up to date is not part of updating your sources. If you downloaded acidify directly, it can be updated using

$ acidify update

If you cloned the git repository, update using git. If you use $ acidify update then git will see the downloaded version as a local change.

Using Acidify to Setup the Build Environment

Simply run:

$ /path/where/you/put/acidify setup
This will fetch all the packages you need to build Android (Ubuntu only). It will also set somethings up for Acidify to function fully (like making it possible for you to use acidify anywhere by typing
acidify
(assuming you have ~/bin/ in your path).

Next, you can initialize the build environment for your desired build type in your current directory. <build type> can be either cm7, cm9, or aokp.

$ acidify init <build type>

This will fetch all required packages for building Android and will checkout the correct branch so that you'll be good to go when it's finished downloading GBs and GBs of source code.

Using Acidify to Build

Acidify makes it easy to build Android, as well. Simply run

$ acidify config

and the Android build system will be configured to compile for the Galaxy S 4G.

Then run

$ acidify build

to actually build a (hopefully) functional build of <build type>.

To clean your build environment:

$ acidify clean

To build a clean release build:

$ acidify release

Using Acidify to Keep Synced with Upstream

Simply run

$ acidify sync

It runs 'repo sync'.

Using Acidify to Deploy and Upload Builds

Acidify may also be used to send the latest build to a device or upload it to goo.im Be sure to set up adb correctly so that it is in your path. Also, be sure to change GOOUSER in the acidify script to your Goo.im developer username.

To send the latest build to your device to test:

$ acidify deploy

To upload the latest build to your goo.im space:

$ acidify upload

Using Acidify to Switch Between Build Types

Acidify allows pretty easy switching between build types. After committing all your local changes, etc., you may switch to anther build type without having to clean out your build environment and redownload many things again.

Warning: Acidify is beta (at best). Use caution when switching between build types. Commit and push / backup any local changes to your current setup before continuing.

Simply run

$ acidify init <new build type>

and your build environment will be switched to that.

The Slightly Harder Way

Before We Begin

The information here is meant to apply to the two main varieties of ROMs available to the Galaxy S 4G: CyanogenMod 7 or CyanogenMod 9. Because of this, some commands will have placeholders that need to be filled differently depending on what you're building.

<username> is your username on your machine.

<build type> can be either CM7 or CM9.

If you're building CM7, <branch> is gingerbread.

If you're building CM9, <branch> is ics.

General Setup

As with any android based build, follow the instructions at: http://source.android.com/source/initializing.html

Then follow the instructions in the section Installing Repo: http://source.android.com/source/downloading.html

When you get to Initializing a Repo client, STOP, and continue here.

You will need to install schedtool by running the following:

sudo apt-get install schedtool

(But don't be afraid to read any other documentation on http://source.android.com/ http://developer.android.com/sdk/index.html or http://developer.android.com/guide/index.html)

Syncing The Source

You have two options to syncing down the source:

The first option is to just sync down the source into a working directory.

The second option is to sync down a mirror, then sync a working directory from the mirror.

The second option is better if you are going to be doing a lot of work where you might screw up your repository.

Syncing Only the Tree (First Option)

cd ${HOME}
rm -rf android-sgs4g
mkdir android-sgs4g
cd android-sgs4g
mkdir work
cd work
repo init -u https://github.com/CyanogenMod/android.git -b <branch>
curl http://teamacid.github.com/manifests/sgh-t959v/<build type>/local_manifest.xml > .repo/local_manifest.xml
repo sync -j<JOBS>

Where <JOBS> is the number of downloads to do at once.

More is not always better. (4 is usually the maximum you would want to do)

Syncing with a Local Mirror (Second Option)

Step 1. Sync a local mirror

We start first by initializing and syncing the mirror:

cd ${HOME}
rm -rf android-sgs4g
mkdir android-sgs4g
cd android-sgs4g
mkdir mirror
cd mirror
repo init -u https://github.com/CyanogenMod/android.git -b <branch> --mirror
curl http://teamacid.github.com/manifests/sgh-t959v/<build type>/local_manifest.xml > .repo/local_manifest.xml
repo sync -j<JOBS>

Again, where <JOBS> is the number of downloads to do at once.

More is not always better.

You have now mirrored Android with the teamacid changes to the manifest.

Step 2. Make a working directory from the local mirror

Now we make our work directory. This is where you will do builds and make your changes.

cd /home/<username>/android-sgs4g
rm -rf work
mkdir work
cd work
repo init -u file:///home/<username>/android-sgs4g/mirror/CyanogenMod/android.git -b <branch>
cp /home/<username>/android-sgs4g/mirror/.repo/local_manifest.xml .repo/
repo sync

Now that you have a mirrored setup, you can do this step over and over again, and not have to download all of the cm7 source over and over again ;)

Create a task branch

If you are going to commit changes or email diffs, it's good to have a task branch setup to commit to. If you don't make a task branch, you will not be able to commit or push your changes.

I recommend making a general task branch:

cd /home/<username>/android-sgs4g/work
repo start <branch> --all

You will now be on the <branch> branch for all git repo's.

Pushing changes back to github

If you have R/W access to the teamacid github repo, go to the directory of the git repository for whatever project and type (we'll use the device tree as an example):

cd /home/<username>/android-sgs4g/work/device/samsung/galaxys4gmtd
git remote add teamacid git@github.com:teamacid/android_device_samsung_galaxys4gmtd.git
git fetch teamacid

Now you can make changes and commit them, then to push... just:

git push teamacid <branch to push to>

After you push changes, you'll want to sync you're mirror, as we discuss in the next section.

Keeping up to date

CyanogenMod gets updated upstream frequently. You will want to sync up often.

When you want to sync to latest, go into the mirror directory and type:

cd /home/<username>/android-sgs4g/mirror
repo sync

then go into the work directory and:

cd /home/<username>/android-sgs4g/work
repo sync

Building

Before you can build, you need to prepare the android build environment.

If you're compiling for CM7:

cd /home/<username>/android-sgs4g/work
source ./build/envsetup.sh
lunch cyanogen_galaxys4gmtd-eng # 
./vendor/cyanogen/get-rommanager

If you're compiling for CM9:

cd /home/<username>/android-sgs4g/work
source ./build/envsetup.sh
lunch cm_galaxys4gmtd-userdebug
./vendor/cm/get-prebuilts

The last step updates the RomManager.apk. You probably don't need to do this everytime, but it's wise to do before a release image.

Building the Kernel (CM7 only)

To build the kernel, change to the kernel directory and run the build.sh. In this example, we remove the build directory before building (this is optional), and output the build to a log file.

cd /home/<username>/android-sgs4g/work/kernel/samsung/galaxys4gmtd
./build.sh distclean
./build.sh build 2>&1 | tee ../build.log

Building the ROM

To do a build of the ROM, go into the work directory and type:

cd /home/<username>/android-sgs4g/work
#to wipe the build tree out
make clobber
brunch galaxys4gmtd

I found it useful to document a few tips.

If all you're doing is updating something after a build... say, the init.herring.rc or another file that is copied into the output (for say the initramfs or /system, etc...)

find out/ -name init.herring.rc -o -name boot.img | xargs rm
make bootimage

Note: we don't clobber, so all other built targets don't get rebuilt and we're assured that init.herring.rc was deleted.

or... updating the kernel (applies only to CM7)

find out/ -name '*.ko' -o -name kernel -o -name boot.img | xargs rm
make bootimage

It may be that the find|xargs steps are unnecessary, but I'm paranoid and want to be assured that the files I've updated are in the next build and I don't have to rebuild the whole thing from clobber just to update an rc in the initramfs.

Personal tools