yashsingh1/xdaforums huggingface dataset:
[ONE Original Android Development] navinthomas:
EFS

Can someone verify whether this 'official' TWRP takes EFS backup? I was under the assumption that official TWRP does not backup EFS at all ............................. until I saw this thread in OnePlus forums. The log files in my NANDroid do mention the modemst files. Still, I am not 100% sure. :confused:

Note: My TWRP version is 2.8.1.0
[ONE Original Android Development] letmeputdatipin:
Yes it does. You can also use Terminal and DD cmd right from ur phone and backup right to ur sdcard.
[ONE Original Android Development] :
If someone doesn't like something, move on......use something else.

Nonconstructive complaining is disrespectful to the members who contribute work, for free and for fun.

Thank you,

Darth

Forum Moderator
[ONE Original Android Development] Nburnes:
or if you have a more recent TWRP installed already
[ONE Original Android Development] navinthomas:
I had an old version so had to flash via fastboot
[ONE Original Android Development] navinthomas:
Firmware backup

Is there anyway I could include the firmware also in my NANDroids? If not with NANDroid, is there any other way possible?

Some ROMs require some specific firmware to be flashed before installing, which means (I think) you can't switch back to the previous ROM using NANDroid alone..... making things a bit less seamless than what I like. :(
[ONE Original Android Development] bombadier:
Simplest way would be to keep a copy of the firmware flashable zips and a sensible naming convention, you could use a script to back up the firmware partitions but unless you know what you are doing could get messy,

Possibly suggest to one of the TWRP custom builders?
[ONE Original Android Development] navinthomas:
Simplest way? Probably. Not simple enough for me. :D

I'm on CM 12S for OnePlus One. Have to look for the firmware of it.

I don't have any experience with scripts and stuff. Let me check with one of the unofficial TWRPs.
[ONE Original Android Development] bombadier:
Here is a recovery flashable zip with the stock YNG1TAS0YL firmware

All you would need to to is restore your recovery made backup of CM OS12 and then flash this zip and you have restored and reverted to the correct firmware for that version, you got 64GB so just keep the firmware zips handy and flash the relevant one as needed, it is pretty simple
[ONE Original Android Development] navinthomas:
Thanks man :highfive: . May I know from where you got it?
[ONE Original Android Development] bombadier:
Just download the image and use flashify to flash, also if you are not already using it use the material theme for TWRP which had support for image flashing before TWRP officially did no need for a zip

---------- Post added at 07:17 PM ---------- Previous post was at 07:15 PM ----------

I made it by replacing the relevant files in an existing firmware zip I have, I think you can handle that :laugh: it really is not too complicated :good:
[ONE Original Android Development] navinthomas:
Didn't get you. :confused:
[ONE Original Android Development] bombadier:
Sent you a pm

tapatyping fae the bacon
[ONE Original Android Development] playya:
Flashable version is simple just find the last version of TWRP that you flashed and simply replace image with the new one. I have been doing this forever and no need to wait for anyone to create something that you can do yourself. Of course you can flash an image with the latter versions of TWRP as well.

Hope this helps and remember to try things for yourself and research things. Its a good feeling when you do it on your own.
[ONE Original Android Development] nofx161:
can anyone help me please, with a previouse version of twrp i was able to backap modem too and more things than i can now, even when i flash a older version, and i need those 2 modems saved too or the backup wont work ,... i always have to flash this one old backup with the two modems in it,... how can i backup everything really everything??

any help is appriciated. thanks in advance.
[ONE Original Android Development] giaur:
Can you add support for lz4 compressed ext4? Lack of support for that currently causes issues on recent cm12.1 build, especially failure of scripts for make copy of gapps while upgrading to newer nightly. Look here:

http://review.cyanogenmod.org/#/c/95349/

http://review.cyanogenmod.org/95220

http://review.cyanogenmod.org/95221
[ONE Original Android Development] :
Update needed,now it's impossible use TWRP with CM12.1
[ONE Original Android Development] DerRomtester:
Dees troy is working on it.
[ONE Original Android Development] tobitege:
CM already disabled lz4 compression for bacon (msm8974-common repo), next builds should work fine as before.
[ONE Original Android Development] giaur:
Yes, but most likely they are going to enable it again in the future.
[ONE Original Android Development] davbarr:
Hey!

problem found with twrp 2.8.6.0:

Unable to wake screen with touchscreen. Only power button and vol up down work!

