torrentz2

Odin Software

Odin

Odin is an official flasher for many Samsung devices, runs only on Windows.

To flash your phone with it you will need .pit file containing information about all partitions, you can find one online or download it from the device e.g using Heimdall.

Using Odin

For Samsung phones only. Only available on Windows. The Knox switch (if present) will trip.

  1. Get the root file ready.
  2. Download Odin (there are many different versions, which mainly differ in the names used).
  3. Launch the phone in Download mode: hold the Volume Down+Power+Home buttons together when the phone is off. Accept the disclaimer.
  4. Select the root file in the appropriate catetory in Odin (the file should tell you which one).
  5. Click Start. Make sure that the phone is detected (a yellow box like COM x should appear).
  6. The phone will restart and the phone should now be rooted. Look for a SuperSu app or similar to confirm the presence of a root.

Logs

1. Odin failed during rooting. The writing to the phone memory never started on a Galaxy S6. The USB plug was pulled off after waiting for a noticiable amount of time with no progress sign either on the phone or Odin. Rebooting the phone led to stock, as expected (as nothing actually happened). Here’s the log from Odin3 v3.09:

<ID:0/004> Added!! 
<ID:0/004> Removed!! 
<ID:0/012> Added!! 
<ID:0/012> Odin v.3 engine (ID:12).. 
<ID:0/012> File analysis.. 
<ID:0/012> SetupConnection.. 
<ID:0/012> Initialzation.. 
<ID:0/012> Get PIT for mapping.. 
<ID:0/012> Firmware update start.. 
<ID:0/012> SingleDownload. 
<ID:0/012> recovery.img 
<ID:0/012> NAND Write Start!!  
<ID:0/012> Complete(Write) operation failed. 
<OSM> All threads completed. (succeed 0 / failed 1) 
<ID:0/012> Removed!! 
<ID:0/004> Added!!

So I tried to change the USB port on the computer and then downloaded the latest version of Odin3. And it worked! What I’m not sure is which of the two (or both?) helped; but do keep it in mind if you do the same.

 

Content of this page is based on informations from wikibooks.org and postmarketos.org, under CC BY-SA 3.0 licence.

T-Mobile G2 Firmware Downgrade (Gingerbread)

This guide will walk you through the process of taking the TMobile G2 from stock Gingerbread firmware to a stock, exploitable version of the Froyo firmware. Once it is downgraded, you would proceed thru the process of getting CyanogenMod on the device. If the TMobile G2 is already running firmware version 1.19.531.1 or lower (Settings » About Phone) you follow the vision install guide.

For other related guides please view the following:

Downgrading to 1.19.531.1

  1. You will need ADB on the computer to proceed thru this process. Follow the Android SDK guide to get the ADB shell on the computer.
  2. Download fre3vo, misc_version 0.2 & the 1.19.531.1 firmware:
    • fre3vo: Download
      md5: 010e076a4a93be876579711bf8934c70
    • misc_version 0.2: Download
      md5: 1f40aaf88d1bf15775631a58c4361218
    • flashgc: Download
      md5: 86e6e81fad3b3c837ed8bd09b6005651
    • 1.19.531.1 firmware: Download
      md5: 531c08dc402e15577b947bf4cd22aec2
  3. Unzip the fre3vo & misc_version packages and save flashgc to the same folder as adb (the /platform-tools folder within the Android SDK folder).
  4. Make sure the filename of the firmware is PC10IMG.zip exactly or it will not work and copy it to the same folder as adb.
  5. Connect the T-Mobile G2 to the computer via USB.
  6. On the computer, open terminal and run the following commands:
    adb push fre3vo /data/local/tmp
    adb push misc_version /data/local/tmp
    adb push flashgc /data/local/tmp
    adb shell
    chmod 777 /data/local/tmp/fre3vo
    chmod 777 /data/local/tmp/misc_version
    chmod 777 /data/local/tmp/flashgc
    /data/local/tmp/fre3vo -debug -start FAA90000 -end FFFFFFFF
    adb shell
  7. You should have the “#” sign instead of the “$”. If you do, you have temporary root, and can continue on. If you have the “$”, then the exploit has failed, refer to xda developers, RootzWiki, or #G2Root for further assistance.
    cd /data/local/tmp
    ./misc_version -s 1.00.000.0
    ./flashgc
    exit
  8. Now that misc version has been downgraded, the T-Mobile G2 is ready to have the firmware downgraded. On the computer, open terminal and run the following commands:
    adb reboot bootloader
  9. Wait for device to reboot into bootloader mode
    fastboot oem rebootRUU
  10. Wait for a black screen with the HTC logo
    fastboot flash zip PC10IMG.zip
  11. If you see a message saying Failed, repeat this step immediately: fastboot flash zip PC10IMG.zip and it should succeed.
  12. Once finished you can can continue to the next section.

Rooting the TMobile G2

Please follow the vision install guide.

Content of this page is based on informations from wiki.cyanogenmod.org, under CC BY-SA 3.0 licence.

HTC Desire Z Firmware Downgrade (Gingerbread)

This guide will walk you through the process of taking the HTC Desire Z from stock Gingerbread firmware to a stock, exploitable version of the Froyo firmware. Once it is downgraded, you would proceed thru the process of getting CyanogenMod on the device. If the HTC Desire Z is already running firmware version 1.34.xxx.x or lower (Settings » About Phone) you can skip to the vision install guide guide.

