[REF][ROM]Recovery Flashable Stock SM-N900V ROMs - Verizon Galaxy Note 3 General

[size=+2]As a convenience to the users here, I have created recovery-flashable versions of the SM-N900V (Verizon Samsung Galaxy Note 3) Stock ROMs from the following releases:[/size]
[size=+3]NC4 NJ6 NK1 OB6 OF1 PL1[/size]
These flashables are ONLY INTENDED FOR SM-N900V OWNERS WITH UNLOCKED BOOTLOADERS AND STANDALONE CUSTOM RECOVERIES.
These ROMS are NOT pre-rooted. You are responsible for doing that (flash a superSU .zip in the recovery following the ROM flash if you desire root). Or, use the custom recovery's offer to root for you.
These ROMs are NOT debloated. Almost all of the original bloat and crapware is enabled.
[size=+1]NOTE: Odin-flashable Modems are provided as separate downloads for those that want to mix-n-match.[/size]
[size=+2]::::: MODIFICATIONS FROM 100% STOCK:[/size]
A small number of preinstalled apps have been suppressed/frozen; specifically those involved in automatic recovery-partition regeneration, OTA, Knox, or carrier spyware. See notes at [*1]
Also, the following two "build.prop" properties were disabled:
Code:
ro.config.tima=0
ro.securestorage.support=false
This seems to produce more stable ROMs when bootloaders are mix-n-matched with different ROM versions.
A script is provided which allows reversal of all of the above modifications to produce a 100% stock ROM (should you want that). See the notes at [*3]
[size=+2]::::: DOWNLOADS:[/size]
ROMs - Courtesy of Androidfilehost.com
Flashable Modems - Courtesy of Androidfilehost.com
[size=+2]::::: INSTALLATION[/size]
- Wipe system, dalvik, cache, and data (do not wipe /data/media)
- Flash ROM
- (OPTIONAL: full stock behavior restore. See [*3] ) (if you don't understand what this is, don't do it.)
- (OPTIONAL: inject root using chainfire's flashable superSU .zip, or allow the custom recovery to inject root) See [*4]
These flashable .zip ROMs ONLY modify the "system" and "boot" partitions. No bootloader firmware, modem firmware, or recovery partitions are affected; nor are wipes performed on any other partitions.
A script is provided in /system/etc for the ROM suppressions to be completely reversed, resulting in an almost-identical-to-Odin-stock ROMs, including resumption of OTAs etc. [*2]
[size=+2]::::: FEEDBACK REQUESTED [/size]
Because of the bootloader firmware anti-rollback protections, it is impossible for me to test all combinations of bootloader vs. kernel+ROM versions. I am presently still on NC4 bootloader firmware and have run all of these on top of the NC4 bootloader (sometimes flashing the modem which matches the ROM version, sometimes not) If you use any of these with a unique combination of bootloader and kernel/ROM, please drop a success/failure report here. Make sure to report both the bootloader and modem firmware versions.
[size=+2]::::: APPLICATIONS (or, Why Would I Find These Useful)?[/size]
- You want to run a Rooted PL1 stock before a root method becomes available without flashing the PL1 bootloader firmware. Benefit of more security against malware, but all the flexibility of root.
- You want to work on attempting root exploits of the PL1 ROM/kernel without taking the plunge of potentially locking your device forever with an Odin full-PL1 stock flash. E.g., flash the PL1 stock ROM over prior bootloaders (NC4/NJ6/NK1/OB6/OF1). The device can be used as a daily driver while you test your code... assuming that it operates correctly (TESTERS WANTED!)
- You want to flash back to Stock "for a minute" to check something, but without having to completely backup, wipe the device, re-root, re-unlock the bootloader, re-install your custom recovery, and restore your "SD card" data.
- You want a ROM where GPS/NFC/BT "just works"
- You occasionally want to use those Samsung S-Pen or TouchWiz apps.
- You'd like to create your own version of debloated stock.
- You think you might have damaged your hardware doing something and want to "see if it still works on stock"
- You want to run a rooted-stock KitKat ROM despite the fact that your ROM will have giant gaping security holes in it (that can be elevated to root privilege from an app with absolutely zero Android privileges)
[size=+2]::::: FAQs[/size]
Q - I am going to sell/give away my device. Should I use this?
A - Probably not. Use Odin with a factory image instead. These flashes by themselves do not enforce consistent bootloader, modem, or recovery firmware.
Q - Why didn't you debloat XXX and YYY from these?
A - Laziness. And besides, everyone has a different idea of what "debloated" means. Moreover, I wanted something that could easily be toggled into a "100% stock" configuration.
Q - I flashed one of these ROMs and yet I still see the "Knox Warranty" message when I boot up. Are the boot images non-stock?
A0 - The boot images in these ROMs are pure stock, right from the Odin factory tar/.md5 blobs.
A1 - Does your bootloader version match the kernel/ROM version? At least with the NC4 bootloader, you get that message when booting any kernel which is not the NC4 Samsung kernel - even when they are validly signed Samsung kernels. So, the only time you do not get that warning message is when the boot image is unmodified AND it exactly matches the version of the bootloader. I suppose that is the same behavior for other bootloader versions. Sigh.
A2 - "Systemless" root injection modifies the boot partition. That certainly will break the signing as you have modified the original boot image.
There is a way to check to see if your boot image has been modified; here it is:
1) compute the md5sum of the "boot.img" file from the release
2) find out the size/byte length of the factory "boot.img" file ("ls -l boot.img")
3) dump the same number of bytes out of the boot partition and pipe those bytes into the "md5sum" utility:
Code:
dd if=/dev/block/platform/msm_sdcc.1/by-name/boot bs=FILELENGTH count=1 | md5sum
Q - I did the stock reversion process and I still have the "Custom" logo showing up on my phone during boot-up. Why?
A - Because you are using a custom recovery, or a kernel which is mismatched to the version of the bootloader firmware. These ROMs are intended for use with unlocked phones with a custom recovery in any event.
Q - I can't get Knox containers to work. Why?
A - Knox containers will not work on phones with a blown Knox Warranty flag. That's an irreversible change you made to your phone when you unlocked it and booted an unsigned kernel. Sorry.
[size=+2]::::: Revision History[/size]
0.95 remove umount /system at end of reversion script; undo Mobicore service suppression.
0.94 add ELM*{.apk|.odex|etc} to suppressions
0.93 correct chmod mode in restore script for bin/install-recovery.sh (PL1)
0.92 baseline
[size=+2]::::: FOOTNOTES[/size]
[*1] For example: bin/install-recovery.sh, LocalFOTA, SDM, Knox*, VMS, SysScope, et cetera. All the other commercial bloatware and Samsung apps remain. NOTE: because of the possiblity of running these kernels/ROMs on mis-matched bootloader(s) where TZ/Attribution failures could disable certain TrustZone capabilities, I have disabled the following properties in /system/build.prop:
ro.config.tima=0
ro.securestorage.support=false
These may be easily reversed and the device rebooted.
[*2] If you were returning to stock in order to sell or dispose the device, probably it is best to just use Odin with the factory images.
[*3] Using the custom recovery's Advanced->Terminal function, find the script name in /system/etc, i.e.
Code:
ls -l /system/etc/bftb0*
and then
Code:
. /system/etc/bftb0_README*
It is sort of unlikely that anyone would need to use this. It may even be the case that Verizon has stopped providing OTA updates on older releases anyway. But it's there if you want it.
If nothing else, this script is very easy to read and so it documents all the changes that make it slightly different from pure stock; if you want to reverse one particular suppression, just read through the script and perform those individual changes manually, and reboot.
[*4] Since about superSU 2.65, the SuperSU .zip installation method MODIFIES THE BOOT PARTITION! The same is true of "systemless" root installations performed by custom recoveries (e.g. TWRP). You need to be aware of this in one very particular application: Installing a new bootloader over the top of a pre-rooted ROM which has the stock kernel version matching the version of the to-be-installed bootloader/modem firmware.

