[RECOVERY] (Un-)tethered TWRP 2.8.7.0 for Asus ZenFone 2 (x86)

[TheSSJ]

Hi folks,

finally we compiled a(n un-)tethered TWRP package for our ZenFone 2 (confirmed on ZE551ML and ZE500ML)!

!!! NOTE: If you want to apply a new OTA update, please flash stock recovery first !!!

Also, if you encounter any errors with the official recovery by TeamWin, please don't ask for support here as this is an unofficial build (done with the hard work of many people collaborating in a great manner!)
​

If you don't want to unlock your Bootloader, you can use the tethered recovery.

Tethered (=after a reboot everything is back to normal)​

Features:
- Compiled with CM12 sources (although CM12 and TWRP are not liking each other very much :silly: )
- Optimized for x86 (smooth UI now)
- internal and external storages are mounted correctly
- Backup of boot, system, cache and data possible
- Full Crypto and SELINUX support

Bugs:
- Sometimes Backup and Restore hang. Fortunately it doesn't begin these operations so you don't brick your device (any hints on this are welcome!)
- USB Storage mount doesn't appear to work at all (pretty sure I took the correct path to the LUN file)

How to use:
- Download the tethered CWM package from here (method 2): http://forum.xda-developers.com/zenfone2/general/root-newbie-root-instructions-zenfone-2-t3114063
- replace the recovery.zip in "CWM_Zenfone_2_IntelFB_RecoveryLauncher" with the one you can find in the download section
- start the procedure by using cai_dat_CWM.bat
- type ACCEPT (case sensitive!) and enter
- type T4 and enter
- Set your timezone when booting the first time into the Recovery, maybe this fixes the backup and restore bug (needs to be done just once)
- Unplug your USB cable from the device, too, before flashing, backing up and/or restoring

Untethered (=permanent recovery)​

Features:
- Compiled with CM12 sources
- Optimized for x86 (smooth UI now)
- internal and external storages are mounted correctly
- Backup of boot, system, cache and data possible
- Full Crypto and SELINUX support
- kernel compiled dynamically (thanks to @crpalmer and @jrior001 and all involved for their fantastic work) with permissive Selinux
- USB-OTG support added (Beta supports NTFS file systems)
- Splashscreen can be backed up (to fiddle around and create your own)
- img files flashable now via recovery (thanks to @cangcan, @yakub234go and @vampirefo)
- F2FS support on kernel side

Drawbacks:
- MTP doesn't work

How to use:

Method 1
Get root rights
Unlock your bootloader
Download twrp.img from the download section and put on sd card (or pick the beta version for NTFS support)
Fire up adb or install a terminal emulator and type:

su
dd if=/sdcard/twrp.img of=/dev/block/by-name/recovery 
reboot recovery

