Sure about that?That is the TWRP I was using though (twrp-3.0.2-0-hltevzw-4.4)
Code:
assert(getprop("ro.product.device") == "SM-N900V" || getprop("ro.build.product") == "SM-N900V" || getprop("ro.product.device") == "hltevzw" || getprop("ro.build.product") == "hltevzw" || abort("This package is for device: SM-N900V,hltevzw; this device is " + getprop("ro.product.device") + "."););
Note that the above assert() only reaches the abort() error message if all of the of the prior conditions have resulted in a "false" (=0) value. I think that (lazy evaluation behavior) is called "logical OR short-circuiting" or something. (The first condition which is true causes the whole thing to be true, so no need to evaluate anything to the right in the chain... so the thing on the end only occurs when everything else has failed.)
In any event, note that when it spews the the error message it does this:
"... this device is " + getprop("ro.product.device") + ...
based on your own report of the error message, that means that the read only init property value of "ro.product.device" was set to "hlte", not "hltevzw" when you got that error message.
If you haven't changed your TWRP, you can boot into it and take a look. Just use the TWRP's Advanced->Terminal and do a
Code:
grep device /default.prop
There's other ways of making that check too without booting up in the recovery. Find out how many bytes long the twrp-3.0.2-0-hltevzw-4.4.img file is, and compute it's MD5 checksum ( "md5sum" command )
Then dump the exact same number of bytes out of the recovery partition and pipe that output into the md5sum command to cross-check the hash. If they are different, you've got something else installed in there.
$ ls -ld twrp-3.0.2-0-hltevzw-4.4.img
-rwxr-xr-x 1 user user 10385408 Apr 27 2016 twrp-3.0.2-0-hltevzw-4.4.img
$ md5sum twrp-3.0.2-0-hltevzw-4.4.img
b4c2206bcc5e1f553a239b16940e9d38 twrp-3.0.2-0-hltevzw-4.4.img
Code:
dd if=/dev/block/mmcblk0p15 bs=10385408 count=1 | md5sum
good luck and safe travels.
.