Database Users

will i recieve OTA?

Hi, i just rooted my nexus 7, with custom recovery and unlocked bootloader. Just wanna know will i still recieve ota from google for my tablet? of i would have to relock my bootloader and flashh the stock recovery before i can recieve the ota...?

Since you have flashed a custom recovery, you'll have to flash back the original recovery in order to do a ota.
It doesn't matter if your rooted or if you have a unlocked boot loader.
BTW, You will loose root if you don't use ota keeper from the market.
Sent from my Xperia Arc

mazlano27 said:
Hi, i just rooted my nexus 7, with custom recovery and unlocked bootloader. Just wanna know will i still recieve ota from google for my tablet? of i would have to relock my bootloader and flashh the stock recovery before i can recieve the ota...?
Click to expand...
Click to collapse
First question is why would you care? Its not like there are OTA's happening all the time. there has been basically one OTA since the device first came out and most people got it as soon as they started to use their device.
Second, if you have a custom recovery, that will stop it from working.
IF you put the recovery back, the question of if you will lose Root or not really depends on the OTA type. Most OTA's are incremental, meaning they only contain the changes of the system, not the whole system. If it is an incremental, unless there is something in the OTA that seeks out and removes root, it most likely will not affect it. However, if you have made any real changes to the system (removed system programs) the OTA may fail to run as it assumes everything in a normal system is there.
IF the OTA is a full system update like what the Kindle Fire was doing for a long time, it will flush the complete system area and load a new one, that effectively removes root since when it is done, it is no longer physically there. OTA Root keeper won't help you in those cases since the entire system area get wiped. Getting root back is trivial though as hard as it was originally.
I'd tend to think that the OTA's will be incremental... and I see little need or desire by Google to be hunting down root since it is a Nexus device and it is designed to allow for that. Its not like it is a phone like device where the Wireless operator is having a cow as to whether or not you gained access... its supposed to have that kind of access.
However, it really doesn't matter. When the next OTA comes out, there will be a number of devs which will take it apart and release an update you can use with the recovery you currently have and root and will keep root just fine. these typically get released within hours that someone notices a new OTA in the wild and sometimes you can get it before you actually even have a chance to get the real OTA over the wire.
So not a real big deal. I'd just stay where you are and when one comes out watch to see what gets released to mimic it.
Note changing the state of the bootloader will wipe your device. Unlocking will wipe it and locking it will wipe it. You are best off, unlocking it and just leaving it that way.

Verizon 4.4.2 OTA discussion for LOCKED bootloaders

The other thread was just too messy with too much cross information.
So, here's the quick and dirty. If you're on 4.4. and rooted you can upgrade to 4.4.2 after disabling Gravity Box and ANY mods (wifi tether, etc) and you will keep root but you will lose the ability to write to the system. This effectively makes root useless.
It's unlikely 4.4.2 will ever be rooted, but there is some sliver of hope that a solution will be found (likely involving SBF) that allows you to retain root and /system RW but it can't be taken for granted.
There's lots of other info, but this thread is just designed to separate out the discussions.