Method 2
Download twrp.img from the download section and put in your adb/fastboot directory
Unlock your bootloader
Boot into bootloader (turn off, keep Vol+ pressed and press the power button until it vibrates - then release ONLY the power button and keep volume up pressed until you see the fastboot GUI
Open up fastboot on your PC and type:

fastboot flash recovery twrp.img

Then press vol down 2 times until "Reboot recovery" shows up and press power 1 time to boot into recovery

Method 3 (if you have an older version of TWRP already installed)
Place img on your internal sdcard, then reboot to recovery, click install zip, then select "Images..." in bottom right, then you see the img. Tick "Recovery" afterwards and then on OK.

Download folder:
Google Drive

Cheers!

Credits

@social-design-concepts for the great tethering method and the brilliant support and guidance :good:
@vampirefo also his support and guidance :good:
@updateing for the link to the commit for x86 pixelflinger
@jrior001 and @crpalmer for the great work on the kernel source
etc. etc.

Special thanks:
@Drew442 Thanks for the contribution!
Amir J. - thank you too!

TeamWin for their great recovery

XDA:DevDB Information
[RECOVERY][LOLLIPOP ONLY] (Un-)tethered TWRP 2.8.7.0 for Asus ZenFone 2 (x86), Tool/Utility for the Asus ZenFone 2

Contributors
TheSSJ, social-design-concepts, vampirefo, updateing, crpalmer, jrior001, knoneNull, etc etc
Source Code: https://github.com/TheSSJ/device_asus_zenfone2


Version Information
Status: Stable
Current Stable Version: 21_f2fs
Stable Release Date: 2015-07-02

Created 2015-06-04
Last Updated 2016-09-24

 

[TheSSJ]

Update 07-02-2015
ADB sideload works now (thanks @jrior001 & @crpalmer)! Make sure to download the latest ADB version: http://forum.xda-developers.com/showthread.php?p=42407269, credits for this to @shimp208

Update 06-30-2015
NTFS Support tested extensively and proved to be stable (not elegant, but functional)
Added recovery partition back to recovery.fstab to make it flashable via recovery itself

Update 06-28-2015
Moved to stable state
Added Beta version for NTFS support (twrp_ntfs.img)

Update 06-23-2015b
Upgraded source to TWRP 2.8.7.0

Update 06-23-2015
Functional TWRP with fast wipe/restore (-DNO_SECURE_DISCARD, thanks crpalmer)
ADB works
Just have fun in fiddleing around with the recovery
If no bugs will be reported we can declare this recovery stable

Update 06-10-2015
Boardconfig parameters changed, seems to back up, restore and flash even with USB cable attached

Update 06-04-2015b
Rolled back to 2.8.5.0 as restoring threw out the error that system was not being able to mount rw
Everything works now!

Update 06-04-2015
Built a version optimized for x86, fixes UI lags
Added Crypto Support again

Update 06-02-2015b
Removed TW_INCLUDE_CRYPTO flag as it caused backup operation to freeze

Update 06-02-2015
Moved to Beta stage
Fixed mounting of external SD

Update 06-01-2015
Completely reworked BoardConfig.mk
Removed all modules
Added @vampirefo 's adbd and adbd-recovery binaries from his TWRP builds (dunno why, but there aren't any binaries in my builds?) - thanks!
Graphics work now (still slow, need to fine tune with the correct boardconfig flags), no double backups, no flickering!

Update 05-31-2015
Included USES_ION flag into boardconfig.mk
Removed cpu temperature to reduce redraws

a little more stable now!

 

[Pilz]

Nice I can't wait for the BL to be fully unlocked so we van get native TWRP.

 

[jejemc]

Hello recovery or rest and it just temporary? thank you

 

[TheSSJ]

Hello recovery or rest and it just temporary? thank you

Hi,

yes, after rebooting no trace of TWRP is left
I have updated the zip now. It is a little stabler after I removed the CPU temperature, but still I have the feeling there are 2 GUIs sharing the same screen. Weird - I have to do more research - maybe I have to write my own UI updater...

Cheers

 

[cjvzla]

the gears are slowly moving! i hope BL gets unlocked by the time my ZF2 arrives..

is this for any ZF2 variant or just 551ML (4gb ram/2gb ram versions)?

thanks for taking the time with this (hopefully) awesome device!

 

[backdown]

This is awesome..thanks for your contribution! I am hoping for some custom roms..the stock ZenUI isn't the greatest :/

 

[crpalmer]

Hi folks,

I managed to compile a tethered TWRP package for our ZenFone 2!

Do you have a link to your device repo?

Are there specific instructions for using it to build a tethered recovery (I'm familiar with building twrp, including within CM, but I haven't looked much into what the tethered exploit does to boot the recovery).

 

[sunshine333]

It seems I have successfully completed a Backup! As mentioned, the interface is painfully slow at times, but this is serious progress. Has anybody tried restoring a backup yet?

 

[joel george alex]

Could you please develop twrp or cwm for asus 450cg

 

[29y6145]

NOTE:
1 backup successfully
2 Use Very lag
3 flash zip not work

 

[TheSSJ]

Do you have a link to your device repo?

Are there specific instructions for using it to build a tethered recovery (I'm familiar with building twrp, including within CM, but I haven't looked much into what the tethered exploit does to boot the recovery).

Hi,

