(As a foreword, I've been searching and trying to find these answers myself but I haven't had much luck. If there are resources out there covering my questions, please direct me there. Thanks!)
Could someone please inform me of the specific difference(s) between the VRALEC and VRALE6 bootloaders? Also any background info would be interesting to know as well (order in which they were leaked, timeframes, circumstances etc).
Next question: I was able to successfully ODIN the VRALEC bootloader (only) to my stock phone on VRBMF1. When I tried to do the same with VRALE6 it failed with a signing-related error. However I was able to flash the VRALE6 directly using the CASUAL utility and that worked fine. I don't understand why/how the phone will allow itself to boot from that file, but wouldn't allow it to be ODIN'd. Could somebody enlighten me? Also, if I were to have tried ODIN'ing the entire VRALE6 bootchain, would that have succeeded?
Also, is there any rationale for using any other bootloader(s)? There appear to be at least 10 different bootloader and/or bootchain version varients out on the web in different places. From what I can gather though, only the two listed above are significant since they are 'unlocked'.
Lastly, which bootloader does the Developer Edition phone use? Does it come unlocked, or is it unlock-able via some web site or something? If it has its own 'special' unlocked bootloader, why could we not simply get a copy and use that on retail phones rather than the old/leaked version widely used now?
B
pluto01 said:
(As a foreword, I've been searching and trying to find these answers myself but I haven't had much luck. If there are resources out there covering my questions, please direct me there. Thanks!)
Could someone please inform me of the specific difference(s) between the VRALEC and VRALE6 bootloaders? Also any background info would be interesting to know as well (order in which they were leaked, timeframes, circumstances etc).
Click to expand...
Click to collapse
Well, for the longest time the VRALEC was titled the "boot chain" and I'm seeing now in Invisiblek's awesome thread over on Rootz, that's not the case anymore. So, I'll preface this by saying referring to both VRALEC and VRALE6 terms as "bootloaders" sounds weird now because VRALEC was originally titled "VRALEC.bootchain.tar".
VRALEC file should be a "tar" and the VRLE6 file should be a "zip." Cool? Here's how to differentiate, the VRALEC.bootloader.tar needs to be flashed in Odin to allow you to install a custom recovery. It is essentially just the first step of several to unlock the bootloader, it is not unlocked at this point. Someone of a more technical background can explain this better but its like this file is hijacking the boot sequence and telling the phone everything is still recognized as official firmware. There's no trigger that prompts the phone to give you the yellow triangle warning. Once a custom recovery is installed, you need to flash in recovery the VRLE6.zip to unlock the bootloader. Both of these files come from a pre-release VZW GSIII that were so graciously provided to AdamOutler by an African-Canadian Sock Monkey. Seriously, check post #317. This also serves to answer your question about times, leaked, etc. Moving on!
Next question: I was able to successfully ODIN the VRALEC bootloader (only) to my stock phone on VRBMF1. When I tried to do the same with VRALE6 it failed with a signing-related error. However I was able to flash the VRALE6 directly using the CASUAL utility and that worked fine. I don't understand why/how the phone will allow itself to boot from that file, but wouldn't allow it to be ODIN'd. Could somebody enlighten me? Also, if I were to have tried ODIN'ing the entire VRALE6 bootchain, would that have succeeded?
Click to expand...
Click to collapse
As I said above, VRALE6 should be a zip file and needs to be flashed in custom recovery NOT Odin. That's the key difference.
Also, is there any rationale for using any other bootloader(s)? There appear to be at least 10 different bootloader and/or bootchain version varients out on the web in different places. From what I can gather though, only the two listed above are significant since they are 'unlocked'.
Click to expand...
Click to collapse
Nope. Idk what you mean by "at least 10 different bootloader and/or bootchain version varients." Maybe there is a "bootloader" per each OTA that we have received? But honestly, every OTA thus far has been rooted/unlocked via almost the exact methods so this is a moot topic. There are only two unlock files of significance for any root/unlock method for the VZW GSIII: VRALE6.zip and VRALEC.tar
Lastly, which bootloader does the Developer Edition phone use? Does it come unlocked, or is it unlock-able via some web site or something? If it has its own 'special' unlocked bootloader, why could we not simply get a copy and use that on retail phones rather than the old/leaked version widely used now?
B
Click to expand...
Click to collapse
Well, AdamOutler actually received some help and got this phone unlocked well before the dev edition was released last year so there was never a need to look towards that device for bootloader unlock help. I have no clue about how to unlock that device and there's been no reason to think about having (at the time) a $650 dev edition GSIII when the retail one was officially unlocked. No clue on compatibility with bootloaders between either device.
Related
I have an AT&T HOX. Came stock with 1.85.
I rooted it using the "redbend" method described here (http://forum.xda-developers.com/showthread.php?t=1709296)
(More or less, the pulling SIM card business wasn't part of the steps when I used it, but the root was successful).
I am using SuperSU to manage root access by apps.
I have not done anything beyond that.
Now, I understand, at some point, AT&T is going to force a 2.20 update on me.
My primary concern is to avoid losing root.
(I have enabled the "preserve root across OTA" in SuperSU, but not sure if its effective or not)
I've looked at the howto's for SuperCID, unlocking the bootloader, etc, and I'm not sure which I NEED, and which are optional, and/or what the pros/cons are of each...
I'd like to stay as close to "stock" as possible, but I want to ensure that I can keep root.
I'm still within my AT&T contract, and would really prefer to avoid bricking the phone.
I'm wondering what the recommendations are as to the minimum steps I should take to keep root in the event the OTA is forced on me?
Can I pre-empty the OTA by installing this? ( http://forum.xda-developers.com/showthread.php?t=1812459 )
If so, what is the safest method for installing it?
FWIW, I am a linux user, and I am comfortable with adb as well as the command line on the phone itself.
I have no windows systems, so any special tools I'd need other than adb I'd have to find a linux version.
I don't need "one click" methods, in fact I'd prefer to see/perform the individual steps and understand what they are doing.
unlock your bootloader using this method http://forum.xda-developers.com/showthread.php?t=1672284 if you don't you wont get root again afterwards.
Dont have to unlock to flash roms?
This document,
http://onexroot.com/one-x-root/root-any-htc-one-x-windowsmaclinuxattinternationalone-click-method/
Near the very bottom, suggests:
For AT&T HTC One XL and alike, if you want to install custom ROMs, you don’t have to unlock your bootloader but simply flash custom recovery in fastboot.
Is this accurate?
My ATT HOX is currently rooted, and I now have SuperCID. I assumed I would need to unlock my bootloader, but I havent done that yet.
Can I install this:
https://play.google.com/store/apps/details?id=com.s0up.goomanager
and then use it to install the "Stock Rooted AT&T 2.20.502.7" here?
http://forum.xda-developers.com/showthread.php?t=1812459
And if I do that, will this avoid AT&T OTA'ing me?
On a relatated note, would the SuperCID survive the OTA, allowing me to unlock the bootloader afterward, even if I hadnt done so already?
Megadave123 said:
This document,
http://onexroot.com/one-x-root/root-any-htc-one-x-windowsmaclinuxattinternationalone-click-method/
Near the very bottom, suggests:
For AT&T HTC One XL and alike, if you want to install custom ROMs, you don’t have to unlock your bootloader but simply flash custom recovery in fastboot.
Is this accurate?
Click to expand...
Click to collapse
Completely false. You cannot install custom recovery without unlocked bootloader. For the safety of your device, I'd suggest sticking with XDA, and not Googling random websites. That website obviously has incorrect information.
Megadave123 said:
and then use it to install the "Stock Rooted AT&T 2.20.502.7" here?
http://forum.xda-developers.com/showthread.php?t=1812459
And if I do that, will this avoid AT&T OTA'ing me?
Click to expand...
Click to collapse
AT&T isn't going to "OTA" you by force. You have to accept the download, then accept the installation. Cancelling either of those will prevent the OTA from being installed.
If you want to update to the stock 2.20 firmware without running the OTA or RUU (and therefore keep the ability to flash kernels and radios), than yes, the ROM you linked is the method I would suggest. But you would need to unlock the bootloader, then install TWRP before you can flash the rooted 2.20. Also keep in mind there are newer (than 2.20) firmwares already posted in Development (2.23, 2.29, etc.) in similar pre-rooted form. Not to mention custom ROMs based on 2.20 or newer.
Megadave123 said:
On a relatated note, would the SuperCID survive the OTA, allowing me to unlock the bootloader afterward, even if I hadnt done so already?
Click to expand...
Click to collapse
SuperCID survives OTA. But the 2.20 OTA has a new hboot, which fixes the hole by which kernels and radios can be flashed from recovery, so my recommendation would be not to install the OTA.
redpoint73 said:
Completely false. You cannot install custom recovery without unlocked bootloader. For the safety of your device, I'd suggest sticking with XDA, and not Googling random websites. That website obviously has incorrect information.
Click to expand...
Click to collapse
FWIW, I didnt google that site. It was linked to from an XDA post. I't didnt seem right to me, which is why I asked here
AT&T isn't going to "OTA" you by force. You have to accept the download, then accept the installation. Cancelling either of those will prevent the OTA from being installed.
If you want to update to the stock 2.20 firmware without running the OTA or RUU (and therefore keep the ability to flash kernels and radios), than yes, the ROM you linked is the method I would suggest. But you would need to unlock the bootloader, then install TWRP before you can flash the rooted 2.20. Also keep in mind there are newer (than 2.20) firmwares already posted in Development (2.23, 2.29, etc.) in similar pre-rooted form. Not to mention custom ROMs based on 2.20 or newer.
Click to expand...
Click to collapse
Ok, that is VERY good to hear.
BTW, thank you very much. I read somewhere that ATT could/might force the OTA, and I've been worried about losing root ever since, but not quite ready to (presumably) completely void my warranty with a bootloader unlock.
Megadave123 said:
BTW, thank you very much. I read somewhere that ATT could/might force the OTA, and I've been worried about losing root ever since, but not quite ready to (presumably) completely void my warranty with a bootloader unlock.
Click to expand...
Click to collapse
I think bypassing the user acceptance dialogues for the OTA install would be a violation of how Android fundamentally works. It would be a serious security issue, as it might allow rogue software to be installed on your device without your interaction. I seriously doubt AT&T would institute such a thing.
The user confirmation of the OTA might be a liability thing, too. If the performance of the device is adversely affected by the OTA (happens to some people) and the OTA was forced by AT&T without the owner having a choice, it would seem to me that AT&T has to accept the responsibility. People can claim its AT&T's fault, and demand a replacement device (since AT&T technically installed the software remotely). By making you confirm the OTA installation (and giving you the chance to opt out), you pretty much are volunteering to install the software and accept the consequences.
In theory, unlocking the bootloader voids you warranty. But more than a few folks on here have gotten warranty replacements from AT&T (after unlocking the bootloader), without issue. Sometimes in-store (within the first 30 days) without them even checking for the bootloader unlock. No guarantee that this will always be the case. But just throwing it out there. Its still up to you whether unlocking the BL is worth the risk in your own case.
I dont remember but isnt hoxl supported by goomanager? As long as your rooted you can install a recovery from it with a locked bootloader. I always reccomend unlocking but im pretty sure its not a total necessity to get twrp recovery
18th.abn said:
I dont remember but isnt hoxl supported by goomanager? As long as your rooted you can install a recovery from it with a locked bootloader. I always reccomend unlocking but im pretty sure its not a total necessity to get twrp recovery
Click to expand...
Click to collapse
The hoxl is officially supported by twrp and can be downloaded from goomanager. I do not know if you can install a custom recovery without an unlocked bootloader. I would be interested to know if this can be done as well.
Sent from my Nocturnalized One XL using Forum Runner
when you try to push a recovery via fastboot with a locked bootloader it will fail due to invalid signature I don't see how goomanager would be any different.
Is there any harm in trying it?
If I install "goo manager", and let it do its thing, and the locked bootloader prevents it from doing so, there wont be any other side effects, will there?
If I come off as a complete noob at this - its because I am..
This is my first Android phone, and I *really* want to avoid bricking it, so I want to make sure I understand as much as possible before I go
trying to do anything to it.
Also I'm still wary of unlocking, mainly because of the whole "will erase your phone" bit.
I'm not yet fully comfortable that I know how/what to fully backup all of "my" data on the phone so as to facilitate easily putting it all back.
I'll answer some q's here.
1.) you cannot flash a custom recovery from hboot with a locked bootloader
2.) you CAN dd a custom recovery with a locked bootloader. However your device will be soft-bricked.
3.) you CAN install custom ROM's via dd right from android. This is how we did it back "in the day".
4.) you "might" be able to get away with dd'ing a custom kernel with locked BL, not not sure. In fact, I'd bet it will softbrick now that I think about it.
Anyways, the SAFEST way to do it is via unlocking the bootloader and installing your roms from custom recovery.
gunnyman said:
when you try to push a recovery via fastboot with a locked bootloader it will fail due to invalid signature I don't see how goomanager would be any different.
Click to expand...
Click to collapse
Beaups pretty much already answered it. But this guy tried installing TWRP thru goomanager with a locked bootloader, and confirmed it doesn't work: http://forum.xda-developers.com/showthread.php?p=31220704#post31220704
I've been around the Android dev community and have been rooting phones / flashing roms for a while now, but I am not adept to the specifics in regards to the s3. I just came over to Verizon in march and prior to that I have always delt with HTC phones on sprint, which obviously are totally different than Samsung. two questions:
1.) I used Beans method to unlock and root with casual. He mentions that the tool flashes an insecure aBoot in order to run the exploit. Since I'm still on the stock rooted rom, would I need to flash a secure aboot? This probably sounds silly but I just don't know if the insecure aBoot is "still there" so to speak.
2.) Same question applies to the bootchain. I've looked around and cannot find the MF1 bootchain anywhere. From my understanding you don't need to do this, but I'd like to.
Again, I apologize as I am previously an HTC man and don't have a very good understanding of Samsung yet.:good:
AZ FadeOut said:
I've been around the Android dev community and have been rooting phones / flashing roms for a while now, but I am not adept to the specifics in regards to the s3. I just came over to Verizon in march and prior to that I have always delt with HTC phones on sprint, which obviously are totally different than Samsung. two questions:
1.) I used Beans method to unlock and root with casual. He mentions that the tool flashes an insecure aBoot in order to run the exploit. Since I'm still on the stock rooted rom, would I need to flash a secure aboot? This probably sounds silly but I just don't know if the insecure aBoot is "still there" so to speak.
2.) Same question applies to the bootchain. I've looked around and cannot find the MF1 bootchain anywhere. From my understanding you don't need to do this, but I'd like to.
Again, I apologize as I am previously an HTC man and don't have a very good understanding of Samsung yet.:good:
Click to expand...
Click to collapse
1. The insecure aboot is needed to root and unlock your phone with the casual method, you can double check you're unlocked with ez unlock v1.2. It should still be applied.
2. The Bootchain is not very important to restore, and I'm not sure if casual automatically changes it back after the process. You can flash the mb1 Bootchain and be close enough or pm darkmenace and request the mf1 Bootchain. Keeping your Bootchain shouldn't give you any issues.
Sent from my SCH-I535 using Tapatalk 2
Introduction
This is the bootloader unlock from ZTE. It was provided to me in private email by a ZTE engineer.
Warning
This package is for the USA version of the Axon 7 Mini (tulip) running 7.1.1 b14 firmware. If you are running any other device or firmware version, it may not work.
Note
After some testing, it appears that the Axon 7 Mini is not locked in any way. In other words, apparently neither this package nor tuliptool's unlock are required to flash custom ROMs. The only apparent advantage to flashing this is to get access to fastboot, which provides a way to flash a custom boot and recovery (among other things).
Flashing Instructions
Place axon_mini_unlock.zip on the root of your sdcard.
Reboot into recovery.
Select "Apply update from SD card".
Select axon_mini_unlock.zip.
Usage Instructions
After the package is flashed, you may boot into the bootloader:
adb reboot bootloader
Once in the bootloader, you will see an on-screen menu. Additionally, you may access the typical fastboot commands:
fastboot oem device-info
fastboot oem unlock
fastboot flash ...
... etc ...
Download
axon_mini_unlock.zip
md5: ea8f1a21c8a46b3045d00f17a37fe359
So, after this is done, I can flash TWRP through fastboot and tuliptool is no longer necessary, correct?
Yes, that is correct.
JoeGatto said:
So, after this is done, I can flash TWRP through fastboot and tuliptool is no longer necessary, correct?
Click to expand...
Click to collapse
This package is for the USA version of the Axon 7 Mini (tulip) running 7.1.1 b14 firmware. If you are running any other device or firmware version, it may not work.
Click to expand...
Click to collapse
Is this something your contact mentioned or something that you believe based on your experience?
Any harm in trying it on verdandi/other versions without any risk of bricking?
After some testing, it appears that the Axon 7 Mini is not locked in any way. In other words, apparently neither this package nor tuliptool are required to flash custom ROMs. The only apparent advantage to flashing this is to get access to fastboot.
Click to expand...
Click to collapse
Any way to confirm this is also the case with other versions as well?
Thanks TDM.... you're going to have a lot of Canadians asking about verdandi as it is quite cheap here at the moment. Better get those questions out of the way early. The source is released, same kernel version as the U.S. one with some small differences with drivers (from what I can see) and I am sure that if people know that custom roms are possible on that version (not bootloader locked forever) it would be appreciated.
trpn111 said:
Is this something your contact mentioned or something that you believe based on your experience?
Any harm in trying it on verdandi/other versions without any risk of bricking?
Any way to confirm this is also the case with other versions as well?
Thanks TDM.... you're going to have a lot of Canadians asking about verdandi as it is quite cheap here at the moment. Better get those questions out of the way early. The source is released, same kernel version as the U.S. one with some small differences with drivers (from what I can see) and I am sure that if people know that custom roms are possible on that version (not bootloader locked forever) it would be appreciated.
Click to expand...
Click to collapse
Yeah...verdandi is stuck on Marshmellow. But since it has different hardware it could brick if this is tried.
The ZTE engineer is USA based, he is not on the China development team (read: probably a support engineer). He said: "I attached the unlock update zip package, please try it. It is based on B14 build."
Sorry, that's all I have to go by for "official" information.
I do not want to be responsible for anyone bricking their device, so I cannot claim that this bootloader will work with anything other than a tulip device running 7.1.1 b14.
If you want to try and report back, I'm sure others will appreciate it. But I can't be responsible for the results.
trpn111 said:
Is this something your contact mentioned or something that you believe based on your experience?
Any harm in trying it on verdandi/other versions without any risk of bricking?
Any way to confirm this is also the case with other versions as well?
Thanks TDM.... you're going to have a lot of Canadians asking about verdandi as it is quite cheap here at the moment. Better get those questions out of the way early. The source is released, same kernel version as the U.S. one with some small differences with drivers (from what I can see) and I am sure that if people know that custom roms are possible on that version (not bootloader locked forever) it would be appreciated.
Click to expand...
Click to collapse
Oh, and here is some more information to help you decide...
The volume key combo to enter EDL is handled by aboot (bootloader, eg. the thing we are flashing). This means even if you aren't currently able to use the key combo, you should be able to use it with the new aboot here. And if you can get to EDL, you can never really brick the device.
The volume key combo is detected very early in the aboot code. Like, first thing after basic platform init. So even if this isn't compatible with your device, it's likely we could restore the old aboot (assuming you back it up first, of course).
I'm convinced that the tulip is not locked based on my investigation today. So I have no idea if this aboot is properly signed. If your device is locked and this aboot is not signed properly, the lower boot loader won't load it. I'm not quite sure if that kicks you into EDL or not.
Not sure if that makes the decision easier or harder...
How did you come to the conclusion that tulip is not locked to begin with? If we don't need tuliptool or this aboot, how can I check verdandi if the device is the same 'locked but not really locked' state?
I will have a read about backing up aboot and see what I come up with concerning getting into edl.
So here's the deal...
I initially assumed the bootloader was locked because... well... it's supposed to be. So I found the place in aboot code where it checks the lock flag in the devinfo partition. I used the firehose to write unlocked to that flag. Then I built TWRP, flashed it and it booted. So I assumed everything was working just as I expected.
Today, I flashed the aboot with fastboot support and ran "fastboot oem device-info". It said that my device was locked. So I went to look and, sure enough, my devinfo partition flag was still set. Hmm, that's odd.
So I wrote locked back to the flag. TWRP still booted. Now things are looking pretty suspicious.
But maybe the new aboot doesn't even support locking? So I flashed the original b14 version of aboot and TWRP still booted.
That's pretty hard evidence that aboot is ignoring the lock flag. I don't know what they did -- whether they just removed the code that reads the lock flag or introduced a bug or what.
This does not necessarily mean that the lower layers are unlocked. That is, the lower boot loader may still required a properly signed aboot. I don't know, and I'm not ready to brick my device trying to find out.
trpn111 said:
How did you come to the conclusion that tulip is not locked to begin with? If we don't need tuliptool or this aboot, how can I check verdandi if the device is the same 'locked but not really locked' state?
I will have a read about backing up aboot and see what I come up with concerning getting into edl.
Click to expand...
Click to collapse
Hmm... Looks like this package incompatible with ZTE/P852A11/tulip.
Got error while trying to flash it by stock recovery. Error message says that it is for A12 version of tulip.
Ah, yes, you have the euro model. See the "calling all mini owners" thread, posts #76 and #77.
maestromony said:
Hmm... Looks like this package incompatible with ZTE/P852A11/tulip.
Got error while trying to flash it by stock recovery. Error message says that it is for A12 version of tulip.
Click to expand...
Click to collapse
i get a message saying "cant update from sd card?"
yeshivabachur said:
i get a message saying "cant update from sd card?"
Click to expand...
Click to collapse
Make sure battery level is at least 30% before applying any update. It's a standard protection feature.
JoeGatto said:
Make sure battery level is at least 30% before applying any update. It's a standard protection feature.
Click to expand...
Click to collapse
My battery was 80%+ mine still said can't update from sdcard
Aries2010 said:
My battery was 80%+ mine still said can't update from sdcard
Click to expand...
Click to collapse
Try turning on the OEM unlock setting in developer settings.
JoeGatto said:
Try turning on the OEM unlock setting in developer settings.
Click to expand...
Click to collapse
Thank you so much that worked I appreciate the it . Now I have one more question I have been searching for a way to root stock rom but I can't find any instructions on it. Could you walk me through it or post a link for me if possible? I have the USA mini 7 with B14 firmware
Aries2010 said:
Thank you so much that worked I appreciate the it . Now I have one more question I have been searching for a way to root stock rom but I can't find any instructions on it. Could you walk me through it or post a link for me if possible? I have the USA mini 7 with B14 firmware
Click to expand...
Click to collapse
Rooting the stock ROM will require that you remove verity, so that the OS won't refuse to boot once you've made any changes to the system partition. You'll need to use tuliptool to flash a new boot image, which you can find in this section of the forum. Then, you could either install TWRP through fastboot or using tuliptool.
JoeGatto said:
Rooting the stock ROM will require that you remove verity, so that the OS won't refuse to boot once you've made any changes to the system partition. You'll need to use tuliptool to flash a new boot image, which you can find in this section of the forum. Then, you could either install TWRP through fastboot or using tuliptool.
Click to expand...
Click to collapse
Thank you sir I appreciate it I shall try it tomorrow.
here's a stupid question.... I have only dealt with Samsung devices so, I have trouble understanding any other kind of process that is not Samsung. If a new update comes out while my device is bootloader unlocked can i update it? or will it brick my device?
The "standard" (not Samsung) method of updating via OTA is to ship:
1. Full images of any firmware partitions (rpm, tz, aboot, etc.)
2. Full image of boot.
3. A delta (patch) to system.
Also note that custom recoveries generally do not work with vendor OTA's.
This means that if you wish to apply an OTA, you must first have stock recovery and a completely pristine, unmodified system partition. The rest doesn't matter.
yeshivabachur said:
here's a stupid question.... I have only dealt with Samsung devices so, I have trouble understanding any other kind of process that is not Samsung. If a new update comes out while my device is bootloader unlocked can i update it? or will it brick my device?
Click to expand...
Click to collapse
I have a A125U that I can't unlock the bootloader of. There's no OEM unlock option in the Developer Options, there's no way to unistall system updates to try the date/time thing to get OEM unlock, nothing else I've tried has worked at all. I even tried flashing A125F firmware to no avail, of course. I was thinking, the BL file is the bootloader, is there a way to flash a bootloader that's already unlocked? Or is that not how this works?
If not, does anyone know how to get OEM unlock to show on the A125U? It's been driving me insane.
Not possible unfortunately
no
LOOOOOOOL
This is the biggest lie I've ever seen in my life!!! of course it,s possible ddd. Everything is possible especially this. Trick to your issue, is just that you have to corssflash to the Canadian firmware on your A125U which is the US model. But that doesn't matter, that's nothing because those 2 phones run on the same hardware so the firmware operates with both. Even the SW_REV value doesn't do anything in that situation. You can take the U models and flash it to W(Canada) but that's useless because then you're locked out of natively unlocking the PBL. Just grab the Canadian firmware and crossflash it via heimdall or patched Odin which is the same thing. Erase old NAND.
Also don't think that stuff like this isn't possible, of course it is. You just have to try harder and harder until you get the result you're stasifed with. There is community with a bunch of us enthusiasts (discord server link is on my profile). Don't be scarred to ask here on xda and there in the server. Also you can dm me for help, I'll help you, don't worry.
Hope I helped, be sure to ask if misunderstood or need more help. Also check out some stuff i wrote on this forum. It's very helpful and interesting.
Stay safe,
Krypton
Attached are pictures of the error messages I'm getting. I've tried everything I come across on these forums, and nothing seems to fix the issue. Does anyone know how to get around this?
eddieofny said:
Attached are pictures of the error messages I'm getting. I've tried everything I come across on these forums, and nothing seems to fix the issue. Does anyone know how to get around this?
Click to expand...
Click to collapse
There should be a PIT file packaged into the AP.tar. You need to extract this and use it in the PIT tab in Odin.
See this guide
V0latyle said:
There should be a PIT file packaged into the AP.tar. You need to extract this and use it in the PIT tab in Odin.
See this guide
Click to expand...
Click to collapse
That's exactly what I did that caused it to throw these error messages
eddieofny said:
That's exactly what I did that caused it to throw these error messages
Click to expand...
Click to collapse
Are you using the correct firmware?
V0latyle said:
Are you using the correct firmware?
Click to expand...
Click to collapse
I guess I should have specified this in the original post. I'm trying to convert it from T-Mobile firmware to carrier unlocked firmware, which is exactly why I was trying to repartition the devices. Right now, it has TMB firmware on it, I'm trying to put XAA firmware on. I'm using the latest version of Patched Odin to try and accomplish that, and to the best of my knowledge, none of the files are corrupt.
eddieofny said:
I guess I should have specified this in the original post. I'm trying to convert it from T-Mobile firmware to carrier unlocked firmware, which is exactly why I was trying to repartition the devices. Right now, it has TMB firmware on it, I'm trying to put XAA firmware on. I'm using the latest version of Patched Odin to try and accomplish that, and to the best of my knowledge, none of the files are corrupt.
Click to expand...
Click to collapse
Ah. Are you following a specific guide that tells you to do this? Carrier unlocking is generally done by the carrier in question. If you're the original owner of the device, contact TMobile and ask them to unlock your phone for use on another network. Your account must be paid off and in good standing to do this.
You can't unlock a phone simply by flashing new firmware, at least not to my knowledge.
A brief search through your post history shows that you already asked the relevant question, so it would appear that you're attempting to do something no one recommended without the knowledge that it will work.
It's better to ask questions before you try to do something you don't really know anything about, because the knowledge and expertise held by many here on XDA can save you a lot of pain. Trying to do things your own way can result in your device becoming no more useful than the average pebble.
As I said above, you cannot carrier unlock a device by flashing different firmware. It is hardware locked to the TMobile network, and to unlock it, the original owner and account holder must contact TMobile for the unlock code.
There are professional methods that can perform an unlock but this is not in the realm of the average user, and those tools are not available here.
V0latyle said:
Ah. Are you following a specific guide that tells you to do this? Carrier unlocking is generally done by the carrier in question. If you're the original owner of the device, contact TMobile and ask them to unlock your phone for use on another network. Your account must be paid off and in good standing to do this.
You can't unlock a phone simply by flashing new firmware, at least not to my knowledge.
Click to expand...
Click to collapse
It's not to carrier unlock it, the phone is already carrier unlocked. But the TMO firmware does not allow for OEM unlocking and comes with a ton of bloatware as well. From all the research I've done, flashing unlocked firmware solves both of those problems
eddieofny said:
It's not to carrier unlock it, the phone is already carrier unlocked. But the TMO firmware does not allow for OEM unlocking and comes with a ton of bloatware as well. From all the research I've done, flashing unlocked firmware solves both of those problems
Click to expand...
Click to collapse
What research where?
Is this a Snapdragon device?
You shouldn't need to repartition your device to flash a different CSC. However, flashing firmware with a different CSC won't enable OEM unlocking.
V0latyle said:
What research where?
Is this a Snapdragon device?
You shouldn't need to repartition your device to flash a different CSC. However, flashing firmware with a different CSC won't enable OEM unlocking.
Click to expand...
Click to collapse
No, it's a MediaTek device. Honestly, I've read so much stuff, I wouldn't be able to remember where. I've read alot from here, as well as Stack Overflow and pretty much anywhere on the internet that looked like it had answers. I came away with the impression that carriers could choose to remove OEM Unlocking from their firmware, but that non-carrier firmware as a general rule of thumb would have that option available. As it stands, I don't have OEM Unlocking in my Developer Options at all
eddieofny said:
No, it's a MediaTek device. Honestly, I've read so much stuff, I wouldn't be able to remember where. I've read alot from here, as well as Stack Overflow and pretty much anywhere on the internet that looked like it had answers. I came away with the impression that carriers could choose to remove OEM Unlocking from their firmware, but that non-carrier firmware as a general rule of thumb would have that option available. As it stands, I don't have OEM Unlocking in my Developer Options at all
Click to expand...
Click to collapse
Well...Yes and no.
There are a couple of properties that determine whether OEM Unlocking is visible: ro.oem_unlock_supported which is set at build time, and sys.oem_unlock_allowed
The first one is generally set at build time. The second one can be dynamic, like if the OEM/carrier wants the device to normally be unlockable, but wants E.T. to phone home to determine whether it should be allowed.
It's hard to say what the circumstance is here. But, in most cases, simply flashing different firmware will not permit unlocking the bootloader; in fact, a locked bootloader will generally prevent flashing anything but the firmware intended for that specific device.