Just to add..
Inside the OTA is a manifest file which which contains check sums for files which need to exist on your phone. If the expected files are not on your phone, or the checksums of the files don't match the manifest, the OTA will fail. Hence why you need to undo some of the "hacks" and "mods"
Addtioinally to install the OTA, you need to have stock recovery on your phone. If its not on there, the OTA will either fail, or worse, put you in a boot loop! (erasing your phone's cache can help you out of the loop... mfastboot erase cache )
Once you are on 4.4.2, you can not downgrade your rom to 4.4 or older!! Trying to downgrade can/will result in bricking your device.

Can anyone comment on the "This will be permanent" warning from when rooting with SlapMyMoto/MotoWPNoMo?
I'm trying to get all my ducks in a row before I update to 4.4.2 and lose a functional root.
I'm thinking of reflashing /sys or restoring tether hack, and accepting OTA.

evandena said:
Can anyone comment on the "This will be permanent" warning from when rooting with SlapMyMoto/MotoWPNoMo?
I'm trying to get all my ducks in a row before I update to 4.4.2 and lose a functional root.
I'm thinking of reflashing /sys or restoring tether hack, and accepting OTA.
Click to expand...
Click to collapse
When MotoWPNoMo came its disabling write protection was "permanent" (it survived flashing between the roms which were out at that time) however it does NOT survive the 4.4.2 OTA.
The statement in the initial post... "keep root but you will lose the ability to write to the system. This effectively makes root useless. " is 100% accurate for those with locked bootloaders.

I got the notification this morning when I woke up that the OTA was downloaded and ready to install. It was a persistent notification, and I didn't want it there. I long pressed on it and went to app info, which was MotoOTA. I force stopped it, which did remove the notification, but it came back immediately.
I then unchecked the "show notifications" box and it was gone. I'm not really a fan of freezing apps with TiBu or anything like that, so this worked for me. I don't really care to update unless I can keep root and have write protection off.
I didn't see anything in the changelog that really implied that I'm missing much by not upgrading, for now at least. I decided to get the Moto Maker edition because I valued the customization more than then unlocked bootloader. The phone works great and does everything I need it to right now, so I have no desire to upgrade and lose root yet.
One question though, I read somewhere before that booting through recovery disables write protection, and allows you to install Xposed and other root stuff. I assume that write protect being off only lasts until the next reboot? And then you'd need to boot through recovery again, and possibly apply things through Xposed each time? Or is it just for initial setup?

fury683 said:
One question though, I read somewhere before that booting through recovery disables write protection, and allows you to install Xposed and other root stuff. I assume that write protect being off only lasts until the next reboot? And then you'd need to boot through recovery again, and possibly apply things through Xposed each time? Or is it just for initial setup?
Click to expand...
Click to collapse
You don't have to boot into recovery each time. You do need to soft reboot each time after a hard reboot though for it to stick

evandena said:
Can anyone comment on the "This will be permanent" warning from when rooting with SlapMyMoto/MotoWPNoMo?
I'm trying to get all my ducks in a row before I update to 4.4.2 and lose a functional root.
I'm thinking of reflashing /sys or restoring tether hack, and accepting OTA.
Click to expand...
Click to collapse
Well that didn't work. I'm stuck in a boot loop now. Guess I'll try flashing /sys when I get home.

fury683 said:
...One question though, I read somewhere before that booting through recovery disables write protection, and allows you to install Xposed and other root stuff. I assume that write protect being off only lasts until the next reboot? And then you'd need to boot through recovery again, and possibly apply things through Xposed each time? Or is it just for initial setup?
Click to expand...
Click to collapse
The early root processes (RockMyMoto and SlapMyMoto) replaced stock recovery with a trick that booted the phone with write protect disabled. To take the OTA, you need to put stock recovery back, thus removing this trick.
Later, MotoWPNoMo replaced the trick of booting to a tricked recovery, and allowed Write Protection to be disabled for normal boot too, and allowed stock recovery to be put back on, but this doesn't survive the OTA.
---------- Post added at 05:35 PM ---------- Previous post was at 05:34 PM ----------
evandena said:
Well that didn't work. I'm stuck in a boot loop now. Guess I'll try flashing /sys when I get home.
Click to expand...
Click to collapse
No. Put your phone in bootloader mode... then...
mfastboot erase cache

KidJoe said:
No. Put your phone in bootloader mode... then...
mfastboot erase cache
Click to expand...
Click to collapse
Can that be done from the phone with fastboot, or do I need my computer? I haven't messed with this stuff since November, so I'm a little rusty.

evandena said:
Can that be done from the phone with fastboot, or do I need my computer? I haven't messed with this stuff since November, so I'm a little rusty.
Click to expand...
Click to collapse
Have to enter that command from the PC

Wifi Tether require Write Protection?
I wasn't able to find an answer on this so I'm asking here. The only thing I really use root for on my Moto X is the wifi tether because I still have unlimited data. I am wondering if I can keep root through the OTA and keep using the Wifi Tether app after it reenables write protection. Thanks in advance.

Reserved Name said:
I wasn't able to find an answer on this so I'm asking here. The only thing I really use root for on my Moto X is the wifi tether because I still have unlimited data. I am wondering if I can keep root through the OTA and keep using the Wifi Tether app after it reenables write protection. Thanks in advance.
Click to expand...
Click to collapse
You'll probably have to keep the file on your phone to replace each time you do a hard reboot. Without R/W, your changes won't stick after a boot. Otherwise, I think you can still use the entitlement trick without an issue other than it not sticking.

Reserved Name said:
I wasn't able to find an answer on this so I'm asking here. The only thing I really use root for on my Moto X is the wifi tether because I still have unlimited data. I am wondering if I can keep root through the OTA and keep using the Wifi Tether app after it reenables write protection. Thanks in advance.
Click to expand...
Click to collapse
I'd like to know this too. At this point the only thing I really use root for is Greenify, which no longer requires root, tethering with my unlimited data (VZ), and bypassing the exchange pin requirement.

KidJoe said:
Have to enter that command from the PC
Click to expand...
Click to collapse
I'm having problems getting into recovery. Once I select Recovery from the fastboot menu, it boots straight into normal mode.
*edit* maybe I don't need adb to recognize the phone for fastboot erase cache to work. Playing with it now...
*edit 2* ok, it looks like that stopped my boot loops. Now to figure out why the update didn't work the first time...

CartlandSmith said:
you select recovery by hitting vol up button.
Click to expand...
Click to collapse
Yep, was. It was booting to safe mode when Recovery was selected.

I should clarify, I don't use the entitlement hack I just use the Wifi Tether apk. Just wondering if it requires write protection to be disabled or not. Thanks.

If I take the OTA and have root but no system RW, is it still possible to install Xposed, soft reboot, and it works normally until a hard reboot happens? Or is Xposed completely broken?

Reserved Name said:
I wasn't able to find an answer on this so I'm asking here. The only thing I really use root for on my Moto X is the wifi tether because I still have unlimited data. I am wondering if I can keep root through the OTA and keep using the Wifi Tether app after it reenables write protection. Thanks in advance.
Click to expand...
Click to collapse
You're talking "wifi tether for root" like this -> https://code.google.com/p/android-wifi-tether/
I don't think it will work due to the changes it makes when you start and stop tethering. (It appears to update files in the normally write protected area). Then again, if temp changes can be made after 4.4.2 is installed, it might work.
I think you and I are the only ones who use that app.. most everyone else is using Xposed or the hacked entitlement apk.

evandena said:
I'm having problems getting into recovery. Once I select Recovery from the fastboot menu, it boots straight into normal mode.
*edit* maybe I don't need adb to recognize the phone for fastboot erase cache to work. Playing with it now...
*edit 2* ok, it looks like that stopped my boot loops. Now to figure out why the update didn't work the first time...
Click to expand...
Click to collapse
If it's booting normally when you select recovery, it's because your recovery is missing - probably because you used SlapMyMoto.
You need to restore your recovery... you can boot into fastboot, then write the correct recovery to your phone with fastboot flash recovery recovery.img, where recovery.img is a file pulled out of the SBF package for whatever version you're running.

You guys really should just wait! Even if a new root method isn't discovered, you will be able to flash a stock 4.4.2 ROM or Eclipse's stock-based ROM via Safestrap soon enough. Certainly not worth risking losing root! Patience!
Sent from my Moto X

Would it be plausible to use JTAG to rewrite an unlocked firmware?

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

Wanting to unlock and root but also want Marshmallow asap

Should I wait to unlock and root if I want to get Marshmallow or is there a way to get it unlocked and rooted?

I would think as long as you do not stray from the stock software you would still get the OTA update. I do not think unlocking the bootloader and simply rooting the phone would prevent the OTA but I could be wrong.

campbellc1052 said:
I would think as long as you do not stray from the stock software you would still get the OTA update. I do not think unlocking the bootloader and simply rooting the phone would prevent the OTA but I could be wrong.
Click to expand...
Click to collapse
Would rooting and then updating break something though? I thought I may have read that somewhere on here.

I just looked into it a little bit more and I think as long as you do not flash a non-stock recovery image you should just be able to disable any system modifications such as xposed and unroot and the update would come through. You can probably find more information on this on google or the moto forums.

Im sure the devs will capture the OTA and make a flashable version, that's usually what happens. It usually doesnt take more than a day after the OTA to do it.

My plan is to wait until after Marshmallow is out before unlocking the bootloader if rooting. Since we have a unlock available we don't have to worry about updates breaking exploits so I am in no rush. The phone is pretty amazing even without root. Once Marsh is out I will test drive a bit and go from there. It could take a week before a dev drops the update or it could take hours... you never know.

Hmmmmm well I'm unlocked and rooted with TWRP..
But there is a Back to Stock zip..
So once Marshmallow comes out ,I'll just go back to Stock and take the OTA...

ttkyles said:
Hmmmmm well I'm unlocked and rooted with TWRP..
But there is a Back to Stock zip..
So once Marshmallow comes out ,I'll just go back to Stock and take the OTA...
Click to expand...
Click to collapse
Yeah, if you have already done it I'm sure someone can assist in getting you the files needed. Even if a dev can walk me through I don't mind pulling it for you. Maybe there will be a back to stock using the marshmallow image then just reroot after installing twrp and you are good to go

campbellc1052 said:
I just looked into it a little bit more and I think as long as you do not flash a non-stock recovery image you should just be able to disable any system modifications such as xposed and unroot and the update would come through. You can probably find more information on this on google or the moto forums.
Click to expand...
Click to collapse
Root breaks the ability to take an OTA, even using the supersu unroot feature the OTA will fail. The only way to take an OTA is to flash a fully stock system and recovery.

BladeRunner said:
Root breaks the ability to take an OTA, even using the supersu unroot feature the OTA will fail. The only way to take an OTA is to flash a fully stock system and recovery.
Click to expand...
Click to collapse
From what I understand it's not so much root that affects the ability to take an OTA it is the bootloader flag and recovery image. Also I think that while a new OTA would completely overwrite the system directory, since we can unlock bootloader, you can just re-flash SuperSU without issue.

I have to say that I'm a bit confused because Motorola have stated that unlocking the bootloader won't affect OTA updates here - https://motorola-global-portal.cust...tail/a_id/91999/p/1449,8620/kw/bootloader OTA
Can anyone clear this up for sure? I'd say a custom recovery would definitely affect them but not just unlocking the bootloader.

skttrbrain said:
I have to say that I'm a bit confused because Motorola have stated that unlocking the bootloader won't affect OTA updates here - https://motorola-global-portal.cust...tail/a_id/91999/p/1449,8620/kw/bootloader OTA
Can anyone clear this up for sure? I'd say a custom recovery would definitely affect them but not just unlocking the bootloader.
Click to expand...
Click to collapse
That's right...unlocking the bootloader alone won't stop an OTA. The custom recovery will be the issue. Basically if you're rooted and running TWRP all you have to do is follow the instructions in the Return To Stock thread and you're good to go for an OTA. Its a pretty simple process.

G6 Play: Pie Soak Test

Please mirror.
ui_print("Target: motorola/aljeter/aljeter:9/PPP29.41/b1fe5:user/release-keys");
Download
As far as I know, you must be on the Sept. patch. So, you must downgrade firmware first. It also appears to be for the Aljeter only, so I don't know if it'll work on the Jeter.
I am not responsible for any bricked devices.
1. Downgrade to OPP27.91-143 first.
2. Extract gpt_main0.bin from the ota zip and flash it in fastboot.
fastboot flash partition gpt_main0.bin
3. Reboot to recovery, and apply the OTA update from your sdcard.
4. Let the system restart. It'll take about 10min.

Could anyone verify?

Figures it's for Aljeter. Makes me wonder if Jeter will get it at all.

yes it is for aljeter and is working fine

Spaceminer said:
Please mirror.
ui_print("Target: motorola/aljeter/aljeter:9/PPP29.41/b1fe5:user/release-keys");
Download
As far as I know, you must be on the Sept. patch. So, you must downgrade firmware first. It also appears to be for the Aljeter only, so I don't know if it'll work on the Jeter.
These installation steps need confirmation. I am not responsible for any bricked devices.
1. Downgrade to OPP27.91-143 first.
2. Extract gpt_main0.bin from the ota zip and flash it in fastboot.
fastboot flash partition gpt_main0.bin
3. Reboot to recovery, and apply the OTA update from your sdcard.
4. Let the system restart. It'll take about 10min.
Click to expand...
Click to collapse
Tested and working on G6 Play do Brasil!

Up and running in UK. G6 Play XT1922-2, Carrier: ID Mobile (Carphone Warehouse), retgb.
Can't get root though, Magisk won't install for me in TWRP. Unable to mount storage or OEM. Not that fussed about that though.
Butter smooth, no glitches so far, no random reboots, battery life is great but still under observation.

Eddster3000 said:
Up and running in UK. G6 Play XT1922-2, Carrier: ID Mobile (Carphone Warehouse), retgb.
Can't get root though, Magisk won't install for me in TWRP. Unable to mount storage or OEM. Not that fussed about that though.
Butter smooth, no glitches so far, no random reboots, battery life is great but still under observation.
Click to expand...
Click to collapse
That's a Pie/Magisk problem. Easy fix...
1. Format /data in TWRP using the "yes" option. Then reboot directly back into recovery.
2. Mount /vendor then flash the universal dm-verity disabler by zackptg5.
3. Reboot directly into recovery once more and flash Magisk.
4. Reboot normally, and install the Magisk manager app manually. Done.
(Magisk should disable encryption and verity, but I've never had it work %100 of the time for both. Hence the disabler.)

Spaceminer said:
That's a Pie/Magisk problem. Easy fix...
1. Format /data in TWRP using the "yes" option. Then reboot directly back into recovery.
2. Mount /vendor then flash the universal dm-verity disabler by zackptg5.
3. Reboot directly into recovery once more and flash Magisk.
4. Reboot normally, and install the Magisk manager app manually. Done.
(Magisk should disable encryption and verity, but I've never had it work %100 of the time for both. Hence the disabler.)
Click to expand...
Click to collapse
Thanks @Spaceminer !!!! I'll give it a go. I thought at first that I might need to make some sort of patched boot image and faff about quite a bit but your instructions are clear and straightforward.
I must say I'm impressed with the G6 Play. I had a Nexus 6P and a Pixel both of which died on me from physical and customisation fatigue. I could afford a flagship so got this to see be through and I haven't had one complaint yet.
The handful of Pie features and esthetics have been implemented well by Motorola and battery life is still epic on this device.
Edit: rooted and fully set up how I usually have my daily driver handset. Pie is so tasty!

Eddster3000 said:
Up and running in UK. G6 Play XT1922-2, Carrier: ID Mobile (Carphone Warehouse), retgb.
Can't get root though, Magisk won't install for me in TWRP. Unable to mount storage or OEM. Not that fussed about that though.
Butter smooth, no glitches so far, no random reboots, battery life is great but still under observation.
Click to expand...
Click to collapse
Ta for taking the plunge and testing mate! Was beginning to think we'd never get this thing, glad to know it works on the same model number as I've got
Now to figure out the exact detailed step-by-step to getting this going, considering I'm actually on the November update...

picopi said:
Ta for taking the plunge and testing mate! Was beginning to think we'd never get this thing, glad to know it works on the same model number as I've got
Now to figure out the exact detailed step-by-step to getting this going, considering I'm actually on the November update...
Click to expand...
Click to collapse
Op is a step by step. Literally. Downgrade to Sept = Flash the build specified. Except the bootloader etc.
Flash the gpt.bin from the new build, apply update.

madbat99 said:
Op is a step by step. Literally. Downgrade to Sept = Flash the build specified. Except the bootloader etc.
Flash the gpt.bin from the new build, apply update.
Click to expand...
Click to collapse
Well yeah, I know that much. I meant the extra stuff like unlocking bootloader and downgrading the firmware etc lol. Ta for the extra info, mind.
Extra questions though because despite being having novice experience of doing phone flashing stuff, I've never touched a soak test for official firmware before...but I'm guessing I'll have to move back to Oreo temporarily to get the official Pie update...? Or will it just shift up from this soak test version?

Anyone get this working with the xt1922-7?

Donavonn said:
Anyone get this working with the xt1922-7?
Click to expand...
Click to collapse
No dice! The bootloader won't accept the gpt.bin. I think the recovery partition is the only thing that gets expanded though, so... I think if someone makes a back up of Pie in TWRP, then I can make it work on our phone. My idea is this.
1. Restore a Pie system backup using twrp, including the boot.img.
2. Use fastboot to flash the modem, oem.img, and vendor.img. Basically flash every part that isn't a patch file.
3. Hope that crap works.
I think that, or something similar would make it happen. I'll be the lab rat if someone wants to upload a system backup.

Spaceminer said:
No dice! The bootloader won't accept the gpt.bin. I think the recovery partition is the only thing that gets expanded though, so... I think if someone makes a back up of Pie in TWRP, then I can make it work on our phone. My idea is this.
1. Restore a Pie system backup using twrp, including the boot.img.
2. Use fastboot to flash the modem, oem.img, and vendor.img. Basically flash every part that isn't a patch file.
3. Hope that crap works.
I think that, or something similar would make it happen. I'll be the lab rat if someone wants to upload a system backup.
Click to expand...
Click to collapse
Haha yes! Someone get this guy a backup! Also, if it does work, the UI and everything can be changed to English, right?

Okay quick question, considering it was said "Flash the build specified except bootloader etc."; what is meant by "etc" here? Which parts of the older firmware should I avoid flashing. I know I gotta get in on that sparsechunk action but what about the other stuff like fsg, modem, boot etc? Sorry for asking what's probably a very obvious question but I don't wanna accidentally bugger my phone up trying to get this working

Donavonn said:
Haha yes! Someone get this guy a backup! Also, if it does work, the UI and everything can be changed to English, right?
Click to expand...
Click to collapse
Yes, it should be possible on the first setup. I think if it works, LTE probably won't without an APN edit. That's what happens when I flash xt1922-5 RETUS firmware anyways.

picopi said:
Okay quick question, considering it was said "Flash the build specified except bootloader etc."; what is meant by "etc" here? Which parts of the older firmware should I avoid flashing. I know I gotta get in on that sparsechunk action but what about the other stuff like fsg, modem, boot etc? Sorry for asking what's probably a very obvious question but I don't wanna accidentally bugger my phone up trying to get this working
Click to expand...
Click to collapse
Flash every part of the old firmware that you are able to. The bootloader and gpt.bin usually fail to flash if they are older than your current version. You should still try anyways. If they fail, just continue flashing the next items in line.

Spaceminer said:
Flash every part of the old firmware that you are able to. The bootloader and gpt.bin usually fail to flash if they are older than your current version. You should still try anyways. If they fail, just continue flashing the next items in line.
Click to expand...
Click to collapse
Righto. Just to clarify, I'm gonna need to unlock my bootloader to make this downgrade happen, right?

picopi said:
Righto. Just to clarify, I'm gonna need to unlock my bootloader to make this downgrade happen, right?
Click to expand...
Click to collapse
Official firmware should flash without any issue on a locked bootloader. That's my understanding. I don't know if this is %100 accurate. Every Motorola I've ever had, I unlocked the bootloader immediately. So, I've never had to test this.

Spaceminer said:
Official firmware should flash without any issue on a locked bootloader. That's my understanding. I don't know if this is %100 accurate. Every Motorola I've ever had, I unlocked the bootloader immediately. So, I've never had to test this.
Click to expand...
Click to collapse
Righto. In that case I'll report back with my findings, but yeah I'd imagine it should work fine as well. We'll see, fingers crossed.