• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[DEV]How to compile TWRP touch recovery

Search This thread

ineedroot69

Senior Member
Nov 13, 2019
825
1
176
Just an advice: do not use VM for twrp developing...I was also trying it. Lot of hassle...I think better to do on native system. But it is up to you. I have trial boot: Win10 Archlinux and Kubuntu20.04. Doing development only at debian...
i fix it apparently you just need to use disk defragmenter created for ubuntu from 89GB to 52GB also there's provably a better way since it took me 3 hours to defragment it manually
 

Attachments

  • dsad.png
    dsad.png
    39.8 KB · Views: 82

ineedroot69

Senior Member
Nov 13, 2019
825
1
176
Device tree: https://github.com/tyler820201/OnePlus8T/tree/OP8T20210530
Vendor tree: prebuilt

Kernel Source: prebuilt

Error log: https://del.dog/epemetylop.txt
As this should be an insufficient RAM capacity regarding googling i was trying:
make clean && make -j# recoveryimage (reducing j# number. I was trying j# 1 2 3 4)
However i have 16GB DDR3 RAM in my laptop and regarding system monitor does not use it much during compilation process. I am using kubuntu 20.04LTS
should i compile it for you?
 
  • Like
Reactions: tyler19820201

tyler19820201

Senior Member
Jun 19, 2011
361
56
London
sorry for really late reply i went on hawaii for vacation does this phone have recovery partition?
cuz you can use different command for it ....
mka recoveryimage ~> twrp for device with recovery partition
mka bootimage ~> twrp for device without recovery partition
it has recovery partition.
fastboot flash recovery_a & fastboot flash recovery_b filename.img
so u need mka recoveryimage
Good luck for build...If u can build i am happy to assist you with testing.
However nobody could build a fully working version of twrp for this phone yet...
 

albatron34000

Senior Member
Apr 15, 2018
81
32
Realme 7
i builded twrp for android 11 from porting officiel twrp Android 10 using AIK
the only problem i have is data encryption, when i wipe data recovery work fine
but when setup device and data been encrypted irecovery stuck at blinking twrp logo
and to enter recovery i must erase data using fastboot then reboot to recovery.
how can i fix this ?
 

edward0181

Senior Member
Jul 28, 2013
178
62
Spijkenisse
Samsung Galaxy A12
For some stupid reason, I can't get my recovery image to boot in Emulator... always the same issue on kernel syncing;
Code:
Failed to execute /init (error -8)
Starting init: /bin/init exists but couldn't execute it (error -8)
Starting init: /bin/sh exists but couldn't execute it (error -8)
Kernel panic - not syncing: No working init found.  Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.

Call Trace:
dump_stack+0x57/0x86
panic+0xe6/0x24b
? rest_init+0xbc/0xbc
kernel_init+0x119/0x131
ret_from_fork+0x1f/0x30
Kernel Offset: 0x21a00000 from 0xffffffff80200000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
Rebooting in 5 seconds..

Donna wanna risk bricking my phone by flashing the recovery image untested.

ps. It's a Samsung device (a12) which needs a ramdisk-recovery normaly.

nevermind if I make a bootimage or recoveryimage with TWRP, the emulator just doesn't want to start.
 

AceSheep

Member
Jul 12, 2021
12
2
I can't compile on AOSP Android 11. When I use the manifest of twrp-10 (android 10) all is ok, can compile just fine. I tried both manifests and both stopped working after compiling the manifest
Is the manifest still not complete, or am I missing something?

https://github.com/minimal-manifest-twrp/platform_manifest_twrp_aosp -b twrp-11
https://github.com/omnirom/android_bootable_recovery -b android-11
Device tree: https://github.com/itzmonvw124/xiaomi_twrp_device_camellia


Code:
============================================
ninja: no work to do.

#### build completed successfully (4 seconds) ####
 

edward0181

Senior Member
Jul 28, 2013
178
62
Spijkenisse
Samsung Galaxy A12
I can't compile on AOSP Android 11. When I use the manifest of twrp-10 (android 10) all is ok, can compile just fine. I tried both manifests and both stopped working after compiling the manifest
Is the manifest still not complete, or am I missing something?

https://github.com/minimal-manifest-twrp/platform_manifest_twrp_aosp -b twrp-11
https://github.com/omnirom/android_bootable_recovery -b android-11
Device tree: https://github.com/itzmonvw124/xiaomi_twrp_device_camellia


Code:
============================================
ninja: no work to do.

#### build completed successfully (4 seconds) ####
Do have the same issue. In the end ninja has no work to do...
 

lilinbo

New member
Oct 31, 2019
2
0
Hello, can someone help me?

I tried to compile twrp, which prompted me to get this error
4 warnings were generated.
[12% 1964/15879] Target boot image: /media/pc/twrp/omni8_minimal/out/target/product/davinci/boot.img
Failure: /media/pc/twrp/omni8_minimal/out/target/product/davinci/boot.img
/bin/bash -c "/media/pc/twrp/omni8_minimal/out/host/linux-x86/bin/mkbootimg --kernel /media/pc/twrp/omni8_minimal/out/target/product/davinci/kernel - base 0x00000000 --pagesize 4096 --cmdline \"console=ttyMSM0,115200n8 androidboot.hardware=qcom androidboot.console=ttyMSM0 androidboot.memcg=1 lpm_levels.sleep_disabled=1 video=0x40bmrtb,70ms,14 .filter=0x237 service_locator.enable =1 swiotlb=1 androidboot.usbcontroller=a600000.dwc3 earlycon=msm_geni_serial,0x880000 loop.max_part=7 printk.devkmsg=on androidboot.selinux=permissive configsengfvariable androidboot.usb -os_version 11 --os_patch_level 2021-12-31 --ramdisk 0x01000000 --tags_offset 0x00000100 --header_version 1 --output /media/pc/twrp/omni8_minimal/out/target/product/davinci/boot.
Usage: mkbootimg [-h] --kernel kernel [--ramdisk RAMDISK] [--second SECOND]
[--cmdline CMDLINE] [--base basis]
[--kernel_offset KERNEL_OFFSET]
[--ramdisk_offset RAMDISK_OFFSET]
[--second_offset SECOND_OFFSET] [--os_version OS_VERSION]
[--os_patch_level OS_PATCH_LEVEL] [--tags_offset TAGS_OFFSET]
[--Board]
[--pagesize {2048,4096,8192,16384,32768,65536,131072}] [--id]
[--dt DT] -o output
mkbootimg: error: unrecognized parameter: --header_version 1
[12% 1969/15879] Target C++: libhealthd_minui <= system/core/healthd/minui/resources.cpp
Ninja: Build stopped: subcommand failed.
00:13:01 Ninja failure: exit status 1

#### Unable to build some goals (03:03 (mm:ss)) ####



你好,有人可以帮我吗?

我试图编译 twrp,这提示我出现此错误
生成了 4 个警告。
[ 12% 1964/15879] 目标启动镜像:/media/pc/twrp/omni8_minimal/out/target/product/davinci/boot.img
失败:/media/pc/twrp/omni8_minimal/out/target/product/davinci/boot.img
/bin/bash -c "/media/pc/twrp/omni8_minimal/out/host/linux-x86/bin/mkbootimg --kernel /media/pc/twrp/omni8_minimal/out/target/product/davinci/kernel -- base 0x00000000 --pagesize 4096 --cmdline \"console=ttyMSM0,115200n8 androidboot.hardware=qcom androidboot.console=ttyMSM0 androidboot.memcg=1 lpm_levels.sleep_disabled=1 video=0x40bmrtb,70ms,14 .filter=0x237 service_locator.enable=1 swiotlb=1 androidboot.usbcontroller=a600000.dwc3 earlycon=msm_geni_serial,0x880000 loop.max_part=7 printk.devkmsg=on androidboot.selinux=permissive configsengfvariable androidboot.usb -os_version 11 --os_patch_level 2021-12-31 --ramdisk_offset 0x01000000 --tags_offset 0x00000100 --header_version 1 --output /media/pc/twrp/omni8_minimal/out/target/product/davinci/boot.
用法:mkbootimg [-h] --kernel 内核 [--ramdisk RAMDISK] [--second SECOND]
[--cmdline CMDLINE] [--base 基础]
[--kernel_offset KERNEL_OFFSET]
[--ramdisk_offset RAMDISK_OFFSET]
[--second_offset SECOND_OFFSET] [--os_version OS_VERSION]
[--os_patch_level OS_PATCH_LEVEL] [--tags_offset TAGS_OFFSET]
[--板板]
[--pagesize {2048,4096,8192,16384,32768,65536,131072}] [--id]
[--dt DT] -o 输出
mkbootimg:错误:无法识别的参数:--header_version 1
[ 12% 1969/15879] 目标 C++:libhealthd_minui <= system/core/healthd/minui/resources.cpp
忍者:构建停止:子命令失败。
00:13:01 忍者失败:退出状态 1

