Related
What would be the difference between these 2 methods of rooting for XPERIA Arc?
I know Gingerbreak is much easier to do than the other one. But, is there any limitations to what Gingerbreak can do compared with the other method ?
Since bootloader is still in locked state, that means those who did it with Gingerbreak still have their warranty valid, right? What about the installation of future custom ROM ? Would the devices rooted with Gingerbreak have no chance to install custom ROM because the bootloader is locked ?
Sorry, I'm pretty much confused atm about rooting the Arc.
My understanding is unlocking the bootloader does not give you root. Even those with unlocked bootloaders must root using either ginger break or the other method.
Having the bootloader unlocked will allow for installing custom roms though, when recovery is sorted. Those of us with locked bootloaders will have to hope for a workaround at a later date.
As for warranties...who knows on this one. SE have allowed the unlocking of bootloaders saying it "may" void warranty. Theres nothing to say rooting will void it. Personally I think the only way you will void it is if you brick it whilst fiddling with it. I think any hardware issues will be sorted regardless. (but thats my opinion, dont take it as gospel)
Rooting is rooting, it doesn't really matter what the mechanics of it are, if it's successful then the outcome is the same.
As for the two methods, yes, GingerBreak seems to be the simplest so for most people there's really no reason not to do that. If it fails and you have a handset you can unlock the bootloader on, then you can always do it the other way if need be.
When it comes to custom ROMs, there's a good chance that having an unlocked bootloader will be a requirement, to begin with at least.
It's possible that someone will find a way to offer custom ROMs for locked bootloaders but it's just more work.
if the buutloader remains unlocked your phone can ALWAYS be repaired through seus, the bootloader needs to be unlocked for the phone to be bricked . also flashing of custom roms may not require the bootloader to be unlocked - as is the case with the x10. as far as i know though the bootloader needs to be unlocked to flash new kernals but there is a workaround that for the time being with the ability to flash the various basebands. my bootloader will remain locked for the timebeing - its a sure failsafe if anything goes wrong
Thanks for the replies everyone.
I had this concept of "If you don't root your phone, you can't install custom ROM" and "If your bootloader is locked, you can't install custom ROM" before I found this Gingerbreak rooting method. (i.e. boot loader unlock -> can root -> can install custom ROM)
But just before it was conflicting because with Gingerbreak root your phone, but it seemed to me that you can't install custom ROM because the bootloader is locked. However they said "If you root your phone you can install custom ROM".
So for this time being, taking out the question whether custom ROM (which no one yet to make it for Arc) can be installed, I think it's safe to say : "Gingerbreak rooting with busybox installed gives you the same capabilities to bootloader unlocking + fastboot flashing", right?
more or less......
x10 was never unlocked bootloader，how many custom ROM out there？
cheers
Sent from my LT15i using XDA Premium App
ArcOnFire said:
"Gingerbreak rooting with busybox installed gives you the same capabilities to bootloader unlocking + fastboot flashing", right?
Click to expand...
Click to collapse
Not exactly. You can't flash custom .imgs via fastboot if you don't unlock the bootloader.
And I don't understand why people think that phone can be totally bricked if you unlock the bootloader...
sorry to say that，unlock bootloader seems waste of wait of time，if gingerbreak works
Sent from my LT15i using XDA Premium App
blagus said:
Not exactly. You can't flash custom .imgs via fastboot if you don't unlock the bootloader.
Click to expand...
Click to collapse
Well... yes, I already thrown that factor out when I asked my question.
But looking at the history, is there any case a custom ROM can be installed on a phone with bootloader still in locked state?
This is AFAIK
SE uses locked bootloaders for three reasons
1- A secure place to put DRM certificates.
2- A secure place to SIM lock the phone
3- A secure way to forbid modifying the software, as the bootloader will require a signed software in order for it to boot it ( If I'm not mistaken this is the problem with X10 unlockable bootloader as it's just hard to sign an image, correct me if I'm wrong ). the signed software thing is meant to be for not bringing bad software that may damage the phone
After SE saw that a lot of peoples want to install custom ROM's into their phones without too much hassle and a lot of them understand the risks of this so they decided to make it possible to unlock the bootloader but they want it to be the right way...
1- First the DRM certificates will be deleted as installing custom ROM's with exposed DRM certificates can bring serious legal problems to SE ( as this will mean the ability to save a digital unprotected copy of a DRM protected media )
2- SIM locked phones are excluded from this bootloader unlocking as this can make it easy to unlock the SIM lock so this will put SE in a bad position between operators..
3- As the main reason for unlocking the bootloader is installing custom ROM's and this is what the community want's SE made a bold statement here that doing so will violate the warranty as SE can't guarantee what a custom ROM may do to the phone...
but x10 has recovery
Sent from my LT15i using XDA App
The Arc isn't the X10.
Boring. This is a first time i use SE phone. I think this is also a last time. I will come back with HTC. There are no custom and no one with cook custom rom for SE device already
justbenice said:
Boring. This is a first time i use SE phone. I think this is also a last time. I will come back with HTC. There are no custom and no one with cook custom rom for SE device already
Click to expand...
Click to collapse
How many time passed from exit of ARC???
justbenice said:
Boring. This is a first time i use SE phone. I think this is also a last time. I will come back with HTC. There are no custom and no one with cook custom rom for SE device already
Click to expand...
Click to collapse
sorry ... I have from only 3 weeks the Arc and already have bootloader unlocked and Root ...
I think you're just a little patience
From what I gather, they can't refuse a warantee repair if it is a hardware fault, not caused by the unlocked software (as it is a problem with their manufacturing, and therefore their fault), but if you mess your phone up with something due to the unlocked bootloader they can (for example, you overheat your CPU with an overclock or something).
chriscpritchard said:
From what I gather, they can't refuse a warantee repair if it is a hardware fault, not caused by the unlocked software (as it is a problem with their manufacturing, and therefore their fault), but if you mess your phone up with something due to the unlocked bootloader they can (for example, you overheat your CPU with an overclock or something).
Click to expand...
Click to collapse
That's what I heard too. As long as you didn't mess with you phone in some way, they can't prove that the hardware fault came from the modified software and should therefore repair your phone nonetheless. I guess that's why they say that unlocking the bootloader MAY void one's warranty.
have rooted thro' gingerbreak - but am am getting frequent random reboots. while calling or recieving. can anyone help me with this.
I just had a quick questions about rooting.
I rooted my phone with motorchopper and things have been working great. Got rid of all the bloatware I didn't need as well as gave my device a quick clean. I've had little to no signs of lag(made in Korea). I'm new to the whole customization route. This is my first smartphone and I couldn't be happier with it
1. I rooted my phone successfully, however, I have heard somewhere else that the device needed to be bootloader unlocked before it is rooted. Now, motochopper, allowed it to find an exploit in the device. Is this, in any way, harmful for the phone if it finds an exploit? Most likely not, just curious. Dumb question
2. Does the device need to be bootloader unlocked before I am able to flash a custom recovery, ROM ect.? If the device turns out to be bootloader unlocked later on and released can I flash custom recoveries, make backups and use most tools successfully through ROM Manager? Or would it be best to do it through Odin and do things manually? Where would I be able to find essential files? Is odin specified for a specific device? Just curious
3.What ROM's would you recommend. Cynogenmod? I just want something that is lightweight, stable and functions well throughout the device. Where would be a good source to find good roms?
4. If the device is already rooted can I just start flashing custom recoveries, ROMs ect? Or would someone need to release an unlocked bootloader? How does unlocking the bootloader work? What are ways to do it? Flashing a file or doing something else. Idk..just curious I may be wrong.
I just want to know some good methods to make sure I don't brick this device. Of course backing up and recovering would do well. I've heard clockworkmod is one of the best custom recoveries you can use.
Thanks, in advance, for you help.
I know that the Verizon bootloader is almost impenetrable as is, but would it be plausible to completely go over the head of the firmware and directly write an image with JTAG that would allow for custom software? If so, would it be possible to use the firmware from another carrier like USC or would it have to be a custom image?
EDIT: summary of the method and everything I have thusfar discovered
So, this method after a bit of evolution, got to the point it basically entailed the following: Using the SD Card debrick method (popularized by the galaxy s3 LTE variants) a modified firmware image would be written to an SD Card, and the phone would boot from that image. The main problem I ran into: it would not let me flash anything that could brick the phone, nor was I able to pull the usb cord at the right moment and try and manually brick it. I was able to flash firmware and stock tars from other variants of the phone (such as the one that runs on T-mobile), but what I found out through that is a couple things:
1. The stock tars seem mostly carrier independent, and I was without any modification able to flash a T-mobile bootloader, system image, and pit file, but within recovery and download mode it would show that because of integrated CSC, it would still change back to the original variant. This could have implications for a very simple method of removing bloat from the phone, but I'm not so sure
2. It must have a very low level method of injecting information and file verification that is not located anywhere on eMMC
The latter led me to research a TON, eventually finding that the most likely culprit is the use of Qualcomm Qfuses, non-volatile pre-set memory located directly on the SoC, to check how the bootloader is signed. They consist of a couple blocks of registers, and definitely aren't readily writable. The trusted base of the entire secure system, the same system that KNOX invokes on other systems, is within a series of Qfuses. From what I have deduced, however, they must be at some software level writable, as although the Knox counter is an e-fuse, the others (such as the warrantee bit) have been both changed upon their void and reverted when brought back to a service center. This must mean that the entire block is possible to modify in both directions, unlike a fuse or breaker; It seems to act more like flash memory than a "fuse." This is very good, mainly because if the service center can change it it means that jtag has not been disabled by those flags, and is enabled in at least some form. What this also means is that without another MAJOR exploit within unfortunately simple, clean code or a leak of several RSA keys from verizon, either current workarounds such as safestrap are the answer for the foreseeable future, or a method of manually changing a simgle Qfuse (the one that controls the "Qualcomm Secureboot" flag) could be used.
What I'm hopefully going to start at some point here is research into finding a way of accessing and changing that Qfuse via JTAG. I have no money for a JTAG box at the moment, so it'll have to wait, but if anyone who already has one wants to use it, hopefully this info helps
P.S. I figured out exactly what T-flash does in odin: it flashes the files that you input into odin to the currently inserted SD Card (or so it seems, I could be wrong but that's what it did for me)
P.P.S. Verizon, I respectfully request that...oh never mind, profanity is definitely frowned upon here
Also, I'm in ongoing discussion with the FCC as to block C violations by Verizon of aspects of the regulations that upon research have not really been argued to any substantial extent, so if that comes to fruition hopefully there'll be simple ODIN flashable patches for this stuff :fingers-crossed:
UPON REFLECTION: if the phone could be bricked, either by very subtly corrupted file or by interrupting a flash at the right moment, then could the debrick image from a tmobile galaxy s5 with an unlocked bootloader be used as not a method of flashing the on-board bootloader but as a kind of external boot, so a permenantly installed SD Card that would be permissive of modified kernels and such but still accepted as a boot device by the phone?
I was wondering something similar. It would be interesting to see if we could do something similar to what we did for the droid x.
tr4nqui1i7y said:
I was wondering something similar. It would be interesting to see if we could do something similar to what we did for the droid x.
Click to expand...
Click to collapse
what was done with the droix x? Did they use a direct JTAG patch?
I just realized something. From reading here: http://forum.gsmhosting.com/vbb/f200/how-fix-samsung-galaxy-s5-sm-g900f-dead-boot-1813266/
It seems to show that the S5 has a "alternative boot upon init fault" method similar to that that allows the galaxy s3 debrick to work (I have a guide I made with details) so would it be possible to somehow corrupt a very important part of the bootloader in an official update (would one or two bits still mess with the signature?), apply that, and have an insecure bootloader on a microsd card in the phone allowing it to boot into that, then use that with odin to flash an insecure bootloader to the s5 itself?
Now I have to ask an interesting question somewhere (since he: http://forum.xda-developers.com/verizon-galaxy-s5/help/g900v-hard-brick-t2914847 seems to have done it): "guys how do I brick my sm-g900v?"
They hijacked the boot init by basically using an alternate boot. It was essentially telling the phone to use a different boot method.
Check out koushs bootstrapper for the droid x and droid 2
Koush, birdman, and apex were the three that I remember the most from the beginning. When I remember who got root first, I'll post here. That or I'll try to get in touch with them.
tr4nqui1i7y said:
They hijacked the boot init by basically using an alternate boot. It was essentially telling the phone to use a different boot method.
Check out koushs bootstrapper for the droid x and droid 2
Koush, birdman, and apex were the three that I remember the most from the beginning. When I remember who got root first, I'll post here. That or I'll try to get in touch with them.
Click to expand...
Click to collapse
I think it might actually be easier
So long as a couple conditions are met for it:
1. The bootloader alone determines if an image is "signed" or not (like when flashed in odin)
2. The same UnBrick exploit from the S3 LTE variants works in some form (secondary storage, fault-triggered boot)
3. It is possible to get it to load a modified bootloader from that secondary boot (this is why number 1 is important)
4. KNOX is completely firmware based, and doesn't have any chip based verification
5. I or someone else actually knows how to modify the bootloader such that it will allow unsigned images (even if not removing it all together, then changing the key to one they publicize so people can sign their rom with it)
If all of these are met, then we might actually have free root! Basically all it would involve would be bricking the device badly enough it boots from secondary storage, have that secondary boot have a "back door" that allows a custom image to be flashed, that allows a bootloader image to be flashed that allows for a signed recovery (signed with that publicly available code) to be flashed without having to deal with safestrap or anything like that. Just full root like on any other phone. Anyone want to offer an opinion? Will this work? I would love to try this out, though I'm a bit unwilling to offer my s5 as a sacrifice just yet as I don't have a JTAG unit on site. I know the bounty is probs gone but I'm ok just getting my bootloader unlocked an' $#*+
The bootloader doesn't need to be bricked, it just needs to be bypassed. If we can find the magic words then we'll be golden.
I'm researching tonight. I'll try tests, hopefully tomorrow. Not sure when I'll be able to have the tone for sure.
An unlock isn't likely. A bypass should be possible though.
Bypassed in what way? I understand the thing with safestrap and such, but that doesn't allow custom kernels or anything, so just modified tw roms which is kinda limiting
tr4nqui1i7y said:
The bootloader doesn't need to be bricked, it just needs to be bypassed. If we can find the magic words then we'll be golden.
I'm researching tonight. I'll try tests, hopefully tomorrow. Not sure when I'll be able to have the tone for sure.
An unlock isn't likely. A bypass should be possible though.
Click to expand...
Click to collapse
Have you found anything yet?
dreamwave said:
Bypassed in what way? I understand the thing with safestrap and such, but that doesn't allow custom kernels or anything, so just modified tw roms which is kinda limiting
Click to expand...
Click to collapse
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
tr4nqui1i7y said:
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
Click to expand...
Click to collapse
safestrap uses root access in a stock rom to create a temporary recovery image that lasts for one boot, but it can be finicky and no way to boot into it if you can't access the rom
dreamwave said:
safestrap uses root access in a stock rom to create a temporary recovery image that lasts for one boot, but it can be finicky and no way to boot into it if you can't access the rom
Click to expand...
Click to collapse
The Droid X bootstrap was used with the same intent. It didn't allow custom kernels either. It didn't allow pure aosp ROMs because of that. It modified a boot file to boot to the custom ROM, rather than the actual ROM. It wasn't a recovery or anything like that. It was in app form and only needed to be applied manually the initial time. Unless you wanted to switch/update your custom ROM.
I'm wondering if safestrap, in conjunction with the oe1 rooted build, the oe1 tar, and the boot vulnerability could lead to a method that would allow a one time "downgrade".
Something along the lines of applying a pre-rooted tar, leaving the phone in a bricked state since the bootloader can't be downgraded, adb pushing safestrap files into place, thus modifying the bootloader to get passed the bricked state, allowing it to boot into the rooted tar that was applied or even booting into a ROM possibly.
^ Is all an uneducated guess. I haven't done enough research to know how viable of an option that would be.
tr4nqui1i7y said:
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
Click to expand...
Click to collapse
that's why I'm hoping the debrick image method will work
tr4nqui1i7y said:
The Droid X bootstrap was used with the same intent. It didn't allow custom kernels either. It didn't allow pure aosp ROMs because of that. It modified a boot file to boot to the custom ROM, rather than the actual ROM. It wasn't a recovery or anything like that. It was in app form and only needed to be applied manually the initial time. Unless you wanted to switch/update your custom ROM.
I'm wondering if safestrap, in conjunction with the oe1 rooted build, the oe1 tar, and the boot vulnerability could lead to a method that would allow a one time "downgrade".
Something along the lines of applying a pre-rooted tar, leaving the phone in a bricked state since the bootloader can't be downgraded, adb pushing safestrap files into place, thus modifying the bootloader to get passed the bricked state, allowing it to boot into the rooted tar that was applied or even booting into a ROM possibly.
^ Is all an uneducated guess. I haven't done enough research to know how viable of an option that would be.
Click to expand...
Click to collapse
so far I've been able to downgrade just fine. Don't do anything with knox and it seems odin can flash back to the original Kitkat rom. Also, safestrap didn't do a thing with the bootloader, it was done during kernel init, right after firmware finishes. If a phone is hard bricked then adb won't work, and what I'm getting at is hard bricking it then using the debrick image thing
dreamwave said:
so far I've been able to downgrade just fine. Don't do anything with knox and it seems odin can flash back to the original Kitkat rom
Click to expand...
Click to collapse
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Hm, I'd be really interested in finding a way to get the downgrade to work properly for users that updated. Perhaps packaging the safestrap into a rooted tar. I'm not sure. There has got to be a possibility. We've got all the pieces, we just need to put them together.
When you say you want to hard brick then debrick... Are you thinking that the bootloader might be ignored when it is in a broken state, allowing an older image to be written?
tr4nqui1i7y said:
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Click to expand...
Click to collapse
I don't know, I got it to go back to when root was still possible to get via an app. I don't see why there's a need to downgrade the bootloader if the debrick image thing works
tr4nqui1i7y said:
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Hm, I'd be really interested in finding a way to get the downgrade to work properly for users that updated. Perhaps packaging the safestrap into a rooted tar. I'm not sure. There has got to be a possibility. We've got all the pieces, we just need to put them together.
When you say you want to hard brick then debrick... Are you thinking that the bootloader might be ignored when it is in a broken state, allowing an older image to be written?
Click to expand...
Click to collapse
Exactly. Safestrap is basically useless for flashing bootloader and stuff as it has no firmware involvement. If the bootloader is the part that determines whether or not it's being upgraded or downgraded then if this works it could be downgraded. If they have a hardware counter that determines it, then a modified new bootloader could be flashed probably but not a previous version.
dreamwave said:
Exactly. Safestrap is basically useless for flashing bootloader and stuff as it has no firmware involvement. If the bootloader is the part that determines whether or not it's being upgraded or downgraded then if this works it could be downgraded. If they have a hardware counter that determines it, then a modified new bootloader could be flashed probably but not a previous version.
Click to expand...
Click to collapse
I am not concerned with fllashing a bootloader. I am only trying to find a way to sneak the old exploit into the updated system via an old flaw.
Old System - Check
Root for old system - Check
init tweak - Check
New bootloader - Check
New system - Check
Rooted new system - Check
Old bootloader vulnerability - Check
New bootloader vuln - Missing
This means we either need to find a way to downgrade again, or find a root method for the new system.
What I am interested in is utilizing the init hack to spoof the old bootloader and allow for the new rooted system to boot for users who have taken updates past OE1.
tr4nqui1i7y said:
I am not concerned with fllashing a bootloader. I am only trying to find a way to sneak the old exploit into the updated system via an old flaw.
Old System - Check
Root for old system - Check
init tweak - Check
New bootloader - Check
New system - Check
Rooted new system - Check
Old bootloader vulnerability - Check
New bootloader vuln - Missing
This means we either need to find a way to downgrade again, or find a root method for the new system.
What I am interested in is utilizing the init hack to spoof the old bootloader and allow for the new rooted system to boot for users who have taken updates past OE1.
Click to expand...
Click to collapse
but that has already been done I think, root on a system with any bootloader so long as a root exploit exists for the OS
That's safestrap. It doesn't allow custom kernels or a full custom recovery though, that's why I'm trying to modify the bootloader
I know there threads that cover some of my questions, but I want to make sure I have everything squared away before I go down path.
I currently have a Verizon Galaxy S4 with 4.4.2. It is rooted and has the MDK boot loader. I want to upgrade to 4.5 and use Magisk (mainly so my son can keep playing Pokemon). I am under the impression that to run Magisk I need a non rooted version of 4.5. Am I correct in this impression? Would a stock 4.5 that is Deodexed work with Magisk? Once I find one I can just flash with TWRP and then install magisk correct?
I have 3 main concerns
Don't want to lose the unlocked bootloader.
Don't want to have to wipe the phone.
Want to make sure I can still remove the OTA update app.
jed.padilla said:
I know there threads that cover some of my questions, but I want to make sure I have everything squared away before I go down path.
I currently have a Verizon Galaxy S4 with 4.4.2. It is rooted and has the MDK boot loader. I want to upgrade to 4.5 and use Magisk (mainly so my son can keep playing Pokemon). I am under the impression that to run Magisk I need a non rooted version of 4.5. Am I correct in this impression? Would a stock 4.5 that is Deodexed work with Magisk? Once I find one I can just flash with TWRP and then install magisk correct?
I have 3 main concerns
Don't want to lose the unlocked bootloader.
Don't want to have to wipe the phone.
Want to make sure I can still remove the OTA update app.
Click to expand...
Click to collapse
Well, first of all, there is no android 4.5 as far as I know.
There is 4.4 and then it jumps to 5.0.
Second, your device does not have an unlocked bootloader. Verizon phones pretty much all have a locked bootloader, and no way to unlock them.
Updating to the latest Android might make rooting impossible.
And since your bootloader is locked, Magisk won't work.
GDReaper said:
Well, first of all, there is no android 4.5 as far as I know.
There is 4.4 and then it jumps to 5.0.
Second, your device does not have an unlocked bootloader. Verizon phones pretty much all have a locked bootloader, and no way to unlock them.
Updating to the latest Android might make rooting impossible.
And since your bootloader is locked, Magisk won't work.
Click to expand...
Click to collapse
I was under the impression that MDK was the only unlocked bootloader Verizon ever had. It was only on the first round of phones.
jed.padilla said:
I was under the impression that MDK was the only unlocked bootloader Verizon ever had. It was only on the first round of phones.
Click to expand...
Click to collapse
I'm pretty sure it is locked. It's just easier exploitable.
But I may be wrong.
Edit: Apparently only the Developer Edition has the unlocked bootloader. The MDK is locked.
GDReaper said:
I'm pretty sure it is locked. It's just easier exploitable.
But I may be wrong.
Edit: Apparently only the Developer Edition has the unlocked bootloader. The MDK is locked.
Click to expand...
Click to collapse
So at this point my options are update the phone to something else with no root so I can continue to play.
Leave my phone rooted and no longer play.
jed.padilla said:
So at this point my options are update the phone to something else with no root so I can continue to play.
Leave my phone rooted and no longer play.
Click to expand...
Click to collapse
There was a way to "hide root", other than Magisk.
But it's a real pain. You'd have to go into recovery and type some terminal commands each time you want to hide root, and then go back into recovery and undo everything once you want to get root back.
GDReaper said:
There was a way to "hide root", other than Magisk.
But it's a real pain. You'd have to go into recovery and type some terminal commands each time you want to hide root, and then go back into recovery and undo everything once you want to get root back.
Click to expand...
Click to collapse
Well that is a big fat meh then. Thanks for the help.
I wish to root my phone(XT1686) but intend to keep the stock ROM(no bootloader unlock).
Is there any advantage in doing so? And will OTA updates be affected?
yourSAS said:
I wish to root my phone(XT1686) but intend to keep the stock ROM(no bootloader unlock).
Is there any advantage in doing so? And will OTA updates be affected?
Click to expand...
Click to collapse
It is not possible to root without unlocking the bootloader on this device...
If you don't have a specific reason to root, don't do it.
And once rooted, you cannot accept any OTA... most likely case if you do it will just fail, worst possible case it bricks (which can happen but is extremely rare).
To answer the question in your title, about the advantages of rooting...
Rooting gives you near full access to your device, and thus the ability to customize it beyond the options provided to you via the default interface. Also, some apps provide additional features on rooted phones. For example, some security programs recommend rooting your device so that it can more forcefully integrate itself with the device to protect against malware, hacking, etc. I tend to install a security package that works better on a rooted device, as well as make use of features that tend to only work on a rooted device, such as folder mounting from the internal SD card to the external one. Also, allows me to access system files that are unavailable otherwise, allowing me to customize certain sounds (or copy them at least).
If you decide you want to root your device, make sure you understand the steps to take BEFORE trying it. That means when you come across a guide on how to do it, make sure you get all the files that will be required and reading through the instructions step by step. If any of the steps sound like it will leave you lost on what to do, then DO NOT do any of it. Also, make sure you read the comments for the guide as well, looking for any mention of issues encountered and consider if you might encounter those issues as well. For example, if it causes issues for devices that use a particular carrier and you use that same carrier, you might want to leave well enough alone. Compare your phone version numbers with what others report having issues with (kernel, baseband, build, etc). Anything that someone has an issue with where their phone somehow matches up with yours in some way, take that as a sign to investigate deeper, so as to avoid having any issues yourself.
For the most part, unless you have a need or desire for a feature/function that requires rooting your device, don't mess with it. I'm not kidding, as one mistake can leave you without a working phone and without any options for returning/replacing it.
Thanks for the replies & warnings.
I'm not a noob so I know the risks of rooting. So maybe I should have rephrased it-
What are the advantages of rooting Moto G5 plus specifically?
Say like in terms of mods and other stuff? Also, is it possible to unroot once rooted- I mean to ask if it's possible to revert the state to factory mode with bootloader locked and stock ROM so that device will be eligible for OTA updates again?
yourSAS said:
Thanks for the replies & warnings.
I'm not a noob so I know the risks of rooting. So maybe I should have rephrased it-
What are the advantages of rooting Moto G5 plus specifically?
Say like in terms of mods and other stuff? Also, is it possible to unroot once rooted- I mean to ask if it's possible to revert the state to factory mode with bootloader locked and stock ROM so that device will be eligible for OTA updates again?
Click to expand...
Click to collapse
Bootloader lock is not relevant to OTA's. You might be able to relock, but the fact it was once unlocked cannot be hidden, it will always be very clear that it was unlocked.
Unrooting is easy, the issue arises undoing what you did with root, undoing them all depends what you changed.
I don't know of any reasons specific to this device to root.
acejavelin said:
Bootloader lock is not relevant to OTA's. You might be able to relock, but the fact it was once unlocked cannot be hidden, it will always be very clear that it was unlocked.
Click to expand...
Click to collapse
If the OEM knows I've unlocked bootloader, why will it push OTAs to my phone even though I've locked bootloader on my end? So isn't bootloader lock status relevant for OTA?
yourSAS said:
If the OEM knows I've unlocked bootloader, why will it push OTAs to my phone even though I've locked bootloader on my end? So isn't bootloader lock status relevant for OTA?
Click to expand...
Click to collapse
No, the status of your bootloader is not relevant... Moto will notify you of an available update and happily attempt to apply it regardless if your bootloader is locked or not.
What matters is if the boot or system partitions is changed, if there is ANY change to those, among other things like if the radio version or recovery versions don't match or the partition table is changed, the update will fail. If you flash any custom recovery it will fail as well.
On this subject I mention a slight con which is that some banking or financial apps might complain to you if they detect root. I have maybe 10 different bank and credit apps installed and all work flawlessly except 1. The Huntington Bank app wont allow me to use fingerprint login but otherwise the app is fully functional like mobile deposits. Just wanted to mention to be aware.