Downgrading to 1.34.707.3

  1. You will need ADB on the computer to proceed thru this process. Follow the Android SDK guide to get the ADB shell on the computer.
  2. Download fre3vo, misc_version 0.2 & the 1.34.707.3 firmware:
    • fre3vo: Download
      md5: 010e076a4a93be876579711bf8934c70
    • misc_version 0.2: Download
      md5: 1f40aaf88d1bf15775631a58c4361218
    • flashgc: Download
      md5: 86e6e81fad3b3c837ed8bd09b6005651
    • 1.34.707.3 firmware: Download
      md5: 8aa11b9e9db9877b029f37caec49547d
  3. Unzip the fre3vo & misc_version packages and save flashgc to the same folder as adb (the /platform-tools folder within the Android SDK folder).
  4. Make sure the filename of the firmware is PC10IMG.zip exactly or it will not work and copy it to the same folder as adb.
  5. Connect the HTC Desire Z to the computer via USB.
  6. On the computer, open terminal and run the following commands:
    adb push fre3vo /data/local/tmp
    adb push misc_version /data/local/tmp
    adb push flashgc /data/local/tmp
    adb shell
    chmod 777 /data/local/tmp/fre3vo
    chmod 777 /data/local/tmp/misc_version
    chmod 777 /data/local/tmp/flashgc
    /data/local/tmp/fre3vo -debug -start FAA90000 -end FFFFFFFF
    adb shell
  7. You should have the “#” sign instead of the “$”. If you do, you have temporary root, and can continue on. If you have the “$”, then the exploit has failed, refer to xda developers, RootzWiki, or #G2Root for further assistance.
    cd /data/local/tmp
    ./misc_version -s 1.00.000.0
    ./flashgc
    exit
  8. Now that misc version has been downgraded, the HTC Desire Z is ready to have the firmware downgraded. On the computer, open terminal and run the following commands:
    adb reboot bootloader
  9. Wait for device to reboot into bootloader mode
    fastboot oem rebootRUU
  10. Wait for a black screen with the HTC logo
    fastboot flash zip PC10IMG.zip
  11. If you see a message saying Failed, repeat this step immediately: fastboot flash zip PC10IMG.zip and it should succeed.
  12. Once finished you can can continue to the next section.

Note

You need to insert an SD card in your phone and use “charge only” mode on the phone.

Rooting the HTC Desire Z

Please follow the vision install guide to continue.

Content of this page is based on informations from wiki.cyanogenmod.org, under CC BY-SA 3.0 licence.

HTC Desire Z Firmware Downgrade (Froyo)

This guide will walk you through the process of taking the HTC Desire Z from a stock, non-exploitable version of the Froyo firmware to a stock, exploitable version of the Froyo firmware. Once it is downgraded, you would proceed thru the process of getting CyanogenMod on the device. If the HTC Desire Z is already running firmware version 1.34.xxx.x or lower (Settings » About Phone » Software number ) you can skip to the vision install guide.

For other related guides please view the following:

  • for the HTC Desire Z running Gingerbread, see the Gingerbread instructions.

Downgrading to 1.34.707.3

  1. You will need ADB on the computer to proceed thru this process. Follow the Android SDK guide, to get the ADB shell on the computer.
  2. Download psneuter, misc_version 0.2 & the 1.34.707.3 firmware:
    • psneuter: Download
      md5: 89c2dec8d72d87b4c669f44dd31c8d17
    • misc_version 0.2: Download
      md5: 1f40aaf88d1bf15775631a58c4361218
    • flashgc: Download
      md5: 86e6e81fad3b3c837ed8bd09b6005651
    • 1.34.707.3 firmware: Download
      md5: 8aa11b9e9db9877b029f37caec49547d
  3. Unzip the psneuter & misc_version package and save flashgc to the same folder as adb (the /platform-tools folder within the Android SDK folder).
  4. Make sure the filename of the firmware is PC10IMG.zip exactly or it will not work and copy it to the same folder as adb.
  5. Connect the HTC Desire Z to the computer via USB.
  6. On the computer, open terminal and run the following commands:
    adb push psneuter /data/local/tmp
    adb push misc_version /data/local/tmp
    adb push flashgc /data/local/tmp
    adb shell
    chmod 777 /data/local/tmp/psneuter
    chmod 777 /data/local/tmp/misc_version
    chmod 777 /data/local/tmp/flashgc
    /data/local/tmp/psneuter
    adb shell

Note:

You should have the “#” sign instead of the “$”. If you do, you have temporary root, and can continue on. If you have the “$”, then the exploit has failed, refer to xda developers, RootzWiki, or #G2Root for further assistance.

  1. cd /data/local/tmp
    ./misc_version -s 1.00.000.0
    ./flashgc
    exit
  2. Now that misc version has been downgraded, the HTC Desire Z is ready to have the firmware downgraded. On the computer, open terminal and run the following commands:
    adb push PC10IMG.zip /sdcard/PC10IMG.zip
    adb reboot bootloader
  3. Use Volume up/down keys on the HTC Desire Z for navigation and Power key for confirmation. Select Bootloader to flash the 1.34.707.3 firmware.
  4. Once finished you can can continue to the next section.

Rooting the HTC Desire Z

Please follow the vision install guide to continue.

Content of this page is based on informations from wiki.cyanogenmod.org, under CC BY-SA 3.0 licence.

Samsung Install

Installing a custom recovery

