Related
I see it mentioned a few times but what on the phone prevents say 4.4.2 from being installed after the upgrade to 4.4.3?
Because the partion table and bootloader are different and can't be downgraded at all.
Or, you can downgrade... But brick your device after, even later.
Anyone who knows anything about the moto x will tell you just don't. ?
I find that odd. I wonder what the purpose is for doing that.
There is no way to just re-write those sections? Even on a Dev Edition?
knitler said:
I find that odd. I wonder what the purpose is for doing that.
There is no way to just re-write those sections? Even on a Dev Edition?
Click to expand...
Click to collapse
Security!
Look at the whole Windows/AntiVirus industry.
All because Microsoft wanted unsecure compatibility with the old OS.
Saving software dev time making things work.
knitler said:
I find that odd. I wonder what the purpose is for doing that.
There is no way to just re-write those sections? Even on a Dev Edition?
Click to expand...
Click to collapse
No, the Dev edition is no different. All the same "rules" apply.
The Dev edition is the same as any other.... It just keeps is warranty if you unlock it.
aviwdoowks said:
Security!
Look at the whole Windows/AntiVirus industry.
All because Microsoft wanted unsecure compatibility with the old OS.
Saving software dev time making things work.
Click to expand...
Click to collapse
I'm kind of not buying this for a second?
How about linux, which is often pointed to for its security... And you can upgrade, down grade, switch out every component for newer/older/different, switch kernels, upgrade kernels, downgrade kernels... hell change out kernels with out even rebooting.
Really not buying it has anything with security.
KJ said:
Or, you can downgrade... But brick your device after, even later.
Anyone who knows anything about the moto x will tell you just don't. ?
Click to expand...
Click to collapse
I think we understand that, I mean if the OP didn't he wouldn't have the question of "why not?". Its not I think it might be a good idea... We are just trying to understand the situation because it seems unique, and so we were hoping someone who knows a lot about
AGISCI said:
Because the partion table and bootloader are different and can't be downgraded at all.
Click to expand...
Click to collapse
This is the most I have heard so far, and I have heard it once or twice... But can't the recovery image include information on the partition table?
I realize the way it is, but was curious on some more technical information explaining it...
scryan said:
I'm kind of not buying this for a second?
How about linux, which is often pointed to for its security... And you can upgrade, down grade, switch out every component for newer/older/different, switch kernels, upgrade kernels, downgrade kernels... hell change out kernels with out even rebooting.
Really not buying it has anything with security.
I think we understand that, I mean if the OP didn't he wouldn't have the question of "why not?". Its not I think it might be a good idea... We are just trying to understand the situation because it seems unique, and so we were hoping someone who knows a lot about
This is the most I have heard so far, and I have heard it once or twice... But can't the recovery image include information on the partition table?
I realize the way it is, but was curious on some more technical information explaining it...
Click to expand...
Click to collapse
It is security. Specifically the SECURED BOOTLOADER. Don't confuse secured with locked. Yes, you can unlock your bootloader, but it is still secured.
Read up on "TrustZone" and see why it is important, and why the OEMs would not want you to be able to downgrade. You can "buy" or "not buy" whatever you want....
I really don't get the linux reference. We are talking about a bootloader, not linux in general. That's beyond the fact that any smart linux user would almost never have any reason at all to downgrade. Think about the heartbleed vuln that was discovered recently. Why on god's green earth would you want to downgrade openssl back to a version that is vulnerable??
The early (4.2.2 & 4.4) bootloader (motoboot.img) was vulnerable to an exploit that allowed us to disable write protection. The updated bootloader (4.4.2+) is patched. You *CAN NOT* downgrade back to the vulnerable version.
^Does that not have *everything* to do with security??
scryan said:
I'm kind of not buying this for a second?
How about linux, which is often pointed to for its security... And you can upgrade, down grade, switch out every component for newer/older/different, switch kernels, upgrade kernels, downgrade kernels... hell change out kernels with out even rebooting.
Really not buying it has anything with security.
I think we understand that, I mean if the OP didn't he wouldn't have the question of "why not?". Its not I think it might be a good idea... We are just trying to understand the situation because it seems unique, and so we were hoping someone who knows a lot about
This is the most I have heard so far, and I have heard it once or twice... But can't the recovery image include information on the partition table?
I realize the way it is, but was curious on some more technical information explaining it...
Click to expand...
Click to collapse
Because even though the patition file and bootloader are included in the archive, they fail to flash because they have a lower version than what is installed.
AGISCI said:
Because even though the patition file and bootloader are included in the archive, they fail to flash because they have a lower version than what is installed.
Click to expand...
Click to collapse
Can't just fake the version number?
No, it's not possible.
samwathegreat said:
I really don't get the linux reference. We are talking about a bootloader, not linux in general. That's beyond the fact that any smart linux user would almost never have any reason at all to downgrade. Think about the heartbleed vuln that was discovered recently. Why on god's green earth would you want to downgrade openssl back to a version that is vulnerable??
Click to expand...
Click to collapse
The linux reference was in direct reply to the quote above it that was making the argument that the PC anti-virus industry as well as the proliferation of malware and viruses is an example of the insecurity that is a result of a computers administrator having the technical ability to downgrade his OS software.
I mention linux because he was using PC OS's as an example, and Linux allows you not only to downgrade... but rewrite the bootloader. Or use a different bootloader. You bootloader can boot securely with UEFI, or you can just use BIOS. All this insecurity, but virtually no viruses, and very few security issues.
Why would you want to downgrade openssl? I wouldn't. I probably wouldn't flash back to an earlier version of android either... I keep my system pretty damn up to date. The point is more that his assertion that MS and Windows proves that being able to downgrade creates inherent security issues doesn't really hold up when you look at other systems that provide even more freedom.
samwathegreat said:
You can "buy" or "not buy" whatever you want....
Click to expand...
Click to collapse
I know, and that is why I want to understand what it is I would be buying.
AGISCI said:
Because even though the patition file and bootloader are included in the archive, they fail to flash because they have a lower version than what is installed.
Click to expand...
Click to collapse
I guess this is the part that we are not understanding. Perhaps because I don't understand enough and have not looked through decompressed recovery images enough... but basically the issue is that Motorola is bricking the device, rather then letting it be downgraded to an potentially insecure image. I am guessing then this is a soft brick?
Does recovery not have the ability to re-write the partition table though? Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
I guess then that is where the trust zone comes in...
scryan said:
The linux reference was in direct reply to the quote above it that was making the argument that the PC anti-virus industry as well as the proliferation of malware and viruses is an example of the insecurity that is a result of a computers administrator having the technical ability to downgrade his OS software.
I mention linux because he was using PC OS's as an example, and Linux allows you not only to downgrade... but rewrite the bootloader. Or use a different bootloader. You bootloader can boot securely with UEFI, or you can just use BIOS. All this insecurity, but virtually no viruses, and very few security issues.
Why would you want to downgrade openssl? I wouldn't. I probably wouldn't flash back to an earlier version of android either... I keep my system pretty damn up to date. The point is more that his assertion that MS and Windows proves that being able to downgrade creates inherent security issues doesn't really hold up when you look at other systems that provide even more freedom.
I know, and that is why I want to understand what it is I would be buying.
I guess this is the part that we are not understanding. Perhaps because I don't understand enough and have not looked through decompressed recovery images enough... but basically the issue is that Motorola is bricking the device, rather then letting it be downgraded to an potentially insecure image. I am guessing then this is a soft brick?
Does recovery not have the ability to re-write the partition table though? Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
I guess then that is where the trust zone comes in...
Click to expand...
Click to collapse
The custom recoveries don't flash gpt.bin nor motoboot.img so using a custom recovery it's impossible to correctly flash a Moto X. You MUST use stock recovery with a Moto X. The problem isn't that it causes a brick by flashing an old version. The problem is that a brick happens the next time you do an OTA update. When the OTA update occurs there is a mismatched partion table and bootloader, so it ends up causing a brick.
The developer edition and the standard moto x are 100% identical. They only difference is that you don't void the warranty when you unlock the bootloader on the dev edition, however with the non dev edition your warranty is voided. So the same problem with the partition table and the bootloader ALSO apply to the developer edition as well.
AGISCI said:
The custom recoveries don't flash gpt.bin nor motoboot.img so using a custom recovery it's impossible to correctly flash a Moto X. You MUST use stock recovery with a Moto X. The problem isn't that it causes a brick by flashing an old version. The problem is that a brick happens the next time you do an OTA update. When the OTA update occurs there is a mismatched partion table and bootloader, so it ends up causing a brick.
The developer edition and the standard moto x are 100% identical. They only difference is that you don't void the warranty when you unlock the bootloader on the dev edition, however with the non dev edition your warranty is voided. So the same problem with the partition table and the bootloader ALSO apply to the developer edition as well.
Click to expand...
Click to collapse
Well said :good:
Still the answer is security.
So upgrade as Moto intended & do not downgrade!
---------- Post added at 07:37 PM ---------- Previous post was at 07:30 PM ----------
scryan said:
Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
Click to expand...
Click to collapse
Our recovery devs never restore such partitions or boot loader elements.
scryan said:
The linux reference was in direct reply to the quote above it that was making the argument that the PC anti-virus industry as well as the proliferation of malware and viruses is an example of the insecurity that is a result of a computers administrator having the technical ability to downgrade his OS software.
I mention linux because he was using PC OS's as an example, and Linux allows you not only to downgrade... but rewrite the bootloader. Or use a different bootloader. You bootloader can boot securely with UEFI, or you can just use BIOS. All this insecurity, but virtually no viruses, and very few security issues.
Why would you want to downgrade openssl? I wouldn't. I probably wouldn't flash back to an earlier version of android either... I keep my system pretty damn up to date. The point is more that his assertion that MS and Windows proves that being able to downgrade creates inherent security issues doesn't really hold up when you look at other systems that provide even more freedom.
I know, and that is why I want to understand what it is I would be buying.
I guess this is the part that we are not understanding. Perhaps because I don't understand enough and have not looked through decompressed recovery images enough... but basically the issue is that Motorola is bricking the device, rather then letting it be downgraded to an potentially insecure image. I am guessing then this is a soft brick?
Does recovery not have the ability to re-write the partition table though? Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
I guess then that is where the trust zone comes in...
Click to expand...
Click to collapse
Smh I normally don't chime into these threads but I had to, you can't downgrade the bootloader because of security/compatibility plan and simple. It's the same concept as why you can't downgrade most PC's bios, if there is a flaw found in the system as a whole, then they don't want you to downgrade to that version. A lot of the times when people brick their device trying to downgrade is because it will flash, but because an efuse was blown when it was upgraded the downgraded version will not boot. Yes the recovery can technically rewrite those partitions but again because the efuse was blown it will not boot. Also yes being able to downgrade on any system Windows, Linux, Unix, IOS, Xbox, PS, etc are causes to security issues. If you can downgrade a system to a vulnerable version, it is then by definition less secure, no matter how you try to spin it. Take the futex vulnerability which affected most linux kernels from the past 5 years, so why would any desktop linux user ever want to downgrade to a vulnerable kernel? They wouldn't but if the end user isn't knowledgeable of the vulnerability they wouldn't know that downgrading makes them vulnerable. So since phones are used by so many people who are not knowledgeable of vulnerabilities, why would you want to give them the opportunity to downgrade themselves to a vulnerable OS?
Appreciate the info given... I don't want to downgrade, I am not trying to downgrade, I understand why its a bad idea, ect...
My view point was more questioning the insistence that it being technically possible to downgrade creates a security flaw on a machine that is kept up to date by a responsible individual. Unless we are trying to speak more abstractly about that fact that given someone the opportunity to make a mistake makes it more likely for one to occur, I don't think that security threat exists until you actually use that ability to downgrade to something with a flaw.
I guess then it comes down to personal viewpoint of do I want my phone to brick it self to protect me from myself and like sam said, you choose to go elsewhere... But then that is somewhat what I am trying to figure out. Even though its not something I would probably ever have to deal with, I don't like the idea... But "bricking" can be such a vague term with manufacturer specific recovery tools and "different levels of bricking".
Just trying to understand how what and when actually happens. I probably need to read some more of the recovery threads, and I have been looking through old threads here while considering VZ dev moto X and waiting for the x + 1 announcement, but I figured I would jump on the thread while it was here.
I understand keeping it simple because its generally a bad idea all around, and its just best not to confuse things... but its been hard to find deeper discussion or information then the general warnings. A bit of a better picture from this thread though.
aviwdoowks said:
Still the answer is security.
So upgrade as Moto intended & do not downgrade!
---------- Post added at 07:37 PM ---------- Previous post was at 07:30 PM ----------
Our recovery devs never restore such partitions or boot loader elements.
Click to expand...
Click to collapse
By "Our recovery devs" do you mean the ones doing the moto specific stuff? Do you know if this Is typical of the custom recoveries for other devices?
@scryan
I know far less then other posters, but yes android recoveries are all very similar in that regard.
scryan said:
Appreciate the info given... I don't want to downgrade, I am not trying to downgrade, I understand why its a bad idea, ect...
My view point was more questioning the insistence that it being technically possible to downgrade creates a security flaw on a machine that is kept up to date by a responsible individual. Unless we are trying to speak more abstractly about that fact that given someone the opportunity to make a mistake makes it more likely for one to occur, I don't think that security threat exists until you actually use that ability to downgrade to something with a flaw.
I guess then it comes down to personal viewpoint of do I want my phone to brick it self to protect me from myself and like sam said, you choose to go elsewhere... But then that is somewhat what I am trying to figure out. Even though its not something I would probably ever have to deal with, I don't like the idea... But "bricking" can be such a vague term with manufacturer specific recovery tools and "different levels of bricking".
Just trying to understand how what and when actually happens. I probably need to read some more of the recovery threads, and I have been looking through old threads here while considering VZ dev moto X and waiting for the x + 1 announcement, but I figured I would jump on the thread while it was here.
I understand keeping it simple because its generally a bad idea all around, and its just best not to confuse things... but its been hard to find deeper discussion or information then the general warnings. A bit of a better picture from this thread though.
Click to expand...
Click to collapse
The thing is you keep looking at it from a PC point of view, where you basically have full control over the software and hardware. Phones have much tighter restrictions on them from carriers, fcc, etc they're not personal computers. So the reason they make it where you can't downgrade the bootloader is because that's what controls the restriction on downgrading any other partition on the device.
So with the Moto X's 4.4.4 update they probably blew an efuse, so users with a locked device can't downgrade. This is done because with locked devices they can only flash signed kernels, so by blowing the efuse they can't downgrade to the vulnerable 4.4.2 and below kernel even though it is signed correctly. This is because lets say a malicious app was able to get on a device that had the ability to downgrade say back to 4.2.2. That app could flash the older vulnerable signed kernel to the recovery partition, to disable write protection gain more control over the phone etc, without the users knowledge. Now that is a stretch and probably will never happen but that doesn't mean the threat isn't there, and hackers are very creative at deploying malicious attacks. So by updating the bootloader and blowing an efuse the older vulnerable kernels can't be flashed. Now this is all negated if you're unlocked of course, but if you don't want to ever worry about this issue don't update your bootloader. This is not recommended but I've mentioned it several times on this forum I haven't updated my X's bootloader since I bought it, it's still running the factory 4.2.2 bootloader, running 4.4.4 with no problem.
The other thing you're missing is we're technically not supposed to have the ability to restore our phones, except for the developer edition of course. The fastboot restore files are leaked not released to the public, they are designed for use when phones are returned to be refurbished. So they don't want the phones that are being refurbished to be flashed back to an older version, they want it to be refurbished and the latest software version flashed to it.
iKrYpToNiTe said:
The other thing you're missing is we're technically not supposed to have the ability to restore our phones, except for the developer edition of course. The fastboot restore files are leaked not released to the public, they are designed for use when phones are returned to be refurbished. So they don't want the phones that are being refurbished to be flashed back to an older version, they want it to be refurbished and the latest software version flashed to it.
Click to expand...
Click to collapse
A bit selfish, and perhaps lazy of me but I am only really here talking about the developer version, I just haven't bothered to write the full "verizon developer edition " every time (most of this is research for next phone, which will be developer handset)... To me, obviously a locked phone is going to have weird restrictions and hacked together paths to getting things done, your not supposed to have admin rights...(yeah, maybe I do look at it too much as a computer. Mostly because I am annoyed the differences seem intentionally imposed). But when I pay outright for a device so that I can own it and have full administrative control... anyways, thats a different more philosophical discussion. The point is I have been talking about an unlocked device using third party software where possible.
Either way, appreciate the reply. I have a better understanding of the issue... Though coming from an S4 it still seems weird that MDK*/developer phones don't seem to have the same issues/warnings. It would seem however that the difference may be that MDK/dev owners only use kernels/roms prepared for their devices and do not update the bootloader. I suppose if more people in the Moto X community were worried about maintaining the ability to downgrade an unlocked device it would be technically possible to upgrade in a way that could be easily reversed, similar to the S4.
(*MDK was the first VZ S4 firmware, and the only one that has a released exploit to allow for a full custom recover. Later locked firmwares must rely on safestrap)
Ok, so I have this nearly new Z3+/Z4 (E6553 single SIM) and I'm looking to do some experimentation. I'm not quite that familiar with Sony smartphones (this is my first) while I come from a background of owning dozens of Samsung, LG, Motorola, and other brands. My main question is this:
I've already requested the bootloader unlock code and got it (haven't actually used it yet so the phone is still "clean" at the moment), but I did use the Sony software to do a full flash of the clean latest firmware (185, Android 6.) and it works great but I'm itching to do some playing around with it and see what's possible.
If I unlock the bootloader does that mean - on this particular device - that I can (if I can locate the firmware) roll it all the way back to the shipping firmware which I believe is Android 5.0.2 with build number 28.0.A.6.8) without any hassles or major issues or, is there something going on with the bootloader (like other devices) that once upgraded to a specific version of bootloader you're blocked from that kind of a rollback?
Also, while I've never compiled firmware or a ROM myself over the past two decades, I'm thinking about giving it a go with this Xperia device because Sony provides all the info needed, at least I think they do. It would be an interesting use of my time to learn something new but the question about that is mainly this:
It says it's AOSP which should be the pure untouched Android experience but then I see Sony has some binaries they have posted so I'm wondering if those are "the bloatware" and can they be dismissed and not used or are those binary files necessary because they're what allows AOSP to run properly with hardware support on the Z3+/Z4 as one might expect?
And of course last question: knowing I can relock the bootloader (fastboot oem lock, probably, will have to look into that) I presume I'd be able to use that Sony tool to get it back to the latest build doing the repair option if necessary, right?
If anyone can offer any suggestions or feedback it would be greatly appreciated, thanks.
Have fun, always...
br0adband said:
Ok, so I have this nearly new Z3+/Z4 (E6553 single SIM) and I'm looking to do some experimentation. I'm not quite that familiar with Sony smartphones (this is my first) while I come from a background of owning dozens of Samsung, LG, Motorola, and other brands. My main question is this:
I've already requested the bootloader unlock code and got it (haven't actually used it yet so the phone is still "clean" at the moment), but I did use the Sony software to do a full flash of the clean latest firmware (185, Android 6.) and it works great but I'm itching to do some playing around with it and see what's possible.
If I unlock the bootloader does that mean - on this particular device - that I can (if I can locate the firmware) roll it all the way back to the shipping firmware which I believe is Android 5.0.2 with build number 28.0.A.6.8) without any hassles or major issues or, is there something going on with the bootloader (like other devices) that once upgraded to a specific version of bootloader you're blocked from that kind of a rollback?
Also, while I've never compiled firmware or a ROM myself over the past two decades, I'm thinking about giving it a go with this Xperia device because Sony provides all the info needed, at least I think they do. It would be an interesting use of my time to learn something new but the question about that is mainly this:
It says it's AOSP which should be the pure untouched Android experience but then I see Sony has some binaries they have posted so I'm wondering if those are "the bloatware" and can they be dismissed and not used or are those binary files necessary because they're what allows AOSP to run properly with hardware support on the Z3+/Z4 as one might expect?
And of course last question: knowing I can relock the bootloader (fastboot oem lock, probably, will have to look into that) I presume I'd be able to use that Sony tool to get it back to the latest build doing the repair option if necessary, right?
If anyone can offer any suggestions or feedback it would be greatly appreciated, thanks.
Have fun, always...
Click to expand...
Click to collapse
1- In 99% percent of cases, which includes this phone, Sony does not have a mechanism that blocks a roll back of the firmware. Of course Sony would officially tell you that once you upgrade you cannot downgrade but they (and everyone else) knows that is not true. You just need to find what's known as an ftf file for your firmware of choice and use the unofficial flashtool (not Sony's) to flash it on your device. It is important for you to know that the bootloader DOES NOT have to be unlocked for flashing Sony's unmodified stock firmware.
2- Xperia firmware is not fully AOSP but it is as close as you can get to it. There is no bloat in Sony's code and even if you consider some of it bloat they are normally removable. There are certain hardware and software provisions specific to Sony (which honestly a lot of people, myself included, find useful) such as the stamina mode, which you do not have in AOSP. So if you want to do your own ROM, start with Sony's code.
3- Unlocking bootloader is irreversible in some sense. If you decide to do it, I suggest you read this post carefully in advance: http://forum.xda-developers.com/xperia-z4/general/guide-safe-bootloader-unlock-restore-t3386915
najoor said:
1- In 99% percent of cases, which includes this phone, Sony does not have a mechanism that blocks a roll back of the firmware. Of course Sony would officially tell you that once you upgrade you cannot downgrade but they (and everyone else) knows that is not true. You just need to find what's known as an ftf file for your firmware of choice and use the unofficial flashtool (not Sony's) to flash it on your device. It is important for you to know that the bootloader DOES NOT have to be unlocked for flashing Sony's unmodified stock firmware.
2- Xperia firmware is not fully AOSP but it is as close as you can get to it. There is no bloat in Sony's code and even if you consider some of it bloat they are normally removable. There are certain hardware and software provisions specific to Sony (which honestly a lot of people, myself included, find useful) such as the stamina mode, which you do not have in AOSP. So if you want to do your own ROM, start with Sony's code.
3- Unlocking bootloader is irreversible in some sense. If you decide to do it, I suggest you read this post carefully in advance: http://forum.xda-developers.com/xperia-z4/general/guide-safe-bootloader-unlock-restore-t3386915
Click to expand...
Click to collapse
Nice Reply + very good.
Thanks for the reply, the information could prove useful to another member in the future, but I sold the Z3+ pretty much the next day, honestly.
Hey so since EMUI 10 hasn't been released yet to Honor Play devices (and won't be released any time soon) I've been looking for every possible way to manually flash a custom rom so I could upgrade myself to Android 10 or anything similiar, but as far as I know it is practically impossible. It always comes back to unlocking the bootloader which is by itself impossible too.
Every information regarding this more than a year old and I can't find new releavnt information.
I'm posting this thread to see if anyone knows of a workaround to this problem because I'm completely in the dark about this.
Is there anyway at all to install a newer EMUI/Android versions on Honor Play, either officiallyor unofficially?
It looks like there isn't and there probably won't be in the future either. There was some kind of manual bootloader unlock by opening the phone, but if I remember correctly you still needed a code. Unfortunately it's like this for any latest huawei phone. Unless huawei changes its mind about modding (narrator: it won't), we don't have many chances at it.
Hey there guys,
I just received my s21 ultra (G998B) and planning to root it. I had a few questions since I’m new to this and wanted some clarifications:
1) If I root the phone can I update it OTA through the settings or do I have to update it by another method? Will I lose root/data/apps if I do that?
2) If I lose root when updating it, can I just root again and be all set? Or do I have to follow another procedure for that?
3) I am planning to debloat a few apps and services that I won’t be using, if I update the system/software will the stuff that I debloated come back and will I have to do the debloat again?
Thank you for all the help.
paul_cherma said:
Hey there guys,
I just received my s21 ultra (G998B) and planning to root it. I had a few questions since I’m new to this and wanted some clarifications:
1) If I root the phone can I update it OTA through the settings or do I have to update it by another method? Will I lose root/data/apps if I do that?
2) If I lose root when updating it, can I just root again and be all set? Or do I have to follow another procedure for that?
3) I am planning to debloat a few apps and services that I won’t be using, if I update the system/software will the stuff that I debloated come back and will I have to do the debloat again?
Thank you for all the help.
Click to expand...
Click to collapse
1- Probably not usually the root or recovery will block OTA updates from installing, even if they download.
2- If you lose root, you can USUALLY re-root assuming the same root method wasnt patched. If it was patched, a new root method (though probably still through magisk) will be needed. If this is the case, its up to the dev to find that method, you might be without root for a while.
3-if you debloat, and receive an OTA, your will probably need to de-bloat again, thought I havent personally had experience with this.
Why are you rooting? Just to de-bloat? If so, root isn't really necessary...
As someone who's been in the rooting stage for many years, i can answer your questions.
1. You can not update your phone through OTA updates after rooting the device, as the device was modified in an unauthorized way. And since you own a galaxy phone, the e-fuse within the motherboard will blow and knox will be permanently blown. You can no longer use samsung pay, google pay, and any other app that uses the safetynet api, even after you unroot the device.
2. You will lose root every time you update. You will need ODIN on your PC in order to properly update your firmware and to re-root your device by following the procedure again that you used to root your device, unless samsung patched the method you used to root your device. You can always check what bootloader version you're on within the firmware. For example, on the galaxy S8, the firmware version is N950U1UES5CRG9. The 5th to last number of the firmware will tell you. In this case, N950U1UES5CRG9 is the 5th bootloader version. Keep this in mind once samsung starts to update your phone often.
3. You will have to debloat again from scratch. In order to fully update your device through ODIN, you need to download the full firmware file containing an AP (Firmware), BL (Bootloader) , CP (Modem), and CSC (Carrier File) and manually flash them.
Do keep in mind, it is possible to soft brick or even hard brick your device, so back up your data frequently if you decide to tinker with your device.
Thank you for the detailed answer. I just updated my software to the latest official one by Samsung (April 1st security patch) but I am not rooted yet. I guess I could live with the fact that I can root the phone now and stay on this software version/security patch until I upgrade, since I would have to go through a lot of hassle to set-up the phone the way I wanted. But the main reason why I want to get the official updates is because of the camera improvements that Samsung does, since the main reason of me getting this phone is the camera. And there are some root-required tweaks that I absolutely need such as Viper, and some xposed tweaks also. I like the Stock ROM of Samsung, it really has come a long way at least imo throughout the years, as I have been a Samsung user since day 1 but:
Would it be a good idea to install a custom ROM then? I am reading the description of a few custom ROMs and it seems like I can “retain everything” by simply dirty flashing the ROM and following the dev’s instructions on how to retain root whenever the developer updates it. Is that a better route to take you think? I can keep my device rooted, and still get the updates through a custom ROM.
paul_cherma said:
Thank you for the detailed answer. I just updated my software to the latest official one by Samsung (April 1st security patch) but I am not rooted yet. I guess I could live with the fact that I can root the phone now and stay on this software version/security patch until I upgrade, since I would have to go through a lot of hassle to set-up the phone the way I wanted. But the main reason why I want to get the official updates is because of the camera improvements that Samsung does, since the main reason of me getting this phone is the camera. And there are some root-required tweaks that I absolutely need such as Viper, and some xposed tweaks also. I like the Stock ROM of Samsung, it really has come a long way at least imo throughout the years, as I have been a Samsung user since day 1 but:
Would it be a good idea to install a custom ROM then? I am reading the description of a few custom ROMs and it seems like I can “retain everything” by simply dirty flashing the ROM and following the dev’s instructions on how to retain root whenever the developer updates it. Is that a better route to take you think? I can keep my device rooted, and still get the updates through a custom ROM.
Click to expand...
Click to collapse
That really varies depending on the custom rom you go for. Usually when you dirty flash a rom, you would need to re root your device, but some (not all) roms are persistent with root after system updates. Do keep in mind if you switch to a custom rom, your system might be more buggy and crash more often. One thing i will say though is that xposed is outdated. The last android version xposed officially supported was either 8 or 9. When it has to come down to certain mods you'd wish to have with root, take that into consideration too, as it might make your device really unstable if it's too outdated or if there's a buggy port available. I've dealt with that issue too many times on my phones.
HighOnLinux said:
That really varies depending on the custom rom you go for. Usually when you dirty flash a rom, you would need to re root your device, but some (not all) roms are persistent with root after system updates. Do keep in mind if you switch to a custom rom, your system might be more buggy and crash more often. One thing i will say though is that xposed is outdated. The last android version xposed officially supported was either 8 or 9. When it has to come down to certain mods you'd wish to have with root, take that into consideration too, as it might make your device really unstable if it's too outdated or if there's a buggy port available. I've dealt with that issue too many times on my phones.
Click to expand...
Click to collapse
if xposed is outdated, what is the new thing the comunity is migrating to? All the privacy, security, and customizability tools available through xposed must go somewhere, right?
Twodordan said:
if xposed is outdated, what is the new thing the comunity is migrating to? All the privacy, security, and customizability tools available through xposed must go somewhere, right?
Click to expand...
Click to collapse
There's buggy ports thats flashable on magisk. While you still can get xposed, it'll be an unofficial version, and more likely to run into issues within your rom and daily use into your device.
HighOnLinux said:
There's buggy ports thats flashable on magisk. While you still can get xposed, it'll be an unofficial version, and more likely to run into issues within your rom and daily use into your device.
Click to expand...
Click to collapse
I mean xprivacy on xposed was the must have killer feature for any android device to turn your device into anything other than a privacy nightmare. If we can't do that any more we are f'd.
[EDIT] Looks like the new version of xprivacy, xprivacyLua is still supported for android 11, with magisk and EdXposed or LSPosed:
[CLOSED][APP][XPOSED][6.0+] XPrivacyLua - Android privacy manager [UNSUPPORTED]
XPrivacyLua Really simple to use privacy manager for Android 6.0 Marshmallow and later (successor of XPrivacy). Revoking Android permissions from apps often let apps crash or malfunction. XPrivacyLua solves this by feeding apps fake data...
forum.xda-developers.com
XPrivacyLua/README.md at master · M66B/XPrivacyLua
Really simple to use privacy manager for Android 6.0 Marshmallow and later - XPrivacyLua/README.md at master · M66B/XPrivacyLua
github.com
Is it possible to downgrade from 13 to 12? I think the upgrade messed up my camera. Or maybe a way to reflash the camera firmware?
If the bootloader wasn't updated you can roll it back.
How can I find out if it was updated? I have a US unlocked phone. Its updated from 11 to 12 and now to 13.
See this thread, different models but the same information applies.
blackhawk said:
See this thread, different models but the same information applies.
Click to expand...
Click to collapse
This is the build I'm on now:
RedCrane3 said:
This is the build I'm on now:
Click to expand...
Click to collapse
Hello good morning
Of course, it can be downgraded, as long as the binary number is the same... example in the image.
The bootloader version is 9 so for you to roll back that build number's 5th digit from the end needs to be the same or higher.
With stock Snapdragon's locked bootloader it's easy to get locked into an OTA upgrade you don't want if it updates the bootloader too. I have two N10+'s, one running on 9, the other 10 (can't be rolled back to 9). That's what they were loaded when bought new. They will likely remain on those versions for their service lives as they are running well. I prefer Pie though.
I could be running Android 11 or 12 but I blew them off mostly because of the scoped storage bs.
The first thing I disable is OTA updates, once bitten twice shy. Had a S4+ that got screwed up by a OTA update that couldn't be rolled back... it sucks.
Thank you guys for helping me with all of this information. I guess I have a decision to make.
I can try to rollback to Android 12 in the hopes that will fix my camera issue, or I can sit tight and hope that a future update will resolve it.
Either way, I'm beginning to regret allowing OTA updates.
I really love the hardware of this phone, especially the screen, but its not important to me to have the latest Android (security updates are important though).
I originnaly submitted the problem to Samsung through their members app and the tech who looked at it said he *thought* it was a hardware issue, but come on, what are the chances that the one camera stops working right after the update to 13 and OneUI 5? I take very good care of my phone and never drop it (certainly didn't recently, after the update), there's not a scratch on it.
I suppose its possible, but it would be an incredible coincidence...
The tech suggested I visit a service center (which for me would be a Best Buy, yikes) or call their support 800 number, but what are they going to be able to do that the tech couldn't?
I just don't know if I can trust their initial assessment - no one knows everything, and plenty of people give up on a problem and pass it off the first trouble they run into. Maybe the tech just wasn't interested in digging deeper? A quote from their answer:
"Chi request is getting timed out. Read wide camera sensor seems to be not responding to requests [...]"
I guess my question is: can a downgrade to 12 even fix the issue?
Should I wait for another update?
Or should i just heave Samsung over the side and try to install a custom ROM?
Thanks again for all your help.
You're welcome.
If the bootloader is locked you can't install a custom rom. This is the case with most newer Snapdragon's including the N10+.
The Samsung Experience center at the best buys can run advanced diagnostics so they might be able to find the issue. They can also roll it back or try a reflash of 13.
blackhawk said:
You're welcome.
If the bootloader is locked you can't install a custom rom. This is the case with most newer Snapdragon's including the N10+.
The Samsung Experience center at the best buys can run advanced diagnostics so they might be able to find the issue. They can also roll it back or try a reflash of 13.
Click to expand...
Click to collapse
Ah, ok, but do you mean that the version I have (unlocked US snapdragon) is not able to unlock the bootloader, or just that I'd need to do that first? I do have experience with custom ROMS; my old moto X4 has seen many different ROMS in it's lifetime, so I do feel comfortable unlocking the bootloader and flashing other ROMS.
RedCrane3 said:
Ah, ok, but do you mean that the version I have (unlocked US snapdragon) is not able to unlock the bootloader, or just that I'd need to do that first? I do have experience with custom ROMS; my old moto X4 has seen many different ROMS in it's lifetime, so I do feel comfortable unlocking the bootloader and flashing other ROMS.
Click to expand...
Click to collapse
That refers to the carrier not bootloader I think. Not sure about your specific model's bootloader.