Database Users

***WARNING!!! PLEASE READ! ICS Kernels and Recovery

I have realized this post was sorely outdated. I have updated it partially, but more updates are needed.
Reinbeau asked me to summarize the situation with ICS leaks in a way that can be stickied, so here it is:
DO NOT FLASH OR WIPE USING ANY ICS REPACK OR STOCK KERNEL
While stock recovery is safer than CWM recovery, there is still evidence that it is dangerous.. Almost all ICS kernels for the GT-N7000 are affected. Only two are currently known to be safe - see the list below.
These kernels are fundamentally dangerous. They can trigger an underlying defect in the flash chip, and once this defect is triggered, the damage is unrepairable, not even with JTAG. Note that for danger, three things are needed:
1) A defective eMMC chip - Nearly every Note has this
2) A kernel that allows MMC ERASE commands to go through - All Samsung ICS stock kernels and leaks fall into this category
3) A recovery or update-binary within a ZIP that attempts to erase a partition when formatting. Unmodified CWM performs a secure erase, which is the most dangerous. Stock recovery performs a nonsecure erase, which is less dangerous but there is still evidence of danger.
The issue is not limited to just Clockworkmod Recovery - Stock recovery, along with factory resetting a device from Settings, can also be dangerous. When XXLPY first came out, a number of people bricked this way. Stock recovery is less dangerous due to using nonsecure erase rather than secure erase, but it has yet to be proven to be fully safe.
Kernels that have been confirmed affected are:
All ICS leaks for the Samsung Epic 4G Touch (SPH-D710)
All ICS leaks for the Samsung Galaxy Note (GT-N7000)
All ICS official releases for the Samsung Galaxy Note (GT-N7000) as of late May 2012 - This includes XXLPY, ZSLPF, and DXLP9, and future kernels should be assumed affected until further notice.
UCLD3 ICS leak for the AT&T Samsung Galaxy S II (SGH-I777) - Other leaks may also be affected
Kernels built using the most recent SHW-M250S/K/L official source code release as of May 3, 2012 - This includes SiyahKernel 3.1rc6 for GT-I9100 (all other Siyah releases are safe)
Damage is not guaranteed - it may only affect a small percentage of users, but even a 5% chance is far more dangerous than the effectively 0% chance of hardbricking due to kernel bugs in safe kernels.
Not all users hardbrick - some wind up with /system, /data, or another partition becoming unwriteable, which leads to an effectively useless phone even though they are able to flash kernels in Odin.
Kernels that have been confirmed safe:
All known Gingerbread kernels for the Galaxy Note and other affected devices listed above
Kernels built from the GT-I9100 Update4 source code release - this includes XplodWILD's CM9 release and my DAFUQ release, hopefully more kernel choices will become available soon
Kernels with MMC_CAP_ERASE removed from mshci.c should be safe - look for it in the listed features of any kernel based off of N7000 Update3. (N7000 Update3 source code without this change made to render it safe is dangerous.)
If you are running an affected kernel:
STOP USING IT IMMEDIATELY. FLASH A SAFE KERNEL USING ODIN/HEIMDALL.
DO NOT wipe in recovery
DO NOT flash anything else in recovery
In general, DO NOT use recovery at all
Right now, what we know:
Some people can wipe with affected kernels as often as they want without problems. Just because you didn't brick, DO NOT advise other users that they will be OK.
Based on reports from the Epic 4G Touch community, some people can wipe/flash 20-30 times before hardbricking - Just because you didn't brick once, DO NOT continue flashing with an affected kernel
What we don't know:
*this needs to be completely updated*
More info:
http://forum.xda-developers.com/showthread.php?t=1607112 - Hardbricks on I777 UCLD3
http://forum.xda-developers.com/showthread.php?t=1615058 - Issues with SHW-M250L Update4
http://forum.xda-developers.com/showpost.php?p=26255080&postcount=159 - Information indicating that our eMMC chip has a serious firmware bug. All of the issues with fwrev 0x19 match our symptoms PERFECTLY. It explains partially why I9100 update4 is safe - MMC_CAP_ERASE is not enabled in the I9100 update4 MMC driver.

Additional information
From this post
Elle233 said:
I know this tread is not about bricks, but your warning must have saved lots of souls from bricks and sorrow. Just wanting to ask, for those currently running ROMs with affected kernels, though, ROMs could be working, could any undetected/unobservable damage possible without one's knowing?
Click to expand...
Click to collapse
Entropy replies: Possible - With the Siyah 3.1rc6 fiasco, some people had situations where just one or two partitions became hosed up (usually /data)
It could be possible that some devices might only have a few damaged sectors in the eMMC - but I haven't seen confirmed reports of this yet. It has always been my suspicion that deleting large files on affected kernels could be dangerous - but I'm not sure about this.