Samsung devices come with a unique boot mode called Download Mode which is very similar to Fastboot Mode on some devices with unlocked bootloaders. Heimdall is a cross-platform, open source tool for interfacing with Download Mode on Samsung devices. The preferred method of installing a custom recovery is through this boot mode. Rooting the stock firmware is neither recommended nor necessary.

  1. Download and install the Heimdall Suite
    • Windows: Extract the Heimdall suite and take note of the directory holding heimdall.exe. You can verify Heimdall is working by opening a command prompt in this directory and typing heimdall version. If you receive an error, be sure that you have the Microsoft Visual C++ 2012 Redistributable Package (x86/32bit) installed on your computer.
    • Linux: Pick the appropriate installation package based on your distribution. The -frontend packages are not required for this guide. After installation, heimdall should be available from the terminal; type heimdall version to verify installation succeeded.
    • Mac: Install the dmg package. After installation, heimdall should be available from the terminal; type heimdall version to verify installation succeeded.
    • Building from source: The source code for the Heimdall Suite is available on Github. For more details about how to compile the Heimdall Suite, please refer to the README file on Github under the relevant operating system directory. You can also refer to the Install and compile Heimdall instructions on this wiki.
  2. Download recovery — visit TWRP site to check for the latest version of recovery for your device (if your device can be found there). For general info about recoveries click here.
  3. Power off the {{{device_name}}} and connect the USB adapter to the computer but not to the {{{device_name}}}, yet.
  4. Boot the {{{device_name}}} into download mode. {{{device_download_mode_steps}}} Accept the disclaimer on the device. Then, insert the USB cable into the device.
  5. Windows (only) driver installation – Skip this step if you are using Linux or Mac
    A more complete set of the following instructions can be found in the Zadig User Guide.
    1. Run zadig.exe from the Drivers folder of the Heimdall Suite.
    2. Choose Options » List All Devices from the menu.
    3. Select Samsung USB Composite Device or MSM8x60 or Gadget Serial or Device Name from the drop down menu. (If nothing relevant appears, try uninstalling any Samsung related Windows software, like Samsung Windows drivers and/or Kies).
    4. Click Replace Driver (having selecting “Install Driver” from the drop down list built into the button).
    5. If you are prompted with a warning that the installer is unable to verify the publisher of the driver, select Install this driver anyway. You may receive two more prompts about security. Select the options that allow you to carry on.
  6. At this point, familiarize yourself with the Flashing with heimdall notes below so that you are prepared for any strange behaviour if it occurs.
  7. On the computer, open a terminal (or Command Prompt on Windows) in the directory where the recovery image is located and type:
    Tip: The file may not be named identically to what’s in this command. If the file is wrapped in a zip or tar file, extract the file first, because heimdall isn’t going to do it for you.
  8. A blue transfer bar will appear on the device showing the recovery being transferred.
  9. Unplug the USB cable from your device.
    • NOTE: Be sure to reboot into recovery immediately after having installed the custom recovery. Otherwise the custom recovery will be overwritten and the device will reboot (appearing as though your custom recovery failed to install).
  10. Manually reboot the phone into recovery mode by performing the following. {{{device_recovery_boot_steps}}}
  11. The {{{device_name}}} now has a custom recovery installed. Continue to the next section.

Note: Flashing with heimdall

  • In Windows 7 UAC (User Account Control) may need switching off. Once Heimdall is finished it can be re-enabled.
  • Protocol initialization can fail if the device is connected via a USB hub – connect the USB cable directly to the PC
  • It may be necessary to run the heimdall flash command as root in Linux or Mac OS X: sudo heimdall flash [...]. Typical symptoms of this are:
    • a blue bar doesn’t show up after the process has finished
    • Failed to confirm end of file transfer sequence!
  • It may be necessary to capitalize the name of the partition on some devices. Try --KERNEL instead of --kernel and/or --recovery instead of --RECOVERY.
  • If on Linux 64bit you get “unable to execute ./heimdall: No such file or directory”, try the 32bit version and make sure to run it with sudo: reference.
  • On Mac OS X you may see this message: “ERROR: Claiming interface failed!”. If so, you need to disable the default USB drivers with the following commands:
    sudo kextunload -b com.apple.driver.AppleUSBCDC;
    sudo kextunload -b com.apple.driver.AppleUSBCDCACMControl;
    sudo kextunload -b com.apple.driver.AppleUSBCDCACMData;
    If you have installed Samsung Kies, you may further need to unload those USB drivers with the following commands:
    sudo kextunload -b com.devguru.driver.SamsungComposite;
    sudo kextunload -b com.devguru.driver.SamsungACMData
    sudo kextunload -b com.devguru.driver.SamsungACMControl
  • Using Heimdall version 1.4.0 (the latest version available for download on the Glass Echidna website) you may see this message or one similar to it:
    Error: Failed to confirm end of PIT file transfer!
    If you experience this error, follow the instructions for compiling Heimdall from source to get the latest version on GitHub with the issue patched.

Helpful Tip

  • The stock ROM may overwrite your custom recovery on boot. To prevent this, boot immediately into recovery after leaving Download Mode instead of letting the ROM boot up normally. If your recovery is overwritten, simply redo the steps you followed above and catch it before it boots next time.
  • Note for upgrades from gingerbread to jellybean remember the recovery is changed. This means once you install do NOT restore to old-gingerbread-stock ROM from cwm-recovery.
  • To upgrade from stock/CM7/CM9/CM10.1.2/CM10.1.3 to CM10.2, you must first boot into recovery and wipe data, cache, and dalvik cache (factory reset). Due to the new partition layout in CM10.2, failing to perform these steps will result in a bootloop. See here for details; more about repartitioning here. If you missed this step before installing, boot to recovery and factory reset, then reinstall CM10.2.
  • Some users have reported connection errors if the device is connected to a USB hub. If you experience such errors it is recommended that you try connecting your device to a USB port on the motherboard.
  • Antivirus software may prevent Heimdall from connecting properly. Disable your antivirus before proceeding.
  • When Heimdall fails to connect, the Download mode may get stuck, making all further attempts fail too. To retry, you may need to restart the Download mode: turn off the phone by holding Power for 5-10 seconds (or by pulling out the battery), then boot into Download mode and run Heimdall again.
  • If Heimdall fails to connect (errors related to initializing the protocol, or transferring data):
    if you just installed the driver, try rebooting your computer and trying again.
    if you still have troubles after reboot, in Zadig try installing the libusbK driver rather than the WinUSB driver.