Do you have the same problem?
[ONE Original Android Development] jmtjr278:
Expected behavior.
[ONE Original Android Development] davbarr:
Sorry, i'm french and i don't understand what you want to mean.

For you, it's normal?

But when i flash TWRP 2.8.1.0 this feature work like a charm but don't work with 2.8.6.0...
[ONE Original Android Development] jrior001:
Here's a build that*should work with lz4 should it make a return, also fixes flashing ota's from CM(was broke in the last official build I tried).

http://downloads.codefi.re/jrior001/openrecovery-TWRP-bacon-UNOFFICIAL-2.8.6.0-lz4.img

Meanwhile I will be trying to get some updates to the twrp devices repos for bacon.
[ONE Original Android Development] davbarr:
Install via fastboot OK

Wow amazing work like a charm with THIS version! :good:

Thanks a lot! :laugh:

But i don't understand why official not work with my opo and work with other user.
[ONE Original Android Development] jrior001:
Dunno... Old trees, dees doesn't have a opo so he'been doing this blind all along. In just trying to help out
[ONE Original Android Development] nuwan32:
does 2.8.6.0 work with cm12.1/5.1.1?
[ONE Original Android Development] dmarden:
Yes
[ONE Original Android Development] Signor Rossi:
Hi,

I encrypted my phone with CWR recovery installed, but after returning to stock recovery for applying the last OTA update I lost root (as expected).

I switched to TWRP 2.8.6.0 which was asking for the Password of the encrypted partition, but it did not accept it.

Any Idea ?
[ONE Original Android Development] xenithorb:
- Bug in 2.8.6.0:

Since the addition of the pattern decrypt....

CM11 and 12, 12.1 all support higher number grids than stock android which is 3x3.

I personally use a 5x5 grid and since the dmcrypt partition is somehow flagged as being a pattern, the only option TWRP gives me to decrypt is a 3x3 pattern.

When booting CM12, there are options on the bottom to change the grid size and it works to authenticate the data partition to mount, I expected similar functionality in TWRP, but there's just simply no way for me to backup at the current moment that I am aware of.

What's worse, is that even changing to a normal password or pin, doesn't work:

"E:Failed to decrypt data." in the log, and "Password Failed, Please Try again" below the pw input box.
[ONE Original Android Development] jrior001:
Twrp won't decrypt /data on begin, hasn't for a long time. CM added some HW decryption that twrp hasn't figured out how to decrypt in recovery yet. Right now there is nothing that can decrypt in recovery that I'm aware of.
[ONE Original Android Development] nolsen311:
Truth. Isn't anyone on TeamWin aware of it? Maybe I should've filled out a bug, but I assumed that someone knew.
[ONE Original Android Development] nsmart:
TWRP is not working with device encryption on bacon and cm12. Details can be found in issue #333 on TWRP Github https://github.com/TeamWin/Team-Win-Recovery-Project/issues/333

When I set up my opo and enabled device encryption, i got bootloops to twrp recovery. I had to flash stock recovery and then the encryption successfully completed. Afterwards I flashed back twrp. As long as decryption of the data partition is not working, you can update the rom by copying the rom.zip to cache partition.
[ONE Original Android Development] Signor Rossi:
Thanks for the Info

Send from OnePlus One using Tapatalk
[ONE Original Android Development] iamelton:
this is to report that in oneplus one with v2.8.6.0 (latest), the time display is offset by 1 hour, i.e. it shows 10am when its actually 11am locally..

the timezone setting is "GMT+8" (Beijing, Hong Kong, Singapore, etc., shown as TAIST-8 in twrp) and DST option not checked..

this issue only occurs with OxygenOS but not with COS12.. so could be a rom-related problem then? (but if yes, how come?)
[ONE Original Android Development] Lanchon:
obviously they set the real time clock differently. in linux the RTC must be set to UTC time (which is sometimes aka GMT). one of the two OSes seems to be setting it to the wrong time. ill try to find some info and post back.
[ONE Original Android Development] iamelton:
in that case could be an issue in AOSP roms, as the issue also appears in my Nexus 5 running stock android kitkat..

and OxygenOS is near AOSP at android lollipop..
[ONE Original Android Development] Lanchon:
or issues in twrp and cos that cancel each other out! :)
[ONE Original Android Development] iamelton:
[MENTION=4141005]Lanchon[/MENTION] thx for the investigation.. im not sure i understand fully.. anyway tried the following..

============================================================

(1)

ran system shell "date -u" command:

Wed Apr 29 18:01:47 GMT 2015