unfortunately I don't have any. Basically I wrote a BoardConfig.mk based on the data provided by the Nexus Player (Asus Fugu, which is also Intel based). Then I took 2 modules (one for the display and one for the support of exfat partitions) and compiled a normal TWRP. The output folder holds the compiled img as well as the ramdisk in a simple folder. I put the ramdisk content into a simple zip file and included an update-script to have it unpacked properly. What the recovery-trigger exactly does is not clear to me. It seems it temporarily overwrites the logcat binary with itself and then gets executed at a reboot directly. The recovery trigger just unpacks the zip and executes the recovery binary if I understood correctly.
If you want I can upload my device configuration, it's better if there are more ppl looking at this

NOTE:
1 backup successfully
2 Use Very lag
3 flash zip not work

Thanks for the feedback!
2. Yeah, the lags are a pain, also because it seems to execute every touch twice and I don't know how to fix this at the moment (maybe it is sufficient to increase the time to determine when a longpress is executed and when a normal touch is done, but this is strongly theoretical.

3. I tested flashing a zip and it does work, which error message do you get?

Anyways, today is a new day, so I will get to work on this (I am on vacation right now fortunately).

Cheers!

 

[crpalmer]

Hi,

unfortunately I don't have any. Basically I wrote a BoardConfig.mk based on the data provided by the Nexus Player (Asus Fugu, which is also Intel based). Then I took 2 modules (one for the display and one for the support of exfat partitions) and compiled a normal TWRP. The output folder holds the compiled img as well as the ramdisk in a simple folder. I put the ramdisk content into a simple zip file and included an update-script to have it unpacked properly. What the recovery-trigger exactly does is not clear to me. It seems it temporarily overwrites the logcat binary with itself and then gets executed at a reboot directly. The recovery trigger just unpacks the zip and executes the recovery binary if I understood correctly.
If you want I can upload my device configuration, it's better if there are more ppl looking at this



Thanks for the feedback!
2. Yeah, the lags are a pain, also because it seems to execute every touch twice and I don't know how to fix this at the moment (maybe it is sufficient to increase the time to determine when a longpress is executed and when a normal touch is done, but this is strongly theoretical.

3. I tested flashing a zip and it does work, which error message do you get?

Anyways, today is a new day, so I will get to work on this (I am on vacation right now fortunately).

Cheers!

If you can upload the device config to github I can try to take a look tonight or tomorrow and see if I can see anything wrong that would explain your "double ui".

Either way, it is good to upload it as you'll have a history saved of when it last worked if you screw it all up!

 

[vampirefo]

Hi,

unfortunately I don't have any. Basically I wrote a BoardConfig.mk based on the data provided by the Nexus Player (Asus Fugu, which is also Intel based). Then I took 2 modules (one for the display and one for the support of exfat partitions) and compiled a normal TWRP. The output folder holds the compiled img as well as the ramdisk in a simple folder. I put the ramdisk content into a simple zip file and included an update-script to have it unpacked properly. What the recovery-trigger exactly does is not clear to me. It seems it temporarily overwrites the logcat binary with itself and then gets executed at a reboot directly. The recovery trigger just unpacks the zip and executes the recovery binary if I understood correctly.
If you want I can upload my device configuration, it's better if there are more ppl looking at this



Thanks for the feedback!
2. Yeah, the lags are a pain, also because it seems to execute every touch twice and I don't know how to fix this at the moment (maybe it is sufficient to increase the time to determine when a longpress is executed and when a normal touch is done, but this is strongly theoretical.

3. I tested flashing a zip and it does work, which error message do you get?

Anyways, today is a new day, so I will get to work on this (I am on vacation right now fortunately).

Cheers!

Is your problems due to recovery or modules you added? My tethered twrp doesn't have the problems yours does, so I wonder if it's the modules, your packaging perhaps and not the recovery?

Sent from my T1 using Tapatalk

 

[sorg]

- Slow graphics, according to @Dees_Troy: "The graphics are a bit laggy because pixelflinger is not very well optimized for x86"

Dees_Troy is lying. TWRP graphic engine isn't optimized for any architecture. Even on my SGS4 (ARM) it's slow as snail. Higher resolution - more slower. I see, they've added some code for Qualcomm overlay support. I didn't try it yet, but support only for one CPU manufacturer is nothing. Especially, there is another way to accelerate at around 1000% by SIMD instuctions. Although i've liked TWRP originally, i see developers have no intentions to improve graphics which is the key feature. So, i've decided to throw away TWRP and look at Aroma File Manager.
It has very fast graphics engine with ARM NEON optimization (and with some effort it become SSE4.2 optimized). The only feature missing is backup/restore, but i'm working on that. Actually, Backup/Restore works now. Just thinking about better backup format.

 

