Related
Here you go every, TWRP for all variants of the One SV. These device folders were accepted officially by Dees_Troy and here are all the links to the official downloads. GooManager supports these phones now as well.
K2_CL (BOOST): Download
K2_PLC_CL (CRICKET): Download
K2_UL (EU LTE): Download
K2_U (EU NON LTE): Download
Enjoy everyone! Be sure to flash the right recovery even if you are k2_u or k2_ul as it will protect your phone on source built roms by being able to use the proper asserts! Note that these recoveries are ready for 4.3 and have encryption already enabled for you. Source is listed below.
Source:
K2_CL
K2_PLC_CL
K2_UL
K2_U
Credits:
jmz
Dees_Troy
What diferences brings this recovery compared with 2.5?
Thanks
Taken from twrp website
What's new in 2.6.0.0:
Special Note: If you are running a custom theme, some of the changes in 2.6.0.0 will likely not be visible with your custom theme.
Can encrypt a backup to prevent theft of private data from your backup files
Updated graphics / icon courtesy of shift
Updated exFAT to latest commits
Fixed a problem with Samsung TouchWiz decryption
Update SuperSU binary
Fixed saving of backup partitions list
Fixed saving of last used zip install folder
Fixed backup of datadata on devices that use a separate partition for datadata
Fixed some issues with the advanced wipe list (android_secure, can now wipe internal storage on data/media deivces and wipe data on the advanced list no longer formats the entire data partition)
Fixed some problems with partitioning a SD card
Various other bug fixes and tweaks
Notes about encrypted backups:
Why encrypt your backups? -- Most people store their backups on the device. Any app that has permission to access storage could potentially read your backup files and try to harvest your data. Encrypted backups also provide an added layer of security if you move your backups to other storage devices or to the cloud. The encryption that we're using is probably not strong enough for enterprise level security, but should be strong enough to make it significantly difficult to get to your data.
Encryption is using OpenAES which uses AES 128-bit cbc encryption. If you happen to use a longer password (over 16 characters) then the encryption strength improves to 192 or 256 bits. Do not forget your password. If you forget your password you will be unable to restore your backup. We don't encrypt the entire backup. Encryption is very CPU intensive and can be fairly slow even when we spread the workload over multiple cores even on the latest high-end devices. To ensure that encrypted backups don't take forever, we don't encrypt any other partitions besides /data and in /data we don't encrypt /data/app (or other app related directories where apks are stored) and we don't encrypt dalvik cache.
I am trying to install it from goomanager app but nothing happens. I will try in a few days in my computer .
Thanks
Well done simon, looking forward to try. :good:
it does not work in my device K2_U. I go back to previus version. Anybody also has problems with it??
Thanks
titin83 said:
it does not work in my device K2_U. I go back to previus version. Anybody also has problems with it??
Thanks
Click to expand...
Click to collapse
I informed simon already and he is working on a fix.
There's a new version - 2.6.1.0
I'll throw them to the builder this weekend
Sent from my C525c using Tapatalk 4
Version - 2.6.1.0 does not work. I got stuck in htc quietly brilliant screen.
Updated for 4.3+ roms, also fixed some features. Encryption now enabled. All devices work
Nice update. So far as i have tested, everything works.
in the old version, when I turn off the power and connect to the charger...then I can not boot up until remove battery and try again
in the latest version, has this issue been resolved ?
thanks
Thats not an issue per say, as it is more of an aspect of htc phones. When charging the phone while off, hold the power button for 15-30 seconds then it will turn the red led off then press it again and it will boot up to android.
solved
Why do we have less options to be backup than previous version?
Because now we have soff. Those partitions shouldn't be backed up or modified. Now only partitions that should be updated backed up ect are available
Sent from my C525c using Tapatalk 4
Hey Guys, Quick question. What's the difference between these versions of TWRP and the 'official' one on the TWRP website?
I don't have S-OFF and don't really intend to do it, which version should I use?
Thanks
ipit said:
Hey Guys, Quick question. What's the difference between these versions of TWRP and the 'official' one on the TWRP website?
I don't have S-OFF and don't really intend to do it, which version should I use?
Thanks
Click to expand...
Click to collapse
Mine work on every variant for one, they're more updates and they're all cleaned. The device trees have been submitted to Dees though. So eventually they're the same but since I ported it, I'm allowed to post my work first
Sent from my C525c using Tapatalk 4
ah gotcha!! Thanks for the explanation.
Team Win Recovery Project 2.x, or twrp2 for short, is a custom recovery built with ease of use and customization in mind. It’s 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.
Phone look:
Tablet look:
CHANGELOG for 2.6.3.0:
-Proper backup and restore of SELinux contexts (thanks to Tassadar)
-Pull in some ROM information for backup name generation
-Merge all recent patches from AOSP bringing TWRP up to date with Android 4.3
-Add 1200x1920 theme (thanks to Tassadar)
-A few other fixes and tweaks
CHANGELOG for 2.6.1.0:
-Initial SELinux support (only a few devices, need testers so come by IRC if your device doesn't have it and needs it)
-Initial support for f2fs file system formatting (Moto X)
-Update SuperSU install for 4.3 ROMs
-Fixed a permissions bug on files created during backup
-Fixed a bug that caused TWRP to not wait for compressed backups to finish causing 0 byte files and md5sums to not match
-Fixed decryption of encrypted data so that both TouchWiz and AOSP decryption are possible
-Ignore lost+found folder during backup and size calculations
-Various other minor bug fixes and tweaks
CHANGELOG for 2.6.0.0:
Special Note: If you are running a custom theme, you will likely need to remove that theme before updating to 2.6.0.0 as your custom theme will likely not have some of the new changes visible (e.g. you won't be able to encrypt a backup)!
-Can encrypt a backup to prevent theft of private data from your backup files
-Updated graphics / icon courtesy of shift
-Updated exFAT to latest commits
-Fixed a problem with Samsung TouchWiz decryption
-Update SuperSU binary
-Fixed saving of backup partitions list
-Fixed saving of last used zip install folder
-Fixed backup of datadata on devices that use a separate partition for datadata
-Fixed some issues with the advanced wipe list (android_secure, can now wipe internal storage on data/media deivces and wipe data on the advanced list no longer formats the entire data partition)
-Fixed some problems with partitioning a SD card
-Various other bug fixes and tweaks
Notes about encrypted backups:
Why encrypt your backups? -- Most people store their backups on the device. Any app that has permission to access storage could potentially read your backup files and try to harvest your data. Encrypted backups also provide an added layer of security if you move your backups to other storage devices or to the cloud. The encryption that we're using is probably not strong enough for enterprise level security, but should be strong enough to make it significantly difficult to get to your data.
Encryption is using OpenAES which uses AES 128-bit cbc encryption. If you happen to use a longer password (over 16 characters) then the encryption strength improves to 192 or 256 bits. Do not forget your password. If you forget your password you will be unable to restore your backup. We don't encrypt the entire backup. Encryption is very CPU intensive and can be fairly slow even when we spread the workload over multiple cores even on the latest high-end devices. To ensure that encrypted backups don't take forever, we don't encrypt any other partitions besides /data and in /data we don't encrypt /data/app (or other app related directories where apks are stored) and we don't encrypt dalvik cache.
DOWNLOAD:
Latest Builds Here
BUGS:
If you have found a bug, 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 PM me directly, 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!
SUPPORT:
Live support is available via #twrp on Freenode with your IRC client or just click this link.[/QUOTE]
Links are up enjoy the light show
Twrp now has haptic feedback.
edit: This is untested.
Wow, finally no more empty zips that bricks the phone. Downloading.
Finally the 2.6.3.0 version
Waited for long time for this
Sent from my Nexus 5 using xda app-developers app
Does this work with all partitions?
Sent from my SPH-D700 using Tapatalk 2
DaKillaWilla said:
Does this work with all partitions?
Sent from my SPH-D700 using Tapatalk 2
Click to expand...
Click to collapse
Yes , it was confirmed working.
Hello all,
I flashed TWRP 2.6.3.0 and now any ROM I try to flash getting FAILED message. Am I missing something...
Thx in Adv
FerociousAndroid said:
Hello all,
I flashed TWRP 2.6.3.0 and now any ROM I try to flash getting FAILED message. Am I missing something...
Thx in Adv
Click to expand...
Click to collapse
Give more info what rom? What recovery etc.
Sent from my SPH-D710 using Tapatalk
Unjustified Dev said:
Give more info what rom? What recovery etc.
Sent from my SPH-D710 using Tapatalk
Click to expand...
Click to collapse
Fashed from CMW 5.0.2.7 to Twrp_6.3_Unofficial_20140211_d700.zip. Then tried installing any of the following:
cm-7.2.0-epicmtd.zip
cm-10.1.3.1-epicmtd.zip
Try to go back to cwm-5.0.2.7-epic4g.zip
ThePeoplesROMv2.22_BML.zip
ThePeoplesROMv2.22_MTD.zip
I odin back to "pit & Deodexed-FC09.zip" and then installed CMW 5.0.2.7. I'm on CM10.x. Didn't bother with TWRP. I could be have been the new Samsung 4GB micro SD card I was using who knows.
Thx any way.
FerociousAndroid said:
Fashed from CMW 5.0.2.7 to Twrp_6.3_Unofficial_20140211_d700.zip. Then tried installing any of the following:
cm-7.2.0-epicmtd.zip
cm-10.1.3.1-epicmtd.zip
Try to go back to cwm-5.0.2.7-epic4g.zip
ThePeoplesROMv2.22_BML.zip
ThePeoplesROMv2.22_MTD.zip
I odin back to "pit & Deodexed-FC09.zip" and then installed CMW 5.0.2.7. I'm on CM10.x. Didn't bother with TWRP. I could be have been the new Samsung 4GB micro SD card I was using who knows.
Thx any way.
Click to expand...
Click to collapse
I second this, my backups & flashable zips that worked fine with 2.6.0.0 are no longer working in this TWRP version, even though the md5 checks out. There is a problem with this new release, imo, as this was an occurrednce with both of my Epics.
Luthiensdad said:
I second this, my backups & flashable zips that worked fine with 2.6.0.0 are no longer working in this TWRP version, even though the md5 checks out. There is a problem with this new release, imo, as this was an occurrednce with both of my Epics.
Click to expand...
Click to collapse
Probably because of the updates etc that were done. I can't guarantee older backups will be compatible.
Unjustified Dev said:
Probably because of the updates etc that were done. I can't guarantee older backups will be compatible.
Click to expand...
Click to collapse
I don't think that's the case, the problem occurs when flashing ROM & kernel zips too, not just when attempting to restore existing backups. I re-downloaded a couple (& checked md5) again to confirm this. (Of course, I also checked md5 for this new recovery prior to installing it)
Luthiensdad said:
I don't think that's the case, the problem occurs when flashing ROM & kernel zips too, not just when attempting to restore existing backups. I re-downloaded a couple (& checked md5) again to confirm this. (Of course, I also checked md5 for this new recovery prior to installing it)
Click to expand...
Click to collapse
Well sorry I guess this won't be fixed because I quit developing. I can do no more than answer questions.
flash off of CWM and now I got stuck on the Samsung screen. any help?
Nexus11 said:
flash off of CWM and now I got stuck on the Samsung screen. any help?
Click to expand...
Click to collapse
Give me some time to compile a new one I have to update both epic 4g and epic 4g touch.
Hello everybody,
I created a tool - initially for the nexus 9 (flounder|flounder_lte) - that gets rid of the ForceEncrypt flag in a generic way (meaning it should work no matter what rom you are on). It does that by patching the currently installed boot.img.
I enhanced that tool to make it work for other devices too. (See the list below to see if your device is supported)
Disclaimer
Code:
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about the features in this tool
* before using it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you. Hard. A lot.
*/
Background
The Android CDD (Compatibility Definition Document) suggests demands that all devices with the appropriate horse power SHOULD MUST enable full disk-encryption (FDE) by default. Even though I support every step towards more security I have to criticize this approach. Full-disk-encryption comes at a price. Encryption takes time because some component has to de- and encrypt the stuff on the disk at some point and in current devices it's the CPU's task. Even though modern devices have quite fast CPU cores you can still easily feel the difference between FDE in the on- or off-state. The I/O is faster and boot-times take only half as long. (I did not do any scientific measurements though)
There is an ongoing discussion about this topic in cyanogenmod's gerrit for the nexus 9. Although it's a fun read it is pretty clear that this exchange of views is not going anywhere near a useful outcome. Additionally, Google's stock ROMs always have forced encryption enabled on newer devices.
Because performance is important to me and at least my tablet does not need the extra security I created the FED-Patcher (ForceEncrypt Disable Patcher).
How does it work?
FED-Patcher is a simple flashable ZIP that is supposed to be run in a recovery that has busybox integrated (like TWRP or CWM). This is what it does:
Checks if your device is compatible
Dumps the currently installed boot.img.
Unpacks the dump of your currently installed boot.img. The unpacking process is done via a self-compiled, statically linked version of unmkbootimg.
It patches the filesystem tables which include the force-encrypt flags. This process will change "forceencrypt" to "encryptable".
Then, if necessary, it patches the filesystem tables to not use dm-verity. This is done by removing the "verify" mount-parameter.
Creates a new boot.img. The unpacking process is done via a self-compiled, statically linked version of mkbootimg.
Flashes the modified boot.img
Supported devices
HTC Nexus 9 WiFi (flounder)
HTC Nexus 9 LTE (flounder_lte)
Motorola Nexus 6 (shamu)
LG Nexus 5X (bullhead)
Huawei Nexus 6P (angler)
Version History
v1 - Initial version with HTC Nexus 9 WiFi (flounder) support
v2 - Added Motorola Nexus 6 (shamu) support
v3 - Added support for HTC Nexus 9 LTE (flounder_lte)
v4 - Added support for signed boot-images
v5 - Changed error handling to compensate for missing fstab files. Some roms seem not to ship with the complete set of boot-files from AOSP.
v6 - FED-Patcher will enforce the same structure for the patched boot.img that the original boot.img had. Additionally, the kernel commandline will also be taken over. This should fix pretty much every case where devices would not boot after patching.
v7 - FED-Patcher will now disable dm-verity in fstab to get rid of the red error sign on marshmallow roms.
v8 - Added support for LG Nexus 5X (bullhead) and Huawei Nexus 6P (angler)
What do I need to make this work?
A supported device
An unlocked bootloader
An already installed ROM with forceencrypt flag. (like cyanogenmod CM12.1)
A recovery that includes busybox (TWRP, CWM)
How do I use it?
Make a thorough, conservative backup of your data if there is any on your device
Go into your recovery (TWRP, CWM)
Flash fed_patcher-signed.zip
If your device is already encrypted (You booted your ROM at least once) you need to do a full wipe to get rid of the encryption. This full wipe will clear all your data on your data-partition (where your apps as well as their settings are stored) as well as on your internal storage so please, do a backup before. If you don't do a backup and want to restore your data... well... Call obama.
How do I know if it worked?
Go into your "Settings"-App. In "Security", if it offers you to encrypt your device it is unencrypted. If it says something like "Device is encrypted" it indeed is encrypted.
IMPORTANT: If you update your ROM you have to run FED-Patcher again because ROM-updates also update the boot-partition which effectively removes my patch. So, if you are on CM12.1 for example and you used my patch and do an update to a newer nightly you have to run FED-Patcher again. If you don't do so Android will encrypt your device at the first boot.
Is it dangerous?
Well, I implemented tons of checks that prevent pretty much anything bad from happening. But, of course, we're dealing with the boot-partition here. Even though I tested FED-Patcher quite a lot there is still room for crap hitting the fan.
Screenshot
Scroll down to the attached thumbnails.
Credits
* pbatard for making (un)mkbootimg (dunno if he is on xda)
* @rovo89 for his xposed framework - I used some of his ideas by reading the source of his xposed installer flashable ZIP for FED-Patcher.
GibHub: https://github.com/gladiac1337/fed-patcher
XDA:DevDB Information
FED-Patcher, Tool/Utility for all devices (see above for details)
Contributors
gladiac, rovo89
Version Information
Status: Beta
Current Beta Version: v8
Beta Release Date: 2015-10-27
Created 2015-10-27
Last Updated 2016-10-23
Hi @gladiac and first of all thanks for the work and time spent developing this amazing tool.
I'm currently running stock Marshmallow on my Nexus 6 and i plan to stay like that, but would like to test my device with ForceEncrypt disabled. Here are my doubts.
1 - Does this work on stock?
2 - Would i be able to flash the monthly security update images without having to wipe my device every time?
3 - In your opinion, do the speed gains justify the all the work?
Thanks in advance.
cyberon said:
Hi @gladiac and first of all thanks for the work and time spent developing this amazing tool.
I'm currently on stock Marshmallow and i plan to stay like that, but would like to test my device with forcencrypt disabled. Here are my doubts.
1 - Does this work on stock?
2 - Would i be able to flash the monthly security update images without having to wipe my device every time?
3 - In your opinion, do the speed gains justify the all the work?
Thanks in advance.
Click to expand...
Click to collapse
Hi @cyberon,
good questions!
Yes, FED-Patcher works on stock! Marshmallow made it necessary to do a new release, v7, to get rid of an error message at boot but other than that, FED-Patcher works just fine on Android 6.
Well, I don't know how the monthly security-updates will be deployed. I guess it will be done by OTA (Over the Air) updates. OTA will probably not work after modifying the boot-image. However, flashing factory images should work just fine. Additionally, most of the time, OTA-zips are being posted here on xda or androidpolice whenever they become available so doing manual OTA updates is another possibility to do updates.
To get back to your question - wiping should not be necessary after an upgrade - be it via OTA or factory images. Google did a fantastic job with the upgrade-functionality in newer Android versions. However, whenever you do an update, be sure to run FED-Patcher afterwards because, in case the boot-partitions got updated, forced encryption will be in place again and on the first boot it will encrypt you device.
Well, I do all my tests on a HTC Nexus 9 (flounder). It is a pretty fast beast. However, on an unmodified stock rom, it was clearly tangible that the GUI had more latency than necessary. Apps loaded pretty slowly - compared to my Sony Xperia Z1 (honami) it took like twice as long to start youtube - and in general it just did not behave like a beast. This was why I started writing FED-Patcher. In my opinion it was worth my time. (it wasn't that much actually)
I hope I could help.
Enjoy, gladiac
Thanks for the quick and detailed answer @gladiac, now regarding point number 2.
I never wait for the OTA, but always flash the images manually.
As far as i understand from your answer, it would it be ok to flash all the img files manually, then flash TWRP and finally flash FED without booting the OS.
Am i missing something?
cyberon said:
Thanks for the quick and detailed answer @gladiac, now regarding point number 2.
I never wait for the OTA, but always flash the images manually.
As far as i understand from your answer, it would it be ok to flash all the img files manually, then flash TWRP and finally flash FED without booting the OS.
Click to expand...
Click to collapse
That's pretty much how I would do it. You don't even have to flash TWRP if you just skip flashing the recovery.img which is included in the factory-image package.
Thanks @gladiac, will try that way.
PS: I have a feeling that if we had this option added to a toolkit like Wugfresh Nexus Root Toolkit, it would be an instant success.
hi @gladiac
first of all thanks for your patch
I'm on Nexus 6 with stock Marshmallow and all I want to do is disable encryption and enable root.
Is your patch + SuperSU enough or I need something else?
Thanks a lot
Worked on my N9 - thanks!
provolinoo said:
hi @gladiac
first of all thanks for your patch
I'm on Nexus 6 with stock Marshmallow and all I want to do is disable encryption and enable root.
Is your patch + SuperSU enough or I need something else?
Thanks a lot
Click to expand...
Click to collapse
Hi @provolinoo,
well, FED Patcher will disable the forced encryption for you. However, SuperSU will not work so easily. The reason for that is that the stock ROM has SeLinux enabled in "enforcing" mode. SuperSU does not work without adding more SeLinux Policies to the stock ROM. Unfortunately, it's not in the scope of FED Patcher to add SeLinux policies for SuperSU. This should be done inside the flashable ZIP of SuperSU instead.
The last time I tested SuperSU with marshmallow stock was with version 2.52 BETA. It did not work. The result was a boot-loop because of one or more SeLinux denials. A little more info on that matter is here.
So, to get SuperSU working you would have to set SeLinux to "permissive" mode. Alternatively, you can use @Chainfire's boot.imgs to make SuperSU work.
Have fun, gladiac
Thank you gladiac. Your FED patcher (v8) works flawlessly on my Nexus 9. Edit: I am using TWRP 2.8.7.1
The gerrit conversation you linked is interesting. I am grateful that someone with your skills decided to support our ability to choose whether or not to encrypt. CM thinks I am smart enough for root priveleges but I am too stupid to be trusted with decryption?
Don't some major vendors allow the disabling of encryption from within Android?
Anyway, thanks for the patcher.
dmantilal said:
Thank you gladiac. Your FED patcher (v8) works flawlessly on my Nexus 9.
The gerrit conversation you linked is interesting. I am grateful that someone with your skills decided to support our ability to choose whether or not to encrypt. CM thinks I am smart enough for root priveleges but I am too stupid to be trusted with decryption?
Don't some major vendors allow the disabling of encryption from within Android?
Anyway, thanks for the patcher.
Click to expand...
Click to collapse
I agree, I love CM roms but their decision to force encryption when most of cm users are power-user is a nonsense
Sooo....basically, I cannot use a stock Marshmallow that is FEDpatched and with root (using SuperSU, unless there is alternative)? If I want those, I have to get one of the custom ROMs?
EDIT: also, I tried using Chainfire's modified boot. It is stated that it will disable the forceencrypt. It didn't work in mine, still encrypted.
jamesalfred said:
Sooo....basically, I cannot use a stock Marshmallow that is FEDpatched and with root (using SuperSU, unless there is alternative)? If I want those, I have to get one of the custom ROMs?
EDIT: also, I tried using Chainfire's modified boot. It is stated that it will disable the forceencrypt. It didn't work in mine, still encrypted.
Click to expand...
Click to collapse
Did you follow the directions and format the entire "data" partition?
dmantilal said:
Did you follow the directions and format the entire "data" partition?
Click to expand...
Click to collapse
I too have the same problem didnt work for me.
im on the the new 6.0 L build but went ahead and flashed the modified boot image for K build just so I could flash the TWRP img.
Once TWRP was installed, I installed the Fed path ZIP and that went well supposedly. and then after that I did a factory reset, then I WIPED the DATA, CACHE and Dalvik.. I rebooted setup my device and it still shows encrypted.
nextelbuddy said:
I too have the same problem didnt work for me.
im on the the new 6.0 L build but went ahead and flashed the modified boot image for K build just so I could flash the TWRP img.
Once TWRP was installed, I installed the Fed path ZIP and that went well supposedly. and then after that I did a factory reset, then I WIPED the DATA, CACHE and Dalvik.. I rebooted setup my device and it still shows encrypted.
Click to expand...
Click to collapse
It did not work because you did not follow the directions.
Flash TWRP. Flash FED. Full wipe (or format, depending on your choice of terminology). OP goes on to clarify by saying "This full wipe will clear all your data on your data-partition (where your apps as well as their settings are stored) as well as on your internal storage so please, do a backup before.", meaning if you did not lose everything on data, which includes "/sdcard", you most likely did it wrong.
Give us more info so we can help (assuming you fid it right initially).
P.S. - 6.0 is M(arshmallow), not L(ollipop).
dmantilal said:
Did you follow the directions and format the entire "data" partition?
Click to expand...
Click to collapse
dmantilal said:
It did not work because you did not follow the directions.
Flash TWRP. Flash FED. Full wipe (or format, depending on your choice of terminology). OP goes on to clarify by saying "This full wipe will clear all your data on your data-partition (where your apps as well as their settings are stored) as well as on your internal storage so please, do a backup before.", meaning if you did not lose everything on data, which includes "/sdcard", you most likely did it wrong.
Give us more info so we can help (assuming you fid it right initially).
P.S. - 6.0 is M(arshmallow), not L(ollipop).
Click to expand...
Click to collapse
i solved my issue. i was wiping DATA but not choosing internal storage. i did that and rebooted and now it says ENCRYPT not ENCRYPTED
THANKS!
so currently I have a modified boot image from the K build, TWRP and now a modifier boot.img kernel for no force encrypt BUT I am not rooted and dont plan on it. does this mean I can still get OTAs?> i would guess not since my boot image has been modified and i am unlocked? would i even want an OTA? wouldnt that just give me a stock boot.img again causing me to get encrypted on the next boot after OTA?
nextelbuddy said:
i solved my issue. i was wiping DATA but not choosing internal storage. i did that and rebooted and now it says ENCRYPT not ENCRYPTED
THANKS!
so currently I have a modified boot image from the K build, TWRP and now a modifier boot.img kernel for no force encrypt BUT I am not rooted and dont plan on it. does this mean I can still get OTAs?> i would guess not since my boot image has been modified and i am unlocked? would i even want an OTA? wouldnt that just give me a stock boot.img again causing me to get encrypted on the next boot after OTA?
Click to expand...
Click to collapse
Side-loading the OTA then following that with a FED flash seems much safer.
Loading an OTA directly would over-write the boot.img with a ForceEncrypt boot.img, logically Forcing Encryption (derp) at boot.
I am using chroma ROM which doesn't force encryption and my device is still encrypted. Can I still use this?
jamespat93 said:
I am using chroma ROM which doesn't force encryption and my device is still encrypted. Can I still use this?
Click to expand...
Click to collapse
You can if you want But if you want to unencrypt your phone, backup your ROM, copy sd content to your computer, wipe everything! in recovery (twrp) including Format Data, Factory reset, internal storage etc. Connect your phone while in recovery to your computer (you'll see 25.98GB instead of 23.03GB), copy sd content back to your phone, restore your rom backup and you'll be fine.
I can't get it work on Nexus 6 and chroma rom r26.
My steps: wipe everything, push folder (rom,patcher and gapps), flash chroma, flash gapps, flash patcher, wipe everything but system
after boot in setting/security it is again encrypted. what I am doing wrong?
I understand that the TWRP team is apparently still working on an official release for Android 13, but is there even an unofficial build available for the P7Pro? If not, is there a recovery alternative? I really want to be able to do a full system (all partitions) backup of my device. Thanks!
You can create dumps of your partitions using ADB shell in system; TWRP is not required to do this.
Though it wouldn't necessarily be any good for doing full partition backups, I'm currently running the recovery from the StagOS ROM in combination with the stock Pixel ROM. I like it because it allows flashing recovery zips without having to say "Yes" every time due to signature stuff.
A very similar thread with the same topic has been discussed a few days ago - you can check here
Anyone can compile TWRP - it's opensource. Pixel 6+ owners are unlikely to get an official build from TWRP since it requires a volunteer to maintain the repo, deal with bug reports, etc.
It's recommended to simply compile the image on an individual basis (you really don't want to rely on a third-party supplied image when you have no way of knowing whether it's safe or not). Compiling isn't a difficult process, but does require an hour or two of reading TWRP's and Google's applicable developer pages, along with ~30 - 60 minutes of set up time on a PC/laptop (I prefer to compile within an Ubuntu VM, but I believe it can also be done in Windows' WSL).
robroy90 said:
I understand that the TWRP team is apparently still working on an official release for Android 13, but is there even an unofficial build available for the P7Pro? If not, is there a recovery alternative? I really want to be able to do a full system (all partitions) backup of my device. Thanks!
Click to expand...
Click to collapse
They still haven't finished official support for Android 12. Since recovery resources on A12+ are located in vendor_boot, bigbiff is trying to figure out a decent way for TWRP to live there, at least as far as the Pixel 5 is concerned. Not sure what other obstacles may be present on the Pixel 6 series and above.
nooted1 said:
Though it wouldn't necessarily be any good for doing full partition backups, I'm currently running the recovery from the StagOS ROM in combination with the stock Pixel ROM. I like it because it allows flashing recovery zips without having to say "Yes" every time due to signature stuff.
Click to expand...
Click to collapse
Hey thanks for this! How did you flash just the recovery partiton on the Pixel? I am an old hand with Odin on the Samsung devices, but Google official devices are still new to me. Will the StagOS recovery recognize an external USB-C flash drive for storage?
s3axel said:
A very similar thread with the same topic has been discussed a few days ago - you can check here
Click to expand...
Click to collapse
Thank you, I went over there and read everything. Much appreciated!
@SkewedZeppelin
Hello, I installed the latest DivestOS version today as I was previosuly pretty dissapointed with standard LineageOS due to the amount of google and propiertry blobs it contained. I have followed divestOS for a while now and when my Lineage boot looped this morning I thought it was a good time to test DivestOS.
First off, I am very impressed with DivestOS, extremely slimmed down OS and I am much more comfortable with the privacy aspects that DivestOS is accomplishing. So thank you for all your efforts with the OS, it really is great and I would without a doubt recommend anyone who hasn't given it a spin to try it asap.
Now, I have a few issues I hoped @SkewedZeppelin or anyone else for that matter might be able to help me with. I have read the DivestOS documentation completely so understand what the recommendations and preferences of the developer is and why. I get it. That being said, we don;t live in an ideal world and unfortunately I do have some specific requirements that I can't go without and so I wanted to see how/if they could be incorporated. First of, which I know is a big no-no for the DivestOS developer, I need to root. I absolutely require call recording and without the native ability to automatically do it I have to really on a very good magisk module. Secondly, I need to be able to use TWRP with the ROM. I know TWRP has not been great with Lineage build but, I was able to unencrypt lineage-20.0-20230105 with the last @Siddk version, which the developer has now discontinued. So https://forum.xda-developers.com/t/recovery-11-12-13-unofficial-twrp-for-oneplus-6-6t.4382121/ is the last version I can use. Unfortunately @Siddk TWRP does not unencrypt the latest DivestOS. I need TWRP for recovery, like this morning when my lineageos boot looped for no apprent reason all my private data was lost, only for @Siddk TWRP saved the day and allowed me to unencrypt and adb pull it all out.
So to overcome these hurdles I would like to install an older version of DivestOS that would allow @Siddk TWRP to work. I had a copy of divested-20.0-20230123 so tried that but it is also too new and not working with TWRP. I would then assume that although the DivestOS is strongly against rooting, I would be able to flash Magisk as normal and then flash TWRP as my recovery. So i end up with an older DivestOS, running TWRP recovery, rooted with Magisk so I can run the call record magisk module. I am aware that rooting will effect future updates however I won't be wanting future updates because I need to stay on the same version to make sure TWRP continues to work.
Sooo, a very long winded way of asking for some links to older DivestOS builds, based on lineage-20.0-20230105 that @Siddk TWRP will work on and also to double check that I can infact still root the OS (even against the advice of the developer) if that is what i need to do.
Many thanks
You don't need an older build.
Just use the latest LineageOS recovery to flash Magisk and then you'll have root for your call recorder app.
Backup your device using Seedvault + copying files over MTP.
Also note there is a known issue recently on these devices where they may appear to bootloop, but it is just a race-condition and you can reboot a few times and they'll work: https://gitlab.com/LineageOS/issues/android/-/issues/5587
Thanks. I prefer a custom receovery (TWRP) that can decrypt the phone so when the phone does crash I have access to my data and it can be saved. If I couldn't use TWRP yesterday then everything since my last backup would have been lost for me. Do you have any links to older builds? Is it something you could possible provide?
Dissapointing that you chose just to ignore my last post. Pretty valid points on my part. Guess you want to keep your build locked down rather than having it open to user. Always a privacy and security concern when developers go down that route.
xs_pam said:
Dissapointing that you chose just to ignore my last post. Pretty valid points on my part. Guess you don't want to keep your build locked down rather than having it open to user. Always a privacy and security concern when developers go down that route.
Click to expand...
Click to collapse
mate the source code is right here, if you don't like my decisions you're welcome to compile with anything you want included: https://github.com/divested-mobile
there is even a written and video version of the build guide to make it very easy: https://divestos.org/pages/build
xs_pam said:
TWRP
Click to expand...
Click to collapse
Is not supported by DivestOS due to the stronger encryption used: https://github.com/Divested-Mobile/...d_system_extras/0001-ext4_pad_filenames.patch
you'd have to compile TWRP with that patch included
I understand, it's your ball, your decisions. Open source developers usually make previous releases available to allow users to snag issues etc, that was all I was asking but I accept your decison.
If TWRP would not work in any event, that means that there is no effective data recovery mechanism for your OS? You are maybe isolating a large part of your market there, I understand there is trade off between security and accesss but I would suggest the option to recover personal data form a bricked/looped OS would be more in demand than having data that absolutely no one can recover, including by the owner. At the end of the day having a recovery option uses the same access decryption method as the general phone access, means the data would still be as secured with a recovery option as it would be on a functioning os. It's the same methos to decrypt.
xs_pam said:
Open source developers usually make previous releases available
Click to expand...
Click to collapse
That is hundreds of gigabytes for each release batch, do you wanna pay that server bill?
That idea of yours wouldn't even work and as noted isn't even neccessary to get Magisk installed.
xs_pam said:
no effective data recovery mechanism for your OS
Click to expand...
Click to collapse
Seedvault is included for app backups.
xs_pam said:
no one can recover
Click to expand...
Click to collapse
it is your responsibility to make backups of your data regardless of what software you use
Fairpoint, I didn't realise the server costs were such an issue.
Your conflating back-up and recovery, they are two seperate things. Backing up is scheduled and planned, recovery is not. Unless you are backing up and then extracting that backup from your phone multiple times per day then you are at risk of losing important data should the unexpected occur. Data recovery is AS important but seperate to backing up. An OS without a data recovery option, or that blocks data recovery options, is significantly lacking. I understand that you use the lineage recovery but that does not provide an option to recover data.
xs_pam said:
Fairpoint, I didn't realise the server costs were such an issue.
Your conflating back-up and recovery, they are two seperate things. Backing up is scheduled and planned, recovery is not. Unless you are backing up and then extracting that backup from your phone multiple times per day then you are at risk of losing important data should the unexpected occur. Data recovery is AS important but seperate to backing up. An OS without a data recovery option, or that blocks data recovery options, is significantly lacking. I understand that you use the lineage recovery but that does not provide an option to recover data.
Click to expand...
Click to collapse
there are workarounds to what you are trying to achieve, i don't own a oneplus but i have achieved it with this OS.