Related
Team Win Recovery Project 3.x, or twrp3 for short, is a custom recovery built with ease of use and customization in mind. Its a fully touch driven user interface no more volume rocker or power buttons to mash. The GUI is also fully XML driven and completely theme-able. You can change just about every aspect of the look and feel.
CHANGELOG for 3.0.2-0:
-Fix a bug with the input box that affected masked inputs (passwords). This fixes decrypt of full device encryption on devices that support decrypt. This bug also impacts encrypted backups. Users are highly encouraged to stop using 3.0.1 if you use encrypted backups or if you need decrypt of data in TWRP.
-Add Greek translation to some builds.
CHANGELOG for 3.0.1-0:
-support new CM 13.0 pattern encryption (sultanqasim)
-fix slow flashing issue due to modprobe (present on only some devices) (#twrp)
-libtar updated to latest upstream and fixes (jcadduono)
-fixes for loading custom themes (_that)
-TWRP will now detect and install TWRP themes automatically through the normal zip install process (Dees_Troy)
-translation updates - added Italian, Czech and Polish and significant updates to Dutch
-progress bar improvements - progress bar updates during image flashing and better tracks progress during file system backups (tar) (Dees_Troy)
-fix input box text display (Dees_Troy)
-reboot option after zip install complete (bigbiff)
-other mostly invisible bug fixes and improvements
CHANGELOG for 3.0.0-0:
-Completely new theme - Much more modern and much nicer looking (by z31s1g)
-True Terminal Emulator - Includes arrow keys, tab and tab completion, etc. (by _that)
-Language translation - It won’t be perfect and especially some languages that require large font files like Chinese & Japanese won’t be availble on most devices. Also some languages may only be partially translated at this time. Feel free to submit more translations to OmniROM’s Gerrit. (mostly by Dees_Troy)
-Flashing of sparse images - On select devices you will be able to flash some parts of factory images via the TWRP GUI (by HashBang173)
-Adopted storage support for select devices - TWRP can now decrypt adopted storage partitions from Marshmallow
-Reworked graphics to bring us more up to date with AOSP - includes support for adf and drm graphics (by Dees_Troy)
-SuperSU prompt will no longer display if a Marshmallow ROM is installed
-Update exfat, exfat fuse, dosfstools (by mdmower)
-Update AOSP base to 6.0
-A huge laundry list of other minor fixes and tweaks
Note: As always, be sure your custom theme is up to date (or remove your custom theme) before updating TWRP.
System read only option: Devices that ship with 5.0 and higher as their initial OS are using block level OTA updates. With this style of OTA update, the update script checks to see if the system partition has ever been mounted read/write. Further, the script also usually runs an SHA sum of the entire system partition to detect if any changes have been made. If any changes have been made, the OTA update will refuse to install. Since not all OEMs and devices have factory images available, we have created a new feature in TWRP that detects if the system partition has ever been mounted read/write. If not, you will be prompted asking if you want TWRP to mount system as read/write. If you choose not to allow TWRP to mount as read/write, TWRP won’t prompt to install SuperSU and TWRP won’t try to patch the stock ROM to prevent TWRP from being replaced by stock recovery. The goal of this option is to hopefully allow the user to make a raw system image backup that they can use to get back to a state where they can take OTA updates again.
resize2fs feature: On some devices like the Nexus 6, the factory images include a userdata image that is the proper size only for the 32GB units. If you flash the factory image to a 64GB Nexus 6, the data partition will appear as if it only has the free space of a 32GB device. Using the resize2fs option, TWRP can resize your data partition to take up the full space available. The resize2fs may also be useful to resize system partitions on devices where custom ROM system images don’t take up the full partition space. Lastly, resize2fs may be useful in some cases to reserve the proper space at the end of a data partition for a full disk encryption key, should your partition be formatted incorrectly for some reason.
DOWNLOAD & HOW-TO INSTALL:
--------- On Device ---------
1) Download the latest recovery.img from Android File Host
2) Use Flashify to flash the recovery.img
(How to use flashify)
1) Grant Root Access
2) Click "Recovery image"
3) Click "Choose a file"
4) Select the img you just downloaded and when prompted to flash, press "Yep"
5) When it offers you to reboot, select "Yep"
------------------------------------------------------------------
--------- Odin (On Windows PC) ---------
1) Download the recovery.tar from Android File Host
2) Open Odin and click the "AP" button and select the .tar file you downloaded
3) Boot your phone into download mode (hold Volume Down + Home + Power)
4) When prompted, press the Volume Up button to continue
5) Connect your device to your PC and press Start
6) Once your device is finished booting, shut it off
7) Once your device is completely off, press and hold Volume up + Home + Power until you get a "recovery is not seenforcing" message in red at the upper left hand of your screen
-----------------------------------------------------------------------------
XDA:DevDB Information
TeamWin TWRP Recovery for the Sprint Samsung Galaxy S6 (SM-G920P)
Contributors
tvm2487 - TWRP Compiler
1619415 - Thread Maintainer
And TeamWin (duh)
Version Information: 3.0.2-0
Status: Stable
Last Updated May 10th, 2016
XDA:DevDB Information
[TOOL/UTILITY][TWRP][RECOVERY] TWRP 3.0.2-0 TeamWin Recovery Project 5/10, Tool/Utility for the Sprint Samsung Galaxy S6
Contributors
1619415, tvm2487
Version Information
Status: Stable
Created 2016-05-10
Last Updated 2016-05-10
We love you, man. No homo
Sent from my SM-G920P using Tapatalk
Thank you guys! Keep up the good work!
asafegous said:
We love you, man. No homo
Sent from my SM-G920P using Tapatalk
Click to expand...
Click to collapse
Lol
Excellent job TeamSpr. Much appreciated. Sadly, not working the Edge yet
iam assuming this will also work for boost mobile,?
nyfl2004 said:
Excellent job TeamSpr. Much appreciated. Sadly, not working the Edge yet
Click to expand...
Click to collapse
If the good folks that built the modified version would share the device tree, I can help unify it with the Edge ( I don't have an edge, but can help @nyfl2004 extract the necessary blobs, et al, to build the Edge in).
Did you start with this by chance? https://github.com/TeamWin/android_device_samsung_zerofltespr
It won't flash for me....it gets most of the way through and then it fails.
Euronymous88 said:
It won't flash for me....it gets most of the way through and then it fails.
Click to expand...
Click to collapse
What version of Odin are you using? I personally use the one linked above which worked fine. Make sure you have enabled OEM Unlocking under Dev options. Also, make sure that you don't bump the cable or anything while flashing I suggest that you just plug it in lay it on a flat surface and just let it run.
1619415 said:
What version of Odin are you using? I personally use the one linked above which worked fine. Make sure you have enabled OEM Unlocking under Dev options. Also, make sure that you don't bump the cable or anything while flashing I suggest that you just plug it in lay it on a flat surface and just let it run.
Click to expand...
Click to collapse
That's what I normally do. I've used Odin many times...I'm using the latest version of Odin. Just seeing if anyone else had the same problem.
tdhite said:
If the good folks that built the modified version would share the device tree, I can help unify it with the Edge ( I don't have an edge, but can help @nyfl2004 extract the necessary blobs, et al, to build the Edge in).
Did you start with this by chance? https://github.com/TeamWin/android_device_samsung_zerofltespr
Click to expand...
Click to collapse
I have already built it for the edge, please pm me on how you rooted!
Sent from my SM-G925P using Tapatalk
Euronymous88 said:
That's what I normally do. I've used Odin many times...I'm using the latest version of Odin. Just seeing if anyone else had the same problem.
Click to expand...
Click to collapse
You can just untar it and that will give you the image. For example, in linux:
Code:
tar xvf New_S6_Spr_TWRP_MM_Bootloader2.tar
That will give you a file called "recovery.img"
Then copy that file to your phone, adb shell in, type "su" at the shell prompt (which will ask you for permission, of course, so grant it); then 'dd' it to the recovery partition as described in the section "dd Install Method (Requires Root)" at https://twrp.me/devices/samsunggalaxys6sprint.html.
You don't need Odin to install TWRP in most cases.
Once you successfully flash TWRP...all you need to do for root is flash SuperSU 2.68.
So soon we will have the TeamSpr v2 rite ?
Sent from my SM-G920P using Tapatalk
TaNuXzx said:
So soon we will have the TeamSpr v2 rite ?
Sent from my SM-G920P using Tapatalk
Click to expand...
Click to collapse
V3.0.0-1 we just added the "-1" that way you guys know that this is the updated and working version
1619415 said:
V3.0.0-1 we just added the "-1" that way you guys know that this is the updated and working version
Click to expand...
Click to collapse
i mean the rom . sorry ?
Sent from my SM-G920P using Tapatalk
I Installed thru Flashify,only Because the wife was on the computer gaming. It worked made a backup flashed xposed modules turned on now thanks.
Great work TeamSpr. Works great on my s6 phone. Thx
Sent from my SM-G920P using Tapatalk
Not taking, still on default recovery
Hi,
Just checking if others see this:
1) turn on oem unlocking (even off then on again to assure it's on);
2) load up Odin3 v3.10.7 (used this to flash twrp in LL, works fine, also used to return to stock and take OTA);
3) turn off R. Reset Time;
4) Flash New_S6_Spr_TWRP_MM_Bootloader2.tar
It just reboots to stock MM, then if I force to recover, it's still stock recovery.
?? Anyone have a clue on that one? I can get to stock recovery and reboot to system still, but sheesh -- no take of the Odin flash of TWRP? Not enough knowledge in my head around Odin for that one if anyone has some help.
tdhite said:
Hi,
Just checking if others see this:
1) turn on oem unlocking (even off then on again to assure it's on);
2) load up Odin3 v3.10.7 (used this to flash twrp in LL, works fine, also used to return to stock and take OTA);
3) turn off R. Reset Time;
4) Flash New_S6_Spr_TWRP_MM_Bootloader2.tar
It just reboots to stock MM, then if I force to recover, it's still stock recovery.
?? Anyone have a clue on that one? I can get to stock recovery and reboot to system still, but sheesh -- no take of the Odin flash of TWRP? Not enough knowledge in my head around Odin for that one if anyone has some help.
Click to expand...
Click to collapse
Turn on Reset time and try the Odin included in This zip
Code:
[CENTER]*** Disclaimer ***
All flashing is done at your own risk!
While nothing from this thread should break your device,
don't come back here blaming anyone if it does![/CENTER]
Introduction
Team Win Recovery Project 3.x, or twrp3 for short, is a custom recovery built with ease of use and customization in mind. Its a fully touch driven user interface no more volume rocker or power buttons to mash. The GUI is also fully XML driven and completely theme-able. You can change just about every aspect of the look and feel.
Click to expand...
Click to collapse
Images
Installation instructions
NOTE: Read the FAQ from Post #2 to ensure that you're installing the correct version of TWRP!!
TWRP Image Install method:
Most devices can be updated quickly and easily within TWRP if you already have version 2.8.4.0 or higher installed.
Download the latest version of TWRP appropriate for your device/firmware
Reboot to TWRP
Hit Install and tap the "Install Image" button in the lower right
Browse to the location of the TWRP image on your device and select it
Select recovery from the partition list and swipe to flash
Alternate Installation Method:
Fastboot Install Method:
You will need the platform-tools from the Android SDK on your computer. Find the Android command line tools section on the page linked and install the SDK tools package. From the SDK Manager, download only the platform-tools to get adb and fastboot binaries.
Windows users will need proper drivers installed on their computer. You can try the Naked ADB drivers or the Universal ADB drivers if you don't already have a working driver installed
On your device, go into Settings -> About and find the Build Number and tap on it 7 times to enable developer settings. Press back and go into Developer Options and enable USB debugging. From your computer, open a command prompt and type:
Code:
adb reboot download
You should now be in fastboot mode.
Download the correct image file and copy the file into the same folder as your adb and fastboot binaries. Rename the image to twrp.img and type:
Code:
fastboot flash recovery twrp.img
Code:
fastboot reboot
Click to expand...
Click to collapse
Device Changelog
Current version: 3.4.0-0:
Code:
[LIST][URL="https://github.com/TeamWin/android_device_htc_pme/commit/f168dc3cd98bb8778e12b14716e3015b9b873256"]Add vendor init[/URL]
[*][URL="https://github.com/TeamWin/android_device_htc_pme/commit/4b4e1c14b65aa3d974e99d08ad0851b5ec24e0c5"]Decryption updates & cleanup[/URL][/LIST]
Older Device-specific versions:
Code:
[SIZE="4"][COLOR="Green"]3.2.3-1:[/COLOR][/SIZE]
[LIST]Updates to support AOSP Pie decryption[/LIST]
[SIZE="4"][COLOR="Green"]3.2.2-1:[/COLOR][/SIZE]
[LIST][update] Add support for AOSP Oreo decryption[/LIST]
[SIZE="4"][COLOR="Green"]3.2.1-4:[/COLOR][/SIZE]
[LIST]Enable f2fs support
- Fixed source so it compiles properly[/LIST]
[SIZE="4"][COLOR="Green"]3.2.1-3:[/COLOR][/SIZE]
[LIST]Update kernel to custom Oreo built from 3.16.708.3_R HTC Dev source
- Patched for proper working touch (reboot recovery now works as well)
[*]Enable NTFS
- f2fs remains disabled, as source won't compile with it enabled[/LIST]
[SIZE="4"][COLOR="Green"]3.2.1-2:[/COLOR][/SIZE]
[LIST]Use /persist as Qualcomm time fix source during early boot
- Fixes broken time issue on Oreo firmware[/LIST]
[SIZE="4"][COLOR="Green"]3.2.1-1:[/COLOR][/SIZE]
[LIST]Updated kernel to US Unlocked Oreo (3.16.617.2) - patched for working touch
[*]Added support for Oreo decryption (posthumous thanks to @nkk71 for all his hard work on decryption)
[*]Disable f2fs & NTFS support until custom kernel can be built
[*]Update vendor init to properly detect Verizon model by CID[/LIST]
Click to expand...
Click to collapse
TWRP Official Changelog
Current version: 3.4.0:
Code:
System As Root (SAR)
[LIST]Fix backup and restore using SAR - dianlujitao
[*]System mount point - Chaosmaster
[*]ORS - Chaosmaster
[*]Zip install - Chaosmaster
[*]system_root bind mount to /system - Chaosmaster
[*]Autodetection of SAR - Chaosmaster[/LIST]
Digest
[LIST]fix creation of digests for sub-partitions (was bugfix applied to many devices since last year) - Bigbiff[/LIST]
Encryption
[LIST]ext4Crypt Wrapped Key Update - Peter Cai
[*]Fix upgrading encryption key if export fails - Peter Cai
[*]Fix wrapped key support for devices without metadata partition - mauronofrio
[*]Don't skip decryption when using block map file in order to write to /data in ORS - CaptainThrowback
[*]FDE - Decrypt master key first - AndroidableDroid
[*]vold_decrypt - set Android version and patch level automatically - CaptainThrowback
[*]Set wrapped decrypt support by twrp flag - Peter Cai
[*]Don't try wrapped support unless needed - mauronofrio
[*]restore ext4 policy on /data/cache - Bigbiff
[*]multiuser decryption - Noah Jacobson
[*]FDE retry - AndroidableDroid[/LIST]
TWRP App
[LIST]unmount system after checking for app - Bigbiff[/LIST]
Prebuilt updates
[LIST][email protected] - cryptomilk[/LIST]
Compilation Fixes
[LIST]TW_EXFAT_FUSE compilation fixes - Bigbiff
[*]libuuid - cryptomilk
[*]'system/etc/ld.config.txt' not found error - Martin Dünkelmann[/LIST]
Language Updates
[LIST]Portugal - Vasco Machado
[*]Dutch - Ian Macdonald
[*]Turkish - Fatih Fırıncı
[*]Localisation of Backup_Tar - Ian Macdonald[/LIST]
ld.config.txt
[LIST]updates for 8.x trees - CaptainThrowback
[*]fix search path for /sbin - CaptainThrowback
[*]/sbin should come first in search path - Ian Macdonald[/LIST]
General Bugs
[LIST]Fix persistent log storage - SyberHexen
[*]Compress Persistent Logs - Bigbiff
[*]FB2PNG compilation errors - Bigbiff
[*]exclude per_boot from backups - Darth9
[*]Unmount all directories that point to same block device - AndroidableDroid
[*]Blank screen fixes - Sean hoyt
[*]Toolbox is default on android-9+ - mauronofrio[/LIST]
Cleanup
[LIST]Typo fix in comment - VDavid003
[*]newlines in ext4crypt - CaptainThrowback
[*]TW_OEM_BUILD compilation issue - Patrick Zacharias
[*]Fix Dependency requirements - Dees_Troy
[*]Fix Symbolic links for BB and Toolbox - Dees_Troy[/LIST]
Bootloader Message
[LIST]cleanup - Alessandro Astone
[*]add configurable offsets[/LIST]
Error Cleanup
[LIST]uevent errors and decryption error - mauronofrio
[*]using copy_file to copy files from /etc - CaptainThrowback
[*]ueventd access to /acct - early directory creation in init - cryptomilk[/LIST]
Haptics
[LIST]TSP Driver - LameMonster82
[*]QTI Input - AndroidableDroid[/LIST]
update_engine
[LIST]read all asserts - Hernán Castañón[/LIST]
Resetprop
[LIST]Add Resetprop from Magisk - CaptainThrowback & mauronofrio
[*]compile from source - Chaosmaster
[*]fix for android-7 and earlier - Chaosmaster
[*]cleanup for spaces in properties - AndroidableDroid[/LIST]
Properties
[LIST]Add Property override - Chaosmaster[/LIST]
Backuptool
[LIST]mount system and vendor for A/B installs for backuptool - Chaosmaster[/LIST]
twrpTar
[LIST]fix backup freezes when pigz and openaes are used - Fabrice Bellet[/LIST]
Zip Installs
[LIST]Info for A/B zip installing to inactive slot - Chaosmaster
[*]Reboot to system button now allows to be rebooted to different partitions after zip install
[*]progressbar rework - Chaosmaster[/LIST]
Magisk updates
[LIST]update binaries from source - AndroidableDroid[/LIST]
A/B Updater Zip Template
[LIST]rewrite A/B installer zip from scratch using a new generic template and latest magiskboot - osm0sis
[*]installer zip support for recovery_a/recovery_b partition ramdisks on newer 2SI SAR A/B devices - osm0sis
[*]generate installer zips for all prod A/B devices - bigbiff
[*]improve installer zip dump/write speed and add more error catching - arter97 & osm0sis[/LIST]
OZIP Encryption Support
[LIST]add OZIP encryption - mauronofrio[/LIST]
File Selector
[LIST]Support for more extensions in File Selector - mauronofrio[/LIST]
Older versions:
Code:
[SIZE="4"][COLOR="Green"]3.3.1:[/COLOR][/SIZE]
[LIST]Fix selinux issues during formatting - dianlujitao
[*]Various fixes for toybox and toolbox builds - CaptainThrowback and bigbiff
[*]Flash both A and B partitions when installing a recovery ramdisk - Dees_Troy
[*]Add option to uninstall TWRP app from /system - Dees_Troy
[*]Create digest for subpartitions - bigbiff[/LIST]
[SIZE="4"][COLOR="Green"]3.3.0:[/COLOR][/SIZE]
[LIST]Merge AOSP 9.0 r3 (Dees_Troy)
[*]Use ANDROID_ROOT variable instead of hard coding to /system (CaptainThrowback)
[*]Decrypt FBE on 9.0 and metadata decrypt (Dees_Troy)
[*]vold decrypt updates (nijel8, CaptainThrowback)
[*]Support vibration on LED class devices (notsyncing)
[*]Metadata decrypt support for Pixel 3 (Dees_Troy)
[*]Support rotating the display via build flag (vladimiroltean)
[*]Reboot to EDL mode button (mauronofrio)
[*]Support MTP on FFS devices (bigbiff)
[*]Update FDE decrypt to support keymaster 3 and 4 (Dees_Troy)
[*]Detect mkfs.f2fs version to properly format on f2fs partitions (Dees_Troy)
[*]Allow TWRP to use md5 and sha256 checksums for zip installs (bigbiff)
[*]TWRP can use /data/cache/recovery and /persist/cache/recovery on AB devices with no cache partition (bigbiff)
[*]Switch part of advanced menus in TWRP to use a listbox of options (Dees_Troy)
[*]Use magiskboot to allow repacking boot images for installing TWRP (Dees_Troy with thanks to topjohnwu of course)[/LIST]
[SIZE="4"][COLOR="Green"]3.2.3:[/COLOR][/SIZE]
[LIST]Fix automatic installing of OTA zips on encrypted devices
[*]Remove SuperSU from TWRP
[*]Support both md5 and md5sum file extensions when doing MD5 checking for zip files[/LIST]
[SIZE="4"][COLOR="Green"]3.2.2:[/COLOR][/SIZE]
[LIST]adb backup fixes
[*]OTA style update zips will now install automatically without prompting for decrypt
[*]minor tweaks to handling date/time on Qualcomm devices
[*]updates to some language translations[/LIST]
[SIZE="4"][COLOR="Green"]3.2.1:[/COLOR][/SIZE]
[LIST]minui fixes (cryptomilk)
[*]Better android-8.0 compatibility in ROM trees (Dees_Troy)
[*]Fix missing library in android-8.0 (nkk71)
[*]Fix inconsistent SDCard naming (DevUt)
[*]Default to TWRP restore instead of adb backup restore to fix restore on fresh TWRP boot (jlask)[/LIST]
[SIZE="4"][COLOR="Green"]3.2.0:[/COLOR][/SIZE]
[LIST]Allow restoring adb backups in the TWRP GUI (bigbiff)
[*]Fix gzip backup error in adb backups (bigbiff)
[*]Fix a bug in TWRP's backup routines that occasionally corrupted backup files (nkk71)
[*]Better support for installing Android 8.0 based zips due to legacy props (nkk71)
[*]Support vold decrypt with keymaster 3.0 in 8.0 firmwares (nkk71)
[*]Decrypt of synthetic passwords for Pixel 2 (Dees_Troy)
[*]Support newer ext4 FBE policies for backup and restore in libtar (Dees_Troy)
[*]v2 fstab support (Dees_Troy)
[*]Bring TWRP forward to android 8.0 AOSP base (Dees_Troy)
[*]Various other minor bugfixes and tweaks[/LIST]
[SIZE="4"][COLOR="Green"]3.1.1:[/COLOR][/SIZE]
[LIST]Backups will now include adopted storage keys (Dees_Troy)
[*]Fixed an adb restore issue (bigbiff)
[*]Fixed rebooting when no OS is present (Dees_Troy)
[*]Fixed line wrapping in the GUI terminal (_that)
[*]Updated TWRP source code to AOSP 7.1.2 (Dees_Troy)[/LIST]
[SIZE="4"][COLOR="Green"]3.1.0:[/COLOR][/SIZE]
[LIST]vold decrypt on a few select HTC devices, TWRP will now attempt to use the system partition's vold and vdc binaries and libraries to decrypt the data partition (nkk71 and CaptainThrowback)
[*]adb backup to stream a backup directly to or from your PC, see documentation [URL="https://github.com/omnirom/android_bootable_recovery/commit/ce8f83c48d200106ff61ad530c863b15c16949d9"]here[/URL] (bigbiff)
[*]tweak MTP startup routines (mdmower)
[*]support new Android 7.x xattrs for backup and restore to fix loss of data after a restore (Dees_Troy)
[*]support POSIX file capabilities backup and restore to fix VoLTE on HTC devices and possibly other issues (Dees_Troy)
[*]better indicate to users that internal storage is not backed up (Dees_Troy)
[*]improve automatic determination of TW_THEME (mdmower)
[*]minimal getcap and setcap support (_that)
[*]try mounting both ext4 and f2fs during decrypt (jcadduono and Dees_Troy)
[*]shut off backlight with power key (mdmower)
[*]timeout during FDE decrypt (Dees_Troy and nkk71)
[*]support for FBE decrypt and backing up and restoring FBE policies (Dees_Troy)
[*]boot slot support (Dees_Troy)
[*]TWRP app install prompt during reboot (Dees_Troy)
[*]support for AB OTA zips (Dees_Troy)
[*]support new Android 7.x log command (Dees_Troy)
[*]update recovery sources to AOSP 7.1 (Dees_Troy)
[*]numerous bugfixes and improvements by too many people to mention[/LIST]
[SIZE="4"][COLOR="Green"]3.0.3:[/COLOR][/SIZE]
[LIST]Partial release to help support the release of the [URL="https://www.xda-developers.com/team-win-releases-their-first-official-twrp-app-in-the-play-store/"]Official TWRP app[/URL][/LIST]
[SIZE="4"][COLOR="Green"]3.0.2:[/COLOR][/SIZE]
[LIST]Fix a bug with the input box that affected masked inputs (passwords). This fixes decrypt of full device encryption on devices that support decrypt. This bug also impacts encrypted backups. Users are highly encouraged to stop using 3.0.1 if you use encrypted backups or if you need decrypt of data in TWRP.
[*]Add Greek translation to some builds.[/LIST]
[SIZE="4"][COLOR="Green"]3.0.1:[/COLOR][/SIZE]
[LIST]support new CM 13.0 pattern encryption (sultanqasim)
[*]fix slow flashing issue due to modprobe (present on only some devices) (#twrp)
[*]libtar updated to latest upstream and fixes (jcadduono)
[*]fixes for loading custom themes (_that)
[*]TWRP will now detect and install TWRP themes automatically through the normal zip install process (Dees_Troy)
[*]translation updates - added Italian, Czech and Polish and significant updates to Dutch
[*]progress bar improvements - progress bar updates during image flashing and better tracks progress during file system backups (tar) (Dees_Troy)
[*]fix input box text display (Dees_Troy)
[*]reboot option after zip install complete (bigbiff)
[*]other mostly invisible bug fixes and improvements[/LIST]
[SIZE="4"][COLOR="Green"]3.0.0:[/COLOR][/SIZE]
[LIST]Completely new theme - Much more modern and much nicer looking (by z31s1g)
[*]True Terminal Emulator - Includes arrow keys, tab and tab completion, etc. (by _that)
[*]Language translation - It won’t be perfect and especially some languages that require large font files like Chinese & Japanese won’t be availble on most devices. Also some languages may only be partially translated at this time. Feel free to submit more translations to OmniROM’s Gerrit. (mostly by Dees_Troy)
[*]Flashing of sparse images - On select devices you will be able to flash some parts of factory images via the TWRP GUI (by HashBang173)
[*]Adopted storage support for select devices - TWRP can now decrypt adopted storage partitions from Marshmallow
[*]Reworked graphics to bring us more up to date with AOSP - includes support for adf and drm graphics (by Dees_Troy)
[*]SuperSU prompt will no longer display if a Marshmallow ROM is installed
[*]Update exfat, exfat fuse, dosfstools (by mdmower)
[*]Update AOSP base to 6.0
[*]A huge laundry list of other minor fixes and tweaks[/LIST]
[U]Additional Notes[/U]
[LIST]WARNING: This is our first release in a long time. We have a lot of new and somewhat aggressive changes in this new release. The changes to the graphics back-end may cause some devices to not boot up properly or have other display-related issues. If you are not in a position to reflash an older build of TWRP, then wait until you are or at least wait until others have tried the new version for your specific device. You don’t want to end up with a non-working recovery and have to wait several hours or days to get to a computer to be able to fix it.
[*]Notes for themers: In addition to the updated theme, we have introduced a theme version variable to the TWRP theme system. If the theme version does not match the version that TWRP expects, TWRP will reject the custom theme and load its stock theme. This change will ensure that people who update TWRP without updating their theme will still have a workable recovery. We have removed libjpeg support. The stock theme was only using a jpeg image for the splash / curtain. This change means that any custom themes will no longer be able to use jpeg images. It also means that tools used to repack recovery images with a different curtain / splash will need to be updated to use the new method.
[*]Version number notes: For a while we’ve been using a 4 digit version number and reserved the 4th digit for device-specific updates. For instance, we find and fix a device-specific issue like decryption of data on Nexus 5, we would release that as a 2.8.7.1. After a while, some people would start asking where 2.8.7.1 was for other devices. So, going forward we have decided to change the numbering scheme to 3.0.0-2, etc. Our hope is that this version numbering scheme will more clearly identify that the 4th digit does not indicate a version change for the code base.
[*]We need your help! The bulk of TWRP work is done by 3 people on a volunteer basis. We have pushed most of our device files to our github and we have a gerrit instance. If you have the ability, please help us maintain our official devices and/or add your device to our official device list. Thanks in advance![/LIST]
[SIZE="4"][COLOR="Green"]2.8.7.0:[/COLOR][/SIZE]
[LIST]Initial ground work for software drawn keyboard (_that)
[*]Fix handling of wiping internal storage on datamedia devices (xuefer)
[*]Allow DataManager to set and read values from the system properties (xuefer)
[*]Fix crash when taking screenshots on arm64 devices (xuefer)
[*]Fix error message after an ORS script completes (Dees_Troy)
[*]Fix crashes / error when creating encrypted backups (_that, Dees_Troy)
[*]Add system read only option – more details below (Dees_Troy)
[*]Add resize2fs and GUI option to run resize2fs (Dees_Troy)
[*]Fix crash loop caused by empty lines in AOSP recovery command file (_that)
[*]Prevent duplicate page overlays such as multiple lock screens (mdmower)[/LIST]
[U]Additional Notes[/U]
[LIST]Note: As always, be sure your custom theme is up to date (or remove your custom theme) before updating TWRP.
[*]System read only option: Devices that ship with 5.0 and higher as their initial OS are using block level OTA updates. With this style of OTA update, the update script checks to see if the system partition has ever been mounted read/write. Further, the script also usually runs an SHA sum of the entire system partition to detect if any changes have been made. If any changes have been made, the OTA update will refuse to install. Since not all OEMs and devices have factory images available, we have created a new feature in TWRP that detects if the system partition has ever been mounted read/write. If not, you will be prompted asking if you want TWRP to mount system as read/write. If you choose not to allow TWRP to mount as read/write, TWRP won’t prompt to install SuperSU and TWRP won’t try to patch the stock ROM to prevent TWRP from being replaced by stock recovery. The goal of this option is to hopefully allow the user to make a raw system image backup that they can use to get back to a state where they can take OTA updates again.
[*]resize2fs feature: On some devices like the Nexus 6, the factory images include a userdata image that is the proper size only for the 32GB units. If you flash the factory image to a 64GB Nexus 6, the data partition will appear as if it only has the free space of a 32GB device. Using the resize2fs option, TWRP can resize your data partition to take up the full space available. The resize2fs may also be useful to resize system partitions on devices where custom ROM system images don’t take up the full partition space. Lastly, resize2fs may be useful in some cases to reserve the proper space at the end of a data partition for a full disk encryption key, should your partition be formatted incorrectly for some reason.
[*]This new version also marks our first set of full builds using our new jenkins build server. You can track the progress of builds at [url]https://jenkins.twrp.me[/url] and we have taken additional steps to make it easier for device maintainers to step up and submit patches to our gerrit server at [url]https://gerrit.twrp.me[/url] to help us keep devices up to date and working.[/LIST]
Click to expand...
Click to collapse
Downloads
NOTE: Read the FAQ from Post #2 to ensure that you're installing the correct version of TWRP!!
Download
Latest Official versions
Latest Unofficial versions
Sources
Device tree
Kernel source
Click to expand...
Click to collapse
FAQ - Post #2
Known Issues
As of version 3.3.0, stock Nougat can no longer be decrypted. Use 3.2.3 or older if you are still running stock Nougat.
Encrypted backups are broken - DO NOT USE THIS FEATURE!!
3.2.1-1 through 3.2.1-2: Reboot recovery is broken (due to patching stock kernel for touch - requires kernel source and custom kernel build to fix) - UPDATE: Fixed with 3.2.1-3
Click to expand...
Click to collapse
We need your help!
Join the TWRP Testing group on Slack to help us test TWRP prior to official releases!
Click to expand...
Click to collapse
Bug Reporting
If you have an issue, the first step is to post a recovery log so we can determine the cause of the issue. This is done in recovery using Advanced -> Copy Log, or adb pull /tmp/recovery.log. Once a log is uploaded we can determine how best to proceed. NOTE: Posts that are reporting bugs or issues without an accompanying recovery log will be ignored! Additionally, providing details about your device setup, including variant, firmware version, and exact steps to reproduce your issue will also be helpful in diagnosing the problem.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
If your issue is determined to be a bug by the device maintainer, please consider posting it to our github issues log. It's pretty much impossible for us to keep up with the more than 40 threads that we have for the devices that we "directly" support. If you have a significant problem that cannot be answered in this thread, your best bet is to contact us via our website, or find us in our IRC channel below. If you see someone that's struggling, feel free to point it out to us. We need your help to help us keep track of all of our devices! Thanks!
Click to expand...
Click to collapse
Additional Help/Support:
Live support is available via #twrp on Freenode with your IRC client or just click this link.
Click to expand...
Click to collapse
XDA:DevDB Information
TeamWin Recovery Project (TWRP), Tool/Utility for the HTC 10
Contributors
Captain_Throwback, Dees_Troy, bigbiff, _that, nkk71
Source Code: https://github.com/TeamWin/android_bootable_recovery
Version Information
Status: Stable
Current Stable Version: 3.4.0-0
Stable Release Date: 2020-06-24
Created 2016-04-13
Last Updated 2020-06-25
Frequently Asked Questions (FAQ)
1. Why is this device different than my previous HTC device?
With the 10 (and the M9 and A9 prior to it), HTC has moved to a block-based OTA system. This means that even mounting system as read-write (as TWRP typically does during startup checks) will nullify the device's ability to take an OTA. Any other changes to the system partition will also cause an OTA to fail (even if that check is removed from the OTA zip) due to "unexpected contents." Additionally, see this thread.
2. I decrypted my device and now I don't have signal. Did a TWRP update cause this?
No, this is not a TWRP issue. It appears that on the HTC 10, having a decrypted device prevents the SIM card/telephony from initializing, resulting in no mobile signal or data connection. The device comes with forced encryption enabled and currently must remain that way in order for mobile signal/data to work. TWRP does not change or affect any of that.
3. Which version of TWRP am I supposed to use?
For all ROMs except stock-based Nougat ROMs: The best version to use is 3.4.0-0, the latest official TWRP from twrp.me.
For stock-based Nougat ROMs: The best version to use is 3.2.3-0, from twrp.me.
4. Why is there a "System" backup option and a "System Image" backup option now?
The "System" option is the standard tar backup. "System Image" is a dd backup of the entire system block device (/dev/block/bootdevice/by-name/system). The "System Image" option is only relevant if your system is unmodified. This allows you to make a fully stock backup that can be restored later to take an OTA.
NOTE: You only need to choose ONE of these options when making a backup!!
[*]NOTE 2: If you are using a FAT32-formatted card, a "System Image" backup may fail (depending on your variant), due to the 4GB file limit on that format. For a successful System Image backup, internal storage or NTFS/exFAT-formatted external storage must be used (either SD card or USB-OTG)
5. How am I supposed to root?
Since the 10 has dm-verity enabled and forces encryption by default, root can only be achieved using a "systemless" root method. Magisk is the recommended root solution, as it is actively developed and up-to-date. It also allows devices to pass Google's SafetyNet API for working contactless payments. See the below thread for full details.
Magisk
6. How do I backup stock recovery prior to flashing TWRP?
You can't. The "fastboot boot" command appears to be disabled on the 10's ABOOT, so TWRP must be fastboot flashed over stock recovery. You can however, extract the stock recovery.img from the OTA firmware.zip when it's received and use that to install the OTA.
An alternate method to obtain a stock recovery is listed below, but it requires 2 devices (either owned by you, or help from someone else in the forum):
Someone fastboot flash twrp and immediately make a backup of boot and upload it to XDA.
Once the above is available, someone else download that boot.img to their device, and fastboot flash twrp to the BOOT partition of their device.
Once the above is done, reboot the device, which will bring up TWRP, and then backup stock RECOVERY in TWRP, and upload to XDA.
Then, from within TWRP, use the Image install feature in TWRP to flash the stock boot.img.
7. How do I restore stock system so that I can accept an OTA?
Check the "Mount system as read-only" box in the Mount menu.
Restore stock "System Image" backup (This will only work if you've made a System Image backup prior to making any modifications to /system).
Fastboot flash stock recovery (fastboot flash recovery recovery_signed.img)
NOTE: It is also possible to restore stock recovery via the TWRP GUI. Rename the stock recovery file to "recovery.emmc.win" and place in the backup folder with the stock system image. Recovery will then show as a restore option. MAKE SURE YOU REALLY WANT TO DO THIS, AS TWRP WILL BE GONE WHEN YOU REBOOT OUT OF RECOVERY!!
[*]NOTE 2: It is possible to install an OTA without using stock recovery (i.e. installing it with TWRP). TWRP will not flash the firmware.zip included in an OTA file. Please see here for a detailed description of the process.
Reboot to system, install OTA.
8. What if I have an RUU? Do I need to worry about all this OTA nonsense?
Not if you don't care about losing all your data. If you're S-ON and have an RUU available for your exact variant (model ID and CID must match) and software number (main version must be the same or newer), then you can get back to a fully stock state by relocking (fastboot oem lock) and flashing an RUU. However, if you'd prefer to take an OTA to keep your data intact, the method stated above is how to do so. Or, you can just run a custom ROM and wait for your ROM chef to update their ROM to the latest software (though you'll still have to find a way to update your firmware if you're not S-OFF)
9. After I go through all this and successfully apply an OTA, how do I make sure I have a clean starting point again?
After the OTA is applied and TWRP is flashed, it will once again detect an untouched system, which will mount system read-only and allow you to make a fully stock backup and start the process over again, this time with the new base.
10. After I restored my Data backup and boot back to Android, I'm entering the correct PIN/password, but it's telling me the password is wrong. What happened, and how do I fix it?
It appears that sometimes after restoring a backup of Data where security was enabled (such as a PIN or password lock), the device does not recognize the correct password. There are two ways to avoid this issue:
Disable security in Android before making a backup of data.
After restoring Data, while still in TWRP, use the TWRP File Manager to navigate to /data/system and delete all the locksettings.* files (such as locksettings.db, etc). When you reboot, the password will be gone.
11. Information about encrypted devices (by default all HTC 10 devices on Nougat+ are encrypted using FDE force-encrypt)
TWRP decryption on the HTC 10 on Nougat+ relies on the currently running ROM's own system files, to be able to decrypt your data partition.
If you intentionally or accidentally delete your system partition, and boot into TWRP without the needed system files, decryption will fail and you will be prompted to enter your password, which will continually fail due to the missing system files.
When the TWRP console is shown during decryption, you will see a red text: "Missing files needed by vold decrypt: /system/bin/vold".
If you encounter this situation, do not panic, do not format your data partition, you will most likely be able to decrypt again, once you have the needed setup back in place, without any data loss.
The easiest way to do this:
Cancel the decrypt prompt
Restore your last System or System_Image backup (no other partitions need to be restored!)
Reboot to bootloader and then back to TWRP (since currently the direct reboot to recovery is broken due to the lack of kernel source code)
Alternatively, in case you do not have a backup available, you can dirty flash whatever ROM you are running, or even fastboot flash a proper system.img, but considering that your system partition is not likely to have changed, since these days most things are run systemless, the restore is the easiest and fastest.
PSA for Devs regarding mounting system in updater-scripts
In order for ROM zips to function properly, ROM devs may need to change the way they're used to performing mount commands in their updater-scripts. Many ROM devs like to use busybox to mount system, like this:
Code:
run_program("/sbin/busybox", "mount", "/system");
However, on newer HTC devices, this will not always be effective, due to the variable state of system when booting into TWRP (more information in the above post). The most reliable way to mount system in TWRP is to use the below command:
Code:
run_program("/sbin/mount", "-t", "ext4", "/dev/block/bootdevice/by-name/system", "/system");
Since this calls the mount binary and specifies the proper filesystem of /system, it will work regardless of the mount state of /system within TWRP.
The reason people are having issues booting ROMs flashed without the above command is because custom ROMs typically include a command to format system within the updater-script, like this one:
Code:
run_program("/sbin/mke2fs", "-t", "ext4", "-m", "0", "/dev/block/bootdevice/by-name/system");
Notice that this calls the mke2fs binary directly and specifies the filesystem, so this command will run properly and format system. However, when the script attempts to mount system using the busybox mount command, it's unsuccessful, resulting in a failed ROM install (even though there likely isn't an error message) and an empty system partition. The same command format should be used both to format system and to mount it.
So, the solution is easy - replace your busybox mount commands with the direct version noted above. Running it that way should work regardless of the update-binary used, since it's not running mount directly but calling it (this makes a difference to some binaries for some reason). This will even work in situations where system has been mounted read-only by TWRP (more on that in the below post).
ROM Devs - please consider making this change going forward. The above method will ALWAYS WORK. Please use this and discontinue whatever other methods to mount system that you have previously used, as they will have inconsistent results, leading people to flash old versions of TWRP or blame TWRP for their errors.
I know HTC is changing how they do things, and it's different than we're all used to. Let's all adapt to the change together. .
You may notice that there's no device page for the HTC 10 on the twrp.me site. Well, obviously, that's because the device hasn't been released yet. However, if you happen to have the device already, you may be able to find a TWRP build for it somewhere, if you figure out where to look .
Once the device is released, please be assured that a device page will be created so everyone can easily get to it. Until that happens, I'll be keeping the thread closed. Thanks for your understanding!
Alright, since @topjohnwu was kind enough to post a TWRP backup from his release version device, I'm opening the thread and offering an "unofficial" release on the Downloads tab until I can get the official build working.
Here's a link to the build:
twrp-3.0.2-1-pme - DEPRECATED BY OFFICIAL RELEASE
P.S. If you happen to have the currently elusive Sprint variant of the 10, this version WILL NOT WORK. I do have a working version for Sprint, but I will need to wait for the release software before I post it.
UPDATE: As of the official 3.0.2-2 release, the Sprint variant is supported!
Captain_Throwback said:
Alright, since @topjohnwu was kind enough to post a TWRP backup from his release version device, I'm opening the thread and offering an "unofficial" release on the Downloads tab until I can get the official build working.
Here's a link to the build:
twrp-3.0.2-1-pme
P.S. If you happen to have the currently elusive Sprint variant of the 10, this version WILL NOT WORK. I do have a working version for Sprint, but I will need to wait for the release software before I post it.
Click to expand...
Click to collapse
Thanks a lot man. I've got a minor issue here, take a look at the picture, it has a mouse cursor in the center for all time.
Also, would you mind me contact you on hangouts? I am curious about some questions, and I cannot contact using PM.
topjohnwu said:
Thanks a lot man. I've got a minor issue here, take a look at the picture, it has a mouse cursor in the center for all time.
Also, would you mind me contact you on hangouts? I am curious about some questions, and I cannot contact using PM.
Click to expand...
Click to collapse
You're just going to have to ignore the mouse cursor for now. I can't get get rid of that without kernel source.
Sure you can contact me on Hangouts. I do prefer PM, though.
P.S. Added mouse cursor issue to current bug list.
I'm trying to do some preliminary setup for AOSP encryption support. Can someone with a device please try flashing the 3.0.2-2 version I just posted, and provide the recovery.log afterwards (provided it boots)? I'd really appreciate it. Thanks!
Better yet, if someone can flash this 3.0.2-3 and pull a recovery log, and also post the output of lsmod either from adb shell or the TWRP Terminal, I'd appreciate it. I'm trying to a few things for decryption.
@Captain_Throwback
Tried 3.0.2-2 and 3.0.2-3, both cannot boot. Is there a way to pull logs?
Captain_Throwback said:
Better yet, if someone can flash this 3.0.2-3 and pull a recovery log, and also post the output of lsmod either from adb shell or the TWRP Terminal, I'd appreciate it. I'm trying to a few things for decryption.
Click to expand...
Click to collapse
Thanks Captain_Throwback .
twrp-3.0.2-2-pme.img & twrp-3.0.2-3-pme.img is work for me . devices TW 1.21.709.2 deodexed
topjohnwu said:
@Captain_Throwback
Tried 3.0.2-2 and 3.0.2-3, both cannot boot. Is there a way to pull logs?
Click to expand...
Click to collapse
When you say they can't boot, what do you mean? What happens, exactly?
When it tries to boot, does it get stuck? If so, do you have adb access? The OP says how to adb pull a recovery log. If not, then it'll just have to wait until I have one for me to try to fix it.
nenebear said:
Thanks Captain_Throwback .
twrp-3.0.2-2-pme.img & twrp-3.0.2-3-pme.img is work for me . devices TW 1.21.709.2 deodexed
Click to expand...
Click to collapse
Thanks, but it looks like you've already removed encryption, so these logs don't really help for what I was trying to work on. I do appreciate your willingness to help, though.
Captain_Throwback said:
When you say they can't boot, what do you mean? What happens, exactly?
When it tries to boot, does it get stuck? If so, do you have adb access? The OP says how to adb pull a recovery log. If not, then it'll just have to wait until I have one for me to try to fix it.
Click to expand...
Click to collapse
It just blinks the splash screen for about 0.5 sec and then no output. About a few seconds later it reboot to system.
I tried to catch adb shell in that few seconds, but it seems it is too short for TWRP to initialize the adbd
topjohnwu said:
It just blinks the splash screen for about 0.5 sec and then no output. About a few seconds later it reboot to system.
I tried to catch adb shell in that few seconds, but it seems it is too short for TWRP to initialize the adbd
Click to expand...
Click to collapse
Understood. I've seen that behavior before with decryption. That'll be difficult to debug without having to device in-hand, so it'll have to wait. Thanks for your feedback, and for being willing to test!
I'll pull down those other versions for now, since they add nothing but freezes.
I've removed the temporary version from the Downloads tab, as the official build has been updated.
And now we have a device page!
https://twrp.me/devices/htc10.html
edited
Is it possible to enable encryption once TWRP installed and dm-verity is disabled?
I'm talking about the old method of encryption where the /data partition is manually encrypted, rather than forceencrypt
Rooting and modding is great, but if the only way to do so is to disable encryption completely, I think that will change a lot of people's value prop.
orrorin said:
Is it possible to enable encryption once TWRP installed and dm-verity is disabled?
I'm talking about the old method of encryption where the /data partition is manually encrypted, rather than forceencrypt
Rooting and modding is great, but if the only way to do so is to disable encryption completely, I think that will change a lot of people's value prop.
Click to expand...
Click to collapse
TWRP doesn't support HTC's encryption. Not sure why you'd think there's a difference between the forced encryption and manual. They still use the same type of encryption on the stock ROM.
Once AOSP is available, decryption should be possible, but only on AOSP-based ROMs.
Captain_Throwback said:
TWRP doesn't support HTC's encryption. Not sure why you'd think there's a difference between the forced encryption and manual. They still use the same type of encryption on the stock ROM.
Once AOSP is available, decryption should be possible, but only on AOSP-based ROMs.
Click to expand...
Click to collapse
I understand that TWRP can't decrypt HTC's encryption, but what I'm wondering is whether it's possible to enable encryption on the HTC 10 after dm-verity has been disabled and root has been flashed.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
You use this tool at your own risk!!
I have tried to put as many safeguards as I can,
but I cannot be held accountable for any soft-bricks, hard-bricks, loss of data and/or information,
or anything else going wrong.
Introduction
MultiROM is one-of-a-kind multi-boot mod for HTC 10. It can boot any Android ROM as well as other systems like Ubuntu Touch, Plasma Active, Bohdi Linux or WebOS port. Besides booting from device's internal memory, MultiROM can boot from USB drive connected to the device via OTG cable. The main part of MultiROM is a boot manager, which appears every time your device starts and lets you choose ROM to boot. You can see how it looks on the left image below and in gallery. ROMs are installed and managed via modified TWRP recovery. You can use standard ZIP files to install secondary Android ROMs, daily prebuilt image files to install Ubuntu Touch and MultiROM even has its own installer system, which can be used to ship other Linux-based systems.
Features:
* Multiboot any number of Android ROMs
* Restore nandroid backup as secondary ROM
* Use for example Ubuntu Touch or Desktop alongside with Android, without the need of device formatting
* Boot from USB drive attached via OTG cable
Warning!
It _is_ dangerous. This whole thing is basically one giant hack - none of these systems are made with multibooting in mind. It is messing with boot sector and data partition. It is no longer messing with data partition or boot sector (actually the no-kexec workaround is messing with your boot sector), but it is possible that something goes wrong and you will have to flash factory images again.
Make backups. Always.
Now seriously: HTC 10 Warnings!
Beware of Dragons, Goblins, Gremlins and lingering primary_boot.img(RIP)
Due to lack of kexec-hardboot kernel support, I am messing with your boot partition!
Since we lack kernels with kexec-hardboot patch, I'm using a workaround to bypass that restriction, and although tested successfully on the HTC One M7, M8, M9, and HTC 10, as well as several other devices I'm not involved with, things can still go wrong, since I'm directly flashing your boot partition.
I have yet to see any negative effect of that, and version 4 of the no-kexec workaround is much more robust, you should still be aware that I'm "temp-flashing" your real boot partition.
If you are in doubt, either ask, or avoid it completely; MultiROM has always been a huge hack to begin with, and this is even more of a hack.
Always have a backup ready. Possibly even RUU! ... I have not had to, I have also not encountered any loss whatsoever, but better be safe!
Current problems on the HTC 10
* OTG is untested and unsupported at the moment
* exFAT partitions are not supported currently
^^ those haven't worked for quite a while, so it's not really HTC 10 specific
Encrypted devices: Your secondary ROMs do not know your device is encrypted, do not (again: do not) try to encrypt your device while booted into a secondary ROM.
Secure boot (ie require Password/Pattern/PIN on boot): Thanks to @Captain_Throwback who found out, that under certain circumstances (yet to be determined), your primary (possibly secondary as well) may loose the ability unlock your LockScreen using your Password/Pattern/PIN.
The same thing has been observed in TWRP restores, and although your password is correct and does decrypt your device, it breaks at the lockscreen for some reason.
I recommend you disable Password/Pattern/PIN on boot until / IF the issue is resolved, but in case you do find yourself in that situation, please go ahead and follow the instruction posted in the TWRP thread:
10. After I restored my Data backup and boot back to Android, I'm entering the correct PIN/password, but it's telling me the password is wrong. What happened, and how do I fix it?
It appears that sometimes after restoring a backup of Data where security was enabled (such as a PIN or password lock), the device does not recognize the correct password. There are two ways to avoid this issue:
Disable security in Android before making a backup of data.
After restoring Data, while still in TWRP, use the TWRP File Manager to navigate to /data/system and delete all the locksettings.* files (such as locksettings.db, etc). When you reboot, the password will be gone.
Please bear in mind, that some ROMs (particularly Sense based ROMs), will take a long time to boot up, well above 10minutes, so patience!
Installation
Not supported at this time: 1. Via MultiROM Manager app
This is the easiest way to install everything MultiROM needs. Install the app and select MultiROM and recovery on the Install/Update card. If the Status card says Kernel: doesn't have kexec-hardboot patch! in red letters, you have to install also patched kernel - either select one on the Install/Update card or get some 3rd-party kernel here on XDA. You are chosing kernel for your primary ROM, not any of your (future) secondary ROMs, so select the version accordingly.
Press "Install" on the Install/Update card to start the installation.
2. Manual installation
MultiROM has 3 parts (well, it should, but in this case it only has 2) you need to install:
Modified recovery (TWRP_3.x.x-x_multirom_pme_YYYYDDMM-pp.img) - download the IMG file from second post and use
TWRP itself to flash newer TWRP to recovery partition:
TWRP->Install-> select Images -> TWRP_3.x.x-x_multirom_pme_YYYYDDMM-pp.img -> to Recovery -> Reboot to Recovery
.
or
.
"fastboot flash recovery TWRP_3.x.x-x_multirom_pme_YYYYDDMM-pp.img"
(in download mode, for example)
Code:
C:ADBADB_10>adb reboot download
C:ADBADB_10>fastboot devices
FAxxxxxxxxxx fastboot
C:ADBADB_10>fastboot flash recovery TWRP_3.0.2-6_multirom_pme_20160917-02.img
target reported max download size of 800000000 bytes
sending 'recovery' (25700 KB)...
OKAY [ 2.001s]
writing 'recovery'...
(bootloader) HOSD CL#761759
(bootloader) [email protected]
(bootloader) [email protected]%
(bootloader) Update partition OK
(bootloader) [email protected]
OKAY [ 2.872s]
finished. total time: 4.878s
C:ADBADB_10>fastboot reboot-bootloader
rebooting into bootloader...
OKAY [ 0.004s]
finished. total time: 0.005s
MultiROM (multirom-YYYYMMDD-vXXd-UNOFFICIAL-pme.zip) - download the ZIP file from second post and flash it in the MultiROM Recovery.
.
.
Patched kernel - You can use either one of the stock ones in second post or third-party kernels which include the patch, you can see list in the second post. Download the ZIP file and flash it in recovery.
We don't have a patched kernel, so I'm using a workaround.
You current rom will not be erased by the installation.
Download links are in the third post.
Adding ROMs
1. Android
Go to recovery, enter the MultiROM section of TWRP (by clicking the icon in to top right corner) -> Add ROM. Select the ROM's zip file and confirm. As for the space, clean installation of stock 4.2 after first boot (with dalvik cache generated and connected to google account) takes 676mb of space.
2. Ubuntu Touch this is NOT SUPPORTED
Use the MultiROM Manager app to install Ubuntu Touch.
Ubuntu Touch is in development - MultiROM will have to be updated to keep up with future changes in Ubuntu, so there's a good chance this method stops working after a while and I'll have to fix it.
Using USB drive
During installation, recovery lets you select install location. Plug in the USB drive, wait a while and press "refresh" so that it shows partitions on the USB drive. You just select the location (extX, NTFS and FAT32 partitions are supported) and proceed with the installation.
If you wanna use other than default FAT32 partition, just format it in PC. If you don't know how/don't know where to find out how, you probably should not try installing MultiROM.
If you are installing to NTFS or FAT32 partition, recovery asks you to set image size for all the partitions - this cannot be easilly changed afterward, so choose carefully. FAT32 is limited to maximum of 4095MB per image - it is limitation of the filesystem, I can do nothing about that.
Installation to USB drives takes a bit longer, because the flash drive is (usually) slower and it needs to create the images, so installation of Ubuntu to 4Gb image on my pretty fast USB drive takes about 20 minutes.
Enumerating USB drive can take a while in MultiROM menu, so when you press the "USB" button in MultiROM, wait a while (max. 30-45s) until it searches the USB drive. It does it by itself, no need to press something, just wait.
Updating/changing ROMs
1. Primary ROM (Internal)
Flash ROM's ZIP file as usual, do factory reset if needed (it won't erase secondary ROMs)
Go to the MultiROM section of TWRP (by clicking the icon in to top right corner) and do Inject curr. boot sector.
2. Secondary Android ROMs
If you want to change the ROM, delete it and add new one. To update ROM, follow these steps:
Go to the MultiROM section of TWRP (by clicking the icon in to top right corner) -> List ROMs and select the ROM you want to update.
Select "Flash ZIP" and flash ROM's ZIP file.
In some cases, you might need to flash patched kernel - get corresponding patched kernel version from second post and flash it to the secondary ROM sama way you flashed ROM's ZIP file.
Explanation of recovery menus
Main menu
- Add ROM - add ROM to boot
- List ROMs - list installed ROMs and manage them
- Inject boot.img file - When you download for example kernel, which is distrubuted as whole boot.img (eg. franco kernel), you have to use this option on it, otherwise you would lose MultiROM.
- Inject curr. boot sector - Use this option if MultiROM does not show up on boot, for example after kernel installation.
- Settings - well, settings.
Manage ROM
- Rename, delete - I believe these are obvious
- Flash ZIP (only Android ROMs) - flash ZIP to the ROM, for example gapps
- Add/replace boot.img - replaces boot.img used by this ROM, this is more like developer option.
- Re-patch init - this is available only for ubuntu. Use it when ubuntu cannot find root partition, ie. after apt-get upgrade which changed the init script.
Screenshots
Special Thanks
@Tasssadar: Original author of MultiROM.
@Captain_Throwback: For testing, giving me a hard time, and warning you guys about the secure boot (ie require Password/Pattern/PIN on boot) issue.
zhuowei: For the fake properties idea.
Source code
MultiROM - https://github.com/Tasssadar/multirom (branch master)
Modified TWRP - https://github.com/Tasssadar/Team-Win-Recovery-Project (branch master)
Device files - ....
Everything is here:
https://github.com/multirom-htc
https://github.com/nkk71
XDA:DevDB Information
MultiROM, Tool/Utility for the HTC 10
Contributors
nkk71
Version Information
Status: Stable
Current Stable Version: 33testbuild
Stable Release Date: 2016-11-15
Created 2016-09-18
Last Updated 2016-11-15
FAQ and other notes
HTC 10 - Peculiarities / Bugs
There are no kexec-hardboot kernels for the HTC 10, so you need to have the no-kexec-workaround enabled. Please refer to post 4 for details.
.
A few notes about enabled adb in MultiROM boot menu: having adb enabled in MultiROM boot menu (TWRP->MultiROM->Settings->Enable ADB) may interfere with the ROMs "connection" (MTP, etc), possibly even prevent the ROM from booting (rarely, but I've seen it happen). Since this option is usually only used for debugging, I recommend to keep this option disabled.
.
Secure boot (ie require Password/Pattern/PIN on boot): Thanks to Captain_Throwback who found out, that under certain circumstances (yet to be determined), your primary (possibly secondary as well) may loose the ability unlock your LockScreen using your Password/Pattern/PIN.
The same thing has been observed in TWRP restores, and although your password is correct and does decrypt your device, it breaks at the lockscreen for some reason.
I recommend you disable Password/Pattern/PIN on boot until / IF the issue is resolved, but in case you do find yourself in that situation, please go ahead and follow the instruction posted in the TWRP thread:
10. After I restored my Data backup and boot back to Android, I'm entering the correct PIN/password, but it's telling me the password is wrong. What happened, and how do I fix it?
It appears that sometimes after restoring a backup of Data where security was enabled (such as a PIN or password lock), the device does not recognize the correct password. There are two ways to avoid this issue:
Disable security in Android before making a backup of data.
After restoring Data, while still in TWRP, use the TWRP File Manager to navigate to /data/system and delete all the locksettings.* files (such as locksettings.db, etc). When you reboot, the password will be gone.
Something not working, or you need help debugging
Please provide the following information:
a detailed explanation of the problem
.
the recovery.log (found in /tmp/recovery.log or by copying it to the sdcard and then copying it to PC)
.
the logs from /sdcard/multirom-klogs (zip those up, before uploading). that option needs to be enabled in TWRP->MultiROM->Settings
.
the link to the thread and name of file (+ which version) you are having problems with
.
due to the large size of some of these ROMs, I may not have time to download and test them, so please also upload the updater-script (found in ROM.ZIP under /META-INF/com/google/android/)
Supported File Systems for secondary ROMs
Currently only the following partitions can boot secondary ROMs:
Internal Storage
.
An external sdcard, properly partitioned with an ext4 partition (see below)
Partitioning your External SD Card
Warning: You will loose all information on your external sdcard!!
There is no way of retrieving that information, so copy everything to your PC before proceeding!!
In order to make a decent assessment of the size of your ext4 partition, below is a small table of some of the ROMs I've installed to my ext4 partition:
Code:
[U][B]2.5G BeanStalk-6.20-20160905-pm[/B][/U]
1.1G BeanStalk-6.20-20160905-pm/data
1.3G BeanStalk-6.20-20160905-pm/system
[U][B]1.4G cm-13.0-20160915-UNOFFICIA[/B][/U]
396M cm-13.0-20160915-UNOFFICIA/data
960M cm-13.0-20160915-UNOFFICIA/system
[U][B]3.8G ice-2.1.1_PERFUME_UHL_M60_[/B][/U]
1.7G ice-2.1.1_PERFUME_UHL_M60_/data
2.0G ice-2.1.1_PERFUME_UHL_M60_/system
[B][U]4.0G Viper10_3.1.0[/U][/B]
1.8G Viper10_3.1.0/data
2.1G Viper10_3.1.0/system
Please bear in mind, those installs have none or very few extra downloaded apps, which would also be using the data partition; if you need a reference for comparison, you can select Backup in TWRP, which will show you the size of your current /data partition (this excludes "Internal Storage")... mine is about 8GB !
FYI: I'm using a 200GB sdcard, and have it setup with a 30GB ext4 partition... but that's just me
Step 1: Partitioning
TWRP Main Menu
-> Advanced
-> Partition SD Card
-> selected Micro SDCard
Set the EXT Size to the size of your choice
Set Swap Size to zero
Set File System to ext4
-> swipe to proceed with repartitioning
go back to the main menu.
Example Screenshots:
TWRP Main Screen
Select Advanced
Select Partition SD Card, Micro SDCard is selected, press OK
Set the EXT Size to the size of your choice
Set Swap Size to zero
Set File System to ext4
then swipe to begin
Partitioning complete
Step 2 (optional, but recommended): Changing the first partition to exFAT
The repartitioning in step 1, has formatted your card with two partitions, the first one (used by ROMs as external storage) being FAT32 formatted. Since FAT32 has certain limitations, in particular the 4GB file size limit, it's recommended to reformat it as exFAT.
TWRP
-> Wipe
-> Advanced Wipe
-> select external_sd or Micro SDCard (whichever is shown in the menu)
-> Repair or Change File System
-> Change File System
-> select exFAT
-> swipe to reformat the first partition to exFAT
Example Screenshots:
Wipe Menu, select Advanced Wipe
Advanced Wipe Menu:
select external_sd or Micro SDCard (whichever is shown in the menu)
and click Repair or Change File System
Select Change File System
Select exFAT
Swipe to reformat to exFAT
Formatting complete
Device encryption
Since v32, MultiROM supports encryption on this device (it has to be added for each device separately). It works only with Android-based secondary ROMs and the secondary ROMs don't know the device is encrypted, so they would allow you to encrypt the device again - do not do that. If you're using password, pin or pattern for the encryption, MultiROM will ask you for the password on boot. If you're booting the primary ROM, then Android will ask you for the password _again_ - unfortunately, there is no way for me to pass the "unencrypted" status to Android. If you're booting secondary ROM, MultiROM will ask you for the password again after the reboot - that's because I have to unencrypt the /data partition after the ROM's kernel is loaded.
I could omit the second password prompt when booting secondary ROM by temporarily saving the password somewhere, but that's obviously unsafe. So is using encryption with unlocked device though, so I might add this later.About security
In order to make multi-booting possible, MultiROM has to sacrifice some security measures. Firstly, on secondary Android ROMs, /system is not mounted read-only. While there are other things preventing malicious software from messing with /system, this might potentialy make it easier for such software to attack that system.
What do the ROMs share?
All ROMs are separate, except /sdcard, which is shared between all Android ROMs.
How many ROMs can I have?/Where are the ROMs stored?
You can have as many ROMs as you can fit in your /sdcard. All the ROMs are stored in /sdcard/multirom/roms or on an USB drive. This folder is unaccessible in Android, to prevent mediascanner from scanning it. You can either in recovery, or obtain root and go to /data/media/0/multirom/roms.
The menu with all the ROMs won't show up during boot, how to fix it?
Either re-flash the MultiROM zip or go to recovery, Advanced -> MultiROM -> Inject curr. boot sector.
The reason for this is that something rewrote your boot.img, which happens for example when you flash a kernel. MultiROM's boot menu is part of the boot image, so it has to be added into it again.
My secondary ROM(s) no longer boot up, after I flashed a new primary ROM / Kernel / boot.img, and the MultiROM menu (as mentioned above) no longer appears
Please issue a restorecon on the particular ROM:
TWRP -> MultiROM -> select ROM in question -> Run Restorecon
Technical explanation
Usually most init.rc scripts will run a restorecon_recursive on /data and /mnt(also cache, but that's not too important for us)
Code:
restorecon_recursive /data
restorecon_recursive /mnt
this will supposedly restore file contexts (permissions if you prefer the older term) on all your data partitions, it will however break all your secondary ROMs as their system partition actually lives there, but the "permissions" have been overwritten to make it look like just normal data.
This is also why so many Android 7 (Nougat) MultiROM people (in other threads) are having so much trouble, as the file_contexts format has changed, and that hasn't been updated for the new format yet.
Downloads
Current Test Builds
All Current Test Builds can be found on androidfilehost under MultiROM TEST BUILDS
You should be using these, not the ones mentioned below!
Definition of Test Builds: These are stable builds which I have and am using (and testing). They contain the most up to date fixes as mentioned in the changelog under <tba>.
The main reason I'm calling them "Test Builds", is because they have not gone through extensive testing as what I would usually do for a "release version". I think most people would call them release versions, but I tend to be more conservative.
.
The second reason, they get uploaded to AFH instead of directly here, is two fold:
I'm maintaining the M7, M8, M9 and HTC 10 MultiROM versions, and uploading to AFH is easier and faster for me.
Updating the actual threads and posts, is too time consuming every time I want to push an update.
1. Main downloads
Modified recovery (based on TWRP): TWRP_3.0.2-6_multirom_pme_20160920-04.img
MultiROM Main ZIP: multirom-20160920-v33b-UNOFFICIAL-pme.zip
Not supported at this time MultiROM Manager Android app: Google Play or link to APK
AndroidFileHost (mirror & old versions): https://www.androidfilehost.com/?w=files&flid=114470
2. third-party kernels with kexec-hardboot patch
None exist at the moment, hence the use of the workaround.
3. Uninstaller
MultiROM uninstaller: multirom_uninstaller
Flash this ZIP file to remove MultiROM from your device. It will erase all secondary ROMs. If you don't want MultiROM menus in recovery, re-flash [RECOVERY][pme] TWRP touch recovery, but it is not needed - those menus don't do anything if MultiROM is not installed.
Changelog
MultiROM Managar App:
Code:
2016-11-11 MultiROM Manager App[-debug] version
=====================
* Add support for external storage
(allows listing, manipulating, and booting secondary ROMs on external storage)
* Highlight currently running ROM first
(also disallow deletion of it)
* Show ROMs in order of location (Current, then Internal, etc.)
* Allow duplicate ROM names if on separate partition
* Fix Widget
* Support for HTC 10 (pme)
* Support for HTC One M9 (hima)
* Support for HTC One M8
* Support for HTC One M7 (m7univ)
MultiROM:
Code:
2017-10-27 MultiROM v33
=====================
* New 'System Partition Mode' ROMs ([URL="https://github.com/nkk71/multirom/commit/dfb1a294ab55374b80bb6f14c2422850610c986d"]technical details[/URL])
* Android 8.0 compatibility
* Fix sdcardfs gid derivation ([URL="https://github.com/nkk71/multirom/commit/e0b749567f4ad976a5aabcdbd944f44f9c68b399"]technical details[/URL])
* vold_decrypt (Decryption on the HTC One M9 and HTC 10)
* trampoline511 (aka trampolineMk2)
* New default icons for Android ROMs when not set in app
* Code fixes and cleanups
2016-11-15 MultiROM v33
=====================
* Preliminary support for Android 7 (Nougat)
* Add support functions for MultiROM Manager App
(allows listing, manipulating, and booting secondary ROMs on external storage)
* Update no-kexec to version 4.1
+ changes to second boot detection
+ no-kexec versioning to allow auto-updating when needed
+ code cleanup
* Reboot to recovery on failed data partition mount
(avoids potentially being stuck in bootloop)
* Add reboot to recovery button on decryption screen when in second boot
* Code fixes
MultiROM v33b
=====================
* Fix [possible] boot img truncation when used in daisy-
chaining [older] systemless SuperSU, [B][U]and[/U][/B] rebooting
directly from AROMA Installer (info to follow later)
* Fixed mr_init_devices for certain devices (better fix will follow)
* Fix the auto-boot issue to properly fall back to primary
when secondary is deleted
MultiROM v33a
=====================
* Initial port for the HTC 10 (pme)
* Updated no-kexec to version 4
* autoboot: "Use last booted ROM" now works with external ROMs
previous changelogs are in M7/M8/M9 threads
i'll consolidate at some point hopefully
Recoveries:
Code:
2017-10-27
=====================
* Fully merged with official TWRP 7.1 branch
* New 'System Partition Mode' ROMs ([URL="https://github.com/nkk71/multirom/commit/dfb1a294ab55374b80bb6f14c2422850610c986d"]technical details[/URL])
* Android 8.0 compatibility
* Auto detect possible use of legacy props
* vold_decrypt (HTC decryption on the M9 and 10)
* Install from backup using a System_Image
* libbootimg: Updated to support AnyKernel2
* Fixes for some boot.img patchers
* Block mount/unmount of secondary partitions
* Use own loop devices to avoid conflicts with other installers
* Code fixes and cleanups
2016-11-15 (33e)
=====================
* Fix restorecon for secondary ROMs
* Rebased on android-7.0 branch
* Preliminary support for Android 7 (Nougat)
* Fix no-kexec restore primary_boot.img on devices
with PIN/Pattern/Password encryption
* Fix flashing of certain gapps zip's which are
missing the updater-script file
[STRIKE]* Add warning on failed injection[/STRIKE]
* Minor code cleanup
2016-09-20 (33b)
=====================
* Fix some installer scripts using certain mount/unmount commands
* Wake up screen before starting flash (fixes AROMA installer issues)
* Changed fstab so external ext4 won't get wiped with a factory reset
2016-09-17 (33a)
=====================
* initial port for the HTC 10 (pme)
* Based on TWRP 3.0.2 android-6.0 tree & branch
* Includes official TWRP commits up to Aug 23, 2016
previous changelogs are in M7/M8/M9 threads
i'll consolidate at some point hopefully
No-kexec workaround (version 4)
As of this version you need to manually enable the no-kexec workaround.
Actually, depending on the developer, (s)he may have already enabled it. Nonetheless, you can still choose to override the settings:
Go to TWRP -> MultiROM -> Settings
and enable the No-KEXEC workaround option
once you do you'll also have the option for ADVanced settings, please see below for a detailed description, though in most cases the default should suffice.
Explanation of the no-kexec workaround advanced options
(the Info page is supposed to provide the same information as here, but I haven't added that yet)
1- Use no-kexec only when needed
This should be the default for most users, the other options are more intended for advanced uses (kernel debugging, and such).
If MultiROM detects a kexec-hardboot enabled kernel in primary slot, it will use the standard kexec method to boot the secondary. If on the other hand it does not detect that the kernel supports kexec-hardboot then it will use the workaround.
2- ... but also ask for confirmation before booting
Same as option 1 above, but in addition you will be presented with a confirmation message, if the workaround is about to be used:
3- Ask whether to kexec or use no-kexec on booting
If the kernel in primary slot does support kexec-hardboot'ing then you will be presented with a choice of which method to use
If the kernel does not support kexec-hardboot then you'll be informed as in option 2 above
4- Always force using no-kexec workaround
Forces the no-kexec workaround to be used, even if the kernel in primary slot has kexec-hardboot support
Options 2 and 3, always present the user with a GUI confirmation, whereas option 1 and 4 will act as instructed without prompting the user.
Visual feedback provided by the Booting... card
Regular kexec-hardboot boot
Booting using no-kexec-workaround
How does all this work, etc
The workaround:
MultiROM TWRP recovery works, and is able to flash ROMs to secondary
MultiROM in essence works (in particular, able to change the mount points during bootup)
what does not work is being able to use the secondary ROM's kernel (due to the lack of kexec-hardboot kernel and tools)
So how do we deal with booting any ROM if we can't use the proper kernel for the ROM?
Easy :
Upon selection of the ROM during MultiROM boot menu, we do the following:
"flash" secondary boot.img to primary partition slot
initiate a full reboot (secondary boot.img is in primary slot)
let the ROM auto-boot up on second boot
The good part:
It works.
.
Every secondary ROM has a boot.img file we can easily access to use the workaround; when you flash a ROM in MultiROM TWRP, not only are the "virtual" system, data, and cache partitions created, but also the boot.img.
The secondary ROMs' boot.img will be found /data/media/0/multirom/<name of rom>/boot.img or if it's on your external ext4 in the appropriate rom folder
We use that file and flash it to primary real boot partition and then upon second boot, the correct boot.img is in place for the correct ROM.
The bad part:
Unlike secondary ROMs, the primary ROM does not have a boot.img file... since it is the primary ROM, the boot.img should always be in the real boot partition, since MultiROM expects the primary kernel to have kexec-hardboot capability, but it does not, so I just go ahead and mess with your primary boot partition.
Since we have no "boot.img" file for the primary, my workaround makes a backup of the boot partition and names it primary_boot.img
In version 4 of the workaround, this backup is created and used only when booting a secondary ROM. When a secondary ROM is selected it's boot.img is flashed to primary slot, upon booting into the secondary ROM, the primary_boot.img is restored.
Long story short: the difference between kexec and no-kexec-workaround
Usual kexec-hardboot MultiROM
Select secondary ROM
MultiROM detects a boot.img
MultiROM reads the secondary boot.img into memory
MultiROM initiates a kexec second boot but into the secondary boot.img from above
MultiROM continues
No-kexec-workaround MultiROM
Select secondary ROM
MultiROM detects a boot.img
MultiROM flashes the secondary boot.img into the primary boot partition
MultiROM initiates a normal second boot but with the secondary boot.img in the real boot partition
MultiROM restores the primary_boot.img and continues as usual
so the difference is in point 3... whereas normal kexec'ing loads the secondary boot.img into memory and goes from there, the workaround, actually flashes it to the real primary boot partition... and continues normally from there
Devices using the no-kexec-workaround successfully
MultiROM threads for:
HTC One M7
HTC One M8
HTC One M9
.
Moto G 2015 by GtrCraft
Moto X Play by GtrCraft
OnePlus One (starting here) by KINGbabasula
OnePlus 3 by martinusbe
OnePlus X by martinusbe
Sony Xperia Z5 by Myself5
Sony Xperia L by STRYDER~007
Sony Xperia SP by Adrian DC
Xiaomi Redmi 2 by premaca
Wileyfox Swift by @beroid
.
(possibly Samsung Note 4, unsure if that was continued or not)
Others; unofficial builds? (if you are, kindly let me know, and I'll add you to the list)
reserved for @Captain_Throwback
Oops
files are in the download section, the posts need some editing, bug gonna be a bit busy tomorrow
so enjoy
Ok,ok,you will say that im noob,but i flashed both files,flash the RR ROM,but the multirom menu doesnt show and it boots me directly to primary rom
azZA_09 said:
Ok,ok,you will say that im noob,but i flashed both files,flash the RR ROM,but the multirom menu doesnt show and it boots me directly to primary rom
Click to expand...
Click to collapse
That's not a "bug report"
Please provide detailed information, and logs... BTW, I didnt add the advanced kernel logging feature "by mistake", it's so you can get "easier" logs... but if those exist, then you still need to pull a kmsg
Code:
adb pull /sys/fs/pstore/console-ramoops
No boot menu, normally means that trampoline (if it's in the above log), wasnt able to mount data... or it's not even there
nkk71 said:
That's not a "bug report"
Please provide detailed information, and logs... BTW, I didnt add the advanced kernel logging feature "by mistake", it's so you can get "easier" logs... but if those exist, then you still need to pull a kmsg
Code:
adb pull /sys/fs/pstore/console-ramoops
No boot menu, normally means that trampoline (if it's in the above log), wasnt able to mount data... or it's not even there
Click to expand...
Click to collapse
Sorry dude,Im at work atm and I think too slow ). I will provide logs tomorrow,but maybe somebosy can provide them since then. Once again,great job and im sure you will fix every problem
azZA_09 said:
Sorry dude,Im at work atm and I think too slow ). I will provide logs tomorrow,but maybe somebosy can provide them since then. Once again,great job and im sure you will fix every problem
Click to expand...
Click to collapse
open a terminal emulator on your phone, and
Code:
cat /sys/fs/pstore/console-ramoops | grep tramp
then you'll see if trampoline is even in there
nkk71 said:
open a terminal emulator on your phone, and
Code:
cat /sys/fs/pstore/console-ramoops | grep tramp
then you'll see if trampoline is even in there
Click to expand...
Click to collapse
It shows only the # after that
Download links are not working.
azZA_09 said:
It shows only the # after that
Click to expand...
Click to collapse
then probably the log is way after trampoline & multirom, so you need to enable "kernel logging"... I didnt add that by mistake
http://forum.xda-developers.com/devdb/project/?id=17079#downloads
Tab isn't showing up for me, but that link should work.
jsaxon2 said:
Download links are not working.
Click to expand...
Click to collapse
They're supposed to be here
If you can't access them, I've uploaded them to AFH as well
Got it installed and booted up cm13 as secondary. Working good so far. Thanks for this. I'm back on Viper running from primary.
jsaxon2 said:
Got it installed and booted up cm13 as secondary. Working good so far. Thanks for this. I'm back on Viper running from primary.
Click to expand...
Click to collapse
hmm is that a complaint? ... sounds rather positive, so i'm unsure. i usually only hear complaints
Well, if it's not, thanks for reporting back :good:
I currently have an old version of Viper10 as primary / daily
and as secondaries:
ice-2.1.1_PERFUME_UHL_M60_SENSE80GP_HTC_Europe_1.90.401.3
BeanStalk-6.20-20160905-pme
cm-13.0-20160915-UNOFFICIAL-pme
and some other weird stuff
nkk71 said:
hmm is that a complaint? ... sounds rather positive, so i'm unsure. i usually only hear complaints
Well, if it's not, thanks for reporting back :good:
I currently have an old version of Viper10 as primary / daily
and as secondaries:
ice-2.1.1_PERFUME_UHL_M60_SENSE80GP_HTC_Europe_1.90.401.3
cm-13.0-20160915-UNOFFICIAL-pme
and some other weird stuff
Click to expand...
Click to collapse
Lol, not a complaint, it's a compliment. You have done excellent work. Just wanted to report that it is working. I'm too tired to mess with it anymore, but awesome that I can test CM builds and get right back to my daily driver.
Job well done.
jsaxon2 said:
Lol, not a complaint, it's a compliment. You have done excellent work. Just wanted to report that it is working. I'm too tired to mess with it anymore, but awesome that I can test CM builds and get right back to my daily driver.
Job well done.
Click to expand...
Click to collapse
Thank you, I do enjoy positive feedback, Hope you enjoy it
as well as comments, thoughts and ideas.
@ all, If something is wrong, please be as descriptive as possible... please no "it doesn't work" posts.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Introduction
MultiROM is one-of-a-kind multi-boot mod. It can boot any Android ROM as well as other systems like Ubuntu Touch, once they are ported to that device. Besides booting from device's internal memory, MultiROM can boot from USB drive connected to the device via OTG cable. The main part of MultiROM is a boot manager, which appears every time your device starts and lets you choose ROM to boot. You can see how it looks on the left image below and in gallery. ROMs are installed and managed via modified TWRP recovery. You can use standard ZIP files to install secondary Android ROMs and MultiROM even has its own installer system, which can be used to ship other Linux-based systems.
Features:
* Multiboot any number of Android ROMs
* Restore nandroid backup as secondary ROM
* Boot from USB drive attached via OTG cable
You can also watch a video which shows it in action.
Warning!
It _is_ dangerous. This whole thing is basically one giant hack - none of these systems are made with multibooting in mind. It is no longer messing with data partition or boot sector, but it is possible that something goes wrong and you will have to flash factory images again. Make backups. Always.
Installation
Manual installation
Firstly, there are videos on youtube. If you want, just search for "MultiROM installation" on youtube and watch those, big thanks to all who made them. There is also an awesome article on Linux Journal.
MultiROM has 2 parts you need to install + one optional (deprecated) :
MultiROM (multirom-YYYYMMDD-v33x-device.zip) - download the ZIP file from second post and flash it in recovery.
Modified recovery (multirom-YYYYMMDD-recovery-fota-device.zip) - download the ZIP file from second post and use a recovery
to flash it into the FOTA partition (see TWRP 3 for more informations).
UNNECESSARY: Patched kernel - You can use those kernels on most Marshmallow based primary ROMs to add kexec boot support.
Kexec support is no longer required thanks to the no-kexec workaround by nkk71.
For convenience reasons, I enabled the workaround by default if kexec is not found.
You current rom will not be erased by the installation.
Download links are in the second post.
Adding ROMs
1. Android
Go to recovery, select Advanced -> MultiROM -> Add ROM. Select the ROM's zip file and confirm.
Recommended values are (not needed for ext4 storages) :
Cache : Keep default value
Data : Minimum 4000 for proper usage
System : 1500 to 2000 should be enough for most installs
Using USB drive
During installation, recovery lets you select install location. Plug in the USB drive, wait a while and press "refresh" so that it shows partitions on the USB drive. You just select the location (extX, NTFS and FAT32 partitions are supported) and proceed with the installation.
If you wanna use other than default FAT32 partition, just format it in PC. If you don't know how/don't know where to find out how, you probably should not try installing MultiROM.
If you are installing to NTFS or FAT32 partition, recovery asks you to set image size for all the partitions - this cannot be easilly changed afterward, so choose carefully. FAT32 is limited to maximum of 4095MB per image - it is limitation of the filesystem, I can do nothing about that.
Installation to USB drives takes a bit longer, because the flash drive is (usually) slower and it needs to create the images, so installation of Android to 4Gb image on a pretty fast USB drive takes about 20 minutes maximum.
Enumerating USB drive can take a while in MultiROM menu, so when you press the "USB" button in MultiROM, wait a while (max. 30-45s) until it searches the USB drive. It does it by itself, no need to press something, just wait.
Updating/changing ROMs
1. Primary ROM (Internal)
Flash ROM's ZIP file as usual, do factory reset if needed (it won't erase secondary ROMs)
Go to Advanced -> MultiROM in recovery and do Inject curr. boot sector.
OPTIONAL: Reflash the kernel patcher to add kexec support
2. Secondary Android ROMs
If you want to change the ROM, delete it and add new one. To update ROM, follow these steps:
Go to Advanced -> MultiROM -> List ROMs and select the ROM you want to update.
Select "Flash ZIP" and flash ROM's ZIP file.
Explanation of recovery menus
Main menu
- Add ROM - add ROM to boot
- List ROMs - list installed ROMs and manage them
- Inject boot.img file - When you download for example kernel, which is distrubuted as whole boot.img (eg. franco kernel), you have to use this option on it, otherwise you would lose MultiROM.
- Inject curr. boot sector - Use this option if MultiROM does not show up on boot, for example after kernel installation.
- Settings - well, settings.
Manage ROM
- Rename, delete - I believe these are obvious
- Flash ZIP (only Android ROMs) - flash ZIP to the ROM, for example gapps
- Add/replace boot.img - replaces boot.img used by this ROM, this is more like developer option.
- Re-patch init - this is available only for ubuntu. Use it when ubuntu cannot find root partition, ie. after apt-get upgrade which changed the init script.
Source code
MultiROM - https://github.com/AdrianDC/multirom_core (branch master)
Modified TWRP - https://github.com/multirom-dev/Team-Win-Recovery-Project (branch master)
Device Tree - https://github.com/XperiaMultiROM/android_device_sony_dora (branch master)
Kernel - https://github.com/AdrianDC/kernel-sony-copyleft (branch master)
TWRP sources - https://github.com/AdrianDC/twrp_development_sony/commits/device_sony_dora (branch device_sony_dora)
MultiROM available for Dora also thanks to :- [MENTION]Tasssadar[/MENTION]
- [MENTION]nkk71[/MENTION]
- The XperiaMultiROM team
XDA:DevDB Information
MultiROM for Xperia X Performance, Tool/Utility for the Sony Xperia X Performance
Contributors
Adrian DC
Source Code: http://forum.xda-developers.com/google-nexus-5/orig-development/mod-multirom-v24-t2571011
Version Information
Status: No Longer Updated
Created 2016-10-08
Last Updated 2019-08-06
Reserved
Downloads
1. Main downloads
MultiROM for Xperia X Performance (Dora): https://mega.nz/#F!Ckd2HbwI!NFv3bh7J87lHTi3cujnV_g
Downloads mirror : https://basketbuild.com/devs/AdrianDC
MultiROM: multirom-2017MMDD-v33x-device.zip
Modified recovery (based on TWRP 3): multirom-2017MMDD-recovery-fota-device.zip
Regular TWRP with my same sources: https://mega.nz/#F!DtsERIzb!OFINTFpTQ6CF85alkcIpgA
2. Uninstaller
MultiROM uninstaller: multirom-2017MMDD-uninstaller-device.zip
Flash this ZIP file to remove MultiROM from your device. It will erase all secondary ROMs.
Otherwise, reflash a ROM or a boot.img without injection (or the v33x zip) to remove MultiROM boot from your device.
Then delete the "multirom..." folders from internal & external storages.
If you don't want MultiROM menus in recovery, re-flash a normal TWRP, but it is not needed,
those menus don't do anything if MultiROM is not installed.
How to install for the first time
Flash the 2 MultiROM zips as explained
Reboot to the FOTA Recovery (Volume +)
In MultiROM TWRP, Add a ROM, set everything properly
Wait for the ROM to be installed (can take a while)
In MultiROM screen, choose the ROM location
For the concerned ROM, "Flash zip" for wished zips (GApps, SuperSU, Addons...)
Reboot the phone
How to install only the recovery
(Option 1) Flash the ...-recovery-fota-device.zip from a recovery
(Option 2) Extract the img from ...-recovery-fota-device.zip,
then use 'fastboot flash recovery twrp.img' to install to FOTA partition
Reboot the phone
Migrate Stock ROM to internal or MicroSD
Reboot to the FOTA Recovery (on boot or with power keys)
Ensure you have already installed Sony Stock Patcher or a custom bootimage
Perform a ROM Backup (at least system, data, cache, boot)
Add a ROM, select the previously made backup
Wait for the ROM to be installed (can take a while)
Reboot the phone
Update Stock ROM on internal or MicroSD
Backup internal data / storage
Upgrade to last FTF official release you want
Reboot to the FOTA Recovery (on boot or with power keys)
Install the Recovery image you want to use
Install Sony Stock Patcher or a custom bootimage
Perform a ROM Backup (at least system, cache, boot)
Add a ROM, select the previously made backup
Wait for the ROM to be installed (can take a while)
Inside *Storage*/multirom-*/, move the data folder
from the old installation to the new one
Rename and delete the ROMs as you wish
Reboot the phone
Changelog
Code:
MultiROM v33x - TWRP 3.1.1 - 07/06/2017
=========================================
* New implementation to handle external boot
on Ext4 / F2FS MicroSD or USB Drive in order
to allow access to the external storage for media,
through the storage 'external_multirom' path
MultiROM v33x - TWRP 3.1.1 - 24/05/2017
======================================
* Fix touchscreen init race condition on a specific variant
MultiROM v33x - TWRP 3.1.1 - 22/05/2017
======================================
* Include all recent improvements from TWRP 3.1.1
* Touchscreen init improvement to match Stock .223
* Fix for SDCardFS full support of the internal storage
* Known common issue : encrypted boot for now
MultiROM v33x - TWRP 3.1.0 - 17/03/2017
======================================
* Include all recent improvements from TWRP 3.1.0
* Proper TWRP support of Stock Nougat encryption
* Known common issue : encrypted boot for now
* Fix USB handling for Sony Stock ROMs
MultiROM v33x - TWRP 3.0.3 - 05/03/2017
======================================
* Built in a clean new tree of Android 7.1.1 (replaces 6.0)
* Multiple fixes to support 7.1 changes
* Include all recent improvements from TWRP 3.0.3
* Fix the 7.1 busybox cpio corruption, needed for MultiROM
MultiROM v33x - TWRP 3.0.2 - 22/12/2016
=========================================
* Kernel updated to Stock Nougat, with proper
> and minimal patching for custom changes
* Touchscreen handling of Stock Nougat
* Encryption handling of Stock Nougat
MultiROM v33x - TWRP 3.0.2 - 18/12/2016
=========================================
* Minor improvements of MultiROM
* Added support for Sony Stock ELF (64 bits) bootimages
* libbootimg changes from my recent updates
MultiROM v33x - TWRP 3.0.2 - 08/10/2016
=========================================
* Initial dora public release
Recent ROMs tested so far :
Code:
Stock SONY 7.1 : OK (Primary & Second)
Stock SONY 7.0 : OK (Primary & Second)
Stock SONY 6.0 : OK (Primary & Second)
AOSP 7.1.1 : OK (Primary & Second, Work in Progress)
CyanogenMod 14.1 : OK (Primary & Second, Work in Progress)
Other ROMs : To confirm & report here
Reserved
FAQ and other notes
About security
In order to make multi-booting possible, MultiROM has to sacrifice some security measures. Firstly, on secondary Android ROMs, /system is not mounted read-only. While there are other things preventing malicious software from messing with /system, this might potentialy make it easier for such software to attack that system.
Next, MultiROM doesn't work with /data encryption. Not many people who use custom ROMs also use encryption anyway, so that isn't much of a concern.
What do the ROMs share?
All ROMs are separate, except /sdcard, which is shared between all Android ROMs.
Why is my USB connection to computer not detected ?
Uncheck the "Enable ADB" option in MultiROM Settings.
How many ROMs can I have?/Where are the ROMs stored?
You can have as many ROMs as you can fit in your /sdcard. All the ROMs are stored in /sdcard/multirom/roms or on an USB drive./external SD card. This folder is unaccessible in Android, to prevent mediascanner from scanning it. You can either in recovery, or obtain root and go to /data/media/0/multirom/roms.
Can I have different versions of Android working alongside
Yes.
The menu with all the ROMs won't show up during boot, how to fix it?
Either re-flash the MultiROM zip or go to recovery, Advanced -> MultiROM -> Inject curr. boot sector.
The reason for this is that something rewrote your boot.img, which happens for example when you flash a kernel. MultiROM's boot menu is part of the boot image, so it has to be added into it again.
Something wrong happened, I lost something or it's really laggy
You have been warned about making backups & the fact this is more experimental than stable.
You alone will be responsible for loosing data or having an usable ROM when you really needed it.
Everyone in this thread will try to help you, but we can't do backups of your data ourselves.
Thanks for your understanding, remember to read the previous comments and please try to help each other.
Current local manifest of the MultiROM build
Code:
<!-- https://github.com/AdrianDC/multirom_development_sony -->
Informations : My 2017 releases of MultiROM and of TWRP include full support for Nougat encryption inside TWRP.
For MultiROM boot UI, Nougat encryption is not yet fully working, it's a common issue and I'm looking into it.
MultiROM 20170317 update : Includes my fix for USB handling inside Sony Stock ROMs,
due to stock files permissions losses : https://github.com/AdrianDC/multirom_core/commit/f42b7c5c7c07471882193c2e1e6d53f17dc71236
Would this work on xperia x too?
Gesendet von meinem F5121 mit Tapatalk
Can I use it with Xperia XZ?
86chan said:
Can I use it with Xperia XZ?
Click to expand...
Click to collapse
I have MultiROM "almost" ready for XZ but I'll release it once I first check something.
However you'll find my TWRP for XZ in the Sony Stock Patcher thread.
AdrianDC said:
I have MultiROM "almost" ready for XZ but I'll release it once I first check something.
However you'll find my TWRP for XZ in the Sony Stock Patcher thread.
Click to expand...
Click to collapse
Thank you for answering my question.
MultiROM 20170522: Release based on TWRP 3.1.1, including changes to match 7.1.1 touchscreen init.
Regular TWRP 20170521: TWRP 3.1.1 release, including changes to match 7.1.1 touchscreen init.
Note about MultiROM and SDCardFS devices
Here's a general note about MultiROM that involves issues with SDCardFS usage:
More and more devices OEMs are starting to use SDCardFS enabled by default on their releases.
Depending on the device and installations, we started finding random behaviours of MultiROM secondary ROMs.
Basically the issue is that a booted secondary ROM using SDCardFS would prevent access to the "Internal Storage",
mostly visible by an "unmounted" internal storage and mostly all Google applications failing in sequence.
A more in-depth search shows that running an "ls -l" on the internal storage paths
fail directly with an "-EXDEV" > "cross-device linkage" error, which means the original and target devices don't match.
The SDCardFS kernel driver is actually returning this -EXDEV failure when it detects such an issue.
Going a step further means comparing which partitions are mounted where, through "mount".
We can confirm SDCardFS is being used by the ROM through the following outputs :
/data/media on /mnt/runtime/default/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,uid=1023,gid=1023,multiuser,allow_utime_grp)
/data/media on /storage/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,uid=1023,gid=1023,multiuser,allow_utime_grp)
/data/media on /mnt/runtime/read/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,uid=1023,gid=1023,multiuser,allow_utime_grp)
/data/media on /mnt/runtime/write/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,uid=1023,gid=1023,multiuser,allow_utime_grp)
However, it also means that /data/media is "mounted" as an sdcardfs file system in the regular internal storage paths.
And the interesting part concerning MultiROM is that we actually mount /data/media on our own to match our paths.
On a "working" secondary installation, we have this type of mount :
/dev/block/mmcblk0p54 on /data/media type ext4 (rw,seclabel,relatime,noauto_da_alloc,errors=panic,data=ordered)
However on a "failing with -EXDEV" secondary installation, we have this type of mount :
/dev/block/mmcblk0p54 on /data/media/0 type ext4 (rw,seclabel,relatime,noauto_da_alloc,errors=panic,data=ordered)
As we can see, the internal partition is being mounted on /data/media/0, which is not an issue by itself,
but the fact the /data/media is later mounted as internal storage means that we're creating a cross-device linkage:
/data/media is owned by the /data partition, running from our external storage with MultiROM, and its sub-path ./0 is on the Internal,
whereas the working situation is that /data/media is directly owned by its original partition hence no cross-device linkage.
Now the question would be : Why the mounted path differs ?
The "multirom_create_media_link" function handles the internal storage mounting (https://github.com/multirom-dev/multirom/commit/c9bd12186baa6911d46138c6c77379c6c3eaa767)
A proper output of this function in the kernel logs is "multirom: Making media dir: api 25, media_new 1, /realdata/media to /data/media"
and a faulty one for SDCardFS to work is "Making media dir: api 25, media_new 0, /realdata/media to /data/media/0"
This was never an issue since 4+ years because the paths and loop would be invisibly used,
and the missing path created through the recursive mkdir hence path resolution was never an issue.
On the other hand, SDCardFS prevents this linkage therefore introducing the issue.
An initial fix can be found here, tested on the Xperia X Performance with and without an internal storage matching the issue.
https://github.com/multirom-dev/multirom/pull/11/commits/81295cd6971317d955cb0c78b41d147b891a601b
The change is also valid for non-sdcardfs devices, tested on Sony 8960 for example, since the path is used the same way.
I wrote this in public here in case other MultiROM devs or new maintainers would face such an issue,
and would not (yet) use our "multirom-dev" sources for updated MultiROM projects.
New special release of MultiROM from 20170607.
Implements something I wished to fix for at least 10 months on MultiROM:
External storage (MicroSD or USB Drive) using Ext4 or F2FS file systems are
now finally accessible from the Android userspace once booted from them,
by means of a special new storage folder called 'external_multirom' that serves
as a bridge between the external storage and Android.
You can therefore once again use the external MicroSD with Ext4 and store music, data, ...,
without Android blocking access to it with "Corrupted storage" notifications.
Why use Ext4 / F2FS MicroSD in the first place ? With MultiROM, these allow us
to install secondary ROMs directly on the MicroSD without setting space sizes / limits,
therefore directly on the drive instead of independent disk images as done for vFAT / FAT32.
The storage space is unlimited / shared between all installs and are faster to create / run / use.
About SDCardFS : A similar issue as the one reported and fixed in the previous post happens here,
the 'external_storage' is also a cross-device linkage and SDCardFS will fail on purpose to give access to the path.
Disabling SDCardFS (through the build.prop property) allows to use the ROM as usual while also accessing the path.
All technical details about the issue and the implementation can be seen here : https://github.com/AdrianDC/multirom_core/commit/0acfa4c53429a7fcf7c2c573b857f2ae69ca5b5a
Is this likely to work for the Xperia XA (F3111)? What would need doing if not?
Could you try to port this for Xperia X/X Compact Variants?
Building guide isn't clear for me, as try to Port MultiROM to S650 Devices
...
Dezqo said:
MultiRom doesn't seem to show up on boot even if I "inject current boot sector".
It is working though as the recovery works fine and I already installed a secondary rom.
I can't boot into it though.
Click to expand...
Click to collapse
See the third post. You can't keep your device encrypted if you want the bootimage to access data. Therefore a factory reset to erase the data partition (including internal data, careful) is needed.
...
Dezqo said:
Thanks for answering, no idea how I didn't notice that
Since there is no way to "decrypt" without wiping, is this completely impossible or just not yet integrated?
It's my day to day phone and even though I make nandroid backups I can't to wipe right now.
Click to expand...
Click to collapse
An easy way would be backup, save internal files to a computer, factory reset, restore data.
Factory reset is important, not just a "Wipe" because the encryption sectors would be kept with a wipe.
...
Dezqo said:
Thanks. Just to be clear, if I make a backup from TWRP to my sdcard and then factory reset, will the device then be decrypted or are any more steps necessary?
Sorry for all the questions but it seems not many people have actually tried MultiRom on this device.
Click to expand...
Click to collapse
Be specific. The term sdcard mostly designates internal storage.
Therefore you should backup to the "MicroSD" + backup all your relevant data from internal to MicroSD or PC.
Once factory reset, data partition is formatted, hence you start clean.
TWRP recommends to reboot to recovery at this stage, which you should do as advised.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Preamble
When TWRP first appeared for the S10 range of devices, it quickly became clear that there were some major issues with the initial builds.
Many users were understandably frustrated at losing the ability to boot their device after shutting it down, and at being unable to update Magisk after installing TWRP.
A number of users took to contacting me privately for support. I answered their questions and even shared fixed images in a few cases, but the number of support requests was rising daily and I could not keep pace with the demand.
Given that the poster of the original images (Geiti94) was evidently unable to offer fixed TWRP images in a timely fashion, I ultimately took the liberty of doing so myself in a posting to the original TWRP thread as a service to the community.
Whilst this served to relieve the immediate pressure, the ongoing need to fix bugs and make further enhancements to the software made a fork of the original project inevitable, so I have taken the step of promoting it to its own DevDB project and thread here on XDA.
Credit goes to Geiti94 for conducting the time-consuming initial legwork and releasing the original builds. His is the foundation on which this work now builds. This fork in no way implies any disrespect to him, but does strongly acknowledge the need of the S10 user base to be supplied with proper, working images and timely updates.
Samsung system-as-root devices
All new devices launched with Android 9 are required to be factory-configured as system-as-root devices. The ramdisk image formerly found in boot.img is now merged with system.img.
For Samsung devices such as the Galaxy S10 series, this means that boot.img can no longer be used to root the device. Instead, Magisk is installed to the recovery partition and the user must subsequently always boot from that partition, regardless of whether TWRP or Android is desired. The device's hardware keys are used at boot time to select between Magisk-rooted Android and TWRP.
This configuration dictates that TWRP and Android share a common recovery kernel. However, because TWRP cannot function with a stock kernel, a modified kernel must be compiled from Samsung's source code. Unfortunately, this kernel is sensitive to changes in Samsung's firmware releases from one month to the next, meaning that problems can arise if a given kernel is used with firmware newer than the version the kernel was intended for.
This unfortunate situation necessitates semi-regular maintenance releases of TWRP to keep the kernel in step with the latest version of the S10 series firmware. This requirement is further complicated by the fact that any given release of Samsung's modified kernel source code typically trails the associated firmware release by anything from a few days to a few weeks.
TWRP without Magisk
If your device is currently still unrooted and running stock firmware, you are strongly advised not to proceed with installing TWRP. First root your device with Magisk, using John Wu's excellent Samsung system-as-root-instructions for patching the firmware's AP file. Only when you have completed that procedure should you return here and continue from the Image Preparation section.
If you insist on proceeding with installing TWRP to a stock device without Magisk, you will need — at a minimum — to flash a vbmeta.img with verity disabled or you will render your device unable to boot. You can construct such an image using the following command:
Code:
$ avbtool make_vbmeta_image --out vbmeta.img
Alternatively, if you don't have a copy of avbtool at hand, the following piece of shell code will do the trick on the device itself:
Code:
h=$(printf '4156423%08d1%0240d617662746f6f6c20312e312e3%0230d')
d=''
i=0
while [ $i -lt ${#h} ]; do
d="$dx${h:$i:2}"
i=$((i+2))
done
printf "$d" > vbmeta.img
Next, flash this to the vbmeta partition, using either Heimdall or Odin.
Code:
# heimdall flash --VBMETA vbmeta.img
You may then proceed with installing TWRP according to the instructions below.
Image preparation
In contrast to the original Geit94 release, these and subsequent TWRP images will not be supplied pre-rooted with Magisk. Whilst it would be trivial to offer them in this format, this kind of binary distribution of Magisk is against the terms of use laid out by Magisk's developer, John Wu.
To root the TWRP image yourself, simply use Magisk Manager to Select and Patch a File. Provide your freshly downloaded TWRP image file as the input.
Installation
You are now ready to flash the resulting magisk_patched.img image file to your device's recovery partition.
One quick and easy way to do this on an already rooted device is from a root shell:
Code:
# f=/storage/emulated/0/Download/magisk_patched.img; dd if=$f of=/dev/block/sda15 bs=$(stat -c%s $f)
1+0 records in
1+0 records out
61734912 bytes transferred in 0.426 secs (144917633 bytes/sec)
If TWRP is already installed and you are merely updating it, you may, of course, use TWRP itself to flash the new version.
If the device is not yet rooted (or even if it is), you may use Odin in Windows, but you will need to rename and tar the image first. Otherwise, Odin will not understand what to do with the image.
For example:
Code:
$ mv twrp-beyond[012]lte.img recovery.img
$ tar cf twrp-beyond[012]lte.img.tar recovery.img
And if rebooting to Windows is too disruptive, there's always Heimdall:
Code:
$ sudo heimdall flash --RECOVERY twrp-beyond[012]lte.img
Download
The latest unofficial local builds currently available are:
Android 10
G970F (S10e): twrp-beyond0lte-3.4.0-4_ianmacd.img
G973F (S10): twrp-beyond1lte-3.4.0-4_ianmacd.img
G975F (S10+): twrp-beyond2lte-3.4.0-4_ianmacd.img
G977B (S10 5G): twrp-beyondx-3.3.1-100_ianmacd.img
Android 9
G970F (S10e): twrp-beyond0lte-3.3.1-13_ianmacd.img
G973F (S10): twrp-beyond1lte-3.3.1-13_ianmacd.img
G975F (S10+): twrp-beyond2lte-3.3.1-13_ianmacd.img
G977B (S10 5G): twrp-beyondx-3.3.1-7_ianmacd.img
Official builds were also offered by me until the release of Android 10 for the S10 series, but have been discontinued. They offered no practical advantage over the unofficial builds, yet added considerably to the administrative burden. Any build for Android 10 and tagged official has not been built by me.
These builds are based on the latest version of TWRP and include a kernel compiled from Samsung's latest available source code. The kernel runs in SELinux enforcing mode and its configuration has intentionally been kept as close to stock as possible in order to provide maximum compatibility with both Android and TWRP.
The builds have been well-tested and are known to work as intended on supported firmware versions. See posting #2 of this thread for details of which TWRP builds work with which versions of Samsung's firmware.
If you later find yourself running on updated firmware that is incompatible with this kernel, you have the option of flashing and rebooting to TWRP on demand. When you are finished in TWRP, you can replace your recovery image with Magisk-rooted stock recovery and reboot back to Android.
If installing TWRP on your device for the first time or reinstalling it following a firmware upgrade, do not forget to disable file-based encryption (FBE) immediately after flashing TWRP or you won't be able to read files on /data in TWRP. To achieve this (and to protect yourself against various anti-root protection mechanisms that Samsung have booby-trapped the device with), flash the latest version of the multidisabler as soon as you have installed TWRP.
Device firmware updates
When it comes time to update your device's firmware, please follow John Wu's excellent instructions for patching the firmware's AP file. Do not skip any of the steps.
Next, use Odin to flash the patched AP file, together with the stock BL, CP and HOME_CSC files. Never leave the CSC slot empty when flashing an AP file, or your /data partition may be shrunk and your data damaged during the flash.
When finished, immediately reboot back to download mode and reflash your Magisk-patched TWRP image. Alternatively, you may replace recovery.img in the patched AP file with your rooted TWRP image, thereby avoiding the need to separately reflash TWRP afterwards:
Code:
$ tar f magisk_patched_twrp.tar --delete recovery.img && tar rf magisk_patched_twrp.tar recovery.img
Lastly, boot to TWRP and reflash the latest version of the multidisabler. Note that your first boot to TWRP after installing new firmware may just run a post-installation recovery script that wipes /cache, so you may need to trap the automatic reboot that follows and boot to TWRP a second time.
Do not skip rerunning the multidisabler, as flashing new firmware will have re-enabled critical security features that you must now re-disable.
Frequently Asked Questions
Q. I've just updated my G97[035]F device to ASIG firmware and now I can no longer boot to TWRP, which means I also can't flash the multidisabler to keep encryption disabled. What can I do?
Samsung's new ASIG firmware for the S10 series has proven to be incompatible with any kernel compiled for an earlier version of the firmware. You are urged to upgrade to TWRP version 3.3.1-10_ianmacd or later to avoid problems with this firmware.
If you are unable or unwilling to do this, the following procedure should be observed:
If you simply upgrade to this new firmware as usual, by patching the AP file with Magisk Manager, you will find yourself unable to boot TWRP afterwards, and therefore also unable to flash the multidisabler. This is a potentially dangerous situation, as it can lead to data loss if not properly tackled.
1. When flashing the new full firmware in Odin, use the BL file from the previous ASH6 firmware, not the one from ASIG. Include the latest version of TWRP as recovery.img in the AP file, as per usual.
2. After flashing the firmware, reboot to TWRP as usual. Flash the multidisabler and any other files you usually flash as part of the post-upgrade process.
3. Make a copy of the ASIG BL tar file. From this copy, either remove vbmeta.img or replace it with a benign copy constructed as per the #vbmeta note in this group.
4. Use Odin to flash your modified BL file, together with a Magisk-patched copy of the stock ASIG recovery image in the AP slot.
5. Reboot to rooted Android.
If you follow these instructions, you will successfully upgrade your device to ASIG firmware, whilst retaining a decrypted /data file-system, etc.
TWRP can still be used on demand, but you will need to add the swapping of the bootloader to your existing procedure for switching between stock and custom recovery. Or you can simply wait a couple of weeks for Samsung to release updated kernel source code for ASIG, at which time I will issue new builds of TWRP.
Lastly, there are apparently some new TWRP builds currently doing the rounds that deal with the ASIG incompaibility issue by including a kernel hacked together from a mixture of S10 and Note10 source code. Approach such hybrids with due caution.
Q. I don't want to dual-boot Android using the custom kernel from my TWRP image. The latest TWRP kernel is often compiled for older firmware. Even if there are no visible issues using this older kernel, I'm probably missing out on improvements and fixes made in the latest kernel. Is there really no other way to run TWRP on these devices?
A. Actually, there is another way and it's actually simpler than and therefore preferable to dual-booting. You can opt to simply flash and boot TWRP on demand, leaving a Magisk-rooted stock recovery on your device the rest of the time.
For example, the following simple script could be used to toggle your recovery partition between stock and TWRP images.
Copy the following (not as the superuser) into a file, for example /storage/emulated/0/switch-recovery:
Code:
#!/bin/sh
twrp_img=/storage/9C33-6BBD/twrp-3.3.1-4.img
# Path to ext. SD is different in TWRP.
stock_img=/external_sd/recovery-asf3-magisk.img
if [ -f /sbin/magisk ]; then
# We're in Android: Switch to TWRP.
#
infile=$twrp_img
su='su -c'
else
# We're in TWRP: Switch to Android.
#
infile=$stock_img
fi
$su dd if=$infile of=/dev/block/sda15 bs=$(stat -c%s $infile) && reboot recovery
Then run it in Android in a terminal session:
Code:
# sh /storage/emulated/0/switch-recovery
It will flash your TWRP image and reboot the device to recovery. If the TWRP image is rooted, you'll still need to press the usual key combo to force pass-through to TWRP.
Do your work in TWRP and then run the script again from the TWRP terminal. This time, it will reflash your stock recovery image and reboot again to recovery. There's no need to press the hardware keys this time, because you are booting to Magisk-rooted Android.
Obviously, you must change the paths in the script to match where your own images are stored.
Q. Somewhere in upgrading my firmware, rooting and installing TWRP, my /data file-system mysteriously shrank to a fraction of its former size and appears to have been wiped. What happened? Is TWRP responsible for this?
A. No. This appears to be a side-effect of using Odin to flash an AP file to these devices with the CSC slots left empty. Never flash a full AP file on this range of devices without also filling at least the HOME_CSC slot. It is safe, however, to flash only a recovery image in the AP slot.
To attempt to repair the damage, you need to boot to TWRP, select Advanced Wipe, tick Data, select Repair or Change File System followed by Resize File System. Your /data will return to its former size, but you will probably find you have lost some data. Restore a /data back-up afterwards to be sure of having all your data.
Q. When I mount /system and execute commands in the TWRP terminal or over adb, I get a lot of noise about problems with the dynamic linker.
A. This problem is fixed as of version 3.3.1-1_ianmacd.
It is caused by /etc/system becoming a symlink to itself when /system is mounted, resulting in infinite recursion when followed.
The screen on your text is just a warning, not an error. Your commands are still being executed.
Nevertheless, noise annoys, so you can silence the warning by pasting the following commands into the terminal (with thanks to John Wu):
Code:
# mount --move /system /system_root && mount -o bind /system_root/system /system
Q. My favourite zip doesn't flash properly using this TWRP. Someone said these TWRP builds are to blame, because they don't include BusyBox. Why don't you fix them?
A. Because there's actually nothing wrong with them. It's the installer code of your favourite zip that is broken. TWRP is merely exposing that fact. Don't shoot the messenger.
A lot of poorly written legacy installer code lazily assumes the presence of certain binaries, in particular BusyBox. However, the inclusion of BusyBox in TWRP is a compile-time option entirely at the discretion of the builder. It is not a requirement.
Not only that, but the inclusion of BusyBox in builds of TWRP targeting Android 9.0 and later is officially deprecated. Maintainers of such devices are instead advised by the TWRP team to use Toybox, and these builds for the S10 series comply with that advice. Furthermore, it's actually currently impossible to even build an official TWRP image for these devices with BusyBox included. Compilation of TWRP on the official build server will fail if this is attempted.
In short, the assuming BusyBox's presence on the device is unsafe and your favourite zip's author should fix his installer code. Supply him with an installation log and politely ask him to rewrite the installer code to be independent of this historical TWRP implementation detail.
Anyone who maintains that TWRP is broken without the inclusion of BusyBox is simply either unwilling or unable to grasp the facts.
Q. When I boot to Android, I can no longer log in. Why?
:victory:
A. Probably because of a mechanism called rollback protection. What has most likely happened here is that you have previously booted the device from a boot image with a later security patch level than the one from which you are trying to boot now.
As an example, let's say you are currently booting your device from a TWRP image with a security patch level of 2019-06. Then, Samsung issues a firmware update with a patch level of 2019-07. You update to that firmware, but immediately replace the stock recovery image with your trusty TWRP image and keep booting from that. Everything continues to work as it did before.
However, one day, you accidentally boot the device from the boot partition instead of the recovery partition. The device predictably comes up unrooted, but more significantly, it has now been booted from a (stock) boot image with a patch level of 2019-07, a fact that the device has now also committed to memory.
If you now reboot from the recovery partition, you will find that Android will no longer allow you to log in when the lock screen appears. This is because you are attempting to boot from an image with a patch level (2019-06) that is now earlier than the latest one previously used to boot the device (2019-07). Android considers this insecure and will not allow it. This mechanism is called rollback protection.
The simplest solution and the one with the least negative impact is to update the security patch level of the TWRP image to match that of the latest image used to boot the device. You can achieve this using magiskboot unpack -h or with AIK.
Links
TWRP source code for Android 9.0
Unofficial device tree for the G970F
Unofficial device tree for the G973F
Unofficial device tree for the G975F
Unofficial device tree for the G977B
Combined kernel source code for the G97[035]F
Kernel source code for the G977B
Telegram group
XDA:DevDB Information
TWRP for Galaxy S10 Exynos series, Tool/Utility for the Samsung Galaxy S10+
Contributors
ianmacd, Geiti94
Version Information
Status: Stable
Current Stable Version: 3.4.0-4_ianmacd
Stable Release Date: 2020-11-17
Created 2019-04-25
Last Updated 2020-11-17
Changelog
v3.4.0-4_ianmacd for G97[035]F [inc. DTJA kernel] (2020-11-17)
Rebase kernel on Samsung's DTJA source code.
Merge all outstanding fixes and enhancements from the TWRP source tree.
This version is intended for use only with Android 10.
v3.4.0-3_ianmacd for G97[035]F [inc. DTH7 kernel] (2020-09-11)
Rebase kernel on Samsung's DTH7 source code.
This version is intended for use only with Android 10.
v3.4.0-2_ianmacd for G97[035]F [inc. CTG4 kernel] (2020-08-14)
Rebase kernel on Samsung's CTG4 source code.
This version is intended for use only with Android 10.
v3.4.0-1_ianmacd for G97[035]F [inc. CTF1 kernel] (2020-06-30)
Update TWRP to version 3.4.0.
This version is intended for use only with Android 10.
v3.3.1-105_ianmacd for G97[035]F [inc. CTF1 kernel] (2020-06-18)
Rebase kernel on Samsung's CTF1 source code.
This version is intended for use only with Android 10.
v3.3.1-104_ianmacd for G97[035]F [inc. CTD1 kernel] (2020-05-31)
Rebase kernel on Samsung's CTD1 source code.
This version is intended for use only with Android 10.
v3.3.1-103_ianmacd for G97[035]F [inc. CTC9 kernel] (2020-03-31)
Rebase kernel on Samsung's CTC9 source code.
This version is intended for use only with Android 10.
v3.3.1-102_ianmacd for G97[035]F [inc. BTA8 kernel] (2020-02-08)
Rebase kernel on Samsung's BTA8 source code.
This version is intended for use only with Android 10.
v3.3.1-101_ianmacd for G97[035]F [inc. BSKO kernel] (2019-12-20)
Fix for cosmetic Unable to decrypt FBE device message that was sometimes displayed in the previous Android 10 release (-100).
This version is intended for use only with Android 10.
v3.3.1-13_ianmacd for G97[035]F [inc. ASJG kernel] (2019-12-20)
Fix for cosmetic Unable to decrypt FBE device message that was sometimes displayed in the previous Android Pie release (-12).
This version is intended for use only with Android 9.
v3.3.1-100_ianmacd for G977B [inc. BSL2 kernel] (2019-12-20)
Rebase kernel on Samsung's BSL2 source code.
This version is intended for use only with Android 10.
v3.3.1-7_ianmacd for G977B [inc. ASJ7 kernel] (2019-12-19)
Rebase kernel on Samsung's ASJ7/ASK1 source code.
Merge latest upstream TWRP commits.
v3.3.1-100_ianmacd for G97[035]F [inc. BSKO kernel] (2019-12-07)
Rebase kernel on Samsung's BSKO source code.
This version is intended for use only with Android 10.
v3.3.1-12_ianmacd for G97[035]F [inc. ASJG kernel] (2019-12-03)
Rebase kernel on Samsung's ASJG source code.
v3.3.1-11_ianmacd for G97[035]F [inc. ASIG kernel] (2019-10-11)
Add support for Samsung DeX for PC.
v3.3.1-10_ianmacd for G97[035]F [inc. ASIG kernel] (2019-10-07)
Rebase kernel on Samsung's ASIG source code.
Merge latest upstream TWRP commits.
v3.3.1-9_ianmacd for G97[035]F [inc. ASH6 kernel (which also works with ASH1 firmware)] (2019-09-17)
Restore working MTP functionality to TWRP. With thanks to bigbiff for the reference and to Geiti for his commit embodying the same fix.
v3.3.1-8_ianmacd for G97[035]F [inc. ASH6 kernel (which also works with ASH1 firmware)] (2019-09-06)
Kernel rebased on Samsung's ASH6 source code.
v3.3.1-7_ianmacd for G97[035]F [inc. ASG8 kernel (which also works with ASH1 firmware)] and v3.3.1-6_ianmacd for G977B [inc. ASF5 kernel] (2019-08-20)
File-based System back-up option was missing in v3.3.1-6_ianmacd.
v3.3.1-6_ianmacd for G97[035]F [inc. ASG8 kernel (which also works with ASH1 firmware)] and v3.3.1-5_ianmacd for G977B [inc. ASF5 kernel] (2019-08-18)
Use $ANDROID_ROOT to set the mount point for the system block device to /system_root on these system-as-root devices.
This change renders this and future TWRP releases incompatible with previous versions. Any existing zip file installer code that attempts to mount /system or expects the system block device to be mounted on /system will now fail under this new version and will require modification.
Solved infinite recursion of symbolic links when resolving /system paths.
v3.3.1-5_ianmacd for G97[035]F [inc. ASG8 kernel (which also works with ASH1 firmware)] (2019-08-07)
Kernel rebased on Samsung's ASG8 source code.
v3.3.1-4_ianmacd for G977B [inc. ASF5 kernel] (2019-07-06)
Kernel rebased on Samsung's ASF5 source code.
Hugely improved Dutch translation.
v3.3.1-4_ianmacd for G97[035]F [inc. ASF3 kernel] (2019-07-05)
Kernel rebased on Samsung's ASF3 source code.
Hugely improved Dutch translation.
v3.3.1-3.1_ianmacd for G977B [inc. ASEC kernel] (2019-06-21)
First production release for the G977B (beyondx).
v3.3.1-3.1_ianmacd for G97[035]F [inc. ASE7 kernel] (2019-06-12)
Removed an experimental patch that was accidentally included in v3.3.1-3_ianmacd.
Previous releases were for the G97[035]F only:
v3.3.1-3_ianmacd [inc. ASE7 kernel] (2019-06-12)
Kernel rebased on Samsung's ASE7 source code.
v3.3.1-2_ianmacd [inc. ASD5 kernel] (2019-05-21)
Image back-ups of /product now possible.
v3.3.1-1_ianmacd [inc. ASD5 kernel] (2019-05-17)
Updated to upstream v3.3.1-0.
Fix linker warnings when binaries are executed while /system is mounted.
v3.3.0-2_ianmacd [inc. ASD5 kernel] (2019-05-11)
Kernel rebased on Samsung's ASD5 source code.
v3.3.0-1_ianmacd [inc. ASCA kernel] (2019-04-26)
Add support for mounting, backing up and restoring /product.
Add support for backing up and restoring /vendor.
Partitions now listed alphabetically.
Default brightness now 66% of maximum brightness (was 50%) to aid reading.
v3.3.0-0 [inc. ASCA kernel] (2019-04-21)
First ianmacd release.
TWRP updated to 3.3.0-0.
Fixes death on power-off issue, which left device unable to boot when turned back on.
Fixes inability to upgrade Magisk via Magisk Manager.
Replaces SELinux permissive kernel with enforcing kernel.
Reserved
Well done sir, well done!
Thank you for your continued work and support for TWRP.
Just to confirm the process if we want root and are already rooted -
follow your steps to root the new TWRP Image you posted today and zip it as a tar file in 7Zip
Flash rooted twrp in Odin
Reboot to Recovery
Format Data
Flash New Disabeler Script
Format Data again
Reboot in recovery (to reboot into magisk
Is that correct? (I read somewhere the other day that we needed to wipe again AFTER flashing the Disabler script and I didn't know if that was really necessary or if someone had mispoke?
Sorry to bother you but I have been trying to do as your OP outlines - but everytime I create a TAR File using the TWRP you provided patched with Magisk, when I try to flash in ODIN - nothing happens. The file won't flash. I have started over 5 times - created new Patched images in Magisk each time - but for some reason I am not having any luck getting this to flash in odin.
Can I flash the MAgisk patched Recovery Image in TWRP ?
EDIT - I answered my own question - I went ahead and tried to flash in TWRP and it flashed perfectly. All is good. But still curoiuos why I couldn't get the Patched Twrp File to fliash via odin - ?
Geekser said:
Sorry to bother you but I have been trying to do as your OP outlines - but everytime I create a TAR File using the TWRP you provided patched with Magisk, when I try to flash in ODIN - nothing happens. The file won't flash. I have started over 5 times - created new Patched images in Magisk each time - but for some reason I am not having any luck getting this to flash in odin.
+1
Click to expand...
Click to collapse
Great thread @ianmacd
By clicking on the button below you will get a set of instructions, step-by-step, on how to install Ians excellent work with TWRP as a recovery for your device and John Wu's root via Magisk.
This is not the fastest or most uncomplicated tutorial to do this. It is, however, made to make sure as many as possible succeed. So if you feel that a step or two is uncessesary, this tutorial is probably not for you since you most likely already know enough to just go by Ians more direct instructions. So dont PM me with tips on how to simplify these steps, I already know about that and that is not the point of the tutorial.
The instructions are intended for:
The user that either is completely new to this world but have managed to get an unlocked bootloader beforehand
The user that just want to have some instructions to follow to not forget a step in the process
Please note that the tutorial should work just fine for the S10E-device, but there might be another set of key combinations for your device, please take care to understand what you need to do in specifics to do the same presses of buttons.
It is strongly encourage to flash lates stock firmware and do a complete clean system install before using this tutorial. However, if you know what you are doing, it will work fine with an already rooted system as long as you have the latest Canary build (both magisk and magisk manager) on your device when patching the TWRP-image and the firmware AP-file per instructions below.
Where ever you decide to start, know that your device will be wiped and you need backups for your relevant data before you begin.
These instructions are ...
.. an "add-on" till John Wu's Magisk solution that will make your device rooted with Magisk and having Ian Macdonalds TWRP-recovery
.. for those who have already an unlocked bootloader - DO NOT attempt this without first making sure you have "OEM Unlocked" enabled
Step-by-step guide:
A) Follow John's instructions HERE until you get to step 5, then return here
B) Download latest TWRP-image by Ian Macdonald for your type of device in the first post in this thread
C) Download latest multidisabler-zip by Ian Macdonald and copy it to your SD-CARD - download here
D) Copy the TWRP-image to your device and do the same as you did with the AP-file in Magisk Manager (Install->Install->Patch file and choose the TWRP-image)
E) Copy the patched TWRP-image and magisk_patched.tar to your computer
F) Rename the patched TWRP-image to "recovery.img" on your computer
G) With your own choice of program on your computer, open the "magisk_patched.tar"-file, remove the existing recovery.img and replace it with your newly patched recovery.img and save the tar-file
H) Boot your device to download mode
I) Go back to John's instructions and IGNORE step 6 and DO step 7 and come back here!
J) We now need to factory reset our device:
-> Press Power + VolDown for a few seconds to get out of download mode
-> AS SOON AS THE SCREEN GOES BLACK: Press Power + Bixby + VolUP and HOLD THESE KEYS FOR A LONG TIME until you see the bootlogo of TWRP, then release the keys
K) In TWRP, install your downloaded multidisabler-zip from your SD-CARD and DO NOT REBOOT
L) In TWRP, format data (not only wipe, choose specifically "Format data" and write "yes" and go ahead and after DO NOT REBOOT
M) In TWRP, go back to the start screen - choose "Reboot" and choose "Recovery" AND NOTHING ELSE - DONT touch any keys on the device
N) Go back to John's instructions and begin from step 12
O) All done - you know have a rooted device by Magisk, with TWRP as recovery - enjoy and be sure to thank Ian Macdonald for the help with TWRP and John Wu for Magisk root!
hanspampel said:
Here are the magisk patched files for all devices. Only tried my s10+, but all the others should work too with odin.
Click to expand...
Click to collapse
Did you not read the OP?
John Wu does not allow the distribution of Magisk binaries in this way. If he did, I would have supplied pre-patched images myself. Post reported for removal.
Ian, does it matter the MM version when patching the AP and twrp img or all MM versions are doing the same job?
Thanks you.
starbucks2010 said:
Ian, does it matter the MM version when patching the AP and twrp img or all MM versions are doing the same job?
Click to expand...
Click to collapse
You need a recent Canary or ianmacd build, certainly from April. I would upgrade to the most recent build if I were you.
Great work Ian greatly appreciated that your placing your time into the community.
Don't copy me (got lazy) but I currently had twrp, so I just patched (the new img) flashed in Odin, and all appears to be good.....
ianmacd said:
changelog
v3.3.0-1_ianmacd (2019-04-26)
Add support for mounting, backing up and restoring /product.
Add support for backing up and restoring /vendor.
Partitions now listed alphabetically.
Default brightness now 66% of maximum brightness (was 50%) to aid reading.
Click to expand...
Click to collapse
Thank you for the decision to do this.
I made some backups on v3.3.0-0 and I believe /vendor was also included. Would there be anything wrong with these backups made on v3.3.0-0 now that I see such a line in the changelog? Did /vendor not backup correctly on TWRP 3.3.0-0?
So it is /vendor and /vendor image like with with system and system image. I flashed the latest TWRP and saw this..
But my Magisk manager patches my recoveries. badly
This is the 3rd time this happens to me.
After patching v3.3.0-1 i used the dd command to flash it. Then booted in TWRP, confirmed it was v3.3.0-1 and even made me a backup.
But I rebooting to rooted system isn't possible. The phone only boots to recovery no matter what. So I flashed patched v3.3.0-0 back. Things worked and booted to system. There I found that this latest "magisk_patched.img" is ~6 mb less than the raw "twrp-beyond2lte-3.3.0-1_ianmacd.img"
So I patched again. And again the produced "magisk_patched.img" was the same as the first one. How can I help myself here?
My Magisk Manager is 7.1.1 -54d1207f (207)
I am attaching the log file from MM for patching process .
tiho5 said:
So it is /vendor and /vendor image like with with system and system image. I flashed the latest TWRP and saw this..
But my Magisk manager patches my recoveries. badly
This is the 3rd time this happens to me.
After patching v3.3.0-1 i used the dd command to flash it. Then booted in TWRP, confirmed it was v3.3.0-1 and even made me a backup.
But I rebooting to rooted system isn't possible. The phone only boots to recovery no matter what. So I flashed patched v3.3.0-0 back. Things worked and booted to system. There I found that this latest "magisk_patched.img" is ~6 mb less than the raw "twrp-beyond2lte-3.3.0-1_ianmacd.img"
So I patched again. And again the produced "magisk_patched.img" was the same as the first one. How can I help myself here?
My Magisk Manager is 7.1.1 -54d1207f (207)
I am attaching the log file from MM for patching process .
Click to expand...
Click to collapse
When that symptom shows, only booting to recovery no matter what, it is always a sign that the recovery you flashed wasn't patched with Magisk.
Are you sure you are flashing the right file? I don't use dd but if you have Odin available, try instead to tar that magisk_patched.img and flash that tar in Odin instead.
Because if you are sure that the IMG is patched alright, then something with dd is not working.
/P
Edit: The shrinking you observe is normal and is as expected.. so it should be patched and then I suspect something in the process of using dd.
PiCkLeS said:
When that symptom shows, only booting to recovery no matter what, it is always a sign that the recovery you flashed wasn't patched with Magisk.
Are you sure you are flashing the right file? I don't use dd but if you have Odin available, try instead to tar that magisk_patched.img and flash that tar in Odin instead.
Because if you are sure that the IMG is patched alright, then something with dd is not working.
/P
Edit: The shrinking you observe is normal and is as expected.. so it should be patched and then I suspect something in the process of using dd.
Click to expand...
Click to collapse
No mate... The patching process is done right, I'm sure. And I also tried with Odin before I posted although I was sure it was not going to help. The recovery simply doesn't get patched right for some reason. This happened to me a few times before.
There is a log attached and one can see what happened and if I'm doing anything wrong (which indeed I doubt).
And also the patched files that I had done successfuly were more or less the same size as the raw file, only slightly bigger. This time it's not like that at all.
I was sure there's no working Magisk in that package.
The dd commands work and they're very convenient. I've used them for years. After I dd'd it, I indeed booted to the new recovery, saw that it's the new version, saw the changed things, the alphabetic order, even made a backup.
I didn't look much at the log file as it doesn't make too much sense to me, but I sure hope that Ian could investigate it.
Thanks anyway, mate.
I just ordered an S10e SM-G9700 with the unlocked Snapdragon bootloader (unlike the locked North American version). Will this work on that or is this purely for Exynos-based devices?
tiho5 said:
No mate... The patching process is done right, I'm sure. The recovery simply doesn't get patched right for some reason. This happened to me a few times before.
There is a log attached and one can see what happened and if I'm doing anything wrong (which indeed I doubt).
I didn't look much at the log file as it doesn't make too much sense to me, but I sure hope that Ian could investigate it.
Click to expand...
Click to collapse
Your log file shows this:
Code:
- Unpacking boot image
Parsing boot image: [/data/user_de/0/com.topjohnwu.magisk/install/boot.img]
It appears you patched a boot image, not a recovery image. Further output in the log show that it was, indeed, treated as a boot image, not a recovery image.
ianmacd said:
Your log file shows this:
It appears you patched a boot image, not a recovery image. Further output in the log show that it was, indeed, treated as a boot image, not a recovery image.
Click to expand...
Click to collapse
Why did Magisk Manager take the twrp-beyond2lte-3.3.0-1_ianmacd.img for a boot image? How can we avoid that.
There am I in need of a prepatched TWRP file, which is against the rules.
Do you have any idea how could I help my situation.