Content of this page is based on informations from wiki.cyanogenmod.org, under CC BY-SA 3.0 licence.

Jewel data/media transition

Information

The HTC EVO 4G LTE (jewel) was pulled from nightlies on Jul 29, 2014 due to frequent modem PIL (Peripheral Image Loader) failures. In short, the kernel was failing to bring the modem out of reset. These modem PIL failures vanish when jewel’s firmware is updated to 4.13.651.4. This guide instructs users on how to update jewel to firmware 4.13.651.4 and install CyanogenMod. Discussion on this topic should be posted to this forum thread.

The decision to take the firmware update route was not reached easily. There is a major caveat: there is no data migration path from an existing CyanogenMod installation. If you opt to perform this firmware update, all of your data, applications, and anything stored on /sdcard will be erased. The latest updates for jewel were published only semi-officially via twitter, likely because the stock ROM would face the same issue of no data migration from older stock ROM versions. The reason for this is a change in partition layout. The latest firmware update follows the recent trend of making /sdcard a directory on the /data partition rather than giving it its own partition. There are advantages and disadvantages to this. Some changes worth noting:

  1. Can only mount /sdcard to computer via MTP (media transport protocol)
  2. Available application installation space is now shared with media storage
  3. Separate user profiles store media in their own directories
    • Example: the first user profile has /sdcard linked to /data/media/0, the second user has /sdcard linked to /data/media/1, etc.

More information about this firmware update, including a short FAQ was put together by Captain_Throwback at XDA Forums:

The instructions provided below only give information on updating, not downgrading your firmware and are only intended for S-OFF users. For all intents and purposes, consider this a one-way street, no going back.

Not sure if you need the firmware update? Restart your phone to the bootloader and look for the HBOOT version. If your HBOOT version is lower than 2.10.0000, this update is for you. If your HBOOT is 2.10.0000 or greater, you can skip this guide and follow the standard installation instructions for jewel.

Backup CyanogenMod+Apps and store on computer

  1. Backup your existing application data with either adb backup or an app from the Play store (e.g. Helium, TitaniumBackup)
    If you have any applications that are partially stored to /sdcard (i.e. the “Move to SD Card” button for applications under Settings > Applications), then first move them back to Phone storage. This storage option is not needed or supported after transitioning to /data/media storage.
  2. Backup your existing ROM in recovery
  3. Copy all /sdcard contents to your computer
  4. Remove your microSD card from the phone to ensure it doesn’t get wiped

You can potentially use the application backups to save some time when setting up CyanogenMod after reinstallation.

The ROM backup is made because it is technically possible to downgrade via RUU 3.17.651.4. Instructions on this process are not provided on this wiki. Once your firmware has been updated, we recommend you stay with it; consider this a one-way street! If you really want to downgrade though, you may find help from users in this xda thread.

Update your firmware

You must be S-OFF to follow these instructions! If you are not S-OFF already, look into rumrunner, or possibly firewater.

Before you begin, be sure that both ADB and fastboot are installed and working on your computer. With your phone booted and connected to your computer, you should be able to type adb devices to see your device’s serial number. Similarly, test fastboot by first rebooting your phone to the bootloader (adb reboot-bootloader) and then typing fastboot devices to see your serial number again. Only continue if you have working adb and fastboot!

  1. Download jewel-firmware-4.13.651.4-twrp-2.7.1.2.zip (mirror)
    SHA1: 3d95f764dc79d6d63c146985760542d150e5984d
    It is imperative that you verify the SHA1 checksum before flashing!
    This firmware package contains an unofficial build of TWRP 2.7.1.2. More information about this recovery can be found here.
  2. Reboot the device to HBOOT:
    adb reboot-bootloader
  3. Enter the OEM update mode:
    fastboot oem rebootRUU
  4. Flash the firmware package. cd to the directory containing jewel-firmware-4.13.651.4-twrp-2.7.1.2.zip and run:
    fastboot flash zip jewel-firmware-4.13.651.4-twrp-2.7.1.2.zip
  5. You will see a FAILED message: remote: 90 hboot pre-update! please flush image again immediately. Do not be alarmed. Wait a few seconds for the HTC logo to reappear on your device, then run the same command again:
    fastboot flash zip jewel-firmware-4.13.651.4-twrp-2.7.1.2.zip
  6. Wait for the process to finish
  7. Reboot the phone to the bootloader:
    fastboot reboot-bootloader
  8. Use the volume keys to navigate to BOOTLOADER and the power key to select; you should see HBOOT-2.10.0000 if the firmware update was successful.
  9. Choose RECOVERY from the HBOOT menu to boot into TWRP

Install CyanogenMod

You have a choice of CyanogenMod build to install:

  1. Official nightlies later than or equal to 20140806
  2. Official M-builds later than or equal to M10

You may also want to download the Google Apps package (version 20140606)

TWRP

  1. Select the Wipe button, followed by Format Data. Type yes to continue, wait for the process to finish, and then return to the home screen with the Home icon at the bottom of the screen.
  2. Select the Wipe button, followed by Advanced Wipe. Select the Cache and System partitions and confirm their wipe. Return to the home screen.
  3. You can now either use adb to push the installation package(s) to /sdcard, or copy the package(s) to a microSD card on your computer and insert it into your device. You may have to reboot recovery for the microSD card to become available.
    adb method: adb push cm-11-20140916-SNAPSHOT-M10-jewel.zip /sdcard/

From here, installation is as you’ve always done. Discussion should be directed to this forum thread.

Content of this page is based on informations from wiki.cyanogenmod.org, under CC BY-SA 3.0 licence.