[vampirefo]

Dees_Troy is lying. TWRP graphic engine isn't optimized for any architecture. Even on my SGS4 (ARM) it's slow as snail. Higher resolution - more slower. I see, they've added some code for Qualcomm overlay support. I didn't try it yet, but support only for one CPU manufacturer is nothing. Especially, there is another way to accelerate at around 1000% by SIMD instuctions. Although i've liked TWRP originally, i see developers have no intentions to improve graphics which is the key feature. So, i've decided to throw away TWRP and look at Aroma File Manager.
It has very fast graphics engine with ARM NEON optimization (and with some effort it become SSE4.2 optimized). The only feature missing is backup/restore, but i'm working on that. Actually, Backup/Restore works now. Just thinking about better backup format.

tar is the best.

Sent from my T1 using Tapatalk

 

[sorg]

tar is the best.

Sent from my T1 using Tapatalk

I know. The problem is how to split the archive. Currently i split by size. In this case you cannot use parts independently. For example, if you want to extract some file, you have to concatenate whole backup first and then extract.
The better way is to split tar at header boundary but so far in many decades of years nobody created such split tool. Also, if there is a file bigger than desired part size, it won't be split and may even produce error if target disk (where backup is saving to) is FAT and file size is bigger than 4GB (extreme case).

 

[social-design-concepts]

Dees_Troy is lying. TWRP graphic engine isn't optimized for any architecture. Even on my SGS4 (ARM) it's slow as snail. Higher resolution - more slower. I see, they've added some code for Qualcomm overlay support. I didn't try it yet, but support only for one CPU manufacturer is nothing. Especially, there is another way to accelerate at around 1000% by SIMD instuctions. Although i've liked TWRP originally, i see developers have no intentions to improve graphics which is the key feature. So, i've decided to throw away TWRP and look at Aroma File Manager.
It has very fast graphics engine with ARM NEON optimization (and with some effort it become SSE4.2 optimized). The only feature missing is backup/restore, but i'm working on that. Actually, Backup/Restore works now. Just thinking about better backup format.

@Dees_Troy actually is not lying pixelflinger_static isn't optimize for x86 and Intel used to add libenc to speed up pixelflinger a little, intel later decided to use the more recent version of libminui cause it doesn't use pixelflinger_static and from what i read it a whole lot faster. i imagine @Dees_Troy and team-win are looking into moving away from pixelflinger because of it's draw backs but that is a very big task.

i plan to build against the windriver android-5.0.0_r2.0.1 source this evening cause it includes the icc tool chain when i built the new recovery.launcher against it , it was much much much much much faster hope it has the same affect on twrp

 

[TheSSJ]

Is your problems due to recovery or modules you added? My tethered twrp doesn't have the problems yours does, so I wonder if it's the modules, your packaging perhaps and not the recovery?

Sent from my T1 using Tapatalk

I assume maybe I am missing some modules. There is a .ko file named fps_throttle...this led me to the conclusion that maybe the framerate is awefully high (or awefully low ), which could explain this flickering text maybe...
I will include all of the modules in my next build to see if it works better, thanks for the tip!

 

[sorg]

@Dees_Troy actually is not lying pixelflinger_static isn't optimize for x86

I think, you've missed the point. I've said current TWRP graphics isn't optimized for ALL platforms (besides very specific Qualcomm overlay which i had no chance to try). Nothing to do with x86. Even on ARM device it's very slow. In several years of TWRP existence, i didn't see any progress in GUI, so i don't hope it will be changed anytime soon.

From other side, Aroma File Manager uses NEON(which can be translated to SSE) optimization making interface very fast. Thus, you don't need any special compiler. But due to very different internal GUI engines, it's hard to port TWRP to Aroma GUI. Using 3rd party compiler give you other problems if you try to compile something requiring Android NDK.

Anyway, let me know if your approach with different compiler will make rocket from snail TWRP GUI