ran recovery shell "date -u" command:

__bionic_open_tzdata: couldn't find any tzdata when looking for UTC0!
__bionic_open_tzdata: couldn't find any tzdata when looking for posixrules!
Wed Apr 29 17:04:08 UTC 2015

i ran the commands at about 2am UTC+8, so the system time was correct while twrp recovery time was wrong by 1 hour..

btw, i dont use network time sync, the option was turned off when i first initialised the phone..

(2)

turned on network time sync and network timezone sync..

i was not sure when it synced as the system didnt change, so did a reboot to make sure..

system time still didnt change..

(3)

ran system shell "date -u" command:

Wed Apr 29 18:12:27 GMT 2015

ran recovery shell "date -u" command:

__bionic_open_tzdata: couldn't find any tzdata when looking for UTC0!
__bionic_open_tzdata: couldn't find any tzdata when looking for posixrules!
Wed Apr 29 17:14:57 UTC 2015

again the system time was correct while twrp recovery time was wrong by 1 hour..

============================================================

what could be wrong here?

---------- Post added at 02:27 AM ---------- Previous post was at 02:18 AM ----------

more info here..

i didnt find any DST setting in the system, so i would assume its taken care by the system after i selected a particular timezone..

when i enabled "DST" in twrp, then the time displayed was correct..

so by [MENTION=4141005]Lanchon[/MENTION]'s theory that twrp was calculating the time from some system stored value, it probably meant that the system was wrong with DST for my UTC+8 timezone..

there should be no DST but system mistook it and added 1 hour offset, and this made twrp report the wrong time..

---------- Post added at 02:33 AM ---------- Previous post was at 02:27 AM ----------

its even more strange that not all nexus devices had this problem..

nexus 5 & oneplus one: system and twrp times differ by 1 hour

nexus 7 & 9: system and twrp times are the same..

in the 3 nexus devices i have stock android (kitkat and lollipop), and in oneplus one i have oxygen os which is near aosp..

all 4 devices have the same system date & time setting, i.e. no network sync and set by me manually..
[ONE Original Android Development] Lanchon:
thanks for testing

well, this only applies to qualcomm krait chips so i dont know if the nexus 7 applies.

> when i enabled "DST" in twrp, then the time displayed was correct..

which displayed time? the UTC (date -u) or the local time in the UI?

even if local time is ok, the UTC time is what's important and timezone and DST settings shouldnt affect it. so although you can tweak the TZ and DST settings to make the displayed time match your local time, that does not fix the problem. the real problem is that the UTC time is incorrect.

this is strange because the gettimeofday here:

https://github.com/omnirom/android_...b7b81a9bac1ef80a67a02/twrp-functions.cpp#L935

works in UTC time, so timezones shouldnt affect the sync of UTC times. assuming the android side of the code is similar, there shouldn't be an hour difference between And & Rec UTCs.

first:

cat /sys/class/rtc/rtc0/since_epoch

anything below 500.000.000 means the your RTC is not set to absolute time (expected in qualcomm devices)

then:

ls -l /data/time

ls -l /data/system/time

in one of those locations you should have some 'ats_*' files (with binary content). maybe twrp is picking the wrong ats_* file.

if you find more than one, check that they are the same. for example, do:

cmp /data/time/ats_1 /data/time/ats_2

in my case the files are identical (ie: no output from 'cmp'), but i dont have the problem you have.

maybe you have files with different content, and twrp could be fixed by choosing the right one.
[ONE Original Android Development] iamelton:
thx again..

(1) that explains why nexus 5 and oneplus one are affected but not nexus 7 & 9, as the former 2 use qualcomm msm8974 chipsets and the latter 2 use nvidia tegra chipsets..

(2) tried "date -u" in recovery with DST option disabled and enabled..

the outputs were the same (though the displayed times in twrp differed by 1 hour)..

so UTC value stored was indeed not affected as u said..

(3) now the strange part..

cat /sys/class/rtc/rtc0/since_epoch

46536229

ls -l /data/system/time

-rw------- system net_raw 8 2015-04-30 02:04 ats_1
-rw------- system net_raw 8 2015-04-30 02:04 ats_2

cmp /data/system/time/ats_1 /data/system/time/ats_2

(no output)

so the stored epoch value was not absolute as expected for qualcomm..

everything seemed normal and it should be working, but it just didnt in twrp!

can i do some more check on that "46536229" relative epoch value then? i just dont know how to verify if this is the correct value or wrong by 3600..