Goldcard

Before You Begin

  • Some SD cards simply will not work as a “goldcard”. The most likely reason is that the SD card does not have a partition table(MBR) and sector 0 of the card starts with the file system boot sector, So writing the Goldcard image on the SD card will overwrite the boot sector of file system thus rendering the card unusable. You can use HP USB Disk Storage Format Tool to format the card correctly with MBR partition scheme, just make sure to format the card with fat32 file system(This will erase everything that is on the SD card, so backup anything that is on it that you consider important). But If you still cannot get the SD card to work properly, try a different SD card.
  • You will need some form of adapter to connect the SD card to the computer, whether it be a microSD to USB adapter, or a microSD to SD adapter plugged into a SD card slot on the computer.
  • You will need to install the Terminal Emulator from the Android Market.

Creating a Goldcard

  1. Insert the SD card you want use for the goldcard into the device.
  2. Unmount the SD card (Settings » SD card & device storage » Unmount SD card) and then format it (Erase/Format SD card).
    NOTE: This will erase everything that is on the SD card, so backup anything that is on it that you consider important.
    NOTE: Make sure your sdcard was formatted to fat32.
  3. On the device, open the Terminal Emulator and type the following command:
    cat /sys/class/mmc_host/mmc1/mmc1:*/cid

    NOTE: If that does not work, try cat /sys/class/mmc_host/mmc0/mmc0:*/cid
    NOTE: For Desire HD / Inspire 4G phones, try cat /sys/class/mmc_host/mmc2/mmc2:*/cid
  4. A 32 character, alphanumeric code will be displayed. Write it down exactly as it is presented.
  • Go to http://huygens.hoxnet.com/goldcard.html and enter the code as a “normal code”.
  • Once you click on “Download Goldcard”, download/save the binary file.
  • Download & install HxD.
  • Take your SD card out of the device and put it into the SD adapter it came with. Then put that into your computer so it shows up on your computer as Removable Disk.
  • Open the Hex Editor (Run as Administrator if one Vista or Windows 7) and click on the Extra tab, then click on Open Disk. Under Physical Disk select Removable Disk (your SD card you just put into the computer). Make sure to UNcheck “Open as ReadOnly”. Click OK.
  • Goto the Extra tab again and click Open Disk Image. Open up the goldcard.img that you saved from your email. You should now have two tabs, one is the SD card (Removable Disk) and the other is the goldcard.img Press OK when prompted for Sector Size 512 (Hard Disks/Floppy Disks).
  • Click on the Goldcard.img tab and click on the Edit tab and click Select All. Then click on the Edit tab again and click Copy.
  • Click on the Removable Disk tab (Your SD Card) and select offset 00000000 to 00000170 then click on the Edit tab and click Paste Write.
  • Click on File then click Save.
  • Close the Hex Editor.
  • Test what we’ve done:
    1. Take out the memory card from the computer, then put it back in.
    2. Try to open the memory card on the computer (Removable Disk), if it lets you, you are all set. If it asks/tells you to reformat the card, then try steps 13 – 19 again. If it gives you the same error again, then try a different memory card (Erlern said it didn’t work for him until he finally went and bought a Kingston 2GB card, then it worked on that card).
  • You can now use this goldcard to root devices that were previously unrootable!
  • Creating a Goldcard on POSIX

    1. Insert the SD card you want use for the goldcard into the device.
    2. Unmount the SD card (Settings » SD card & device storage » Unmount SD card) and then format it (Erase/Format SD card).
      NOTE: This will erase everything that is on the SD card, so backup anything that is on it that you consider important.
      NOTE: Make sure your sdcard was formatted to fat32.
    3. On the device, open the Terminal Emulator and type the following command:
      cat /sys/class/mmc_host/mmc1/mmc1:*/cid

      NOTE: If that does not work, try cat /sys/class/mmc_host/mmc0/mmc0:*/cid
      NOTE: For Desire HD / Inspire 4G phones, try cat /sys/class/mmc_host/mmc2/mmc2:*/cid
  • Go to http://huygens.hoxnet.com/goldcard.html and input the code as “normal”
  • Once you click on “Download Goldcard”, download/save the binary file.
  • Take your SD card out of the device and put it into your computer, you may need a micro to full size SD adapter. If it doesn’t have an SD card slot, you’ll have to buy a USB card reader, these are US$5 for a cheap one
  • Open a Terminal
  • Determine the device that matches the memory card; executing “dmesg” should show any recent cards/card readers connected to the PC, this is written below as /dev/(usbdevice)
  • Umount the SD card; that depends on your OS
    # umount -l /dev/(usbdevice) # on linux
    # umount -f /dev/(usbdevice) #on mac
  • Execute the following command:
    # dd if=goldcard.img of=/dev/(usbdevice)
  • Test what we’ve done:
    1. Take out the memory card from the computer, then put it back in.
    2. Try to open the memory card on the computer (Removable Disk), if it lets you, you are all set. If it asks/tells you to reformat the card, then try steps 13 – 19 again. If it gives you the same error again, then try a different memory card (Erlern said it didn’t work for him until he finally went and bought a Kingston 2GB card, then it worked on that card).
  • You can now use this goldcard to root devices that were previously unrootable!
  • Content of this page is based on informations from wiki.cyanogenmod.org, under CC BY-SA 3.0 licence.

    HTC fstab updates

    Encryption Notice

    Beginning with nightly 20140501 (or milestone 7, if you prefer the stable channel), the location where encryption information is stored is being moved on the following devices:

    • evita – HTC One XL
    • fireball – HTC Droid Incredible 4G LTE
    • jewel – HTC EVO 4G LTE
    • ville – HTC One S

    If you utilize Android’s built-in data encryption (i.e. Settings > Security > Encrypt phone), read and follow these instructions before installing a new recovery and any nightly equal to or newer than 20140501 (or milestone 7). If you do not utilize data encryption, you can safely skip to the next section, “Recovery Update”.

    Technical info for the curious: the “extra” mmcblk partition is the new home for encryption information, rather than the footer of /data.

    In order to preserve your data, follow this procedure:

    1. Install a recent build of TWRP with the “legacy” encryption location
      twrp-2.7.0.7-device-oldenc.img recoveries are available at android.cmphys.com
    2. Upon entering TWRP, enter your passcode to allow reading from /data
    3. Make a backup of your /data partition
    4. Reboot to Android
    5. Delete /sdcard/TWRP/.twrps    Many thanks to Clark008 for debugging this
    6. Flash TWRP 2.7.0.8 or newer (available at android.cmphys.com and AFH)
    7. Restart to recovery, but this time do not enter your passcode when entering TWRP (cancel)
    8. Restore your /data backup (this will wipe it beforehand) – it is now decrypted
    9. You should be able to boot into Android without a passcode now. Only re-encrypt your phone if using a build of CyanogenMod equal to or newer than 20140501.

    Recovery Update

    Beginning with nightly 20140501 (or milestone 7, if you prefer the stable channel), several HTC devices are being transitioned to a new fstab layout. This will not affect your data. This change requires kernel support in recovery for CyanogenMod packages to install.

    Affected devices include:

    • evita – HTC One XL
    • fireball – HTC Droid Incredible 4G LTE
    • jewel – HTC EVO 4G LTE
    • m4 – HTC One Mini
    • m7 – HTC One [GSM]
    • m7spr – HTC One [Sprint]
    • m7vzw – HTC One [Verizon]
    • ville – HTC One S

    jewel and ville users: This is not the /data/media transition. That change is still being ruled out because there is simply no migration path that preserves data. With that said, if you are running an unofficial build of CyanogenMod that also incorporates this fstab change, TWRP recoveries are available from android.cmphys.com.

    All of these recoveries are backwards compatible.

    • ClockworkMod recoveries with version greater than or equal to 6.0.4.8 support this fstab change. HTC One AT&T (m7att), HTC One T-Mobile (m7tmo), and HTC One non-US GSM (m7ul) can safely use the recovery for the generic “HTC One” (m7). Note: version 6.0.4.8 for m4 may have been built before by-name support was added to the kernel.
    • TWRP recoveries with version greater than or equal to 2.7.0.8 support this fstab change.* If you have a favorite recovery maintainer, encourage them to incorporate “block: by-name” support into their recovery kernels!
      • (*) Official 2.7.1.0 for m4, m7, m7spr/m7wls, and m7vzw/m7wlv mistakenly did not include the necessary fstab support, so 2.7.1.1 was released for these devices, addressing the issue.
      • More recent unofficial builds of TWRP can be found at android.cmphys.com. You’ll find source code for all these devices linked there as well.

    Troubleshooting

    If booting into TWRP 2.7.0.8 causes the TeamWin logo to repeatedly flash without ever reaching the home screen:

    1. Reboot your device to Android: either hold power until the device turns off or use adb reboot
    2. Delete the settings file /sdcard/TWRP/.twrps
    3. Reboot back to recovery

    This problem is fixed in TWRP 2.7.1.0 and later.

    Mirrors for recoveries

    All TWRP recoveries mentioned above have been mirrored to Android File Host

    Content of this page is based on informations from wiki.cyanogenmod.org, under CC BY-SA 3.0 licence.

    Paths

    “Command not found” errors

    If the binary is installed on your computer and you see a “command not found” type of error when entering your command into the terminal, the problem may be that the /platform-tools directory (or whichever directory contains the binary such as ~/bin) is not in the “path of execution” for your terminal session. This means that your computer doesn’t know where exactly the binary is located.

    The solution to this is to add the directory containing the binary to your PATH.

    Linux/OSX

    On most Linux/OSX systems using the Bourne Again Shell (bash), you can do the following:

    1. Edit the .bashrc file in your home directory. You can use any text editor (the example below uses “gedit”) to make this change.
      $ gedit ~/.bashrc
    2. Add the following line (/path/to/dir below would need to be replaced with whatever directory you want added to your PATH)
      $ export PATH=/path/to/dir:$PATH
    3. Save the file, then use the source command from the Terminal to load your .bashrc file:
      $ source ~/.bashrc

    Alternately, you can simply open a new window or tab to load the changes in the new terminal.

    That’s it!

    Windows

    On Windows systems, you can do the following:

    1. Right-click on My Computer and select Properties.
    2. Choose Advanced and click on the Environment Variables button.
    3. Navigate to System Variables and double-click on Path to edit.
    4. Enter the full path to the directory/folder you want added to your PATH.

    Content of this page is based on informations from wiki.cyanogenmod.org, under CC BY-SA 3.0 licence.

    How To Port CyanogenMod Android To Your Own Device

    Note:

    If you came to this page by searching for information about porting Android, and you’re not sure what CyanogenMod is, learn more about the CyanogenMod distribution of Android here.

    Some tips on porting CyanogenMod to your own device

    So you may come across a phone or tablet or whatever that does not yet have CyanogenMod available.

    You’ve previously built CyanogenMod on your computer for another device or two, and you feel comfortable with the process. In fact, you’ve still got the source code standing by and are ready to tackle a big project.

    Looks like this is your opportunity to shine!

    Note:

    For the purposes of this tutorial, all references to directories will assume you are in the root of the source code (ie, where you did the repo init), and folder names will be relative to there. If you followed the build guide, the root of the source code is at ~/android/system

    Prerequisites

    Porting CyanogenMod to a new device can be ridiculously easy or ridiculously difficult, depending on the device itself, whether it currently runs a recent version of Android or not, and of course your skills as a developer matter too.

    It would be pretty hard to do a port without having built CyanogenMod (and recovery) previously for another device. So if you haven’t done a build or two, give it a shot.

    Helpful Tip

    If you found this page other than via the CyanogenMod Learning Center, head over to Development for much more information.

    Additionally, you should familiarize yourself with the CyanogenMod source code. You should expect that, barring some rare exceptions, nearly everything you need to do will be in the /device/[vendor]/[codename], /vendor/[vendor]/[codename], and /kernel/[vendor]/[codename] directories.

    Helpful Tip

    For a more-detailed overview of what’s where in the CyanogenMod source folders, see here. In fact, you really should read this if you plan on doing a port.

    Collect information about your device

    Before you begin your port, you will want to collect as much information about your device as you can. 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. Try to learn as much about the device, including any similarities it may have to other devices.

    Helpful Tip

    Many devices are architecturally similar to other devices that are already on the market and have existing CM ports. When a new device comes out, see if you can find out if it may be identical to another device, only with a different sized screen or more memory or some other minor difference. If you find an “ancestor” or “sibling” of your device, much of the work may already be done for you!

    Much of the information you need may be available online, but assuming the device is already running a non-CyanogenMod version Android, you may also get some of that information from the device itself. To view the files containing this information, the device may need to be rooted. However, sometimes you can find a stock firmware update package online, and can view the files from the .zip archive file.

    Look at the device’s current /system/build.prop

    Assuming the device is already running a version of Android, there should be a file, /system/build.prop, on the device which may contain useful information that will come into play as you do your port. This file contains definitions for various parameters and settings used by Android.

    So, if you have previously installed adb onto your computer, you can use the following command to pull this file to your computer:

    adb pull /system/build.prop

    If you receive an error relating to permissions, the device may need to be rooted to gain access to this file. However, there are other ways to locate this file. For example, it may be included in any stock firmware “upgrade” package online.

    Once you have the file…

    • Write down the value of the ro.product.manufacturer parameter. This will be your vendor name. The [vendor] is the name of the manufacturer/vendor of the device. CM has established naming conventions for most major vendors, such as samsung, htc, lge, etc. Note that in these directory names, the vendor is always lowercase and contains no spaces.
    • Write down the value of the ro.product.device parameter. This will be your device codename. The [codename] corresponds to the project code name of the device itself. This is almost never the sales name of the device. If you have built CM before (and again, you better have!), you should be familiar with the concept of a code name for each device. Like the vendor name, the codename is always lowercase and contains no spaces.

    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.

    Examine boot.img and recovery.img

    As stated, when doing your port, you may wish to use an existing pre-built kernel that you know works instead of building one from source code. Depending on your device, you may need to extract this kernel file from the device. The kernel may exist as a single file (as it does on many OMAP devices) or may be wrapped up along with the ramdisk in a boot or recovery partition.

    Similarly, the contents of the stock ramdisk may be extremely helpful and can often be extracted and reviewed. It may be the case that a device requires specific files from the stock ramdisk in order to boot properly, load a module, etc. In most cases you can view files in the ramdisk from the device itself, but it you may prefer to look at the full directory.

    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.

    You can frequently extract the boot and recovery images (to a file you name boot.img and recovery.img) on a rooted Android device using dd. Or, if you have access to an update .zip file from the vendor, you can often find those files within.

    Collect any available existing source code

    The manufacturer or vendor of any device using Android will minimally need to make the source code available for all GPL components upon request, including (and especially) the kernel. You definitely want to request a copy of the kernel source and keep it handy.

    Determine the partition scheme

    The primary long-term storage portion of your mobile device– usually an “emmc” (embedded multimedia card)– is much like a computer hard drive in that it is prepared in a particular way to identify and isolate different areas of data. These unique areas are called partitions and they can have any kind of data stored there. Some partitions contain raw data– firmware, kernels, ramdisks, etc. More often, a partition is formatted to use a particular file system that the kernel will recognize so that individual files and directories can be read and written there.

    Before you can replace the stock operating system with CyanogenMod, it is therefore important to ascertain the partition scheme of the device. The recovery image you build will need this information to know where to find the various Android directories. Particularly, you want to 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 (such as the u-boot used by many OMAP-based devices), you will likely find the information there as well.

    Note:

    Be aware that in some rare cases, such as the HP Touchpad, an abstracted virtual file system is used.

    Set up three new directories

    Now that you’ve gathered information about your device, it’s time to generate the folders for your device configuration, located in the following directories, relative to the code source directory.

    • 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. As mentioned, when starting the folder for this device, it may be a good idea to adapt a directory for an existing device that is architecturally similar to the one you wish to port. Look for a device that is based on the same platform, for example.
    • vendor/[vendor]/[codename]/ — The vendor/ directory contains proprietary, binary “blobs” that are backed up from the original device (or provided by the vendor, such as in the case of Google Nexus devices and some TI graphics blobs).
    • 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. This can vary from device-to-device, so it may again be helpful to look at similar devices to yours that use a similar architecture. Building the kernel from source is not strictly necessary for every device, but in the spirit of open source, it is the preferred practice for CyanogenMod. See here for a detailed discussion about how CyanogenMod builds the kernel source from scratch.

    There are at least three methods to generate these directories:

    Method 1: Use mkvendor.sh to generate skeleton files

    Use the mkvendor.sh script in build/tools/device/ to automatically generate the directories.

    Note:

    The mkvendor script only works with devices that use a standard boot.img file, using the standard Android conventions and headers. It won’t work for devices that deviate from this standard (Nook Color, Touchpad, etc.).

    This script accepts three parameters: vendor, codename, and a boot.img file.

    Example usage:

    $ ./build/tools/device/mkvendor.sh samsung i9300 ~/Desktop/i9300boot.img
    

    In the above example, samsung represents the vendor, i9300 represents the codename and the last parameter is the path to the boot.img file that was extracted from the boot partition with dd or provided by the vendor in an update .zip as discussed above.

    The command above should create a /device/samsung/i9300/ folder within your CyanogenMod source repo structure. And inside the folder, the files AndroidBoard.mk, AndroidProducts.mk, BoardConfig.mk, cm.mk, device_[codename].mk, kernel (the binary), recovery.fstab, etc.

    This will not build the kernel/ directory. You will need to do that later, when you are ready to build the kernel.

    Note:

    If it returns the message “unpackbootimg not found. Is your
    android build environment set up and have the host tools been built?” please be sure that you run the following command during setting up the developer environment:

    $ make -j4 otatools

    Method 2: Fork a similar device’s git repository

    If you’ve got a GitHub account, you might want to start by forking another, similar device, and then rename it for your device. See the section on setting up github for a discussion on how to name your repository.

    Always be sure you’re compliant with the license of any repository you fork.

    Method 3: create the directories and files manually

    You can always start with an empty directory and start creating the files by hand. This is the least recommended and perhaps the most tedious method, but it may be the most instructive. You can look at other devices for reference on what files you need.

    Customize the files

    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.

    Helpful Tip – Start with the recovery!

    The first major step is to get a working recovery image for your device so that testing subsequent update.zips is easy and so that you can do backups if necessary. These next few steps will therefore focus more on getting a working recovery than getting CM itself to work. Once the recovery is built and operating safely, the work you’ve done for it will apply directly to the CM part.

    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.

    kernel

    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:

    /systemext4/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

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

    If things break (and they will break), have a look at these tips for dealing with build errors.

    Helpful Tip

    If you have fastboot, you can try it to install the recovery image to the recovery partition. There are other methods for installing the recovery, such as using dd from a rooted system to flash it into place.

    Not much needs to be said here, but make sure the recovery is working before you move on to getting CyanogenMod working. A 100%-working and reliable recovery mode is absolutely necessary before you start testing experimental Android builds.

    Adjust recovery_ui.cpp if necessary

    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.

    Put your device folder in github, and use a local manifest to automatically sync it with repo sync

    Once you’ve started your device folder, create your own GitHub account and set up your folder as a public GitHub repository. This is a great opportunity to learn about git, and also your source can be accessible to others who can collaborate with you.

    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_device_bn_encore. It would be accessible at https://github.com/fat-tire/android_device_bn_encore. Similarly, the kernel repository would be called android_kernel_bn_encore. 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>
    

    Note:

    The revision attribute is optional. If it is omitted, repo sync will use the revision specified by the <default ... /> tag in the default manifest.

    Once you’ve tested that the local manifest file works, you can pass it on to others, who can then try out your work. At that point you can continue to push your changes to GitHub, and even give other users commit access so that you can work on the device together.

    Helpful Tip – Using other repositories

    If you find that for some reason you need to replace or supplement other repositories provided by CyanogenMod, you can add additional repositories using the local manifest. Once you’ve got everything working, you can use Gerrit to submit stuff found in those repositories back upstream to CyanogenMod.

    Add the blobs to the vendor/ directory

    Once you have a working recovery, it’s now time to get CyanogenMod building and working.

    The first thing to do is to get all the proprietary, binary blobs into the vendor/ folder, along with a .mk file that will include them in the final build.

    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.

    Now revise the device/ directory

    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.

    You now have a easy means to do backups and test your builds. So start tweaking the device folder itself, and see if you get it to boot… Once you do, from there its a matter of building and supporting the various parts and peripherals, one-by-one.

    Getting help from the manufacturers & vendors

    Many of the OEMs (Original Equipment Manufacturers) who make the underlying platform used by your device frequently provide wikis, documentation, and sample code that can assist you in completing your port. You’ll find that some companies are more friendly to the development community than others. Here are some of the more common OEMs and vendors, along with web sites and repositories that may help.

    (This list is incomplete. Please help add to it)

    OEM Platform Repositories/Resources
    Google various Google’s Git Repository , Nexus binary blobs
    HTC various Dev Center
    HP various HP Open Source
    Lenovo various Lenovo Smartphones (Search your device)
    LG various LG Open Source Code Distribution
    Motorola various Motorola Open Source Center
    Nvidia Tegra Tegra’s GitWeb
    Qualcomm MSM/QSD Code Aurora Forum
    Samsung various Samsung Open Source Release Center
    Texas Instruments OMAP www.omapzoom.com , Omappedia

    Sometimes if you have questions you can even reach out to the developers via email or the support forums.

    Adding XML Overlays

    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.

    Make the kernel and kernel modules build from source

    If you have previously used a pre-built kernel, you may at some point want to start building the kernel from scratch.

    See the instructions for how to change the BoardConfig.mk file to make CyanogenMod build the kernel and any required kernel modules automatically.

    Conclusion

    There’s no way a single wiki page will tell you everything you need to know to do a port from beginning to end. However, hopefully you now have an understanding of how things are set up and the steps you need to take. You an always ask for help on the forums or on IRC. Others with the same device may jump in to help too.

    Hopefully you’ll find the process rewarding and educational. And it’ll get you some street cred as well.

    When you’re all done, and your port works better than stock… when it’s stable and shiny and marvelous and wonderful…

    You may want to contribute your work upstream. Here are the instructions for how to do just that.

    Good luck!

    See Also

    Content of this page is based on informations from wiki.cyanogenmod.org, under CC BY-SA 3.0 licence.