#### 无法构建一些目标 (03:03 (mm:ss)) ####
 
Last edited by a moderator:

daboross

Senior Member
Edit: I've gotten help from the TWRP Zulip (linked in readme of https://github.com/minimal-manifest-twrp/platform_manifest_twrp_aosp). No longer need assistance here. See edit at end of message.


Is there any way to build TWRP for a new device without binary blobs?

I'm trying to build for a device on the SM4350 platform, and A) no stock rom is available, B) no custom ROMs have been ported yet, and C) there are no other older devices on the same SM4350 platform with either of those two :(

I've been trying to modify an existing android_device repository into one for my device (https://github.com/daboross/android_device_oneplus_holi), but I'm not having a lot of luck.

Since I'm basing it off of the oneplus_fajita manifest, there are some leftover references to common device files. If I leave those in, I get a failing build - since, well, they don't match my device configuration.

But if I take them out, I get the following error upon running "mka recoveryimage":

Code:
$ mka recoveryimage
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=16.1.0
TARGET_PRODUCT=aosp_holi
TARGET_BUILD_VARIANT=eng
TARGET_BUILD_TYPE=release
TARGET_ARCH=arm64
TARGET_ARCH_VARIANT=armv8-2a
TARGET_CPU_VARIANT=cortex-a76
HOST_ARCH=x86_64
HOST_2ND_ARCH=x86
HOST_OS=linux
HOST_OS_EXTRA=Linux-5.13.0-0.rc6.45.vanilla.1.fc34.x86_64-x86_64-Fedora-34-(Workstation-Edition)
HOST_CROSS_OS=windows
HOST_CROSS_ARCH=x86
HOST_CROSS_2ND_ARCH=x86_64
HOST_BUILD_TYPE=release
BUILD_ID=RQ1A.210205.004
OUT_DIR=out
============================================
[ 99% 282/283] finishing build rules ...
FAILED:
In file included from build/make/core/main.mk:1327:
In file included from build/make/core/Makefile:5574:
vendor/twrp/build/tasks/kernel.mk:104: error: BOARD_KERNEL_IMAGE_NAME not defined..
02:31:30 ckati failed with: exit status 1

#### failed to build some targets (37 seconds) ####


I'm using https://github.com/minimal-manifest-twrp/platform_manifest_twrp_aosp, as my device comes stock with Android 11, so it seemed best to use an Android 11 recovery rather than one older than the device. Maybe I should use the omni-9.0 branch? But I don't know if that would work either without vendor blobs...

Any and all advice or help is appreciated.

Edit: that exact error may have been because I removed the prebuilt kernel without providing a new one.... So - any advice on adding rules to build a fresh kernel or prebuilt kernel for Android 11?

Edit: If I re-include the prebuilt kernel image, it compiles, but does not produce a recovery.img. Any advice or things I'm obviously missing in that repository right now?

Edit: I've gotten help from the TWRP Zulip (linked in readme of https://github.com/minimal-manifest-twrp/platform_manifest_twrp_aosp). No longer need assistance here.