---

Running twrp/developer mode (via the unlocked bootloader thread), s7 edge AryaMod rom, with NC4 modem.
Do I flash this via twrp or Odin to get on the PL1 modem?
I want to stay on aryamod. I just want to update my modem

---

@bftb0 Thank you for this thread Sir. You are always a missive help :good:

---

godrick15 said:
Running twrp/developer mode (via the unlocked bootloader thread), s7 edge AryaMod rom, with NC4 modem.
Do I flash this via twrp or Odin to get on the PL1 modem?
I want to stay on aryamod. I just want to update my modem
Click to expand...
Click to collapse
Then just flash the N900VVRSEPL1_Modem.tar.md5 modem using Odin. (In the AP slot)
The modems are in a separate folder titled "OdinFlashableModems"; they are meant to be flashed separately according to the whims of the user.**
**having said that - and to stay on topic (which is these Stock ROM flashables) - if any connectivity troubles are encountered, the first thing to be tried is matching the kernel version of the ROM with the same modem version. As in NC4 modem with NC4 kernel, OB6 modem with OB6 kernel, et cetera. Flash the ROM in TWRP, and the modem in Odin (I actually am right now going through a matrix of flashing tests; already it is clear that the NC4 modem can't be used with NJ6 or NK1 kernels, for instance.)
For these ROMs (discussed in the OP) it's probably a good practice to simply download both the ROM of a specific release and the matching modem and perform the first boot of the ROM with the releases paired together. After that folks should feel free to screw around with modems to their heart's content.
cheers
.

---

bftb0 said:
Then just flash the N900VVRSEPL1_Modem.tar.md5 modem using Odin. (In the AP slot)
The modems are in a separate folder titled "OdinFlashableModems"; they are meant to be flashed separately according to the whims of the user.**
**having said that - and to stay on topic (which is these Stock ROM flashables) - if any connectivity troubles are encountered, the first thing to be tried is matching the kernel version of the ROM with the same modem version. As in NC4 modem with NC4 kernel, OB6 modem with OB6 kernel, et cetera. Flash the ROM in TWRP, and the modem in Odin (I actually am right now going through a matrix of flashing tests; already it is clear that the NC4 modem can't be used with NJ6 or NK1 kernels, for instance.)
For these ROMs (discussed in the OP) it's probably a good practice to simply download both the ROM of a specific release and the matching modem and perform the first boot of the ROM with the releases paired together. After that folks should feel free to screw around with modems to their heart's content.
cheers
.
Click to expand...
Click to collapse
Flash modem from CP slot,
Power off phone, start Odin, turn on phone in download mode.. (vol. down + home + power) and then plug into computer. Hit Vol Up to switch into download mode. Wait for com: notification in Odin and hit Start in Odin.
The above is only for XXXmodem.tar.md5 files. For complete ROMs that also include modem, follow the same except flash from AP slot.
I don't know why, but booting from power off into download mode seems to insure modem only tars 'take'.
Sent from my SM-N900V using Tapatalk

---

@donc113
I'll admit that I've never come across an Odin guide of any technical depth. I've used both the AP and BL slots (not together) for bootloader firmware, and largely haven't had any major issues flashing modems in the AP slot.
I'm wondering if there is no other purpose for the "slots" other than to be able to sequentially flash firmware using multiple file sources "in a single go". (i.e., the slots are not functionally different from each other, and are mostly there because Samsung service centers have firmware files partitioned by BL/AP/CP/CSC functionality, and the "slots" simply remind their techs to "fill up all the slots" when a complete flash is necessary)
One thing that is certain is that having begun an Odin flash, you can hit the "reset" button in the application (after the phone issues a RESET), but you need to restart the phone again in Odin/Download mode to perform a second flashing operation. Thus (maybe?) the need for multiple slots if firmware is in multiple files?. I guess I could break up a factory image into multiple sets and experiment but that seems low on the priority totem pole right now.
roll your own Odin .md5 tarballs:
Code:
tar -H ustar -c -f Odin-flashable-XYZ.tar flle1 file2 [...fileN]
md5sum Odin-flashable-XYZ.tar >> Odin-flashable-XYZ.tar
mv Odin-flashable-XYZ.tar Odin-flashable-XYZ.tar.md5

---

bftb0 said:
@donc113
I'll admit that I've never come across an Odin guide of any technical depth. I've used both the AP and BL slots (not together) for bootloader firmware, and largely haven't had any major issues flashing modems in the AP slot.
I'm wondering if there is no other purpose for the "slots" other than to be able to sequentially flash firmware using multiple file sources "in a single go". (i.e., the slots are not functionally different from each other, and are mostly there because Samsung service centers have firmware files partitioned by BL/AP/CP/CSC functionality, and the "slots" simply remind their techs to "fill up all the slots" when a complete flash is necessary)
One thing that is certain is that having begun an Odin flash, you can hit the "reset" button in the application (after the phone issues a RESET), but you need to restart the phone again in Odin/Download mode to perform a second flashing operation. Thus (maybe?) the need for multiple slots if firmware is in multiple files?. I guess I could break up a factory image into multiple sets and experiment but that seems low on the priority totem pole right now.
roll your own Odin .md5 tarballs:
Code:
tar -H ustar -c -f Odin-flashable-XYZ.tar flle1 file2 [...fileN]
md5sum Odin-flashable-XYZ.tar >> Odin-flashable-XYZ.tar
mv Odin-flashable-XYZ.tar Odin-flashable-XYZ.tar.md5
Click to expand...
Click to collapse
The CP slot is also able to flash .bin files.
Sent from my SM-N900V using Tapatalk

---

Carrier unlocked
flashed rom .rebooted with t-mobile SIM, wih no option in setting to change APN
bftb0 said:
Then just flash the N900VVRSEPL1_Modem.tar.md5 modem using Odin. (In the AP slot)
The modems are in a separate folder titled "OdinFlashableModems"; they are meant to be flashed separately according to the whims of the user.**
**having said that - and to stay on topic (which is these Stock ROM flashables) - if any connectivity troubles are encountered, the first thing to be tried is matching the kernel version of the ROM with the same modem version. As in NC4 modem with NC4 kernel, OB6 modem with OB6 kernel, et cetera. Flash the ROM in TWRP, and the modem in Odin (I actually am right now going through a matrix of flashing tests; already it is clear that the NC4 modem can't be used with NJ6 or NK1 kernels, for instance.)
For these ROMs (discussed in the OP) it's probably a good practice to simply download both the ROM of a specific release and the matching modem and perform the first boot of the ROM with the releases paired together. After that folks should feel free to screw around with modems to their heart's content.
cheers
.
Click to expand...
Click to collapse

---

teeve said:
flashed rom .rebooted with t-mobile SIM, wih no option in setting to change APN
Click to expand...
Click to collapse
https://forum.xda-developers.com/showthread.php?t=2582747
Sent from my SM-N900V using Tapatalk

---

teeve said:
flashed rom .rebooted with t-mobile SIM, wih no option in setting to change APN
Click to expand...
Click to collapse
These are in fact Verizon Stock ROMs. If they were intended to be for multiple carriers (out of the box) they would not be in this specific forum, and I would have mentioned it.
That said, any hacks/mods that might have worked in the past on SM-N900V stock ROMs could be possible, with "some assembly required".
I don't have a T-mo SIM to test out the method described in the link @donc113 provided above. (I can tell you though that with a VZW SIM, on the PL1 ROM you only will see "LTE/CDMA" and "CDMA" under Settings->Mobile networks->Network mode. I suppose that could depend on what SIM was in when the phone booted, but I don't really know)
If you get it working, please file a success report. Don't forget to mention the version that you flashed - you omitted that in your Q.
cheers

---

unlocked Verizon Note 3 w/flashable "stock roms ?
bftb0 said:
These are in fact Verizon Stock ROMs. If they were intended to be for multiple carriers (out of the box) they would not be in this specific forum, and I would have mentioned it.
That said, any hacks/mods that might have worked in the past on SM-N900V stock ROMs could be possible, with "some assembly required".
I don't have a T-mo SIM to test out the method described in the link @donc113 provided above. (I can tell you though that with a VZW SIM, on the PL1 ROM you only will see "LTE/CDMA" and "CDMA" under Settings->Mobile networks->Network mode. I suppose that could depend on what SIM was in when the phone booted, but I don't really know)
If you get it working, please file a success report. Don't forget to mention the version that you flashed - you omitted that in your Q.
cheers
Click to expand...
Click to collapse
OF1. Will try the unlocked hack. Only have LTE/CDMA option as it stands.

---

Carrier unlocked
bftb0 said:
These are in fact Verizon Stock ROMs. If they were intended to be for multiple carriers (out of the box) they would not be in this specific forum, and I would have mentioned it.
That said, any hacks/mods that might have worked in the past on SM-N900V stock ROMs could be possible, with "some assembly required".
I don't have a T-mo SIM to test out the method described in the link @donc113 provided above. (I can tell you though that with a VZW SIM, on the PL1 ROM you only will see "LTE/CDMA" and "CDMA" under Settings->Mobile networks->Network mode. I suppose that could depend on what SIM was in when the phone booted, but I don't really know)
If you get it working, please file a success report. Don't forget to mention the version that you flashed - you omitted that in your Q.
cheers
Click to expand...
Click to collapse
I dont have a verizon SIM to try the method described in the link. But I flashed the OF1 modem, and when I first start the phone with the T-mobile SIM, it says T-mobile and there is signal bars - and then immediately the data connection goes away and the "not a verizon SIM" comes up:silly:

---

teeve said:
I dont have a verizon SIM to try the method described in the link. But I flashed the OF1 modem, and when I first start the phone with the T-mobile SIM, it says T-mobile and there is signal bars - and then immediately the data connection goes away and the "not a verizon SIM" comes up:silly:
Click to expand...
Click to collapse
I noticed after my initial reply that those instructions @donc113 referenced presumed there is a "global" mode toggle in the Settings menus, and that doesn't seem to be the case for OF1 (as you say) or PL1 (as I observed).
This isn't an area of expertise for me - I've always been on Verizon, so I never had much of a need to hack a phone to a new carrier. (I'd recommend that you have a complete backup of your EFS partition before you start messing around.) << read that part two or three times.
On PL1, there is this (needs to be executed as root if you don't start it from within an app such as "App Browser"):
Code:
am start -W -n com.test.LTEfunctionality/com.test.LTEfunctionality.LTEFunctionalityTest
And then scroll down to "LTE APN Setting". Hitting the "+" sign (upper right corner) allows you to add a new set of APN parameters. Thing is, I don't know if this is something that allows you to make only a temporary change or if they "stick" after you exit that activity.
There is a file in /efs (namely /efs/apn-changes.xml) which seems to hold APN configuration data, but I have no clue if that is consulted for configuration information, or merely a copy of data that really lives elsewhere.
If the phone isn't your daily driver, you could probably flash back to the NC4 ROM as an experiment to see if "Global" is still available in the settings menu. Not so much because you would want to use an old, insecure ROM, but just to see if you can successfully get it programmed to work with T-mobile for voice+data+sms+mms. At least if you figured out what the correct settings were supposed to be, you'd only be faced with where they are supposed to go in OF1/PL1 (Were you using this phone before on T-mobile? If so, what ROM?)
There's a ton of stuff under the hood with those hidden settings. Hundred if not thousands of tweakable parameters. (If you want your head to spin look under IMS Settings) I would be careful about randomly poking at things. Apparently there's a fair amount of stuff stored in NVRAM which has nothing to do with anything that gets flashed by Odin with factory images, so it is entirely possible to permanently mess up a phone if you aren't super careful about recording prior settings and watching every keystroke. Some of those "maintenance" menus seem to be really poorly programmed - not defensively - and you could make unintended changes simply by walking through a set of menu picks.
.

---

bftb0 said:
I noticed after my initial reply that those instructions @donc113 referenced presumed there is a "global" mode toggle in the Settings menus, and that doesn't seem to be the case for OF1 (as you say) or PL1 (as I observed).
This isn't an area of expertise for me - I've always been on Verizon, so I never had much of a need to hack a phone to a new carrier. (I'd recommend that you have a complete backup of your EFS partition before you start messing around.) << read that part two or three times.
On PL1, there is this (needs to be executed as root if you don't start it from within an app such as "App Browser"):
Code:
am start -W -n com.test.LTEfunctionality/com.test.LTEfunctionality.LTEFunctionalityTest
And then scroll down to "LTE APN Setting". Hitting the "+" sign (upper right corner) allows you to add a new set of APN parameters. Thing is, I don't know if this is something that allows you to make only a temporary change or if they "stick" after you exit that activity.
There is a file in /efs (namely /efs/apn-changes.xml) which seems to hold APN configuration data, but I have no clue if that is consulted for configuration information, or merely a copy of data that really lives elsewhere.
If the phone isn't your daily driver, you could probably flash back to the NC4 ROM as an experiment to see if "Global" is still available in the settings menu. Not so much because you would want to use an old, insecure ROM, but just to see if you can successfully get it programmed to work with T-mobile for voice+data+sms+mms. At least if you figured out what the correct settings were supposed to be, you'd only be faced with where they are supposed to go in OF1/PL1 (Were you using this phone before on T-mobile? If so, what ROM?)
There's a ton of stuff under the hood with those hidden settings. Hundred if not thousands of tweakable parameters. (If you want your head to spin look under IMS Settings) I would be careful about randomly poking at things. Apparently there's a fair amount of stuff stored in NVRAM which has nothing to do with anything that gets flashed by Odin with factory images, so it is entirely possible to permanently mess up a phone if you aren't super careful about recording prior settings and watching every keystroke. Some of those "maintenance" menus seem to be really poorly programmed - not defensively - and you could make unintended changes simply by walking through a set of menu picks.
.
Click to expand...
Click to collapse
I'm on Jasmine which is OF1 and I have a global mode selection.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Sent from my SM-N900V using Tapatalk

---

Took a look over in my AFH area at the file counts to see what the activity level was. (The Note 3 is an "old" device, 3 years is approximately infinitely old LOL)
Over 60 downloads of the ROMs (OF1 and PL1 mostly) and about the same count for modems.**
And yet not a single report here of something actually getting installed. I suppose (as XDA doesn't require a login) that lurkers vastly outnumber XDA contributors ???
Ahh, well; I put them up there so folks could use them. Hopefully that's the case.
** oddly, a fair number of downloads of the NC4 modem. No clue what that would mean.
.

---

I'm running into an error when flashing the ROM in TWRP:
Code:
This package is for device: SM-N900V,hltevzw; this device is hlte.
Updater process ended with ERROR: 7
Error installing zip file '/external_sd/ROM_STUFF/Roms/N900VVRSEPL1_flashable_OTAsuppressed_vo.95.zip'
Updating partition details...
...done
My phone is a N900V.
---------- Post added at 02:12 PM ---------- Previous post was at 01:29 PM ----------
*Update*
Nevermind, I managed to get it working by editing the \META-INF\com\google\android\updater-script, replacing all 'hltevzw' with 'hlte', and updating the zip.

---

pnuker said:
I'm running into an error when flashing the ROM in TWRP:
Code:
This package is for device: SM-N900V,hltevzw; this device is hlte.
Updater process ended with ERROR: 7
Error installing zip file '/external_sd/ROM_STUFF/Roms/N900VVRSEPL1_flashable_OTAsuppressed_vo.95.zip'
Updating partition details...
...done
My phone is a N900V.
---------- Post added at 02:12 PM ---------- Previous post was at 01:29 PM ----------
Nevermind, I managed to get it working by editing the \META-INF\com\google\android\updater-script, replacing all 'hltevzw' with 'hlte', and updating the zip.
Click to expand...
Click to collapse
Cool :good:
Just for info to anyone else that get that error:
Basically its an error you get if you are using the wrong twrp. In your case you are using an hlte recovery not N900V twrp recovery. But what you did will work :good:

---

Sczar said:
Just for info to anyone else that get that error:
Basically its an error you get if you are using the wrong twrp. In your case you are using an hlte recovery not N900V twrp recovery. But what you did will work :good:
Click to expand...
Click to collapse
^this.
The custom recoveries don't do any fancy hardware detection during the assert in
META-INF/com/google/android/update-script
; they merely check the value in the script against the property
ro.product.device
that is established by init from reading the /default.prop file when the recovery boots up. Wrong recovery? Wrong ro.product.device value.
The situation is somewhat muddled by virtue of the fact that there are ROMs that will install & run more or less correctly on multiple device types, so the devs either check for each compatible device in the assert statement in the update-script... or they simply omit the assert() in the script altogether.
Either of the latter can lead people to conclude that they installed the correct twrp version - "hey, I used it to install a new ROM and it worked."
I chose to use strict checking when I packaged these up.
In any event, here are the TWRP downloads for hltevzw

---

bftb0 said:
^this.
The custom recoveries don't do any fancy hardware detection during the assert in
META-INF/com/google/android/update-script
; they merely check the value in the script against the property
ro.product.device
that is established by init from reading the /default.prop file when the recovery boots up. Wrong recovery? Wrong ro.product.device value.
The situation is somewhat muddled by virtue of the fact that there are ROMs that will install & run more or less correctly on multiple device types, so the devs either check for each compatible device in the assert statement in the update-script... or they simply omit the assert() in the script altogether.
Either of the latter can lead people to conclude that they installed the correct twrp version - "hey, I used it to install a new ROM and it worked."
I chose to use strict checking when I packaged these up.
In any event, here are the TWRP downloads for hltevzw
Click to expand...
Click to collapse
this ^^
True. Its not a hardware detection. Its a command in the default.prop i was trying to simplify it as much as possible.
But as you explained in details ?
Thank you

---

bftb0 said:
In any event, here are the TWRP downloads for hltevzw
Click to expand...
Click to collapse
That is the TWRP I was using though (twrp-3.0.2-0-hltevzw-4.4)