My N910F started being unstable about 6 months ago, with stock firmware.
At first it was clearable with a factory reset so I assumed it was a bad app, but it's now at the point where it bootloops even after reformatting all partitions and reinstalling roms+kernels (it happens with stock or custom roms/kernels)
To cap it off, it's even possible to provoke a crash inside TWRP 2.8.1.0 by issuing a simple "dmesg" command in the terminal
Does anyone have suggestions?
Turno off finge print scanner and android encryptation
just updated to twrp 2.8.7.0 and having the same problem.
EclipseX said:
Turno off finge print scanner and android encryptation
Click to expand...
Click to collapse
It's not getting past the bootup screen on any rom to be able to do either - and I've never enabled encryption anyway - not that it matters as both are disabled on a factory-fresh installation of any rom (stock or modified)
The crash on dmesg is one thing that I'm particularly worried about. Can anyone else replicate this behaviour in recovery?
It's really too bad that CWM or TWRP don't contain badblock and memory testers.
After writing zeros to the entire /cache /system and /data partitions (dd if=/dev/zero of=/filesystem/dummy), the phone finally stabilised.
My hypothesis at the moment is that there's a SSD badblock lurking somewhere. It'd be interesting to know if there are any tools which can analyse the flash chips (on par with smartctl)
UPDATE:
I was able to get 2 units side-by-side again. This time both of them were encrypted. The difference was one was running the original MDA89E OS and the other was running the latest MTC19V OS.
I just did 1 simple test, I created a 238.5MB zip file of my Titanium backup directory.
On MDA89E (user partition encrypted) it took 6:39
On MTC19V (user partition encrypted) it took 1:01
This result along with the previous results that found virtually no difference between decrypted and encrypted on MHC19Q leads me to the conclusion that decrypting probably did see a performance boost on the original MDA89E software all the way up to probably MMB29V but from MHC19J onwards, up to at least MTC19V, there is virtually no real-world (rather than benchmark) difference between decrypted and encrypted.
I didn't have time to do more detailed testing on this phone as it needed to be returned.
----
So I have 2 5x's side-by-side running MHC19Q. Exact same software loaded, exact same system settings.
One has encrypted userdata. The other has decrypted userdata. Both have dm-verity (integrity checking for /system and /vendor) disabled.
I compare boot times and they are the same.
Then I compare taking 3 HDR+ camera shots and the speed is the same and the processing of HDR completes at the same time.
I start browsers on both and they come back the same time.
I tried starting Riptide GP2, Cut The Rope, and a offline GPS program I use. The games started maybe 0.25 seconds faster on the unencrypted phone. The GPS started the same.
I was surprised at how little difference, so I rebooted to make sure nothing was cached, and retried. Same results.
As an aside, I also compared boot times with bootloader locked stock encrypted with dm-verity enabled to decrypted with dm-verity disabled. Decrypted with dm-verity disabled might be 1 or 2 seconds faster for start up, but you get a 5 second delay with the Orange bootloader warning screen.
So I'm wondering what else to test to show off how fast decrypted userdata is? If there is a noticeable benefit on something I use often I'd probably end up keeping the userdata unencrypted.
I'm not interested in artificial benchmarks showing throughput.
For the record, I haven't experienced any lagginess on any of the configurations, encrypted or not, for my own usage patterns, even on the original MDA89E.
The camera is definitely faster to start up on MHC19Q over the one in MDA89E but only by about 0.5 second.
Standby battery time is the same whether encrypted or not. That is really dominated by whether you have wifi turned on all time (either on purpose or through android bug) or going to sleep and whether you have strong or weak cell signal.
From my personal experience.
I ran my N5X unencrypted for couple of months and then decided to encrypt to see if I experience a noticeable difference.
I didn't experience any noticeable difference so I decided to keep it encrypted and still have it this way. I think it's not worth it to bother with disabling forced encryption during every firmware update, especially when running stock kernel.
Pretty much same as everyone else i have talked to and my personal experience isn't any different.
One other test I am interested in, restoring a back up of stock rom. My 5X seems way slower restoring a back up in twrp latest than my n6 or 6P, anyone else have the same experience resorting back ups.
Or do sfhub can you run the test?
Thanks for the post!
Sent from my Nexus 5X using XDA-Developers mobile app
razrlover said:
One other test I am interested in, restoring a back up of stock rom. My 5X seems way slower restoring a back up in twrp latest than my n6 or 6P, anyone else have the same experience resorting back ups.
Or do sfhub can you run the test?
Click to expand...
Click to collapse
I don't have the side-by-side units anymore, but I'm guessing at the linux level if I did copied the system partition image to the data partition using dd I would notice a difference.
At the Android level I'm thinking the "extra" stuff Android is doing causes it to not be able to reach the full potential of the storage (even at the half speed the encryption has supposedly limited the storage to)
Kind of like putting a 550MB/sec SSD on an old computer with SATA2. It can probably only do 150MB/sec over the SATA2 (vs SATA3) interface, so even if you drop the SSD rate in half to 225MB/sec, while that looks bad on benchmarks, your old PC doesn't care because it can barely handle 150MB/sec.
I didn't do tests to prove this, so it is just a theory, but I did do some side-by-side comparisons listed above and I really can't effectively tell any difference between encrypted and decrypted userdata (for my usage)
I'm guessing the nandroid backups from TWRP would see some difference, but I don't do those often as the images are just getting larger and larger these days.
As an update, I left the unit unencrypted for about a month, but recently I discovered 2 downsides, which while minor, pushed me over the edge to re-encrypt the user partition.
With user partition un-encrypted (only tested MHC19J through MTC19T)
1) visual voice mail tab disappears from phone application if you reboot in airplane mode (this is on Project Fi)
2) USB OTG flash drive reader takes 2 inserts to recognize micro-sd card
These both have to do with delayed recognition of attached devices when user partition is decrypted. In the first case, upon reboot while in Airplane mode the SIM card is not detected, instead it says "No SIM card". When you have encrypted user, it detects the SIM card and says "No service"
For the second case, it detects the USB flash card reader, but not the microsd card in the reader. Upon second insert, it detects both. When user partition is encrypted, it detects both immediately.
These are detailed here:
http://forum.xda-developers.com/nexus-5x/general/resolved-visual-voice-mail-disappearing-t3391434
Also in re-encrypting the user partition I found it didn't work through Android "Settings" for my setup.
I have systemless root and TWRP 3.0.2-0. When you choose to Encrypt phone using Settings, it proceeds to reboot, but then gets stuck at the animation forever. I left it like that overnight.
I then held the Power button to reboot, expecting everything to be corrupted with a half way encryption, but to my surprise, the phone booted with no issues and the Settings still said it was un-encrypted.
I then went back and flashed stock boot and recovery, and rebooted the phone, allowing the standard "first boot" encryption to run. It took around 10 minutes, but everything encrypted fine with no data loss (I had around 15GB on the phone at the time, all backed up of course)
sfhub said:
I'm not interested in artificial benchmarks showing throughput.
Click to expand...
Click to collapse
When the difference is small you won't notice in daily activities, unless in a particular condition, one day, on one app that requires to process lot of data (reading/writing from disk) you will notice that it take some time if you have encryption. That's why the use of benchamark, they give you an indication of who is definetely faster (in many conditions faster just for 1 millisecond, sometimes faster than some seconds/minutes)!
You should test apps that write read / write lot of data, maybe like measure a heavy game start up, or measure an app that write for example mp3 tags in bulk mode to all mp3 of a huge album, etc.
sfhub said:
So I have 2 5x's side-by-side running MHC19Q. Exact same software loaded, exact same system settings.
One has encrypted userdata. The other has decrypted userdata. Both have dm-verity (integrity checking for /system and /vendor) disabled.
I compare boot times and they are the same.
Then I compare taking 3 HDR+ camera shots and the speed is the same and the processing of HDR completes at the same time.
I start browsers on both and they come back the same time.
I tried starting Riptide GP2, Cut The Rope, and a offline GPS program I use. The games started maybe 0.25 seconds faster on the unencrypted phone. The GPS started the same.
I was surprised at how little difference, so I rebooted to make sure nothing was cached, and retried. Same results.
As an aside, I also compared boot times with bootloader locked stock encrypted with dm-verity enabled to decrypted with dm-verity disabled. Decrypted with dm-verity disabled might be 1 or 2 seconds faster for start up, but you get a 5 second delay with the Orange bootloader warning screen.
So I'm wondering what else to test to show off how fast decrypted userdata is? If there is a noticeable benefit on something I use often I'd probably end up keeping the userdata unencrypted.
I'm not interested in artificial benchmarks showing throughput.
For the record, I haven't experienced any lagginess on any of the configurations, encrypted or not, for my own usage patterns, even on the original MDA89E.
The camera is definitely faster to start up on MHC19Q over the one in MDA89E but only by about 0.5 second.
Standby battery time is the same whether encrypted or not. That is really dominated by whether you have wifi turned on all time (either on purpose or through android bug) or going to sleep and whether you have strong or weak cell signal.
Click to expand...
Click to collapse
Right on, it has no real-world difference similar to modifying the kernel, just a PITA to go back and forth every time there is a new release.
this discussion is making me consider encrypting my data partition again via the security->encrypt phone menu.
if i backed up my current system via TWRP to external storage prior to encryption, would i be able to restore it on top of the encryption?
Damn it! I decrypted but today I flashed PA rom and it got encrypted again
Do I need to format data always when flashing??
When I had decrypted, I didn't notice better battery. But maybe a slightly fastness improvement. Or maybe placebo. But I don't mind losing encryption
Sent from my Nexus 5X using Tapatalk
andQlimax said:
When the difference is small you won't notice in daily activities, unless in a particular condition, one day, on one app that requires to process lot of data (reading/writing from disk) you will notice that it take some time if you have encryption. That's why the use of benchamark, they give you an indication of who is definetely faster (in many conditions faster just for 1 millisecond, sometimes faster than some seconds/minutes)!
You should test apps that write read / write lot of data, maybe like measure a heavy game start up, or measure an app that write for example mp3 tags in bulk mode to all mp3 of a huge album, etc.
Click to expand...
Click to collapse
As I mentioned, I understand benchmark differences. I only care about differences I will notice in everyday use. I don't really care about running un-encrypted so that a benchmark runs fast or something somebody else uses, but I never, or almost never, use will run slightly faster.
For what I do use, I tested offline GPS apps which load lots of data. I tested Riptide GP2 which loads a decent amount of data. Basically everything I tested from within Android had so little difference (if any) that it wasn't noticeable. I am talking .25 second at most.
You probably will notice if you write to a file directly using dd, for example if you are doing image backup of system, but I really don't do this stuff daily. I might do it only once when I first get the phone to preserve the factory images.
Anyway, since the difference was so tiny and I noticed a separate problem of my visual voicemail tab disappearing on reboot related to encrypted user partition, I re-encrypted. The test I care about is if I am grumbling everyday about how slow things are and really I noticed zero difference.
I don't have anything against un-encrypted user as I ran that way for a month. I just really saw no benefit.
As a bonus my USB OTG flash reader gets recognized right away instead of requiring 2 inserts.
There is no way this encrypted vs un-encrypted setup is causing the huge slowdowns some people are experiencing. That is caused by something different, probably EMMC getting close to full or some Android bug.
2x4 said:
this discussion is making me consider encrypting my data partition again via the security->encrypt phone menu.
if i backed up my current system via TWRP to external storage prior to encryption, would i be able to restore it on top of the encryption?
Click to expand...
Click to collapse
Encrypt from Settings->Security won't work with TWRP and rooted boot.img. At least it didn't with MTC19T. I don't know if the problem is TWRP or boot.img but on the reboot after the Encryption plugin your phone warning/prompt the thing just hangs on the boot animation forever (I left it all night).
I ended up flashing stock boot.img and recovery.img, then letting the encrypt on first use routine go through. It took around 10-15 minutes. Then I flashed TWRP and supersu again. This is the only way I was able to re-encrypt and preserve my data.
sfhub said:
Encrypt from Settings->Security won't work with TWRP and rooted boot.img. At least it didn't with MTC19T. I don't know if the problem is TWRP or boot.img but on the reboot after the Encryption plugin your phone warning/prompt the thing just hangs on the boot animation forever (I left it all night).
I ended up flashing stock boot.img and recovery.img, then letting the encrypt on first use routine go through. It took around 10-15 minutes. Then I flashed TWRP and supersu again. This is the only way I was able to re-encrypt and preserve my data.
Click to expand...
Click to collapse
hmm wait, so there's no way to re-encrypt if you've already decrypted and you're using a custom rom?
Javi22 said:
Damn it! I decrypted but today I flashed PA rom and it got encrypted again
Do I need to format data always when flashing??
When I had decrypted, I didn't notice better battery. But maybe a slightly fastness improvement. Or maybe placebo. But I don't mind losing encryption
Click to expand...
Click to collapse
If the kernel you flashed has forceencrypt in the mount tables, it will encrypt upon first boot.
I was able to preserve unencrypted through various flashes by following this routine.
fastboot erase boot
fastboot flash boot boot.img
fastboot erase recovery
fastboot flash recovery twrp.img
[(re)boot into recovery from bootloader]
install SuperSU.zip
The key is never let an unknown status boot.img, where you aren't sure of the encryption status, boot on your phone.
If you always install SuperSU (even if not necessary) after flashing unknown status boot.img, then it will always patch the boot.img to remove forceencrypt and you'll never get re-encrypted.
You could replace any of the steps above with equivalent pre-patched kernels, etc.
sfhub said:
If the kernel you flashed has forceencrypt in the mount tables, it will encrypt upon first boot.
I was able to preserve unencrypted through various flashes by following this routine.
fastboot erase boot
fastboot flash boot boot.img
fastboot erase recovery
fastboot flash recovery twrp.img
[(re)boot into recovery from bootloader]
install SuperSU.zip
The key is never let an unknown status boot.img, where you aren't sure of the encryption status, boot on your phone.
If you always install SuperSU (even if not necessary) after flashing unknown status boot.img, then it will always patch the boot.img to remove forceencrypt and you'll never get re-encrypted.
You could replace any of the steps above with equivalent pre-patched kernels, etc.
Click to expand...
Click to collapse
Thank you! I will consider this next time
2x4 said:
hmm wait, so there's no way to re-encrypt if you've already decrypted and you're using a custom rom?
Click to expand...
Click to collapse
I don't know if it works with custom roms, I can only tell you what I experienced with the setup I described, originally stock MTC19T boot.img that went through systemless root setup via SuperSU and TWRP recovery.
I didn't experiment further to see if the problem was with TWRP recovery or with the systemless root boot.img so I can't tell you which one (or both) was causing the issue.
I imagine if your custom ROM is based on a stock kernel, you could LEAVE the custom rom system image in place, JUST flash stock boot.img and stock recovery.img, let the first boot encryption do its thing, then reflash your custom boot.img and twrp recovery.
That is what I did to get things re-encrypted and it was relatively painless after I figured out what to do.
Even if your custom ROM is not based on stock kernel, the same technique might work, because the encryption is done by the kernel prior to Android booting. Your custom ROM in this case, depending on why it is using a modified kernel, might not boot properly until after you replace the kernel it expects.
So in short, I think you should be able the encrypt, but probably not with Settings->Security
UPDATE:
I was able to get 2 units side-by-side again. This time both of them were encrypted. The difference was one was running the original MDA89E OS and the other was running the latest MTC19V OS.
I just did 1 simple test, I created a 238.5MB zip file of my Titanium backup directory.
On MDA89E (user partition encrypted) it took 6:39
On MTC19V (user partition encrypted) it took 1:01
This result along with the previous results that found virtually no difference between decrypted and encrypted on MHC19Q leads me to the conclusion that decrypting probably did see a performance boost on the original MDA89E software all the way up to probably MMB29V but from MHC19J onwards, up to at least MTC19V, there is virtually no real-world (rather than benchmark) difference between decrypted and encrypted.
I didn't have time to do more detailed testing on this phone as it needed to be returned.
For me, unencrypted is the way to go. I use my phone as my main music player, and audio tends to skip when I'm using my phone while listening to music on an encrypted setup. It's kind of a deal breaker for me tbh.
hmghmg said:
For me, unencrypted is the way to go. I use my phone as my main music player, and audio tends to skip when I'm using my phone while listening to music on an encrypted setup. It's kind of a deal breaker for me tbh.
Click to expand...
Click to collapse
Did you try that only on early OS releases?
I record and playback 1080p video with no skipping. 1080p video is much higher bitrate than audio so it would be surprising if encryption on the latest releases would cause skipping for audio.
sfhub said:
Did you try that only on early OS releases?
I record and playback 1080p video with no skipping. 1080p video is much higher bitrate than audio so it would be surprising if encryption on the latest releases would cause skipping for audio.
Click to expand...
Click to collapse
Yes, I have! I tried it on the latest marshmallow build. (Sorry, I forgot the build number)
If it works for you, I wonder what's wrong with mine...
hmghmg said:
Yes, I have! I tried it on the latest marshmallow build. (Sorry, I forgot the build number)
If it works for you, I wonder what's wrong with mine...
Click to expand...
Click to collapse
1) When you say "using your phone" what else are you doing when it starts skipping?
2) Which music app are you using
I'm pretty sure decryption of an encrypted user partition can easily handle the bit rate needed for audio playback if everything is being done in isolation, so there must be some interaction going on that causes what you are seeing.
Hello together,
I'm using official RR ROM 7.0.2 on my G900F, until recently with latest tuned kernel. I suddenly got some random freezes with reboots without knowing the reason. Then after some crashes it resulted in a bootloop, meaning that the RR bootscreen is loading forever (already tested for hours).
Flashing RR ROM again fixed the issue completely, but when I flash tuned kernel again I immediately end in bootloop. Flashing boot.img of RR ROM once again fixes the problem. Then I tried Intelli-Kernel and it boots, however the first unlock screen is very laggy, system ui takes long time to load after unlock (after that it works normal) and I get here and then sudden reboots. After some crashes/reboots I end up with bootloop with Intelli-Kernel.
Once again: flashing boot.img of RR fixes all the problems.
It's unlikely that the kernels itself are at fault, as they are working for many others and also worked for my device until recently.
So why am I unable to use custom kernels suddenly and how can I fix it?
I'm grateful for any hints you can give to pinpoint the reason. I already asked in the kernel Telegram group but sadly they weren't able to help me.
- I'm clearing dalvik/cache every time,
- tried TWRP repair feature for /data partition
- and as far as I can say I removed all remands of boeffla config app, but even if there are some they should load after system boot so obviously kernel settings aren't applied when I stuck on boot screen.
I don't overclock but for the same reason it shouldn't matter even if I do.
If possible, I would like to avoid a full wipe.
Thanks in advance.
Have you tried backing up your entire phone, wiping and installing RR, letting it boot etc before rebooting to recovery and installing a custom kernel again? If that fails, then either the version of RR you are using is incompatible, or you have some sort of hardware failure somewhere.