What I had wrong was A) BOARD_USES_RECOVERY_AS_BOOT was set, which means it generates boot.img instead of recovery.img, and B) the base repo I used (https://github.com/TeamWin/android_device_oneplus_fajita) was pretty old. I'm now using https://github.com/theincognito-inc/android_device_oneplus_kebab instead.
 
Last edited:

HemanthJabalpuri

Senior Member
I just want to share my fixes here from the error I got.
Deceyption failed but boots to TWRP for Realme Narzo 20 RMX2193 Android 10 with following in recovery.log
Code:
I:File Based Encryption is present
fscrypt_initialize_systemwide_keys returned fail
fscrypt_initialize_systemwide_keys returned fail
fscrypt_initialize_systemwide_keys returned fail
I:Setting up '/data' as data/media emulated storage.
I have fixed it with below flag
Code:
PLATFORM_VERSION := 16.1.0
See this commit https://github.com/HemanthJabalpuri...mmit/93ae5bd11ab8328a6e458abb10d66a8902516808

Also many Mediatek devices have non standard decryption process, so we have to refer to more trees for working of decryption
Here are some of working decryption trees
- https://github.com/TeamWin/android_device_redmi_begonia
- https://github.com/Redmi-MT6768/omni_device_xiaomi_merlin
- https://github.com/HemanthJabalpuri/twrp_infinix_X687
- https://github.com/HemanthJabalpuri/twrp_realme_RMX2185
- https://github.com/ADeadTrousers/twrp_device_Unihertz_Atom_LXL
 
Last edited:
  • Like
Reactions: Aitra

HemanthJabalpuri

Senior Member
I am making TWRP for InnJoo Fire 4 Plus Android 7.0 using twrp-7.1 manifest. It boots fine but touch seems not working
I got below in dmesg
Code:
[    2.211679]  (0)[182:kworker/u16:5][mtk-tpd]: MediaTek touch panel driver init
[    2.214779]  (0)[182:kworker/u16:5]mtk-tpd: enter tpd_probe, 555
[    2.214901]  (0)[182:kworker/u16:5][mtk-tpd]: [tpd -1] mt_tpd_pinctrl+++++++++++++++++
[    2.215274]  (0)[182:kworker/u16:5][mtk-tpd]: [tpd-1] mt_tpd_pinctrl----------
[    2.215303]  (0)[182:kworker/u16:5]mtk-tpd: Focaltech FT5x0x I2C Touchscreen Driver...
[    2.215728]  (0)[182:kworker/u16:5]ft5x0x: probe of 0-0038 failed with error -1
[    2.215899]  (0)[182:kworker/u16:5]mtk-tpd: add error touch panel driver.
[    2.215987]  (0)[182:kworker/u16:5]<<GTP-INF>>[tpd_local_init:904] Device Tree get regulator!
[    2.216077]  (0)[182:kworker/u16:5]------------[ cut here ]------------
[    2.216112]  (0)[182:kworker/u16:5]WARNING: CPU: 0 PID: 182 at /home/builder2018/code/f620/ALPS-MP-N0.MP7-V1_AEON6755_66_N_INHOUSE/alps/kernel-3.18/fs/sysfs/dir.c:31 sysfs_warn_dup+0x64/0x84()
[    2.216131]  (0)[182:kworker/u16:5]sysfs: cannot create duplicate filename '/devices/platform/mt-pmic/regulator/regulator.6/soc:touch-vtouch'
[    2.216154] -(0)[182:kworker/u16:5]CPU: 0 PID: 182 Comm: kworker/u16:5 Tainted: G        W      3.18.35 #1
[    2.216170] -(0)[182:kworker/u16:5]Hardware name: MT6750T (DT)
[    2.216196] -(0)[182:kworker/u16:5]Workqueue: mtk-tpd tpd_init_work_callback
[    2.216221] -(0)[182:kworker/u16:5]Call trace:
[    2.216246] -(0)[182:kworker/u16:5][<ffffffc00008a914>] dump_backtrace+0x0/0x15c
[    2.216267] -(0)[182:kworker/u16:5][<ffffffc00008aa84>] show_stack+0x14/0x1c
[    2.216290] -(0)[182:kworker/u16:5][<ffffffc000b8611c>] dump_stack+0x80/0xa4
[    2.216313] -(0)[182:kworker/u16:5][<ffffffc0000a03d4>] warn_slowpath_fmt+0xb4/0xd8
[    2.216334] -(0)[182:kworker/u16:5][<ffffffc00022070c>] sysfs_warn_dup+0x64/0x84
[    2.216353] -(0)[182:kworker/u16:5][<ffffffc000220a1c>] sysfs_do_create_link_sd.isra.2+0xfc/0x104
[    2.216372] -(0)[182:kworker/u16:5][<ffffffc000220a60>] sysfs_create_link+0x20/0x3c
[    2.216393] -(0)[182:kworker/u16:5][<ffffffc0003533c4>] create_regulator+0xb8/0x25c
[    2.216411] -(0)[182:kworker/u16:5][<ffffffc0003536b4>] _regulator_get+0x14c/0x220
[    2.216431] -(0)[182:kworker/u16:5][<ffffffc00035442c>] regulator_get+0x14/0x1c
[    2.216454] -(0)[182:kworker/u16:5][<ffffffc00087afc8>] tpd_local_init+0x50/0x358
[    2.216473] -(0)[182:kworker/u16:5][<ffffffc00086cdb0>] tpd_probe+0x214/0x6d4
[    2.216496] -(0)[182:kworker/u16:5][<ffffffc000379140>] platform_drv_probe+0x4c/0xc4
[    2.216517] -(0)[182:kworker/u16:5][<ffffffc000377308>] really_probe+0x194/0x3b8
[    2.216538] -(0)[182:kworker/u16:5][<ffffffc0003778dc>] driver_probe_device+0x38/0x8c
[    2.216558] -(0)[182:kworker/u16:5][<ffffffc0003779cc>] __driver_attach+0x9c/0xa0
[    2.216579] -(0)[182:kworker/u16:5][<ffffffc000375928>] bus_for_each_dev+0x58/0x98
[    2.216599] -(0)[182:kworker/u16:5][<ffffffc000377aa0>] driver_attach+0x20/0x28
[    2.216619] -(0)[182:kworker/u16:5][<ffffffc000376160>] bus_add_driver+0x15c/0x234
[    2.216640] -(0)[182:kworker/u16:5][<ffffffc0003783f4>] driver_register+0x74/0x138
[    2.216659] -(0)[182:kworker/u16:5][<ffffffc000379dd8>] __platform_driver_register+0x60/0x68
[    2.216681] -(0)[182:kworker/u16:5][<ffffffc00086bfe8>] tpd_init_work_callback+0x24/0x40
[    2.216703] -(0)[182:kworker/u16:5][<ffffffc0000b87ac>] process_one_work+0x160/0x468
[    2.216723] -(0)[182:kworker/u16:5][<ffffffc0000b8bf4>] worker_thread+0x140/0x4e4
[    2.216745] -(0)[182:kworker/u16:5][<ffffffc0000be4c8>] kthread+0xd8/0xec
[    2.216761]  (0)[182:kworker/u16:5]---[ end trace 2156fff91f6f901f ]---
[    2.216779]  (0)[182:kworker/u16:5]vldo28: could not add device link soc:touch err -17
[    2.216808]  (0)[182:kworker/u16:5]vldo28: Failed to create debugfs directory
[    2.217092]  (0)[182:kworker/u16:5]<<GTP-INF>>[tpd_i2c_probe:531] tpd_i2c_probe start.
[    2.217122]  (0)[182:kworker/u16:5]gt1x: probe of 0-005d failed with error -1
[    2.217266]  (0)[182:kworker/u16:5]<<GTP-ERR>>[tpd_local_init:947] add error touch panel driver.
[    2.217348]  (0)[182:kworker/u16:5]mtk-tpd: [mtk-tpd]cap touch and Generic touch both are not loaded!!
Tree is at https://github.com/HemanthJabalpuri/twrp_innjoo_Fire4Plus
and kernel sources seems like at https://github.com/mtkkkk/mt6755_aeon6755_66_n_kernel
I am not sure that above are kernel sources but seems like it.
 
Last edited:

Aitra

Member
May 17, 2021
13
0
I just want to share my fixes here from the error I got.
Deceyption failed but boots to TWRP for Realme Narzo 20 RMX2193 Android 10 with following in recovery.log
Code:
I:File Based Encryption is present
fscrypt_initialize_systemwide_keys returned fail
fscrypt_initialize_systemwide_keys returned fail
fscrypt_initialize_systemwide_keys returned fail
I:Setting up '/data' as data/media emulated storage.
I have fixed it with below flag
Code:
PLATFORM_VERSION := 16.1.0
See this commit https://github.com/HemanthJabalpuri...mmit/93ae5bd11ab8328a6e458abb10d66a8902516808

Also many Mediatek devices have non standard decryption process, so we have to refer to more trees for working of decryption
Here are some of working decryption trees
- https://github.com/TeamWin/android_device_redmi_begonia
- https://github.com/Redmi-MT6768/omni_device_xiaomi_merlin
- https://github.com/HemanthJabalpuri/twrp_infinix_X687
- https://github.com/HemanthJabalpuri/twrp_realme_RMX2185
- https://github.com/ADeadTrousers/twrp_device_Unihertz_Atom_LXL
So what about MT6853 on Realme Q2 brother? Can it decode well? I very much hope there will be TWRP released on MT6853.
 

rohitrss

Member
Nov 27, 2013
35
5
Moto G
Xiaomi Redmi Note 7
The guide on 1st page still valid or there is an updated version somewhere in the thread? I am asking this because it says "Omni 9.0 is recommended for now unless your device has a super partition" but what if device is on Android 11 even in that case I should use android-9.0 branch or I should use android-11 branch only?
I want to port TWRP for Galaxy M40 with Android 11 installed.
Any tips/suggestions would be really appreciated as I am gonna do this for the first time.
 

tagcart

Member
Jul 9, 2016
12
2
I can't compile on AOSP Android 11. When I use the manifest of twrp-10 (android 10) all is ok, can compile just fine. I tried both manifests and both stopped working after compiling the manifest
Is the manifest still not complete, or am I missing something?

https://github.com/minimal-manifest-twrp/platform_manifest_twrp_aosp -b twrp-11
https://github.com/omnirom/android_bootable_recovery -b android-11
Device tree: https://github.com/itzmonvw124/xiaomi_twrp_device_camellia


Code:
============================================
ninja: no work to do.

#### build completed successfully (4 seconds) ####
I also was having this problem and found that you must add the BOARD_RECOVERYIMAGE_PARTITION_SIZE flag in your BoardConfig.mk.

I believe it is a new requirement in android 10 and up. I found the solution here: https://github.com/minimal-manifest-twrp/platform_manifest_twrp_aosp/issues/2#issuecomment-890281986

Here is how you calculate the value of BOARD_RECOVERYIMAGE_PARTITION_SIZE for your device. Obviously do not use the values in the example below:

Connect to your device with ADB shell

Code:
gts7lwifi:/ $ ls -l /dev/block/by-name/recovery
lrwxrwxrwx 1 root root 16 2019-04-12 05:57 /dev/block/by-name/recovery -> /dev/block/sda23
gts7lwifi:/ $ cat /proc/partitions | egrep 'sda23'           
259        7      84852 sda23
Then
84852*1024 = 86888448

Then set in BoardConfig.mk for your device:
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 86888448


With all that said, I was able to compile TWRP for Android 11 and get a recovery.img to output, but it didn't seem to work on my device (Galaxy Tab A7 Lite). After flashing with Odin, I just get a black screen when trying to enter recovery. Hopefully someone out there with more experience could shed some light!
 

Top Liked Posts

  • There are no posts matching your filters.
  • 407
    All of TWRP 3.x source is public. You can compile it on your own. This guide isn't going to be a step-by-step, word-for-word type of guide. If you're not familiar with basic Linux commands and/or building in AOSP then you probably won't be able to do this.

    You can currently use Omni 6.0, Omni 7.1, Omni 8.1, Omni 9.0, CM 13.0, CM 14.1, CM 15.1, LineageOS 16.0 source code. Omni 9.0 is recommended for now unless your device has a super partition.

    If you are using CM/LineageOS, you'll need to place TWRP in the LineageOS/bootable/recovery-twrp folder and set RECOVERY_VARIANT := twrp in your BoardConfig.mk file. TWRP source code can be found here:
    https://github.com/TeamWin/android_bootable_recovery (NOTE: The location for the latest TWRP source code has changed!)
    Select the newest branch available. This step is not necessary with Omni because Omni already includes TWRP source by default, however, if you are using an older version of Omni, you will probably want to pull from the latest branch (the latest branch will compile successfully in older build trees)

    If you are only interested in building TWRP, you may want to try working with a smaller tree. You can try using this manifest. It should work in most cases but there may be some situations where you will need more repos in your tree than this manifest provides:
    https://github.com/minimal-manifest-twrp

    *BEFORE YOU COMPILE*
    Note: If you add or change any flags, you will need to make clean or make clobber before recompiling or your flag changes will not be picked up.

    Now that you have the source code, you'll need to set or change a few build flags for your device(s). Find the BoardConfig.mk for your device. The BoardConfig.mk is in your devices/manufacturer/codename folder (e.g. devices/lge/hammerhead/BoardConfig.mk).

    Your board config will need to include architecture and platform settings. Usually these are already included if you're using device configs that someone else created, but if you created your own, you may need to add them. Without them, recovery may seg fault during startup and you'll just see the teamwin curtain flash on the screen over and over.

    We usually put all of our flags at the bottom of the BoardConfig.mk under a heading of #twrp For all devices you'll need to tell TWRP what theme to use. This TW_THEME flag replaces the older DEVICE_RESOLUTION flag. TWRP now uses scaling to stretch any theme to fit the screen resolution. There are currently 5 settings which are: portrait_hdpi, portrait_mdpi, landscape_hdpi, landscape_mdpi, and watch_mdpi. For portrait, you should probably select the hdpi theme for resolutions of 720x1280 and higher. For landscape devices, use the hdpi theme for 1280x720 or higher.
    TW_THEME := portrait_hdpi

    Note that themes do not rotate 90 degrees and there currently is no option to rotate a theme. If you find that the touchscreen is rotated relative to the screen, then you can use some flags (discussed later in this guide) to rotate the touch input to match the screen's orientation.

    In addition to the resolution, we have the following build flags:
    RECOVERY_SDCARD_ON_DATA := true -- this enables proper handling of /data/media on devices that have this folder for storage (most Honeycomb and devices that originally shipped with ICS like Galaxy Nexus) This flag is not required for these types of devices though. If you do not define this flag and also do not include any references to /sdcard, /internal_sd, /internal_sdcard, or /emmc in your fstab, then we will automatically assume that the device is using emulated storage.
    BOARD_HAS_NO_REAL_SDCARD := true -- disables things like sdcard partitioning and may save you some space if TWRP isn't fitting in your recovery patition
    TW_NO_BATT_PERCENT := true -- disables the display of the battery percentage for devices that don't support it properly
    TW_CUSTOM_POWER_BUTTON := 107 -- custom maps the power button for the lockscreen
    TW_NO_REBOOT_BOOTLOADER := true -- removes the reboot bootloader button from the reboot menu
    TW_NO_REBOOT_RECOVERY := true -- removes the reboot recovery button from the reboot menu
    RECOVERY_TOUCHSCREEN_SWAP_XY := true -- swaps the mapping of touches between the X and Y axis
    RECOVERY_TOUCHSCREEN_FLIP_Y := true -- flips y axis touchscreen values
    RECOVERY_TOUCHSCREEN_FLIP_X := true -- flips x axis touchscreen values

    TWRP_EVENT_LOGGING := true -- enables touch event logging to help debug touchscreen issues (don't leave this on for a release - it will fill up your logfile very quickly)
    BOARD_HAS_FLIPPED_SCREEN := true -- flips the screen upside down for screens that were mounted upside-down

    There are other build flags which you can locate by scanning the Android.mk files in the recovery source. Most of the other build flags are not often used and thus I won't document them all here.

    *RECOVERY.FSTAB*
    TWRP 2.5 and higher supports some new recovery.fstab features that you can use to extend TWRP's backup/restore capabilities. You do not have to add fstab flags as most partitions are handled automatically.

    Note that TWRP only supports v2 fstabs in version 3.2.0 and higher. You will still need to use the "old" format of fstab for older TWRP (example of that format is below), and even TWRP 3.2.0 still supports the v1 format in addition to the v2 format. To maximize TWRP's compatibility with your build tree, you can create a twrp.fstab and use PRODUCT_COPY_FILES to place the file in /etc/twrp.fstab When TWRP boots, if it finds a twrp.fstab in the ramdisk it will rename /etc/recovery.fstab to /etc/recovery.fstab.bak and then rename /etc/twrp.fstab to /etc/recovery.fstab. Effectively this will "replace" the fstab 2 file that your device files are providing with the TWRP fstab allowing you to maintain compatibility within your device files and with other recoveries.
    Code:
    PRODUCT_COPY_FILES += device/lge/hammerhead/twrp.fstab:recovery/root/etc/twrp.fstab

    The fstab in TWRP can contain some "flags" for each partition listed in the fstab.

    Here's a sample TWRP fstab for the Galaxy S4 that we will use for reference:
    Code:
    /boot       emmc        /dev/block/platform/msm_sdcc.1/by-name/boot
    /system     ext4        /dev/block/platform/msm_sdcc.1/by-name/system
    /data       ext4        /dev/block/platform/msm_sdcc.1/by-name/userdata length=-16384
    /cache      ext4        /dev/block/platform/msm_sdcc.1/by-name/cache
    /recovery   emmc        /dev/block/platform/msm_sdcc.1/by-name/recovery
    /efs        ext4        /dev/block/platform/msm_sdcc.1/by-name/efs                            flags=display="EFS";backup=1
    /external_sd     vfat       /dev/block/mmcblk1p1    /dev/block/mmcblk1   flags=display="Micro SDcard";storage;wipeingui;removable
    /usb-otg         vfat       /dev/block/sda1         /dev/block/sda       flags=display="USB-OTG";storage;wipeingui;removable
    /preload    ext4        /dev/block/platform/msm_sdcc.1/by-name/hidden                            flags=display="Preload";wipeingui;backup=1
    /modem      ext4        /dev/block/platform/msm_sdcc.1/by-name/apnhlos
    /mdm		emmc		/dev/block/platform/msm_sdcc.1/by-name/mdm

    Flags are added to the end of the partition listing in the fstab separated by white space (spaces or tabs are fine). The flags affect only that partition but not any of the others. Flags are separated by semicolons. If your display name is going to have a space, you must surround the display name with quotes.
    Code:
    /external_sd  vfat  /dev/block/mmcblk1p1  flags=display="Micro SDcard";storage;wipeingui;removable
    The flags for this partition give it a display name of "Micro SDcard" which is displayed to the user. wipeingui makes this partition available for wiping in the advanced wipe menu. The removable flag indicates that sometimes this partition may not be present preventing mounting errors from being displayed during startup. Here is a full list of flags:
    removable -- indicates that the partition may not be present preventing mounting errors from being displayed during boot
    storage -- indicates that the partition can be used as storage which makes the partition available as storage for backup, restore, zip installs, etc.
    settingsstorage -- only one partition should be set as settings storage, this partition is used as the location for storing TWRP's settings file
    canbewiped -- indicates that the partition can be wiped by the back-end system, but may not be listed in the GUI for wiping by the user
    userrmrf -- overrides the normal format type of wiping and only allows the partition to be wiped using the rm -rf command
    backup= -- must be succeeded by the equals sign, so backup=1 or backup=0, 1 indicates that the partition can be listed in the backup/restore list while 0 ensures that this partition will not show up in the backup list.
    wipeingui -- makes the partition show up in the GUI to allow the user to select it for wiping in the advanced wipe menu
    wipeduringfactoryreset -- the partition will be wiped during a factory reset
    ignoreblkid -- blkid is used to determine what file system is in use by TWRP, this flag will cause TWRP to skip/ignore the results of blkid and use the file system specified in the fstab only
    retainlayoutversion -- causes TWRP to retain the .layoutversion file in /data on devices like Sony Xperia S which sort of uses /data/media but still has a separate /sdcard partition
    symlink= -- causes TWRP to run an additional mount command when mounting the partition, generally used with /data/media to create /sdcard
    display= -- sets a display name for the partition for listing in the GUI
    storagename= -- sets a storage name for the partition for listing in the GUI storage list
    backupname= -- sets a backup name for the partition for listing in the GUI backup/restore list
    length= -- usually used to reserve empty space at the end of the /data partition for storing the decryption key when Android's full device encryption is present, not setting this may lead to the inability to encrypt the device
    canencryptbackup= -- 1 or 0 to enable/disable, makes TWRP encrypt the backup of this partition if the user chooses encryption (only applies to tar backups, not images)
    userdataencryptbackup= -- 1 or 0 to enable/disable, makes TWRP encrypt only the userdata portion of this partition, certain subfuldes like /data/app would not be encrypted to save time
    subpartitionof= -- must be succeeded by the equals sign and the path of the partition it is a subpartition of. A subpartition is treated as "part" of the main partition so for instance, TWRP automatically makes /datadata a subpartition of /data. This means that /datadata will not show up in the GUI listings, but /datadata would be wiped, backed up, restored, mounted, and unmounted anytime those operations are performed on /data. A good example of the use of subpartitions is the 3x efs partitions on the LG Optimus G:
    Code:
    /efs1         emmc   /dev/block/mmcblk0p12 flags=backup=1;display=EFS
    /efs2         emmc   /dev/block/mmcblk0p13 flags=backup=1;subpartitionof=/efs1
    /efs3         emmc   /dev/block/mmcblk0p14 flags=backup=1;subpartitionof=/efs1
    This lumps all 3 partitions into a single "EFS" entry in the TWRP GUI allowing all three to be backed up and restored together under a single entry.

    As of TWRP 3.2.0, TWRP now supports a version 2 fstab like those that have been found in Android devices for years. Yes, I know we're really slow to adopt this one, but I also saw no major advantage to v2 and the v2 fstab was being used in regular Android as well as recovery and I didn't want full ROM builds crashing or doing other weird things because of TWRP flags being present in the fstab. Version 2 fstab support is automatic. You don’t need to add any build flags. The regular version 1 fstab format is also still valid and it’s possible to use both v1 and v2 types in the same fstab. TWRP 3.2.0 also supports using wildcards via the asterisk in v1 format which can be useful for USB OTG and micro SD cards with multiple partitions. Note also that v2 fstab formats haven’t been extensively tested so developers should test their v2 fstabs before shipping to users (you should always be testing anyway!).

    This is a v1 fstab line with a wildcard intended for a USB OTG drive. All partitions should show up in the list of available storage devices when the user plugs in a drive:

    Code:
    /usb-otg  vfat   /dev/block/sda*  flags=removable;storage;display=USB-OTG

    This line is straight from the v2 fstab for the same device and also should work. In this case the kernel will notify us that new devices have been added or removed via uevents:

    Code:
    /devices/soc.0/f9200000.ssusb/f9200000.dwc3/xhci-hcd.0.auto/usb*    auto      auto    defaults      voldmanaged=usb:auto

    In addition to the v2 fstab, you can include /etc/twrp.flags which uses the v1 fstab format. The twrp.flags file can be used to supplement the v2 fstab with TWRP flags, additional partitions not included in the v2 fstab, and to override settings in the v2 fstab. For example, I have a Huawei device with the following stock v2 fstab present as /etc/recovery.fstab

    Code:
    # Android fstab file.
    #<src>                                                  <mnt_point>         <type>    <mnt_flags and options>                       <fs_mgr_flags>
    # The filesystem that contains the filesystem checker binary (typically /system) cannot
    # specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
    /dev/block/bootdevice/by-name/system    /system    ext4    ro,barrier=1    wait,verify
    /dev/block/bootdevice/by-name/cust    /cust    ext4    ro,barrier=1    wait,verify
    /devices/hi_mci.1/mmc_host/mmc1/*                       auto                auto      defaults                                      voldmanaged=sdcard:auto,noemulatedsd
    /devices/hisi-usb-otg/usb1/*                            auto                auto      defaults                                      voldmanaged=usbotg:auto
    /dev/block/bootdevice/by-name/userdata         /data                f2fs     nosuid,nodev,noatime,discard,inline_data,inline_xattr wait,forceencrypt=footer,check
    /dev/block/bootdevice/by-name/cache         /cache                ext4      rw,nosuid,nodev,noatime,data=ordered wait,check
    /dev/block/bootdevice/by-name/splash2         /splash2                ext4      rw,nosuid,nodev,noatime,data=ordered,context=u:object_r:splash2_data_file:s0 wait,check
    /dev/block/bootdevice/by-name/secure_storage         /sec_storage                ext4      rw,nosuid,nodev,noatime,discard,auto_da_alloc,mblk_io_submit,data=journal,context=u:object_r:teecd_data_file:s0 wait,check

    In addition I have also included this in /etc/twrp.flags:

    Code:
    /boot         emmc       /dev/block/platform/hi_mci.0/by-name/boot
    /recovery     emmc       /dev/block/platform/hi_mci.0/by-name/recovery   flags=backup=1
    /cust         ext4       /dev/block/platform/hi_mci.0/by-name/cust       flags=display="Cust";backup=1
    /misc         emmc       /dev/block/platform/hi_mci.0/by-name/misc
    /oeminfo      emmc       /dev/block/platform/hi_mci.0/by-name/oeminfo    flags=display="OEMinfo";backup=1
    /data         f2fs       /dev/block/dm-0
    /system_image emmc       /dev/block/platform/hi_mci.0/by-name/system

    The first 2 lines in twrp.flags adds the boot and recovery partitions which were not present at all in the v2 fstab. The /cust line in the twrp.flags file is added to tell TWRP to allow users to back up the cust partition and to give it a slightly better display name. The /misc partition is also only present in the twrp.flags file. Much like the /cust partition, the /oeminfo partition is in the twrp.flags file to tell TWRP to allow users to back it up and give a display name. The /data line is needed because this Huawei device, like many Huawei devices, is encrypted but the encryption uses some special Huawei binaries and is encrypted with some sort of default password that the user cannot change. We use the Huawei binaries to decrypt the device automatically in recovery. The /data line here tells TWRP to use /dev/block/dm-0 instead of /dev/block/bootdevice/by-name/userdata which is required for proper mounting, etc. Lastly we have the /system_image line so that TWRP will add a system image option for backup and restore.

    As we add more new devices, we’ll add more example device trees to https://github.com/TeamWin/ which should help you find more ways to use this new fstab support. Please note that using the v2 fstab format at this point is completely optional, so feel free to continue using v1 if that is what is more comfortable or if you have trouble with the v2 format support.

    If you have questions, feel free to stop by #twrp on Freenode. If you post here I may not see it for a while as I have lots of threads out there and there's no way for me to keep track of them all. If you successfully port TWRP to a new device, please let us know! We love to hear success stories!

    If you have code changes that you'd like to submit, please submit them through the Omni Gerrit server. Guide is here.

    Once you get Omni or CM sync'ed and your TWRP flags set, you should do a source ./build/envsetup.sh We usually lunch for the device in question, so something like "lunch omni_hammerhead-eng".

    After you lunch successfully for your device this is the command used for most devices:
    Code:
    make clean && make -j# recoveryimage

    Replace the # with the core count +1, so if you have a dual core it's -j3 and a quad core becomes -j5, etc. If you're dealing with a "typical" Samsung device, then you'll need to
    Code:
    make -j# bootimage
    Most Samsung devices have the recovery included as an extra ramdisk in the boot image instead of a separate recovery partition as found on most other devices.

    Old guide here: http://forum.xda-developers.com/showpost.php?p=65482905&postcount=1471
    120
    So, now, hopefully you've compiled TWRP for your device and gotten it working. Now, you'd like to know how to get TWRP officially supported for your device so that it can be installed automatically with the TWRP app. In order for us to add "official support" for your device we'll need the following:
    1) Device configuration files to compile TWRP from source for your device. This means that you cannot have repacked a recovery.img by hand to get it working. We need to be able to compile it from source so that we can easily release future updates.
    2) We'll build a copy of TWRP and send it to you for validation. Once you've validated that we can build a working image for your device, we'll add it to the official TWRP app.

    Note that we won't take credit for your port. You'll still get to post it on XDA to collect all the credit that goes with releasing something new for your device along with having your name listed on our website as the maintainer for the device. Also note that it's not always possible to provide automated installs for all devices.

    You can now boot TWRP in an emulator. If you're trying to help develop TWRP, this can be a huge help as you don't have to risk your device and you can do everything directly on your computer.
    jPYg.png


    Download this set of device configuration files.

    Compile a recoveryimage using those device files. In the Android SDK, click on Tools -> Manage AVDs. Click New. Set it up as the following:
    AVD Name: TWRP
    Device: Galaxy Nexus
    Target: ICS or newer though anything will probably work here
    CPU: ARM (armeabi-v7a)
    Check the box for hardware keyboard (your computer's keyboard will work in TWRP)
    Up to you if you want to have the skin with controls present
    Front Camera: None
    Back Camera: None
    RAM: 1024 VM Heap: 64
    Internal Storage: 200
    SD Card: Size: 500 MiB

    Then click OK.

    Once you have your AVD and your recoveryimage, you can boot TWRP in the emulator by browsing to your android-sdk/tools folder and run this command:
    ./emulator -avd TWRP -ramdisk CMFOLDER/out/target/product/twrp/ramdisk-recovery.img

    Note that ADB doesn't work right away. About 10 to 15 seconds after TWRP finishes booting, ADB will come online. We start ADB via init.rc so even if TWRP fails to boot due to some kind of code error that you may have made, ADB should still work. Enjoy!
    117
    TWRP and A/B devices:

    From a TWRP standpoint, A/B devices aren't a whole lot different from regular devices, but developers seem to be shy about working on these devices. I'm going to try to shed some light on this subject and hopefully this will serve as a guide for porting TWRP to A/B devices.

    Firstly, let's understand what is an A/B device and how it's different. A/B devices have duplicates of many partitions on the device. An A/B device has 2x system partitions, 2x boot partitions, 2x vendor partitions, 2x modem / firmware partitions, etc. Only one slot is in use at a time. During early boot, the first stages of the bootloader read some small amount of data called the BCB or Bootloader Control Block and decide whether to boot the A partitions or the B partitions. When an OTA update is available, the data from the active slot is copied from the inactive slot and patched / updated. For example, if you're currently on slot A, your device would download the update and copy the existing system partition from slot A and patch / update it with the new updates into slot B. Once the copying and updating is complete, the BCB is updated and the device reboots using slot B. Next time an update is available, the system partition in slot B is copied to slot A and updated, the BCB gets updated, and we reboot to slot A. When viewing partitions on the device, you'll see something like this:

    Code:
    /dev/block/bootdevice/by-name/boot_a
    /dev/block/bootdevice/by-name/boot_b
    /dev/block/bootdevice/by-name/system_a
    /dev/block/bootdevice/by-name/system_b
    /dev/block/bootdevice/by-name/userdata
    /dev/block/bootdevice/by-name/vendor_a
    /dev/block/bootdevice/by-name/vendor_b

    Note the dual boot, system and vendor partitions in the list above, but only one userdata partition.

    While there is technically no requirement that I am aware of, all A/B devices shipped thus far have no separate recovery partition. Instead, the boot image contains the recovery in its ramdisk. The important thing is knowing that the boot image now also contains the recovery. For completeness, the system partition is a full root file system. During boot, if the kernel is told to boot to recovery, it will extract the ramdisk in the boot partition. If the kernel is not told by the bootloader to boot to recovery, then the kernel will mount the appropriate system partition (A or B) because the system partition is a full root file system. This means that the system partition on these devices is mounted to / instead of to /system and the system partition contains all of the files that would have normally been in the boot image ramdisk and a /system subfolder.

    From a TWRP standpoint, there are 3 things that you have to do for an A/B device. First, you need to set
    Code:
    AB_OTA_UPDATER := true
    in your BoardConfig.mk. Secondly, for any partition that has an A/B option, you need to add
    Code:
    flags=slotselect
    in your fstab so something like this:
    Code:
    /boot		emmc	/dev/block/bootdevice/by-name/boot	flags=slotselect
    /system		ext4	/dev/block/bootdevice/by-name/system	flags=slotselect
    /system_image	emmc	/dev/block/bootdevice/by-name/system	flags=slotselect
    /vendor		ext4	/dev/block/bootdevice/by-name/vendor	flags=slotselect;display="Vendor";backup=1
    /vendor_image	emmc	/dev/block/bootdevice/by-name/vendor	flags=slotselect

    Lastly, once you get into TWRP, you will probably want to make sure that bootctl hal-info responds correctly with no errors. Usually the bootctl binary requires a proprietary library or even a couple of services to work correctly. If bootctl does not work correctly, then you will not be able to switch slots within TWRP correctly either.

    In addition to setting
    Code:
    AB_OTA_UPDATER := true
    you may also want to set:
    Code:
    BOARD_USES_RECOVERY_AS_BOOT := true
    BOARD_BUILD_SYSTEM_ROOT_IMAGE := true

    If you set
    Code:
    BOARD_USES_RECOVERY_AS_BOOT := true
    then make recoveryimage will no longer work and instead you will have to make bootimage. I don't recommend setting either of these flags for TWRP-only build trees. These flags will probably be required for developers building full ROMs for A/B devices.

    Installing / Flashing TWRP on A/B devices:

    Since all known A/B devices do not have a separate recovery partition, you will eventually have to flash TWRP to the boot partition. On the Pixel 1 and 2, we use fastboot boot to temporarily boot TWRP without flashing TWRP. We are then supplying a zip to allow users to flash TWRP to both slots. You can download one of these zips from our website and update the zip as needed to support your devices. Eventually we will add tools to TWRP to allow users to flash recoveries on these devices without needing to use zips.

    Recently, I worked on the Razer Phone. The Razer Phone unfortunately does not support fastboot boot. Instead, users have to determine their currently active boot slot using
    Code:
    adb shell getprop ro.boot.slot_suffix
    then use
    Code:
    fastboot --set-active=_a
    to switch slots to the inactive slot. From here, the user can
    Code:
    fastboot flash boot twrp.img && fastboot reboot
    to get into TWRP. Once in TWRP they can then go to the reboot page and change back to their originally active slot, make a backup, then install TWRP. Using the inactive slot allows users to get a good, unmodified backup of their device before installing TWRP.

    Hopefully this helps!

    Debugging with gdb in TWRP guide can be found here!
    19
    gdb in TWRP

    gdb in TWRP

    To make things quick and easy, the TLDR version is to create a script with the below code. After booting up TWRP, from the same terminal where you have done your source ./build/envsetup.sh and lunch commands, run this script:
    Code:
    if [ ! -f $OUT/system/bin/gdbserver64 ]; then
        echo Building gdbserver64
        make -j8 gdbserver64
    fi
    adb shell stop recovery
    adb push $OUT/system/bin/gdbserver /sbin/
    adb shell chmod 755 /sbin/gdbserver
    adb forward tcp:5039 tcp:5039
    cp $OUT/symbols/recovery/root/sbin/recovery $OUT/symbols/sbin/recovery
    adb push $OUT/symbols/sbin/recovery /sbin/recovery && adb shell chmod 755 /sbin/recovery
    cp $OUT/symbols/system/bin/linker64 $OUT/symbols/sbin/linker64
    cp $OUT/symbols/system/lib64/* $OUT/symbols/sbin
    if [ "$#" = 1 ]; then
    	adb push $OUT/symbols/sbin/$1 /sbin/
    fi
    echo In another terminal run:
    echo gdbclient pid_goes_here
    adb shell gdbserver :5039 /sbin/recovery
    Then in another terminal you will need to source ./build/envsetup.sh and lunch again then run gdbclient pid_goes_here

    THE LONG VERSION:

    This guide was using an Omni 8.1 build tree and the target device was the Razer Phone 2. Since the target device was using aarch64, paths and files may be using “64” in them. If your device is using 32 bit, you can remove 64 from the paths and filenames where needed. You must be able to compile TWRP from source and have some basic knowledge of Linux. Your device must have working adb while in TWRP. The basis for this guide came from the following sites, but reading these sites should not be necessary:
    https://source.android.com/devices/tech/debug/gdb
    https://packmad.github.io/gdb-android/
    https://wladimir-tm4pda.github.io/porting/debugging_gdb.html

    Compile your TWRP image as usual with
    Code:
    make recoveryimage
    and then boot up TWRP. If TWRP is crashing during startup, you may want to
    Code:
    adb shell stop recovery
    so that the recovery service stops and you end the crash loop. This guide assumes that you want to debug TWRP while TWRP starts up.

    The compiled recovery image contains many binaries and libraries that have been stripped of their debugging symbols. The stripped binaries are smaller, but gdb will need access to the unstripped binaries and libraries to assist with debugging. gdb expects to find these binaries and libraries in the same relative path as they are on the device. Unfortunately, in order to get TWRP to work with the linker while in recovery, the build process of TWRP moves binaries and libraries into places that they normally aren’t located (see bootable/recovery/prebuilt/Android.mk if you want a better understanding). You will have to move the unstripped binaries and libraries around a bit to make gdb happy.

    First you will need gdbserver64 which you can compile using
    Code:
    make gdbserver64
    Once gdbserver64 is compiled you must push it to the device with
    Code:
    adb push $OUT/system/bin/gdbserver64 /sbin
    followed by
    Code:
    adb shell chmod 755 /sbin/gdbserver64
    You may also need to issue this command, but I’m not sure if it is required:
    Code:
    adb forward tcp:5039 tcp:5039
    Finally open a new terminal and issue
    Code:
    adb shell gdbserver64 :5039 /sbin/recovery
    You will need to make note of the number at the end of the first line of the output:
    Code:
    Process /sbin/recovery created; pid = [COLOR="Green"]575[/COLOR]

    The first problem that I ran into was that the device uses ro.hardware of qcom and for some reason, the gdbclient expected the symbols files to be in out/target/product/qcom/symbols. If you run into this issue, you’ll have to manually change ro.hardware to match the codename of the device which may require you to change the kernel cmdline. The other option is to simply create the out/target/product/qcom/symbols directory yourself and
    Code:
    cp -R $OUT/symbols $OUT/../qcom/symbols
    I suppose a third option would be to modify the gdbclient code to look in the right place for the symbols, but I didn’t attempt this yet.

    From here you still need to move more things around. Specifically you will need to move symbols/recovery/root/sbin/recovery to symbols/sbin/recovery. Then for the shared libraries, you’ll need to copy everything in symbols/system/lib64 to symbols/sbin. Finally, you’ll need to copy symbols/system/bin/linker64 into symbols/sbin as well.

    In addition, you need to push the unstripped recovery binary to the device so that gdb can match up the symbols with functions and line numbers in the TWRP code:
    Code:
    adb push $OUT/symbols/sbin/recovery /sbin/recovery && adb shell chmod 755 /sbin/recovery

    If you are working on a shared library, you'll also want to push the unstripped library:
    Code:
    adb push $OUT/symbols/sbin/libfoo.so /sbin/libfoo.so

    Now that you have everything where you need it, you can run the gdbclient command from the original terminal where you were issuing your make commands:
    Code:
    gdbclient 575
    where 575 is the pid from your other terminal. You should see some output like this:

    Code:
    It looks like gdbserver is already attached to 575 (process is traced), trying to connect to it using local port=5039
    GNU gdb (GDB) 7.11
    Copyright (C) 2016 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "x86_64-linux-gnu".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>.
    Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.
    For help, type "help".
    Type "apropos word" to search for commands related to "word"...
    Reading symbols from /home/dees_troy/build/oomni/out/target/product/qcom/symbols/sbin/recovery...done.
    __dl__start () at bionic/linker/arch/arm64/begin.S:32
    32	  mov x0, sp
    (gdb)

    At which point you are at the (gdb) prompt. You can type
    Code:
    continue
    and hit enter to have TWRP continue to load. Once TWRP crashes, you can type
    Code:
    bt
    and hit enter to get the backtrace which should give you a better idea of where things went wrong. Type
    Code:
    quit
    and hit enter to exit the debugging session.

    Hope that helps!
    19
    Old guide which might be useful if someone is building with an older version:

    All of TWRP 2.x source is public. You can compile it on your own. This guide isn't going to be a step-by-step, word-for-word type of guide. If you're not familiar with basic Linux commands and/or building in AOSP then you probably won't be able to do this.

    You can currently use Omni 4.3, Omni 4.4, Omni 5.0, CM10.0, CM10.1, CM10.2, and CM11.0 source code. Omni 4.4 or 5.0 is recommended. Lately CM keeps making changes that make building TWRP more difficult and they make no effort to work with TWRP. You can build in CM but you may run into a few minor issues. If you don't know how to fix make file issues, then you should choose to use Omni instead. (If for some reason you need to compile in an older tree like CM9 or CM7, you will have to use the android-4.4 branch which we will not continue to update.)

    If you are using CM, you'll need to replace CM/bootable/recovery with this:
    https://github.com/omnirom/android_bootable_recovery
    Select the newest branch available. This step is not necessary with Omni because Omni already includes TWRP source by default.
    If you are using CM 12.0 then you will probably want to cherry pick this patch into external/sepolicy: http://review.cyanogenmod.org/#/c/89474/

    If you are in a bind and want to try working with a smaller tree either due to disk space or download size, you can try using this manifest. It should work in most cases but there may be some situations where you will need more repos in your tree than this manifest provides:
    https://github.com/marduk191/recovery_manifest

    *BEFORE YOU COMPILE*
    Note: If you add or change any flags, you will need to make clean or make clobber before recompiling or your flag changes will not be picked up.

    Now that you have the source code, you'll need to set or change a few build flags for your device(s). Find the BoardConfig.mk for your device. The BoardConfig.mk is in your devices/manufacturer/codename folder (e.g. devices/lge/hammerhead/BoardConfig.mk). First, scan the BoardConfig.mk file for
    TARGET_RECOVERY_INITRC :=
    If your device has this line, it will have a path to a custom, prebuilt init.rc that is used in recovery. Most likely you will need to change the custom init.rc slightly. Find the recovery's init.rc file and open it. Near the top you will see something like this:
    Code:
    on init
    	export PATH /sbin
    	export LD_LIBRARY_PATH .:/sbin
    Add the last line needed. This line is needed to get the linker running. Unlike ClockworkMod, TWRP is a dynamically linked recovery. Dynamic linking allows us to save a considerable amount of space to help make sure that TWRP recovery images will fit on more devices. It also lets us use dynamically linked touchscreen binaries as seen on the Motorola Photon and Atrix and the HP TouchPad without having to mount /system.

    Your board config also needs to include architecture and platform settings. Usually these are already included if you're using device configs that someone else created, but if you created your own, you may need to add them. Without them, recovery may seg fault during startup and you'll just see the teamwin curtain flash on the screen over and over.

    We usually put all of our flags at the bottom of the BoardConfig.mk under a heading of #twrp For all devices you'll need to set a resolution. TWRP needs to know the resolution at compile time so that it knows what stock theme to include. You can only use resolutions that have a theme so if you don't see your resolution, you'll have to pick one that's less than or equal to your resolution. You can find the list of stock themes in bootable/recovery/gui/devices. So if your device has a 540x960 display, you would add this:
    DEVICE_RESOLUTION := 540x960

    Note that themes do not rotate, so the 1280x800 theme is intended for tablets and would not work on the Samsung Galaxy Note 1 that expects a 800x1280 type of theme.

    In addition to the resolution, we have the following build flags:
    RECOVERY_SDCARD_ON_DATA := true -- this enables proper handling of /data/media on devices that have this folder for storage (most Honeycomb and devices that originally shipped with ICS like Galaxy Nexus)
    RECOVERY_GRAPHICS_USE_LINELENGTH := true -- fixes slanty looking graphics on some devices
    BOARD_HAS_NO_REAL_SDCARD := true -- disables things like sdcard partitioning and may save you some space if TWRP isn't fitting in your recovery patition
    TW_INCLUDE_DUMLOCK := true -- includes HTC Dumlock for devices that need it
    TW_NO_BATT_PERCENT := true -- disables the display of the battery percentage for devices that don't support it properly
    TW_CUSTOM_POWER_BUTTON := 107 -- custom maps the power button for the lockscreen
    TW_NO_REBOOT_BOOTLOADER := true -- removes the reboot bootloader button from the reboot menu
    TW_NO_REBOOT_RECOVERY := true -- removes the reboot recovery button from the reboot menu
    TW_NO_USB_STORAGE := true -- removes the USB storage button on devices that don't support USB storage
    RECOVERY_TOUCHSCREEN_SWAP_XY := true -- swaps the mapping of touches between the X and Y axis
    RECOVERY_TOUCHSCREEN_FLIP_Y := true -- flips y axis touchscreen values
    RECOVERY_TOUCHSCREEN_FLIP_X := true -- flips x axis touchscreen values
    TW_ALWAYS_RMRF := true -- forces the rm -rf option to always be on (needed for some Motorola devices)
    TW_NEVER_UNMOUNT_SYSTEM := true -- never unmount system (needed for some Motorola devices)
    TW_INCLUDE_INJECTTWRP := true -- adds ability to inject TWRP into some Samsung boot images for Samsung devices that have recovery as a second ramdisk in the boot image
    TW_DEFAULT_EXTERNAL_STORAGE := true -- defaults to external storage instead of internal on dual storage devices (largely deprecated)
    TWRP_EVENT_LOGGING := true -- enables touch event logging to help debug touchscreen issues (don't leave this on for a release - it will fill up your logfile very quickly)

    Here's some flags that may help you, but are not specific to TWRP (works in CWM too):
    This flag has multiple options, but can be used to set different graphics modes that may be need to correct color space issues on some devices:
    TARGET_RECOVERY_PIXEL_FORMAT := "BGRA_8888"
    TARGET_RECOVERY_PIXEL_FORMAT := "RGBX_8888"
    TARGET_RECOVERY_PIXEL_FORMAT := "RGB_565"

    BOARD_HAS_FLIPPED_SCREEN := true -- flips the screen upside down for screens that were mounted upside-down
    TARGET_PREBUILT_RECOVERY_KERNEL := path/to/kernel -- use to specify a kernel specifically for building recovery

    *RECOVERY.FSTAB*
    TWRP 2.5 and higher supports some new recovery.fstab features that you can use to extend TWRP's backup/restore capabilities. You do not have to add fstab flags as most partitions are handled automatically.

    Note that TWRP does not currently support the "fstab 2" version of fstab files seen in 4.3 or higher. You will still need to use the "old" format of fstab for TWRP (example of that format is below). To maximize TWRP's compatibility with your build tree, you can create a twrp.fstab and use PRODUCT_COPY_FILES to place the file in /etc/twrp.fstab When TWRP boots, if it finds a twrp.fstab in the ramdisk it will rename /etc/recovery.fstab to /etc/recovery.fstab.bak and then rename /etc/twrp.fstab to /etc/recovery.fstab. Effectively this will "replace" the fstab 2 file that your device files are providing with the TWRP fstab allowing you to maintain compatibility within your device files and with other recoveries.
    Code:
    PRODUCT_COPY_FILES += device/lge/hammerhead/twrp.fstab:recovery/root/etc/twrp.fstab

    The fstab in TWRP can contain some "flags" for each partition listed in the fstab.

    Here's a sample TWRP fstab for the Galaxy S4 that we will use for reference:
    Code:
    /boot       emmc        /dev/block/platform/msm_sdcc.1/by-name/boot
    /system     ext4        /dev/block/platform/msm_sdcc.1/by-name/system
    /data       ext4        /dev/block/platform/msm_sdcc.1/by-name/userdata length=-16384
    /cache      ext4        /dev/block/platform/msm_sdcc.1/by-name/cache
    /recovery   emmc        /dev/block/platform/msm_sdcc.1/by-name/recovery
    /efs        ext4        /dev/block/platform/msm_sdcc.1/by-name/efs                            flags=display="EFS";backup=1
    /external_sd     vfat       /dev/block/mmcblk1p1    /dev/block/mmcblk1   flags=display="Micro SDcard";storage;wipeingui;removable
    /usb-otg         vfat       /dev/block/sda1         /dev/block/sda       flags=display="USB-OTG";storage;wipeingui;removable
    /preload    ext4        /dev/block/platform/msm_sdcc.1/by-name/hidden                            flags=display="Preload";wipeingui;backup=1
    /modem      ext4        /dev/block/platform/msm_sdcc.1/by-name/apnhlos
    /mdm		emmc		/dev/block/platform/msm_sdcc.1/by-name/mdm

    Flags are added to the end of the partition listing in the fstab separated by white space (spaces or tabs are fine). The flags affect only that partition but not any of the others. Flags are separated by semicolons. If your display name is going to have a space, you must surround the display name with quotes.
    Code:
    /external_sd  vfat  /dev/block/mmcblk1p1  flags=display="Micro SDcard";storage;wipeingui;removable
    The flags for this partition give it a display name of "Micro SDcard" which is displayed to the user. wipeingui makes this partition available for wiping in the advanced wipe menu. The removable flag indicates that sometimes this partition may not be present preventing mounting errors from being displayed during startup. Here is a full list of flags:
    removable -- indicates that the partition may not be present preventing mounting errors from being displayed during boot
    storage -- indicates that the partition can be used as storage which makes the partition available as storage for backup, restore, zip installs, etc.
    settingsstorage -- only one partition should be set as settings storage, this partition is used as the location for storing TWRP's settings file
    canbewiped -- indicates that the partition can be wiped by the back-end system, but may not be listed in the GUI for wiping by the user
    userrmrf -- overrides the normal format type of wiping and only allows the partition to be wiped using the rm -rf command
    backup= -- must be succeeded by the equals sign, so backup=1 or backup=0, 1 indicates that the partition can be listed in the backup/restore list while 0 ensures that this partition will not show up in the backup list.
    wipeingui -- makes the partition show up in the GUI to allow the user to select it for wiping in the advanced wipe menu
    wipeduringfactoryreset -- the partition will be wiped during a factory reset
    ignoreblkid -- blkid is used to determine what file system is in use by TWRP, this flag will cause TWRP to skip/ignore the results of blkid and use the file system specified in the fstab only
    retainlayoutversion -- causes TWRP to retain the .layoutversion file in /data on devices like Sony Xperia S which sort of uses /data/media but still has a separate /sdcard partition
    symlink= -- causes TWRP to run an additional mount command when mounting the partition, generally used with /data/media to create /sdcard
    display= -- sets a display name for the partition for listing in the GUI
    storagename= -- sets a storage name for the partition for listing in the GUI storage list
    backupname= -- sets a backup name for the partition for listing in the GUI backup/restore list
    length= -- usually used to reserve empty space at the end of the /data partition for storing the decryption key when Android's full device encryption is present, not setting this may lead to the inability to encrypt the device
    canencryptbackup= -- 1 or 0 to enable/disable, makes TWRP encrypt the backup of this partition if the user chooses encryption (only applies to tar backups, not images)
    userdataencryptbackup= -- 1 or 0 to enable/disable, makes TWRP encrypt only the userdata portion of this partition, certain subfuldes like /data/app would not be encrypted to save time
    subpartitionof= -- must be succeeded by the equals sign and the path of the partition it is a subpartition of. A subpartition is treated as "part" of the main partition so for instance, TWRP automatically makes /datadata a subpartition of /data. This means that /datadata will not show up in the GUI listings, but /datadata would be wiped, backed up, restored, mounted, and unmounted anytime those operations are performed on /data. A good example of the use of subpartitions is the 3x efs partitions on the LG Optimus G:
    Code:
    /efs1         emmc   /dev/block/mmcblk0p12 flags=backup=1;display=EFS
    /efs2         emmc   /dev/block/mmcblk0p13 flags=backup=1;subpartitionof=/efs1
    /efs3         emmc   /dev/block/mmcblk0p14 flags=backup=1;subpartitionof=/efs1
    This lumps all 3 partitions into a single "EFS" entry in the TWRP GUI allowing all three to be backed up and restored together under a single entry.

    If you have questions, feel free to stop by #twrp on Freenode. If you post here I may not see it for a while as I have lots of threads out there and there's no way for me to keep track of them all. If you successfully port TWRP to a new device, please let us know! We love to hear success stories!

    If you have code changes that you'd like to submit, please submit them through the Omni Gerrit server. Guide is here.

    Once you get Omni or CM sync'ed and your TWRP flags set, you should do a source ./build/envsetup.sh We usually lunch for the device in question, so something like "lunch omni_hammerhead-eng".

    After you lunch successfully for your device this is the command used for most devices:
    Code:
    make clean && make -j# recoveryimage

    Replace the # with the core count +1, so if you have a dual core it's -j3 and a quad core becomes -j5, etc. If you're dealing with a "typical" Samsung device, then you'll need to
    Code:
    make -j# bootimage
    Most Samsung devices have the recovery included as an extra ramdisk in the boot image instead of a separate recovery partition as found on most other devices.

    Notes about 4.4 Kit Kat ROMs and SELinux
    There's absolutely no SELinux support in ICS trees or older. libselinux is not included in these trees and some dependencies for libselinux don't exist elsewhere in these older trees so there's no way to get SELinux support unless you move to a newer tree. I recommend using a 4.3 based tree or higher.

    SELinux support is included in all builds of TWRP so long as you build in a tree that has libselinux present. However, for SELinux support to work, your kernel must support EXT4 security labels as well. If you're using an older kernel, your TWRP won't support SELinux and you will get errors when installing 4.4 Kit Kat ROMs due to set_metadata not being able to set SELinux contexts. You'll see an error in the recovery log stating something along the lines of "Operation not supported on transport endpoint." This means you need to add proper support to the kernel you are using in recovery. (Yes, at least in most cases, recovery has its own kernel.)

    In the kernel source I was testing, the needed flag was CONFIG_EXT4_FS_SECURITY=y and the option was called Ext4 Security Labels under the file systems menu. If you want full SELinux in your kernel you will need to add auditing support (usually found under general setup) then enable SELinux under security options. There's multiple flags and some dependencies involved so your setup may vary slightly.

    The android-4.4 branch of TWRP from Omni now includes a check during boot. You will see text in the log and in the console indicating the SELinux status. This should help you identify what issue(s) you may have with SELinux support.

    Deprecated build flags:
    For TWRP < 2.5:
    The below is how you can add custom / special partitions to the list of partitions available for backup. The SP1_NAME must match the name of a partition defined in recovery.fstab. The SP1_DISPLAY_NAME is the name displayed on the backup page if it needs to be different than SP1_NAME. SP1_BACKUP_METHOD defines how the partition should be backed up (files or image). And SP1_MOUNTABLE determines if the partition can be mounted.
    SP1_NAME := "pds"
    SP1_BACKUP_METHOD := files
    SP1_MOUNTABLE := 1
    SP2_NAME := "osh"
    SP2_DISPLAY_NAME := "Webtop"
    SP2_BACKUP_METHOD := files
    SP2_MOUNTABLE := 1
    SP3_NAME := "preinstall"
    SP3_BACKUP_METHOD := image
    SP3_MOUNTABLE := 0