Mod note: I copied this post here from its original thread as it contains pertinent information.
Chainfire said:
Ok so it still isn't really clear if the problem is still present in LPY, or if the issue is "left-over" due to previous ROMs.
It's all possible. Either way, what I wan't to make absolutely clear again:
If the problem is present in CF-Root LPY (and it's not a "leftover" problem from previous ROM - this is possibly the case), then it's also present in stock LPY. This means you *can* randomly brick your phone even if fully booted into Android, under heavy I/O load.
(on the Note there normal and recovery kernels are the same, and CWM is just a userspace program, nothing special(!) - so if the problem can happen in CWM, it can happen in Android)
Click to expand...
Click to collapse
Additional information: I've seen at least one report of someone's device dying after a wipe in stock recovery, and one report of someone's device dying by doing a factory reset in Settings.
Which confirms everything you just said.

Latest from Android Team
Well, it's been some time but thankfully Mr. Sumrall from Android did get back to us on our questions. I think the community will find that this was worth the wait.
Issue: fwrev not set properly.
As we suspected the bugfix is not in our build. (The patch applies this unconditionally.)
Ken Sumrall said:
The patch includes a line in mmc.c setting fwrev to the rights bits from the cid register. Before this patch, the file /sys/class/block/mmcblk0/device/fwrev was not initialized from the CID for emmc devices rev 4 and greater, and thus showed zero.
(On second inquiry)
fwrev is zero until the patch is applied.
Click to expand...
Click to collapse
Question: Revision didn't match the fix
(Emphasis mine in red as it discusses the superbrick issue.)
Ken Sumrall said:
You probably have the bug, but rev 0x19 was a previous version of the firmware we had in our prototype devices, but we found it had another bug that if you issued an mmc erase command, it could screw up the data structures in the chip and lead to the device locking up until it was powered cycled. We discovered this when many of our developers were doing a fastboot erase userdata while we were developing ICS. So Samsung fixed the problem and moved to firmware revision 0x25. Yes, it is very annoying that 0x19 is decimal 25, and that led to lots of confusion when trying to diagnose emmc firmware issues. I finally learned to _ALWAYS_ refer to emmc version in hexadecimal, and precede the number with 0x just to be unambiguous.
However, even though 0x19 probably has the bug that can insert 32 Kbytes of zeros into the flash, you can't use this patch on devices with firmware revision 0x19. This patch does a very specific hack to two bytes of code in the revision 0x25 firmware, and the patch most likely will not work on 0x19, and will probably cause the chip to malfunction at best, and lose data at worst. There is a reason the selection criteria are so strict for applying this patch to the emmc firmware.
I passed on our results a few days later mentioning that the file system didn't corrupt until the wipe. This is a response to that follow-up.
As I mentioned in the previous post, firmware rev 0x19 has a bug where the emmc chip can lockup after an erase command is given. Not every time, but often enough. Usually, the device can reboot after this, but then lockup during the boot process. Very rarely, it can lockup even before fastboot is loaded. Your tester was unlucky. Since you can't even start fastboot, the device is probably bricked. :-( If he could run fastboot, then the device could probably be recovered with the firmware update code I have, assuming I can share it. I'll ask.
Click to expand...
Click to collapse
Question: Why the /data partition?
Ken Sumrall (Android SE) said:
Because /data is the place the chip that experiences the most write activity. /system is never written to (except during an system update) and /cache is rarely used (mostly to receiving OTAs).
Click to expand...
Click to collapse
Question: Why JTAG won't work?
Ken Sumrall said:
As I mention above, the revision 0x19 firmware had a bug that after an emmc erase command, it could leave the internal data structures of the emmc chip in a bad state that cause the chip to lock up when a particular sector was accessed. The only fix was to wipe the chip, and update the firmware. I have code to do that, but I don't know if I can share it. I'll ask.
Click to expand...
Click to collapse
Question: Can a corrupted file system be repaired (on the eMMC)?
Ken Sumrall said:
e2fsck can repair the filesystem, but often the 32 Kbytes were inserted at the start of a block group, which erased many inodes, and thus running e2fsck would often result in many files getting lost.
Click to expand...
Click to collapse
So, while the fix doesn't apply to us at the moment, we've been given a great insight into the superbrick issue as well as information that a fix is already developed (hopefully we'll see it released!). The bug likely applies to us and assuming the fix for the 0x19 firmware is given then it would apply to our devices.
On a lighter note, I wanted to include his close:
Ken Sumrall said:
You are getting a glimpse into the exciting life of an Android kernel developer. Turns out the job is mostly fighting with buggy hardware. At least, it seems that way sometimes.
Click to expand...
Click to collapse

garwynn said:
Well, it's been some time but thankfully Mr. Sumrall from Android did get back to us on our questions. I think the community will find that this was worth the wait.
Issue: fwrev not set properly.
As we suspected the bugfix is not in our build. (The patch applies this unconditionally.)
Question: Revision didn't match the fix
(Emphasis mine in red as it discusses the superbrick issue.)
Question: Why the /data partition?
Question: Why JTAG won't work?
Question: Can a corrupted file system be repaired (on the eMMC)?
So, while the fix doesn't apply to us at the moment, we've been given a great insight into the superbrick issue as well as information that a fix is already developed (hopefully we'll see it released!). The bug likely applies to us and assuming the fix for the 0x19 firmware is given then it would apply to our devices.
On a lighter note, I wanted to include his close:
Click to expand...
Click to collapse
BOOYA! (unfortunately, my quote of your post likely doesn't include Mr. Sumrall's comments)
So, in short - the AOSP patch in 4.0.4 is not relevant to our devices, HOWEVER:
There is a known issue that does affect our devices.
A bug with the ERASE command is EXACTLY what one would expect to cause this kind of behavior.
The remaining question is:
Gingerbread kernels have MMC_CAP_ERASE enabled for the MMC driver- why don't they cause problems, unless there's something somewhere else that prevents the ERASE function from being used even though the controller supports it?
This also explains why I9100 update4 is safe - one of the major differences between I9100 update4 and SHW-M250* sources is that MMC_CAP_ERASE is enabled in the SHW-M250* sources and not in I9100 update4.

This post on the portal is a very informative read. The take away quote for me:
Originally Posted by Ken Sumrall
You are getting a glimpse into the exciting life of an Android kernel developer. Turns out the job is mostly fighting with buggy hardware. At least, it seems that way sometimes.
Please stay clear from flashing anything ICS onto your devices until this has been solved.
Click to expand...
Click to collapse

Stock ROMs Factory v6.1 , v8.3 , v8.4 , v8.5 , v8.7, V9.0, V9.2-patch : v21

CAUTION TO NOT LOOSE TWRP
I read two posts that say v21, now again on V8.5, put the stock recovery back instead of twrp. This is probably a side effect of a fresh stock /system and wipe of /data.
As a preventive step, when done flashing and wiping reboot to recovery FIRST, before booting the system It will allow recovery to handle removing the recovery-from-boot.p that flashes stock recovery.
I just patched the modified V7.4.2 up to the newly released 8.3 now 8.4. 8.5, 8.7,9.0 -V9.2 Patch
New update has been made from V17 to V21 of the non prime version of R1-HD, Non prime is behind on security patch (2017-05-05)
Copied ROM from phone and made twrp install ROM from it.
* No preloader change (official updates change the preloader to block your ability to use sp flash tools for rom flashing)
* No lk.bin change __ this part is what allows you to choose boot options(boot menu when power and volume pressed together)
* No "FOTA" app Fota has now been left in to make it easier to get next update, if that ever happens.
* No opera browser
* No adds (removed in the modified 7.4.2)
* Custom boot logo (only done on v8.3, there was no interest in this so abandoned)
--Newer versions of rom left stock, Leaving mods up to user.
** while it is not necessary to do a wipe with this ROM, I still recommend it.
**Thanks:
** @vampirefo needed his patched v7.4.2 in order to apply this new 8.3 patch and again for 8.4
** @ColtonDRG OR @jasonmerc I do not remember which one made it: For the image used in the custom logo
and the modified zip is here .
Roms are rootable with SuperSU, flashed in twrp after install. Must be done in systemless mode. In order to patch system veridy in boot.img
Logo update did not work on original rom changing link to updated version
BLU rolled v8.3 back to v7.4.2 because of app compatability issues. V8.4 is there fixed release. Both 8.3 and 8.4 are modified prime roms with ads stripped
V21 is the non prime update.
Unmodified V6.1
==>NON-ROOTED-logo-not-replaced-modified-V8.3
==>Fixed Logo modified NON_ROOTED V8.3
==>>modified V8.4
==>>modified V8.5
==>>Full with Ads V8.7
==>>Full with Ads V9.0
==>>Patch For V9.2 must be flashed on top of fresh V9.0
****Run debloat ==>script to remove ads if you need/ want to, or remove from zip before flashing ****
alt. manual example: before reboot, while still in twrp. Select mount and put checkmark next to system. Then run these two commands in adb terminal
Code:
adb shell rm /system/priv-app/com.amazon.*/com.amazon.*.apk
adb shell rm /system/app/Adups*/*.apk
==>>Modified V21
** stand alone logo installs

I flashed this but I didn't get the custom boot logo.

mendelgordon said:
I flashed this but I didn't get the custom boot logo.
Click to expand...
Click to collapse
I had that happen to my second phone too.
I don't have an explanation yet.
I even made a separate update.zip , that one didn't make the logo change either. I did eventually change it with sp flash tool.
I tried with both recoveries.
and multiple /dev location formats. and for whatever reason my one phone did not accept the logo change from recovery.
And the other test phone it worked.

mendelgordon said:
I flashed this but I didn't get the custom boot logo.
Click to expand...
Click to collapse
Neither did I but it all seems to be working fine

Been using this for about a day now, likewise no custom boot logo, but that's fine. Otherwise, it's been running super well. A lot better than the previous mostly stock version did for me with the bloatware APKs removed after the install. A lot of the general idiosyncrasies of the previous version of the stock rom seem to have gone away for me. It seemed to have weird storage management issues, errors moving to SD, broken symlinks that prevent apps from moving or being reinstalled, and a lot of other little non-storage issues, but so far, none off that here.
Long story short, good work! I hope we eventually see proper 7.x roms through some of the efforts going on, but in the meanwhile, your work here has made life a little bit better on 6.

It seems that I was able to get the logo.bin to update when I applied the original update patch, but not when I used the same line in the rom install.
It is no big deal that it did not work, I was just trying to make it look different at boot time.
edit:
I think i found the problem with the logo not updating.
i used the update-binary from the official patch update. (the one that allowed the logo to change the first time)
and it changes . so since the ROM seems to install the way it is , only the logo didn't flash I put it in a separate update.zip if anyone is interested in it.
EDIT 2:
clarification.
It was not so much the binary allowing the logo to change but the format of the partition location I had been using that needed that binary.
Further test had shown me that I could have used the binary I was using but just change the partition naming line
Code:
package_extract_file("logo.bin", "/dev/block/mmcblk0p9")
the above code works with the same update-binary as rom install
But I was using
Code:
package_extract_file("logo.bin", "/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/logo")
Taken straight from the official patch, and thats why it needed the update-binary also.
I dont know what is different in the binary other than , major size difference.
The powered by me logo was just a test file to see changes in the logo.
**logo-update is same as composite but with alt updater-binary
**composite-logo screenshot is in op
**stock logo will return to original BLU logo

mrmazak said:
It seems that I was able to get the logo.bin to update when I applied the original update patch, but not when I used the same line in the rom install.
It is no big deal that it did not work, I was just trying to make it look different at boot time.
edit:
I think i found the problem with the logo not updating.
i used the update-binary from the official patch update. (the one that allowed the logo to change the first time)
and it changes . so since the ROM seems to install the way it is , only the logo didn't flash I put it in a separate update.zip if anyone is interested in it.
EDIT 2:
clarification.
It was not so much the binary allowing the logo to change but the format of the partition location I had been using that needed that binary.
Further test had shown me that I could have used the binary I was using but just change the partition naming line
Code:
package_extract_file("logo.bin", "/dev/block/mmcblk0p9")
the above code works with the same update-binary as rom install
But I was using
Code:
package_extract_file("logo.bin", "/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/logo")
Taken straight from the official patch, and thats why it needed the update-binary also.
I dont know what is different in the binary other than , major size difference.
The powered by me logo was just a test file to see changes in the logo.
Click to expand...
Click to collapse
Hahaha the scribbled "ME" is hilarious. Your work is awesome, I don't think anyone using this rom will have an issue with the boot image but thanks for being so helpful and explaining.
P. S. Do you have any plans with the Nougat update?

Serenitybs said:
Hahaha the scribbled "ME" is hilarious. Your work is awesome, I don't think anyone using this rom will have an issue with the boot image but thanks for being so helpful and explaining.
P. S. Do you have any plans with the Nougat update?
Click to expand...
Click to collapse
Nougat is going to take a full build from scratch. We don't have 100% identical hardware with any other nougat device to my knowledge. We might have the same MTK chipset, but there are several other differences. All we really need is an official device overlay and the vendor files released by BLU themselves. We can then apply those to the latest Lineage or AOSP (I prefer AOSP myself) and build. Then the only problem we'll run into is anything that has changed in 7.x that isn't compatible with our kernel we use in 6.0. It'd be a slight chance our current kernel would work without some patches on 7.x We can't even get our official sources for anything else, so I'm almost certain we'll not find any patches to for the kernel to work properly with Nougat, at least not from BLU or any similar devices. None The less Nougat has been well thought of, and we have been trying to debug issues with a broken Port. But a broken port from a different device is just that - Broken. We need a team of knowledgeable devs to build Nougat + Kernel from scratch and then we'll have it working. I can't do it alone with the old computer I have, the R1HD would be long forgot of by the time I got Android Compiled haha.
Mr. Mazak I flashed your rom it went smooth, I was hoping the newest update was for 6.0.1. But I didn't lose any functionality, hopefully on my Cricket Service this update has patched some things to the radio device that will retain connection more steadily. I experienced a lot of coming and going with the 7.4.2 rom. None The Less you did a good job with this update Mr. My suggestion is find the same MTK chipset with a fully working 7.x rom and just port the /System but keep all our libs and inits from this release just for a test starter. And don't replace the camera app thats in AOSP 7.x. )

linuxsociety said:
Nougat is going to take a full build from scratch. We don't have 100% identical hardware with any other nougat device to my knowledge. We might have the same MTK chipset, but there are several other differences. All we really need is an official device overlay and the vendor files released by BLU themselves. We can then apply those to the latest Lineage or AOSP (I prefer AOSP myself) and build. Then the only problem we'll run into is anything that has changed in 7.x that isn't compatible with our kernel we use in 6.0. It'd be a slight chance our current kernel would work without some patches on 7.x We can't even get our official sources for anything else, so I'm almost certain we'll not find any patches to for the kernel to work properly with Nougat, at least not from BLU or any similar devices. None The less Nougat has been well thought of, and we have been trying to debug issues with a broken Port. But a broken port from a different device is just that - Broken. We need a team of knowledgeable devs to build Nougat + Kernel from scratch and then we'll have it working. I can't do it alone with the old computer I have, the R1HD would be long forgot of by the time I got Android Compiled haha.
Mr. Mazak I flashed your rom it went smooth, I was hoping the newest update was for 6.0.1. But I didn't lose any functionality, hopefully on my Cricket Service this update has patched some things to the radio device that will retain connection more steadily. I experienced a lot of coming and going with the 7.4.2 rom. None The Less you did a good job with this update Mr. My suggestion is find the same MTK chipset with a fully working 7.x rom and just port the /System but keep all our libs and inits from this release just for a test starter. And don't replace the camera app thats in AOSP 7.x. )
Click to expand...
Click to collapse
Somebody already tried this out

linuxsociety said:
Nougat is going to take a full build from scratch. We don't have 100% identical hardware with any other nougat device to my knowledge. We might have the same MTK chipset, but there are several other differences. All we really need is an official device overlay and the vendor files released by BLU themselves. We can then apply those to the latest Lineage or AOSP (I prefer AOSP myself) and build. Then the only problem we'll run into is anything that has changed in 7.x that isn't compatible with our kernel we use in 6.0. It'd be a slight chance our current kernel would work without some patches on 7.x We can't even get our official sources for anything else, so I'm almost certain we'll not find any patches to for the kernel to work properly with Nougat, at least not from BLU or any similar devices. None The less Nougat has been well thought of, and we have been trying to debug issues with a broken Port. But a broken port from a different device is just that - Broken. We need a team of knowledgeable devs to build Nougat + Kernel from scratch and then we'll have it working. I can't do it alone with the old computer I have, the R1HD would be long forgot of by the time I got Android Compiled haha.
Mr. Mazak I flashed your rom it went smooth, I was hoping the newest update was for 6.0.1. But I didn't lose any functionality, hopefully on my Cricket Service this update has patched some things to the radio device that will retain connection more steadily. I experienced a lot of coming and going with the 7.4.2 rom. None The Less you did a good job with this update Mr. My suggestion is find the same MTK chipset with a fully working 7.x rom and just port the /System but keep all our libs and inits from this release just for a test starter. And don't replace the camera app thats in AOSP 7.x. )
Click to expand...
Click to collapse
It was just wishful thinking. I have no idea how all of this is done. All I know is @mrmazak has helped me to fall in love with my phone again with this V8.3. The 7.4.2 did seem a bit buggy for my phone but this update works beautifully and I didn't even root it. If this remains true I will be happy with this phone for awhile even on 6.0

Really confused right now.
I was browsing through the settings menus. And found in the Settings-security- menu a toggle labeled "quick boot" ( not to be confused with "fastboot") . I enabled it then rebooted to see if it booted quicker. Didn't seem to make much if any difference. So I went back to turn it back off. And it wasn't there. I checked in my other phone , it wasn't there on that one either.
Did any body see this menu item, and if so where is is it?
Edit 1:
Few more power off , power on cycles to compare times. With other phone and defiantly seems to have turned on some faster boot option.
This phone goes from off to on in 5-6 seconds other phone takes about 20.
Edit 2:
OK , I panicked for a minute.
Couldn't find the setting and thought that it was another way to block sp flash tool by preventing you from ever being fully powered off.
But the setting was in accessibility not security.

Mrmazak, first of all, thanks for the ROM, installed it yesterday. But I have a problem with SELinuxModeChanger app. First, I'm getting a security warning when installing it, then - when running it. And another message, with this app running - "can't obtain root", although SuperSU shows its status with green #, like every other app it gives root privileges to. On my other Prime phone, running 6.1 out of the box stock ROM, FM radio works just fine with SELinuxModeChanger app behaving flawlessly (no security warnings whatsoever). Any ideas?

detroitredwings said:
Mrmazak, first of all, thanks for the ROM, installed it yesterday. But I have a problem with SELinuxModeChanger app. First, I'm getting a security warning when installing it, then - when running it. And another message, with this app running - "can't obtain root", although SuperSU shows its status with green #, like every other app it gives root privileges to. On my other Prime phone, running 6.1 out of the box stock ROM, FM radio works just fine with SELinuxModeChanger app behaving flawlessly (no security warnings whatsoever). Any ideas?
Click to expand...
Click to collapse
The mode changer app is technically a security issue. I did have that warning a few times when using mode changer app from the XDA thread of the developer, then when I used the app downloaded from f-droid it worked with systemless root and didn't give the security warning.

The app downloaded from f-droid worked for me as well, many thanks!

Big thanks for getting this out, updated from previous debloated, rooted version to this modified 8.3 stock rom, rooted with SU v2.79 SR3, all is good - only App that won't show up nor install, even tried the ones off APK Mirror site - is my Dunkin Donuts App, LOL. Play Store now said it's not compatible and the APK started to install then failed - any ideas or suggestions on what to do ??
Otherwise, it's all good - I will survive without DD App, just run that from another device when I need my caffeine fix.

Letitride said:
Big thanks for getting this out, updated from previous debloated, rooted version to this modified 8.3 stock rom, rooted with SU v2.79 SR3, all is good - only App that won't show up nor install, even tried the ones off APK Mirror site - is my Dunkin Donuts App, LOL. Play Store now said it's not compatible and the APK started to install then failed - any ideas or suggestions on what to do ??
Otherwise, it's all good - I will survive without DD App, just run that from another device when I need my caffeine fix.
Click to expand...
Click to collapse
I also had an app that previously work, say is not compatible now.
Maybe has to do with apps that have links to pay accounts. And that has something to do with trustzone. (Tee1 & tee2)
Those sections I left out of the update. I will add it back in and test. Update when I do. It is also possible this problem is why Blu rolled back there update.
**EDIT**
well that didn't go well at all.
I flashed the new trustzone.bin files from the official update. Now phone no longer turns on and no longer connects to flash tool
**EDIT 2**
After much persistence and many failed attempts to get phone recognized in pc again. Finnaly got to a point that phone was cycling between "preloader" driver and "usb serial device", and with careful timing was able to start sp flash tool at just right time and the flashing back to original trustzone files seems to have recovered phone.
for the record i am not sure what steps made it work. But I was shifting back and forth between leaving phone sit on charge, then on charge with rubber band wrapped around power button, then not plugged in , and not plugged in with rubber band on power button.

Okay... persistence is key in customization, i guess! I am getting somewhere here!
mrmazak said:
The first link is needed to get phone unlocked so you can install twrp.
Click to expand...
Click to collapse
Finally got thru the steps in order (1-2-3-4) then Step (5) and sub-step 1. I can also boot to TWRP.
Now this brings me to this thread, 8.3 Stock ROM. The thread assumes one knows how to install it and I suspect this could be as easy as uploading it to a folder in the phone then booting to TWRP and INSTALLING the ZIP file? Could someone clarify the steps to install this 8.3 ROM?
Thanks!

OldSkewler said:
Okay... persistence is key in customization, i guess! I am getting somewhere here!
Finally got thru the steps in order (1-2-3-4) then Step (5) and sub-step 1. I can also boot to TWRP.
Now this brings me to this thread, 8.3 Stock ROM. The thread assumes one knows how to install it and I suspect this could be as easy as uploading it to a folder in the phone then booting to TWRP and INSTALLING the ZIP file? Could someone clarify the steps to install this 8.3 ROM?
Thanks!
Click to expand...
Click to collapse
Yes. You are correct
Either put the zip file on external sd card , put card into phone boot into recovery mode and install , or put file directly onto phone .
Many ways to do that.
Easiest is to copy to phone while phone is connected to PC.
Cam also download file from internet with your phone.
Bottom line is get zip file to the phone boot to recovery and install

Anyone else having wifi issues after upgrading? While watching videos it seems the internet cuts out. The phone says it's still connected but I have to turn wifi off and back on for anything to work. Could be my router also but it didn't seem to be doing this until I installed 8.3

mrmazak said:
Yes. You are correct
Either put the zip file on external sd card , put card into phone boot into recovery mode and install , or put file directly onto phone .
Easiest is to copy to phone while phone is connected to PC.
Bottom line is get zip file to the phone boot to recovery and install
Click to expand...
Click to collapse
Right on man! I am officially running 8.3 ROM with April 5th 2017 Security Patch Level! Geez.. it was not easy but I got this working!
MrMazak, I followed all your instructions on both links, so could you tell me what exactly I have on my phone? Is it rooted? Bootloader Unlocked? The phone seems to be working fine but I don't know what level of access I have. Honestly I don't even know exactly what the differences between all these terms are.
Also, do I have or not SU? One of the steps under the .bat I believe install it. How do I access it?
Thanks again!
---------- Post added at 10:19 PM ---------- Previous post was at 10:18 PM ----------
Weasel0 said:
Anyone else having wifi issues after upgrading? While watching videos it seems the internet cuts out. The phone says it's still connected but I have to turn wifi off and back on for anything to work. Could be my router also but it didn't seem to be doing this until I installed 8.3
Click to expand...
Click to collapse
My install is pretty fresh, couple of hours, but as far as I can tell all is working fine with Wifi, As a matter of fact this is a new device only connected with Wifi and no SIM Card.... internet works fine.

Nexus 5X bootloop of death fix (BLOD) | 7/30 Huge performance update!

Read First: This method is relatively drastic, and will hurt device performance some. You should only use this as a last resort, if the more basic methods of fixing a soft brick didn't work (e.g, factory reset, flash stock firmware, etc.)​
*Update 7/30: On my 6P, I found that the original kernel with this mod was using pretty much 1.5 cores, instead of all 4. People with the 5X were also reporting this, so I modified the images to utilize all 4 cores better. It helps performance a lot (able to beat stock 6P in some Antutu marks now, and play intensive games), try it out if you haven't yet!
*Petition:
I made a petition for Google to officially release and sign modified boot.imgs, so that people with locked bootloaders can fix their devices too. Check it out here. (I apologize for dumbing it down so much, I wanted to make sure everyone could understand it)
*Changelog:
8/26 - EX kernel for Android O uploaded.
8/22 - Android O working, boot.img and source uploaded.
8/08, 2nd Change - Added boot.img for 48C firmware (August security patch).
8/08 - Updated EX kernel to version 4.1.2. This updated zip adds the CPU utilization patch to the init.elemntalx.rc, instead of removing the old init.angler.rc and copying the new init over. That should mean more compatibility with Roms/kernels that modify the init.angler.rc. I also modified the camera-daemon to use cpus 0-3 instead of 0-2, so hopefully this should make the a camera bit faster too.
8/07 - Added boot.img for 1 core, just to see if it would work for devices that didn't work with the 4 core image.
7/30, 2nd Change - Added universal EX zip, this zip should modify your kernel to use only 4 cores, and it should modify it to utilize all 4 cores. You can flash this over most ROMs and it should work. Also added a donation url, and this changelog.
7/30 - Updated this fix to greatly improve performance. Before this fix, the device was only using 1 core for foreground tasks, now it will use all 4 cores. Also revamped OP, and added Marshmallow images.
7/23- Created this fix, stock boot.img, twrp, and EX kernel added.
*What this fix does, and how to apply it:
The problem:
The problem with most of the devices in a BLOD, is that a hardware failure related to the BIG cluster has occurred. This fix remedies the problem by disabling the BIG cores. Unfortunately, this does mean that you will take a performance hit. However, I am continually working on ways to improve the device's performance.
The update: If anyone remembers device performance with the first fix, it was hurt a lot, however, after finding out that the device was only using 1 core for all foreground tasks, I modified the ramdisk to utilize all 4 cores more effectively, and it helps a lot.
Requirements: For this fix to work, you need:
A brain
A computer
A bootlooping 5X with an unlocked bootloader/OEM unlocking enabled
The modified files of your choice.
Fastboot on your computer (preferably installed system wide). If you do not know what this is, or do not have it, look at this post. Answer yes to all of the prompts to install it.
How to apply the fix:
Boot your phone into bootloader (hold power and volume down).
Connect your phone to the computer.
Go to the folder where you have the modified files, then hold shift and right click in a blank space, click on "open command prompt here" in the menu that pops up.
In the command prompt: type "fastboot flash boot [name of the file here]" and then press enter. If you're flashing TWRP, replace boot with recovery. (Linux users, make sure you're running as root)
Edit: with the new universal EX zip, you don't have to flash the modified boot.img now, you can just flash TWRP, and then flash the EX zip, and everything should work.
Boot up your phone, and hopefully it should work!
*If your phone is bootloader locked/OEM locked:
You can try to get your phone to boot long enough to enable OEM unlocking. Some users have reported success by freezing their phone for a bit, then booting it. Others have let their battery drain all the way, and then tried to boot their phone, but the most successful method seems to be heating up your phone (a lot).
If you do attempt any of these methods, make sure you have time and patience, as it will take a long time.
To enable OEM unlocking and unlock bootloader:
Go to settings.
Go to developer options, if you do not see that, go to "about phone", scroll to build number, and then tap it 7 times. You should now see developer options in settings.
Once you're in developer options, click on "OEM unlocking" and accept the prompt.
Now reboot your phone to bootloader, connect your phone to the computer, and type "fastboot flashing unlock" Your bootloader should now be unlocked.
*Downloads:
Boot.img from Android O DP6: Download | Mirror. This Image is the from the first official release of Android O, and is modified to use 4 cores. As a bonus, it also disables forced encryption. Thank you to @xls654 for figuring out how to get Android O to work.
Boot.img from stock 48C, 7.1.2 firmware (August security patch): Download | Mirror. This Image is modified to use only 4 cores, and is modified to utilize the 4 cores more effectively. I have had multiple people on the 6p say that first boot takes a while after flashing this, so just wait about 20 minutes before you declare something is wrong with it.
Boot.img from stock 47Z, 7.1.2 firmware: Download | Mirror. This Image is modified to use only 4 cores, and is modified to utilize the 4 cores more effectively. I have had multiple people on the 6p say that first boot takes a while after flashing this, so just wait about 20 minutes before you declare something is wrong with it.
TWRP version 3.1.1: Download | Mirror. This TWRP image is modified to use only 4 cores.
EX kernel version 5.03, for Android O: Download | Mirror. EX kernel for Android Oreo, modified to use 4 cores. You must flash it over the 4 core boot.img for it to work.
EX kernel version 4.12, universal zip: Download | Mirror. This zip is modified to use only 4 cores, and it will also apply the speed fix. Flash this in TWRP. I highly recommend you flash this, as it improves device performance notably, and disables forced encryption. This kernel should work with almost any other ROM, and it applies the core utilization mod from the first image, thanks to AnyKernel.
Boot.img modified to use only 1 Core. Some people were reporting that the 4 core images weren't working for them, someone suggested that I make a 1 core version to see if that helps at all. Here it is: Download | Mirror
For Marshmallow:
Boot.img from the latest 6.0.1 20K firmware: Download | Mirror. This boot.img is modified to use only 4 cores, and is modified to utilize those 4 cores more effectively. Untested as of now.
Ex kernel version 1.2.0 for Marshmallow: Download | Mirror. This is the latest EX kernel for marshmallow, it will keep the core utilization mod from the above image, and should work on almost any other ROM, thanks to any kernel. Untested as of now.
*Source Code:
Source for 4 core Android O DP6: Source.
*Tested custom ROMS/kernels
you should be able to use almost any ROM with a stock based kernel, just flash the EX zip over it.
If you have a custom ROM/kernel that worked for you, let me know and I'll put it up here.
*To improve performance slightly:
Flash a custom kernel. I will upload more kernels as people request more, so stay tuned.
Flash a custom ROM. Once again, I will upload more as people request more, so stay tuned.
Overclock the little cores. It can slightly help offset the lost performance, on my 6P, I have mine overclocked to 1632MHz, and it works perfectly for me. Edit: I actually recommend not overclocking. Many people have reported their Little cores failing, so I would go for longevity on this device, and keep it at stock clocks, or even underclock it. The speed difference you get from overclocking is negligible anyways.
Disable animations in developer options. Seriously, as soon as I found out about this tweak, I've used it on ever single device I've owned, it helps a ton.
*Credits:
@rchtk, His post here gave me the idea for how to modify the images.
@flar2, He built the Elemental X kernel for this device, I merely made a small modification to his kernel to use 4 cores. In no way am I trying to steal and/or discredit his work.
The TWRP development team, they built the TWRP recovery for this device, I merely made a small modification to their recovery to use 4 cores. In no way am I trying to steal and/or discredit their work.
@xls654, He found out how to get Android O working with 4 cores.
*FAQs:
What's the password for TWRP/Why is TWRP asking for a password? - In android 7.0, Google added forced encryption to the data partition. To get around this, click cancel when TWRP asks you for a password, and then factory reset the device. Then you can flash EX kernel/Magisk to disable forced encryption.
Why am I getting an error when I try to flash the images? - Your bootloader is probably not unlocked, try running the command "fastboot flashing unlock", If you get an error there too, then you will have to enable OEM unlocking before you can continue.
It's not working for me, how do I fix it? - My only advice for that is: "Flash the stock firmware for whatever version image you're trying to flash, then reflash the images again" If you're stuck on the boot animation, wait at least 20 minutes before you declare it's not working. If none of that works, chances are you have a different problem.
Does EX kernel have the new speed fix? - Yep, the EX kernel zip should apply the 4 core fix, and the speed fix. It should also work with almost any ROM, including stock.
I would like to help as many people as I can, however, I am much more likely to be able to easily help you/reply to your post if you clearly state your problem and the steps you attempted to fix it. I will be much less likely to reply to posts such as "omggg i flashed the image and my phone won't boot helppp" Please read through post first, I did not spend time typing up this OP for no one to read it. If I can see that you read through the OP and have attempted all the steps, then I will be much more willing to help you.
I set up donations on my profile, for those of you who want to donate. I have spent countless hours modifying, flashing, testing, and helping, don't get me wrong, I love doing this and helping y'all out, but donations really keep me motivated to keep going, and donations also will help me fund new equipment and devices that will help further my android development. Every single donation is appreciated Donate to me here!
If this guide helped you, please click thanks, it means a lot to me

Didn't work
I flashed the image and the bootloop is still there, thanks for the effort though. Anything else you'll need for the 5X to continue your research ?

Acelogic_ said:
I flashed the image and the bootloop is still there, thanks for the effort though. Anything else you'll need for the 5X to continue your research ?
Click to expand...
Click to collapse
dang :/ If you can get into twrp, pulling the "console-ramoops" would be helpful, but I don't think you can boot to twrp.

this actually fixes my phone, i do the same with elementalx kernel i disable the big cores as soon as my phone boots up so this img is really handy

TheIronLefty said:
this actually fixes my phone, i do the same with elementalx kernel i disable the big cores as soon as my phone boots up so this img is really handy
Click to expand...
Click to collapse
Awesome! Glad to hear it.

XCnathan32 said:
dang :/ If you can get into twrp, pulling the "console-ramoops" would be helpful, but I don't think you can boot to twrp.
Click to expand...
Click to collapse
Yeah Twrp is not working.

So I just flashed this over the May 2017 build and my phone boots and is working just fine, albeit a bit slowly.
I'll update to the latest build and reflash but for now you can say it works as intended. Thanks for the effort

Gonna try this
Sent from my EVA-L09 using Tapatalk

It's worked for me. Phone is slower, and taking picture with hdr+ is okey but processing is very slow. I turned off animation, is there anything else I can change so phone can perform faster ?

Any idea how long this should take? I managed to get into my 5x and enable debug mode / OEM unlocking
I ran the fastboot flash boot N2G47Z_4Cores.img command and its been stuck for about 5 minutes

This works, thanks. First time I've been able to boot my 5X in months.

Acelogic_ said:
I flashed the image and the bootloop is still there, thanks for the effort though. Anything else you'll need for the 5X to continue your research ?
Click to expand...
Click to collapse
I uploaded a custom TWRP image and EX kernel zip. Try flashing the modified TWRP, and then flashing the modified EX kernel, and see if that works.

after trying again I was able to get it to write successfully however the nexus 5x is still bootlooping, this is an original hardware revision nexus 5x if that helps

ragdoll96 said:
So I just flashed this over the May 2017 build and my phone boots and is working just fine, albeit a bit slowly.
I'll update to the latest build and reflash but for now you can say it works as intended. Thanks for the effort
Click to expand...
Click to collapse
X-calibar said:
It's worked for me. Phone is slower, and taking picture with hdr+ is okey but processing is very slow. I turned off animation, is there anything else I can change so phone can perform faster ?
Click to expand...
Click to collapse
I updated the OP with a modified EX kernel, and some tweaks to make your device faster, check it out to see if it helps your device.
stipo42 said:
Any idea how long this should take? I managed to get into my 5x and enable debug mode / OEM unlocking
I ran the fastboot flash boot N2G47Z_4Cores.img command and its been stuck for about 5 minutes
Click to expand...
Click to collapse
My first time took around 10 minutes to boot I think, if it takes over 20 minutes, reboot your device and reflash, and if that fails, update your firmware to the latest version.

stipo42 said:
after trying again I was able to get it to write successfully however the nexus 5x is still bootlooping, this is an original hardware revision nexus 5x if that helps
Click to expand...
Click to collapse
Are you upgrading from stock firmware or a custom rom? This boot.img is for the latest 7.1.2 build. Unless you have files that you can't afford to delete, I would recommend reflashing your stock firmware with the latest version.

flar2 said:
This works, thanks. First time I've been able to boot my 5X in months.
Click to expand...
Click to collapse
Awesome! I just want to say how much I love your kernel, it makes this fix much more viable.

update: I was able to install twrp and boot into that, but its asking for a password.... @XCnathan32 is there a specific password you set or should "default_password" work?

stipo42 said:
update: I was able to install twrp and boot into that, but its asking for a password.... @XCnathan32 is there a specific password you set or should "default_password" work?
Click to expand...
Click to collapse
default_password didn't work for me, I just clicked cancel when it asked for the encryption, and then I factory reset the device through TWRP. If you have important files you can't delete, you can try just flashing EX Kernel, as I don't think EX needs to access the /data partition.

Update 2 : Seems I was able to just cancel out of the password prompt. Flashed Elemental X and it looks like its booting!
Awesome job my friend, you fixed the (temporarily) unfixable. I'll play around with this for a few days and report back.

Thanks!
XCnathan32 said:
So I found a bootloop fix for the Nexus 6p here, and some users reported having the same problem with their Nexus 5X.
I do not own a Nexus 5X, but I made a modified boot.img the same way I made the modified 6P image. It simply disables the big cores, as that's what was preventing the 6P from booting.
Please report if this works/does not work for you, that way I can get a good sample size to determine how effective this is.
Disclaimer: I have not tested this, I uploaded this image so testers could flash it and report if it works or not. If your device breaks/spontaneously combusts after flashing this, you accepted that risk.
Edit: A few people have reported this working, so it should be safe.
N2G47Z_4Cores.img, this image is based on the latest 7.1.2 firmware for the Nexus 5X, modified by me to only use 4 cores. 4 reported working, 2 reported not working.
To flash it: you must have an unlocked bootloader and fastboot on your PC. Boot your device into bootloader, and then run the command fastboot flash boot N2G47Z_4Cores.img Hopefully, your device will now boot up.
TWRP3_1_1_5X.img, modified to use only 4 cores, will get working TWRP on your device. Not tested yet
To flash, navigate to the folder where it is downloaded, make sure you have fastboot installed, and then run this command: fastboot flash recovery TWRP3_1_1_5X.img.
EX4_10_5X.zip, Elemental X kernel V4.10 for android 7.1.2, modified to use only 4 cores, I highly recommend you flash this, as EX kernel is faster, and you can overclock to the little cluster to make up for some speed. Not tested yet.
To flash, copy the zip to your device, then flash it in the modified TWRP, just go through the AROMA installer as usual. Changing the BIG cpu frequency in the installer will not change anything, as the cores are disabled.
Additional notes:
Root worked on my 6p by flashing the regular SuperSu zip just as normal. None tested for 5X yet
To improve performance slightly:
Disable animations in developer options, it helps a lot.
Overclock little cores with EX kernel, I have mine set to 1632 MHz and everything is working fine so far.
Set CPU governor to performance (or some aggressive governor), with the BIG cores disabled, the battery is already much better, so using a better performance governor shouldn't be a problem for battery life.
Doing a fresh flash of the firmware/factory reset can help a lot too.
Fast custom roms can also help.
Roms that me/other users have found working with this fix:
Pure Nexus worked well for me on the 6p, insane battery life and very little lag. If you are going to flash a rom, be sure to flash the modified EX kernel over it.
If you find a rom that works with this fix, tell me, and I'll put it here.
Credits:
@rchtk, his post here gave me the idea for how to modify the images.
@flar2, He built the Elemental X kernel for this device, I merely made a small modification to his kernel to use 4 cores. In no way am I trying to steal and/or discredit his work.
The TWRP development team, they built the TWRP recovery for this device, I merely made a small modification to their recovery to use 4 cores. In no way am I trying to steal and/or discredit their work.
Feel free to ask me for help, If you have a favorite ROM/Kernel that you want to use, tell me and i'll modify it to use 4 cores.
Please click thanks if I helped you, it means a lot to me
Click to expand...
Click to collapse
Hey man I tried this method, and I can confirm that this works! Although it is slow, it's better than nothing I truly do appreciate your efforts. SCREW LG

(VS995) Graphical Glitch When Flashing ANY Custom Firmware

Ok, so I've been lost as far as for what is going wrong with my device, I managed to downgrade to VS99513b from the 14b update through kdz, and I got TWRP installed successfully, but when I install ANY custom rom made for my device it gives me graphical glitches on the Boot logo, and even when it boots into the actual OS itself?
I don't know what's causing this, I mean TWRP looks to be just fine while I'm flashing these ROMS I did make a back-up prior, but I'd prefer a custom firm if I can get it any suggestions, or any explanations would be nice

Ok, I found the issue
It had to do with the kernel somehow? I just successfully flashed a Rom, and repeated the steps with a previously "broken" rom the only change is my use of a Stock Kernel Mod zip which seems to fix the graphical bug entirely... why that is I don't know, but hell if it works IDC

ProtoPropski said:
Ok, I found the issue
It had to do with the kernel somehow? I just successfully flashed a Rom, and repeated the steps with a previously "broken" rom the only change is my use of a Stock Kernel Mod zip which seems to fix the graphical bug entirely... why that is I don't know, but hell if it works IDC
Click to expand...
Click to collapse
this has been discussed so many times is why no one is responding.
if you googled v20 and static screen you would have had 1000 posts discussing this or even when you read disclaimer on root.
The static is due to changing your aboot aka bootlaoder for the us996 unlock one, casuing ALL stock boot.img to display static. Fortunately months after root had been released the devs developed fixes to hide static and return a normalish boot experience. with the exception 1st boot takes a little longer.
The static can be overcome by locking screen after bootup, then covering the proximity sensor until 2nd screen falls asleep then unlock and use as normal.
This was the initial fix that was the ONLY way to use the device after root, but now most stock kernels being built include the fix, and dont require this.
Hope this helps, and i dont mean to be rude by my response but theres a ton of this info everywhere on the forum and these questions that have been asked 1000 times wont keep getting answered. Please use the search function or read the disclaimers us devs are putting out there before using the methods to gain root and be using cfw.

Team DevDigitel said:
this has been discussed so many times is why no one is responding.
if you googled v20 and static screen you would have had 1000 posts discussing this or even when you read disclaimer on root.
The static is due to changing your aboot aka bootlaoder for the us996 unlock one, casuing ALL stock boot.img to display static. Fortunately months after root had been released the devs developed fixes to hide static and return a normalish boot experience. with the exception 1st boot takes a little longer.
The static can be overcome by locking screen after bootup, then covering the proximity sensor until 2nd screen falls asleep then unlock and use as normal.
This was the initial fix that was the ONLY way to use the device after root, but now most stock kernels being built include the fix, and dont require this.
Hope this helps, and i dont mean to be rude by my response but theres a ton of this info everywhere on the forum and these questions that have been asked 1000 times wont keep getting answered. Please use the search function or read the disclaimers us devs are putting out there before using the methods to gain root and be using cfw.
Click to expand...
Click to collapse
I was looking up info on "LG V20 Graphical Glitched Boot Screens" prior to posting this, and in that process I had only found one dead post, trust me I looked guess the search term I used was too descriptive, or uncommonly used? thanks for the reply though, I kinda fixed it on my own (by accident) through patching in a Stock Kernel Mod through TWRP after writing a fresh VS995 custom ROM it's all good now, my last post wasn't a bump, it was a poorly explained solution lol
Sry, I'm still not use to how this forum is ran, I kinda bounce between forums like a drunk whore on prom night
Link To Kernel Mod Used | ModStock

Question Fingerprint Sensor Not Working after unbricking phone

Long story short, I bricked my device very hard, very many times while trying out different ROMS and getting accustomed to handling fastboot and adb. At some point along the journey I must've broken something to do with the fingerprint sensor (or the security authentication method)? The sensor doesn't pick up anything when I have my finger on it, as if I had replaced the screen or something. This happens with all ROMS, including after doing a full reset to factory images and running Nothing OS. Maybe a driver or something?
I was using NOS 1.1.6 and and reset to the image that I found on https://reindex-ot.github.io/
There is now also a 1.1.7 ROM but I haven't tried updating to it yet, though I will at some point.
I have no idea how this actually works so any help would be appreciated. If there is a fingerprint calibration method, a piece of software to help or a certain stock img file that is needed then please leave a reply!
For now I have been using Face Unlock as a drop in replacement, although the algorithm and sensors don't provide for as quick and reliable authentication as the fingerprint sensor, so I would really like to get this fixed.
It also kinda forces me into using Paranoid Android right now as it has best Face Unlock that I've come across so far, and being able to authenticate quickly is worth most of the downsides that come with using it at this stage of development.

Calibrating the fingerprint sensor may improve the situation. The site introduced here is in Japanese.
Relife RL-071Bで光学式画面内指紋認証センサーの動作を修正する方法 - AndroPlus
画面内指紋認証センサーを搭載したAndroidスマホで指紋を登録できなくなったときの対処法を紹介します。 キャリブレーションし直しで解決できる場合あり 画面内指紋認証センサーを搭載したAndroidスマートフォンでは、特にBootloader
androplus.org

ot_inc said:
Calibrating the fingerprint sensor may improve the situation. The site introduced here is in Japanese.
Relife RL-071Bで光学式画面内指紋認証センサーの動作を修正する方法 - AndroPlus
画面内指紋認証センサーを搭載したAndroidスマホで指紋を登録できなくなったときの対処法を紹介します。 キャリブレーションし直しで解決できる場合あり 画面内指紋認証センサーを搭載したAndroidスマートフォンでは、特にBootloader
androplus.org
Click to expand...
Click to collapse
I read through the article and tried all the methods but I couldn't get anything to happen when I dialled. Thanks so much for the help though!
I think the reason my sensor is not working is because I flashed a persist partition when I was unbricking my phone, maybe if i flash a recent persist partition it will fix the fingerprint issue? Maybe it wont, not sure if something like that needs to be calibrated at the factory?
Either way, I am willing to try...
If anyone has a factory persist.img for Phone 1 that might help?
Ideally Nothing OS 1.1.6 full factory setup, but 1.1.7 will also help a lot as I can update.
Any post is appreciated!

I will put out a persist.img. I hope this fixes it.
NothingPhone(1)_Persist.zip
Nothing Phone(1) persist
drive.google.com

ot_inc said:
I will put out a persist.img. I hope this fixes it.
NothingPhone(1)_Persist.zip
Nothing Phone(1) persist
drive.google.com
Click to expand...
Click to collapse
Can I ask what version this is from?

jhonnytable said:
Can I ask what version this is from?
Click to expand...
Click to collapse
v1.1.7