(fyi, i got that value at about 09:32am UTC+8, i.e. 01:32am UTC..)
[ONE Original Android Development] Lanchon:
ok so everything you say is true. the two ats_* files are identical so its not the choice that is wrong. i assume the two ats_* files should always be and they are simply a way to survive crashes during writes.

there is no check you can do on the rtc value: it's just a running counter. the rtc in your phone's chipset has been powered on for 46536229 seconds, pressumably since manufacturing.

the recovery code seems ok, which means that ats_* files seem not to contain what people think. but in any case, do a:

hexdump /data/system/time/ats_1

and i'll verify that, effectively, the value in ats_1 is "wrong".

unfortunately the code that writes these files is a qcom blob and we cant look into it (seriously, why do we take this $#!+). more details here:

http://xdaforums.com/google-nexus-5...philz-touch-6-43-6-f2fs-t2565174/post51386258

https://github.com/TheMuppets/propr...1.0/hammerhead/hammerhead-vendor-blobs.mk#L35

let me see the dump of your ats_1 file, just to validate twrp. but it looks like the solution might be adding the blob to twrp, or remove it from android and replace it with an open one.
[ONE Original Android Development] iamelton:
heres the dump file of ats_1

View attachment ats_1.zip

to double confirm, i also hexdump'ed ats_2 and diff'ed the two outputs, and they were the same..
[ONE Original Android Development] Lanchon:
thanks! so check it out

you say...

RTC was: 46536229

at approximately: 09:32am UTC+8, i.e. 01:32am UTC

and ats_* is: 0x014231f628f0

given that ats is in milliseconds, the corrected RTC (ie: the UTC in unix time) at that time was:

https://www.wolframalpha.com/input/?i=round(0x014231f628f0+/+1000+++46536229)

which translated to gregorian is:

https://www.wolframalpha.com/input/?i=1430353914+unix+time

or: 12:31:54 am UTC | Thursday, April 30, 2015

which is incorrect and exactly one hour before the actual time the measurement was taken.

so we can conclude:

-that the code in twrp does what it was supposed to do.

-that the contents of ats_* sometimes is not what it was thought to be (but sometimes it is, like in my oneplus one that i have right here).

-there is probably no way to tell the behavior from recovery.

-different phones and builds have different proprietary qualcomm time daemons, and they might behave differently or have bugs.

-if a daemon has a bug in calculating ats, as long as the error results in a repeatable bias, the time save and restore will still work in android.

-workarounds on the android side would be cleaner (but not implementable in twrp): upgrading the daemon, replacing it with a free implementation, adding a second daemon that only saves a constant for recovery (but does not set time in android).

-workarounds in twrp would be ugly: fingerprinting the daemon and looking up behavior in a database, adding an offset setting to let you manually adjust UTC.
[ONE Original Android Development] iamelton:
[MENTION=4141005]Lanchon[/MENTION] thx a lot for ur tests and explanations.. now i think i understand more of the time handling stuff..

since the error most probably lies in the qualcomm time daemon logic and is exactly 1 hour offset, could it be due to errors in DST configuration?

certain timezones are pre-set correctly and thus the times are stored correctly..

certain timezones are pre-set wrongly (like my timezone where there is no DST but somehow the time daemon determines that my timezone is with DST), and then the time values are stored with 1 hour offset..

if my theory is correct, some time in future the time value stored in ats_* files will be right again when the time daemon thinks that my timezone has gone out of the DST period.. and then the display in twrp recovery will be correct again magically..

well unless more info are exposed or a proper fix (in the qualcomm code) becomes available, i can only wait and see at the moment i guess..
[ONE Original Android Development] Lanchon:
anything goes in proprietary code, but i have to say that i don't think so. the daemon has no place messing with timezones or local times at all, it should just operate on UTC. actually it should operate on unix time, which is even simpler and always global (there is no such thing as a 'local' unix time). so it happens that i can't come up with any convincing story for a bug in the daemon; it just doesn't make sense. i thought that maybe, during android boot, the kernel is set to the wrong time (off by one) due to some unrelated bug, then the ats_* files are generated, then some other process resets the time to the correct value (eg: net time) but the ats files are not regenerated. but this explanation is at least as implausible as an unjustified bug in the daemon itself for many reasons, and thus doesnt solve anything. it's like postulating a god to explain the existence of the universe because you might not know how it got created, but then god is more implausible than the universe itself so you are worse than when you started.

really, i can't provide any reasonable explanation for all this. i'm sure there must be one, but i obviously ignore too many factors to tell. i have no plans to reverse the stupid daemon, so unless someone chips in, this is as far as i can go.

but thanks again for tests and all the help! i'm sorry we couldn't solve it. :(
[ONE Original Android Development] iamelton:
i raised the problem and u helped a lot along the process.. yes the fix is beyond our reach (or even understanding) but its a fun ride and good learning process to me.. so thx! :good:
[ONE Original Android Development] nolsen311:
Just to clarify, the encryption issue affects everyone.
[ONE Original Android Development] harshalg:
i am facing a strange problem: there is no swipe bar below 'swipe to install' statement in any twrp above 2.8.4.0.....i have tried official and unofficial versions but to no avail....i am currently on 2.8.4.0 and there is no such problem.....any solutions?
[ONE Original Android Development] sean.trinidade:
Are you using a theme? I had that issue when I upgraded twrp but was using a theme designed for an old version!
[ONE Original Android Development] harshalg:
i do remember fiddling with some theme settings (i was trying to change the pic you're greeted with when you boot into recovery)....but my attempts were unsuccessful....so possibly what you say is true.... how do i revert back to stock theme so that i can successfully flash newer twrp versions without any bugs??
[ONE Original Android Development] z31s1g:
On the theme settings page (palette icon on main menu) push the "delete icon" (bin) on the top right corner.

Alternatively, use the "change theme" button on the same page to update your theme to the latest version from here:

https://basketbuild.com/devs/z31s1g/1080/TWRP 286X_v1
[ONE Original Android Development] harshalg:
yup..... the theme was definitely the issue.....i pressed the delete icon and then flashed 2.8.6.0 recovery....and now its working perfectly....thanks to both of you [MENTION=1962979]sean.trinidade[/MENTION] and [MENTION=2719389]z31s1g[/MENTION] :good:
[ONE Original Android Development] z31s1g:
If you keep using the theme, make it a habit to check for updates if a new twrp is out. There's always one for the theme as well... ;)
[ONE Original Android Development] harshalg:
For now, I've decided to stay stock... But I didn't knew that themes too are updated :good:

Baconified goodness with a dash of Euphoria!!
[ONE Original Android Development] geowolf1000:
Latest 2.8.6.0 with implement red material theme

Link

And

Blue grey

Link
[ONE Original Android Development] Formhault:
Screenshots? :D
[ONE Original Android Development] tracerit:
i'm having some issues with TWRP not showing my backups when I try to restore. They're there according to my file manager (Solid Explorer 2) and I can also see the folder when I navigate to it through TWRP's file manager in recovery. Fortunately I was able to backup by installing a new ROM again, downloading TWRP Manager app and restoring from the app (using OpenRecovery script).
[ONE Original Android Development] :
http://up.picr.de/21944540od.jpg

http://up.picr.de/21944579aj.jpg

http://up.picr.de/21944583ry.jpg
[ONE Original Android Development] nolsen311:
2.8.6.1 Update fixes Qualcomm encryption!

(Link is to G+ Post detailing the fix) New build of TWRP for bacon fixes the Qualcomm encryption issues! Took only minutes to verify that I can access encrypted data partition; now I've got a repacked 2.8.6.1 + Splash + Materialised!

https://dl.twrp.me/bacon/twrp-2.8.6.1-bacon.img
[ONE Original Android Development] Uqbar:
2.8.6.1?

Just available now. No changelog available yet, though.

https://dl.twrp.me/bacon/twrp-2.8.6.1-bacon.img.html
[ONE Original Android Development] xanthrax:
Most probably encryption updates as I've seen the developer's post on g+

https://plus.google.com/+DeesTroy/posts/2duMgmYjpLW

Sent from my Darkside of 1+1
[ONE Original Android Development] kartikb:
AROMA installer still doesn't work
[ONE Original Android Development] Lanchon:
[MENTION=912474]Dees_Troy[/MENTION] congrats on figuring out qcom cypt, thank you a lot!! too bad it was such a pita, it shouldnt have been, oh well...
[ONE Original Android Development] dubazar:
Aroma File manager is working on my device, using latest beta version (v.2). Download can be found in this thread http://xdaforums.com/showthread.php?t=1646108
[ONE Original Android Development] Formhault:
Can you please explain why does this matter, exactly? In plain English, please. :D
[ONE Original Android Development] Lanchon:
https://plus.google.com/+DeesTroy/posts/2duMgmYjpLW