I have several Moto Z Plays here; two are retus and one is reteu. The reteu one is running 7.1.1 (official version, not a soak test, NPN26.118-22) because I downloaded the official update and sideloaded it yesterday. It has the July security patch. I was never a soak tester, either. The retuses are still on 7.0, May security patch (NPN25.137-24.4).
Here's the issue. When I sideload NPN26.118-22 (7.1.1. official) on a retus, I get an error saying "E3002: Package expects build thumbprint of 7.1.1/NPN26.118-22/21:user/release-keys or 7.0/NPN25.137-24.3/4:user/release-keys; this device has 7.0/NPN25137-24.4/5:user/release-keys," and it fails. (This also happened on reteu, but I happened to have the package it wanted to see, so I installed it first. See below.)
So, my next move is to replicate what worked on reteu, which was to flash the other package I have first, but I get another error saying "E3002: Package expects build thumbprint of 7.0/NPN25.137-24.3/4:user/release-keys or 7.0/NPNS25.137-24-1-9/10:user/release-keys; this device has 7.0/NPN25.137-24.4/5:user/release-keys."
I'm sort of at a loss from here of what to do, since the May security update for retus does seem to prevent compatibility with flashing any new package. The reason this wasn't an issue on the reteu one was, I'm assuming, because it was on the April security update, and I was able to install the second package, and then finally official 7.1.1 to get it current.
Anyone have any ideas? I can't be the only one running this freaking NPN25.137-24.4 (May) update on the retus Z Play that is preventing me from sideloading official 7.1.1. Thanks in advance!
Let me ask again (not you, in general). Why do you so desperately want 7.1.1? And risk hard bricking flashing images?
Mine Play is also retus and got May security patch last week. I'm not noticing any bugs. 7.1.1 is not bringing something revolutionary. It's still 7.x after all. I'm even thinking to not accept update. Don't fix it if is not broken.
Zeljko1234 said:
Let me ask again (not you, in general). Why do you so desperately want 7.1.1? And risk hard bricking flashing images?
Mine Play is also retus and got May security patch last week. I'm not noticing any bugs. 7.1.1 is not bringing something revolutionary. It's still 7.x after all. I'm even thinking to not accept update. Don't fix it if is not broken.
Click to expand...
Click to collapse
I appreciate your reply, but this isn't really relevant to my question at all. I acknowledge there are risks with flashing, but I did it successfully on one of my devices and it's really not the scariest thing I've ever done on ADB.
If you're content to wait, that's fine; what I want to know is the reason why I can't seem to do it on 2/3 of my devices. I'd appreciate responses that are relevant to my question.
I replied to your post on reddit, but I'll share it here too. Someone may even correct me here on XDA if I've got any info wrong.
The 7.1.1 that was released to most of us (retbr, retca, etc) require the build number NPN25.137-24.3 (May 2017 security patch) to be installed.
The May security patch on retus has the build number of NPN25.137-24.4 (I guess there was a change that warranted the .4 over .3). All retus phones will have this build number if they've installed the May patch.
This is why you were getting errors when trying to sideload 7.1.1 onto the retus phones (trying to install an update not meant for the device). retus will likely get a different install package for Android 7.1.1
How do you sideload using stock recovery? I tried adb devices and my device is not listed. I want to sideload Google stuff to stock ROM, any idea how to do that? Tried to install the APK files manually but I got force closed after that. Thank you.
This is really a big topic that no one asks, everyone just asks how to fix it but I want to know what exactly happens to Android system in deep that cause hard brick and unable to start the device. Previously when I had a Chinese phone, it was so simple to downgrade and upgrade stuff without bricking because there was no bootloader at all. Everytime I check it said "Unkonwn Bootloader". I'd be happy if someone explain or just drop links about the bootloader and why hard brick happens due to downgrade. I am thinking a way to fix the hard brick device in a way that will fix it all the time with just a simple procedure, doesn't matter if you had downgraded or rekt system stuff or you're on any Android version, it will be fixed. It sounds stupid but I think there must be a way, if we go more deeper into Android system, we can make it working.
I'll have a go at answering this...
It's generally not the downgrading of stock Motorola firmware that bricks a device, often times it's the usage of OTA updates following a downgrade that causes the hard brick.
From what I've seen of many hard bricks (on Moto G4/Plus, G5 Plus, Z Play, though probably a similar scenario on other devices from other manufacturers):
1)You have your system firmware and your bootloader. E.g. The C1:14 version bootloader comes with the Feb 2018 7.1.1 stock Nougat firmware/OTA update. Normally, they would be matching (so you'd have the 7.1.1 Feb 2018 firmware with the C1:14 bootloader). Using OTA updates would be no problem.
2)If you downgrade your stock firmware (custom ROMs usually are not applicable in this case, regardless of the custom ROM security patch/version), you may be able to flash older stock firmware but your bootloader cannot be downgraded. E.g. you flashed the August 2017 7.1.1 stock firmware on a device previously updated to Feb 2018 stock firmware. You'd have the August 2017 system firmware but a Feb 2018 bootloader. Your device may run okay and the flash may have gone okay besides some 'security version downgrade' errors with the bootloader and GPT.
3)So your downgraded device runs okay and you get an OTA prompt to the Sept 2017 security patch OTA. This is where the problems start. OTA updates appear to only be verified by your system version, and looking through the updater scripts for various OTA updates, they check if your system partition, OEM, boot (kernel) etc are fully stock and are of the correct build to flash to. Tellingly, the OTA script does not seem to check for your bootloader version , I think the OTA assumes your bootloader and the system are of the same matching versions/patch levels. As you've downgraded your device, this assumption does not hold. Should there be a check for the bootloader version if it was possible? Perhaps.
4)Your device reboots and begins flashing the Sept 2017 OTA. So far, the OTA is checking and verifies your device is running the August 2017 firmware, and begins patching. However, the OTA can patch your bootloader with older images without verification, which means it applies Sept 2017 images to a Feb 2018 bootloader, corrupting the bootloader and thus hard bricking your device.
(EDIT - reading this page, it suggests that there are multiple bootloaders in your device, each one verifying each other to ensure integrity. https://forum.xda-developers.com/android/general/info-android-device-partitions-basic-t3586565 My guess is that applying the old OTA images to a newer bootloader changes the signature of the bootloader we see - e.g. changing the signature of the secondary bootloader/SBL or having an old aboot image in the newer bootloader - and so fails the upstream verification, hence a hard brick.)
I'm not sure how your old device's bootloader is different, maybe it's a lot less stringent. Was it running a Qualcomm bootloader or a Mediatek bootloader?
However, with Qualcomm bootloaders, if the bootloader image is corrupted they appear to fall back to a emergency download mode (you can read more here: https://alephsecurity.com/vulns/aleph-2017028 ). To recover, you often need crytographically signed images from the appropriate OEM (Motorola in this case) to rescue a device in such a state. As I understand it, these images - including the often requested blankflashes - include methods to communicate with your device (via the sahara protocol) https://github.com/openpst/sahara and a programmer to verify your device and bootloader are suitable for repairing, before flashing a new bootloader: https://forum.xda-developers.com/showpost.php?p=62191317&postcount=2112 https://forum.xda-developers.com/showpost.php?p=63490742&postcount=17 We cannot make these, and any attempts to modify them would likely break the cryptographic signatures on the files, so would be rejected (else you could inject your own compromised bootloader, or downgraded bootloader as per the paper, which would be dangerous for security). This security issue is likely why OEMs do not release blankflashes or other such repair files.
If the blankflash is too old or older than the corrupted bootloader, the programmer appears to fail to rescue the device. Short of having the actual, signed files in a blankflash or similar, that are as new or newer than your current corrupted bootloader, it becomes very hard to rescue a device. That's likely why we've seen quite a few Z Play devices on 7.1.1 or 8.0 that downgraded and got corrupted by an OTA that are not rescuable at the moment - we simply do not have updated tools. Motorola (and likely other OEMs) seems to regard these blankflashes as internal development tools and as such won't give them out - all we have are leaks. I imagine Motorola's point of view also includes that since your bootloader was unlocked, you assume responsiblity for anything that happens.
If you do hard brick then I recall there are a few options:
a)Hope that a blankflash or updated MSM8953 programmer/signed images for Motorola devices is leaked. Must be as new or newer than your corrupted bootloader (recall you cannot downgrade bootloaders). No guarantee of being released if at all.
b)Hope that someone finds a JTAG or other board level repair.
c)Pay for a motherboard replacement (expensive, 60-80% of the device cost sometimes) - perhaps you may be covered by local consumer laws.
d)Buy a new device, forget about repairing this one.
As I mentioned above, hard bricks are very difficult to recover from without the correct tools. However, they are avoidable if users do not flash older stock firmware, only flashing the same stock firmware as they had on their device (matching their bootloader) or newer stock firmware. If they do downgrade, then not using OTA updates whatsoever may also save them from a hard brick (though in that case you must use the latest stock firmware to update with). Alternatively, if you unlocked your device bootloader, you could just use TWRP flashable stock ROMs and forget about using stock firmware at all - TWRP flashables in general should not affect the bootloader.
Any further comments or corrections welcome.
echo92 said:
I'm not sure how your old device's bootloader is different, maybe it's a lot less stringent. Was it running a Qualcomm bootloader or a Mediatek bootloader?
.
Click to expand...
Click to collapse
Yes indeed it was a mediatek device and thank you so much for your answer, I really appreciate it.
So a patched bootloader will able to bypass the verification step and the update will be flashed easily but the problem is with the security. BTW, what kind of security concerns? Will my device become vulnerable to hackers and viruses?
And if the patching bootloader is a pain then is there any way to patch the OTA itself? A patched OTA which doesn't requires verification and won't cause hard bricking. So if a person who has downgraded to predecessor version and have a bootloader of successor version can get the successor version of Android through side loading the patched OTA.
I was thinking about the JTAG stuff but it's overall not economically feasible.
I think patched Ota update is a good way to get around but is it possible?
Manish355 said:
Yes indeed it was a mediatek device and thank you so much for your answer, I really appreciate it.
So a patched bootloader will able to bypass the verification step and the update will be flashed easily but the problem is with the security. BTW, what kind of security concerns? Will my device become vulnerable to hackers and viruses?
And if the patching bootloader is a pain then is there any way to patch the OTA itself? A patched OTA which doesn't requires verification and won't cause hard bricking. So if a person who has downgraded to predecessor version and have a bootloader of successor version can get the successor version of Android through side loading the patched OTA.
I was thinking about the JTAG stuff but it's overall not economically feasible.
I think patched Ota update is a good way to get around but is it possible?
Click to expand...
Click to collapse
Good questions.
1)In theory, a patched bootloader may let you bypass the verification step, though the upstream bootloaders (including those burned into your device's memory) may still stop that bootloader from running, as it fails the 'chain of trust' as Google puts it. https://source.android.com/security/verifiedboot/verified-boot
As for security concerns, well, who knows? If you could put a compromised bootloader onto your device with the correct authorisations, it could do anything. That's likely why blankflashes are not around, plus the fact they have to be signed by the issuing OEM to be valid. Else, that could be a potential vector to breaking security. If you can't trust the guardian of your device (which the bootloader can act as), what can you then trust about that device?
2)In theory, again, you could patch the OTA, but the OTA is signed, and thus any modification may break the signing. This would then cause rejection by the stock recovery https://source.android.com/devices/tech/ota/sign_builds
I have seen OTA updates modified to work with TWRP, though I think they may not update your bootloader (e.g. have a look here: https://forum.xda-developers.com/g5-plus/how-to/npn25-137-33-stock-firmware-t3577081/page12 ) However, in that case, you may be better off staying with TWRP flashables of the stock ROM and forget about using stock ROM firmware if you are worried about the bootloader.
So in summary, if you want to avoid a hard brick, some ways are:
1)Ensure you only flash the latest firmware onto your device that is as new or newer than your bootloader. If your bootloader is locked, that should apply automatically (as the bootloader will block downgrades).
2)If you do choose to flash older stock firmware that is older than your bootloader version, please do not use OTA updates. Only use newer stock firmware to update (and ensure it's the correct build for your region/software channel).
3)If you so wish and you have an unlocked bootloader, forget about using stock firmware, use the TWRP flashables of the stock firmware (e.g. https://forum.xda-developers.com/moto-z-play/development/rom-nov-patch-npns26-118-22-2-8-t3717037) Of course, OTA updates are not usable.
echo92 said:
Good questions.
1)In theory, a patched bootloader may let you bypass the verification step, though the upstream bootloaders (including those burned into your device's memory) may still stop that bootloader from running, as it fails the 'chain of trust' as Google puts it. https://source.android.com/security/verifiedboot/verified-boot
As for security concerns, well, who knows? If you could put a compromised bootloader onto your device with the correct authorisations, it could do anything. That's likely why blankflashes are not around, plus the fact they have to be signed by the issuing OEM to be valid. Else, that could be a potential vector to breaking security. If you can't trust the guardian of your device (which the bootloader can act as), what can you then trust about that device?
2)In theory, again, you could patch the OTA, but the OTA is signed, and thus any modification may break the signing. This would then cause rejection by the stock recovery https://source.android.com/devices/tech/ota/sign_builds
I have seen OTA updates modified to work with TWRP, though I think they may not update your bootloader (e.g. have a look here: https://forum.xda-developers.com/g5-plus/how-to/npn25-137-33-stock-firmware-t3577081/page12 ) However, in that case, you may be better off staying with TWRP flashables of the stock ROM and forget about using stock ROM firmware if you are worried about the bootloader.
So in summary, if you want to avoid a hard brick, some ways are:
1)Ensure you only flash the latest firmware onto your device that is as new or newer than your bootloader. If your bootloader is locked, that should apply automatically (as the bootloader will block downgrades).
2)If you do choose to flash older stock firmware that is older than your bootloader version, please do not use OTA updates. Only use newer stock firmware to update (and ensure it's the correct build for your region/software channel).
3)If you so wish and you have an unlocked bootloader, forget about using stock firmware, use the TWRP flashables of the stock firmware (e.g. https://forum.xda-developers.com/moto-z-play/development/rom-nov-patch-npns26-118-22-2-8-t3717037) Of course, OTA updates are not usable.
Click to expand...
Click to collapse
Wow, you're the man. I was expecting that because when I looked into the OTAs, I found it's hard to modify the OTA to work on signed bootloader. It's like a lock and key system that makes the OTA possible. Thanks for your help, it has saved me not of time.
BTW, the stock ROM (Oreo) replaces the build prop everytime I reboot? I am trying to modify the build prop but no results till now. Is it because of magisk? Because magisk is a systemless root so it prevents system modifications?
Manish355 said:
Wow, you're the man. I was expecting that because when I looked into the OTAs, I found it's hard to modify the OTA to work on signed bootloader. It's like a lock and key system that makes the OTA possible. Thanks for your help, it has saved me not of time.
BTW, the stock ROM (Oreo) replaces the build prop everytime I reboot? I am trying to modify the build prop but no results till now. Is it because of magisk? Because magisk is a systemless root so it prevents system modifications?
Click to expand...
Click to collapse
Hmm, if you're following this rooting guide, https://forum.xda-developers.com/moto-z-play/how-to/guide-how-to-magisk-root-xposed-oreo-8-t3743273 it could well be dm-verity which is still enabled on your device. As I understand it, dm-verity is there to prevent modifications to your system partition (which build.prop is part of) and other key partitions, or if it detects modifications, to stop your device from booting. Others have reported the same issue on other devices https://forum.xda-developers.com/mate-9/help/mount-writable-twrp-t3685867 https://source.android.com/security/verifiedboot/ I think dm-verity is strictly enforced on Nougat and I imagine the same applies to Oreo, if not more so.
However, looking at the magisk help documentation, attempting to disable dm-verity with the stock kernel (stock = the Motorola hudsoncm kernel in this case) can cause odd instabilities on devices https://www.didgeridoohan.com/magisk/MagiskIssues so you may have to look into flashing an Oreo based custom kernel, if one is available (which hopefully has the F2FS fix integrated, and has dm-verity disabled or not present) if you wish to modify your system. However, that custom kernel probably will have to wait for the Oreo stock kernel source to be released by Motorola, as you'll need the Motorola Oreo kernel source to build a compatible kernel for stock Oreo ROMs from what I understand.
echo92 said:
Hmm, if you're following this rooting guide, https://forum.xda-developers.com/moto-z-play/how-to/guide-how-to-magisk-root-xposed-oreo-8-t3743273 it could well be dm-verity which is still enabled on your device. As I understand it, dm-verity is there to prevent modifications to your system partition (which build.prop is part of) and other key partitions, or if it detects modifications, to stop your device from booting. Others have reported the same issue on other devices https://forum.xda-developers.com/mate-9/help/mount-writable-twrp-t3685867 https://source.android.com/security/verifiedboot/ I think dm-verity is strictly enforced on Nougat and I imagine the same applies to Oreo, if not more so.
However, looking at the magisk help documentation, attempting to disable dm-verity can cause odd instabilities on devices https://www.didgeridoohan.com/magisk/MagiskIssues so you may have to look into flashing an Oreo based custom kernel, if one is available (which hopefully has the F2FS fix integrated, and has dm-verity disabled or not present) if you wish to modify your system. However, that custom kernel probably will have to wait for the Oreo stock kernel source to be released by Motorola, as you'll need the Motorola Oreo kernel source to build a compatible kernel for stock Oreo ROMs from what I understand.
Click to expand...
Click to collapse
There's an option in magisk that says "Preserve AVB 2.0/dm-verity", should unchecking it will work?
Or rooting with SuperSU would work? I tried SuperSU 2.82, it all flashed but stuck on boot at the last. Do you know how can I root my device using SuperSU, safety net is not an issue.
Manish355 said:
There's an option in magisk that says "Preserve AVB 2.0/dm-verity", should unchecking it will work?
Click to expand...
Click to collapse
I honestly do not know, though it's possible unchecking that may cause a bootloop if magisk tries to disable dm-verity on the stock kernel. I'm hoping you could boot into recovery and enable dm-verity then re-flash magisk to get your device running if you do bootloop.
echo92 said:
I honestly do not know, though it's possible unchecking that may cause a bootloop if magisk tries to disable dm-verity on the stock kernel. I'm hoping you could boot into recovery and enable dm-verity then re-flash magisk to get your device running if you do bootloop.
Click to expand...
Click to collapse
Rooting with SuperSU would work? I tried SU 2.82 but my device got stuck at boot after long time and several bootloops. Do you know how to root using superSU? I don't mind safety net fail or pass, I don't use apps that requires safety net either.
Manish355 said:
Rooting with SuperSU would work? I tried SU 2.82 but my device got stuck at boot after long time and several bootloops. Do you know how to root using superSU? I don't mind safety net fail or pass, I don't use apps that requires safety net either.
Click to expand...
Click to collapse
I'm not familiar with rooting with SuperSU on the Z Play - for my G4 Plus, the easiest way was to flash a custom kernel (ElementalX courtesy of flar2 or vegito) which had dm-verity removed from the kernel. That way, when you flashed magisk or SuperSU, there was less risk of boot issues. There were dm-verity disablers but I recall they had to be modified for each new stock firmware and sometimes had boot issues if the patch didn't work properly.
I have absolutely no idea if this will work on the Oreo stock kernel, in theory you could unpack the kernel, disable dm-verity and re-pack the kernel: https://forum.xda-developers.com/showpost.php?p=69558535&postcount=7912
However, I think the most compatible and reliable path would be to compile a custom kernel, without dm-verity, from the Z Play Oreo kernel source, then flash that to your device then flash magisk/SuperSU.
echo92 said:
I'm not familiar with rooting with SuperSU on the Z Play - for my G4 Plus, the easiest way was to flash a custom kernel (ElementalX courtesy of flar2 or vegito) which had dm-verity removed from the kernel. That way, when you flashed magisk or SuperSU, there was less risk of boot issues. There were dm-verity disablers but I recall they had to be modified for each new stock firmware and sometimes had boot issues if the patch didn't work properly.
I have absolutely no idea if this will work on the Oreo stock kernel, in theory you could unpack the kernel, disable dm-verity and re-pack the kernel: https://forum.xda-developers.com/showpost.php?p=69558535&postcount=7912
However, I think the most compatible and reliable path would be to compile a custom kernel, without dm-verity, from the Z Play Oreo kernel source, then flash that to your device then flash magisk/SuperSU.
Click to expand...
Click to collapse
I haven't tried compiling a kernel, I am not a developer (I had ported ROMs for my old MTK device but none for this device, I am not very much familiar with snapdragon devices) so i think I should just flash a custom ROM, that would work, right?
Manish355 said:
I haven't tried compiling a kernel, I am not a developer (I had ported ROMs for my old MTK device but none for this device, I am not very much familiar with snapdragon devices) so i think I should just flash a custom ROM, that would work, right?
Click to expand...
Click to collapse
If you really want access to your /system partition and build.prop, custom ROMs are an option, yes, as their kernels shouldn't have dm-verity on and so are easier to root. Ensure you have the stock firmware to revert back to if you so wish and back up your data, as a custom ROM flash will usually mandate a data wipe/factory reset.
Alternatively, wait for the Z Play Oreo kernel source and for a developer to release a custom kernel built on that source.
echo92 said:
Alternatively, wait for the Z Play Oreo kernel source and for a developer to release a custom kernel built on that source.
Click to expand...
Click to collapse
Ya, this seems like a good option. BTW, unchecking the dm-verity in magisk won't do anything, after reboot it checks again. Thanks for the help.
Driver Installation
Does anyone know how to update the drivers to reflect that the device is a Moto phone? I bricked my device (exactly as described here; downgraded then OTA bricked). When I plug in to my computer it recognizes it as a USB driver Qualcomm HS-USB QDLoader 9008. Would it help any to download a driver to have it identify as a phone?
Tweedledope said:
Does anyone know how to update the drivers to reflect that the device is a Moto phone? I bricked my device (exactly as described here; downgraded then OTA bricked). When I plug in to my computer it recognizes it as a USB driver Qualcomm HS-USB QDLoader 9008. Would it help any to download a driver to have it identify as a phone?
Click to expand...
Click to collapse
Unfortunately, the only way is to somehow repair your bootloader as the bootloader is (part of ) what identifies your device to your computer as a phone. That Qualcomm HS-USB 9008 is your device in emergency mode - usually when your bootloader is corrupted (by a bad OTA update) or non-existent and now it's in a fail-safe boot state.
The only ways to get your device recognised again are to find a working blankflash to repair your device bootloader, try to boot from a cloned image of a working device (and then perform a firmware flash to repair the damage) or pay for a motherboard replacement.
Hey guys, quick question about the Pixel XL (Marlin) I've got.
Bought from Google when they were first released, ran stock for the last few years with little to no issues...decided to make the plunge to custom ROM with unlocked bootloader/straight to 8.1 I think it was worked without root...then 9.0 came out and I wiped out everything with factory image procedures and it's been issue after issue...
My question is specifically which factory image should I be using, Google offers 2 with the October patches right now:
9.0.0 (PPR1.181005.003, Oct 2018, Telus Only) Link 87fbdecc08c8e9cabd17449118d9cc3df4db3e82663280200867dc04b25d7ee8
9.0.0 (PPR2.181005.003, Oct 2018) Link 59b2d3ddc0ee8b42f88cceb01f2a52cbca5028af1969e7abaade3424688b935d
My Carrier is Public Mobile, which is a sub-brand of Telus...so I went with the Telus factory image (thinking radios/etc are a better match???), did the flash-all.bat method, re-setup/etc.
2 Issues:
1) No matter which Magisk I try, I get nothing but bootloops -- flashing magisk-uninstaller fixes the bootloop, so I'm thinking something screwy image related. Could it be that the Magisk-v17. 2 wasn't tested against the Telus factory images? @topjohnwu Magisk Queries @topjohnwu
2) Tried checking my voicemail, and the call dials out and is able to connect (Minutes start counting up), but can't hear/say anything...just silence.
I'm about to try the "standard" Pixel XL image (line 2 above) but curious what you guys think, any input would be appreciated.
Thanks!
ZachPatterson said:
Hey guys, quick question about the Pixel XL (Marlin) I've got.
Bought from Google when they were first released, ran stock for the last few years with little to no issues...decided to make the plunge to custom ROM with unlocked bootloader/straight to 8.1 I think it was worked without root...then 9.0 came out and I wiped out everything with factory image procedures and it's been issue after issue...
My question is specifically which factory image should I be using, Google offers 2 with the October patches right now:
9.0.0 (PPR1.181005.003, Oct 2018, Telus Only) Link 87fbdecc08c8e9cabd17449118d9cc3df4db3e82663280200867dc04b25d7ee8
9.0.0 (PPR2.181005.003, Oct 2018) Link 59b2d3ddc0ee8b42f88cceb01f2a52cbca5028af1969e7abaade3424688b935d
My Carrier is Public Mobile, which is a sub-brand of Telus...so I went with the Telus factory image (thinking radios/etc are a better match???), did the flash-all.bat method, re-setup/etc.
2 Issues:
1) No matter which Magisk I try, I get nothing but bootloops -- flashing magisk-uninstaller fixes the bootloop, so I'm thinking something screwy image related. Could it be that the Magisk-v17. 2 wasn't tested against the Telus factory images? @topjohnwu Magisk [email protected]
2) Tried checking my voicemail, and the call dials out and is able to connect (Minutes start counting up), but can't hear/say anything...just silence.
I'm about to try the "standard" Pixel XL image (line 2 above) but curious what you guys think, any input would be appreciated.
Thanks!
Click to expand...
Click to collapse
I'm with Fido and I just use the standard one
I'm rooted and sideload OTA's every 3-4 months. I've done this several times since the phone was released with no issues. Today, was going to be May - August updates. May went through with no problem. However, when I went to install the June OTA, it failed with the following error:
Update package is older than the current build, expected a build newer than timestamp 1586927258 but package has timestamp 1586827774 and downgrade not allowed.
Do you folks have any suggestions? I tried re-downloading, but that didn't work. I checked the SHA-256 Checksum and they're all correct per the Google Developer site. I could move on to the July OTA, but I've never skipped an OTA before and am not sure of the consequences. I'd rather not install factory image and have to set things up again if I can avoid it.
Quick and easy
Fastboot boot the latest TWRP 3.4.0-1 img and flash the August OTA
Skipping June & July OTAs isn't an issue?
Edmontonchef said:
Quick and easy
Fastboot boot the latest TWRP 3.4.0-1 img and flash the August OTA
Click to expand...
Click to collapse
jaybird779 said:
Skipping June & July OTAs isn't an issue?
Click to expand...
Click to collapse
Never had a problem, you could flash and boot those the same way first if it makes you feel better.
Are you sticking to stock or are you running a custom ROM?
This is a known problem with the June update. Notified Google, posted about it on Android Police, problem never fixed. Only way to get the June update was OTA.
Skip June, sideload July or August. Why not just sideload most up to date anyway? Curious. Running August no problem.
A new version of Platform Tools has been released since June.....you may want to download newest Platform Tools and give June another try before loading July or August.
Read Comments: https://www.androidpolice.com/2020/...ogle-pixels-are-here-with-plenty-of-bugfixes/
Hi,
First off I'm pretty new to the Forum so I'm just starting to understand some of the existing threads posted here.
My TMO OnePlus 9 Pro was updated to Android 12 back in March and since that time I've been having several issues the primary of which is that Microsoft Intune is no longer able to validate the configuration of my device. This has locked me out of company apps on my phone for the past several months and it's a real pain.
I looked into the issue and from what I can see it seems to be a bug in oxygen OS 12 relating to Android work profile. I have heard that this bug was fixed in later versions of oxygen OS but unfortunately T-Mobile have not made any new version available since March.
I tried converting my device to T-Mobile EU using the MSM tool and, while I was initially successful I wasn't able to get the T-Mobile modem to work on Android 12. I sent reverted back to T-Mobile US using that MSM.
The way I see it I have two options.
1. Wait and/or work with T-Mobile support to get a newer Oxygen OS build pushed to my device.
2. Figure out a way to fix the modem issues I was facing after upgrading to A12 following the EU MSM conversion.
Is there a fix available for the T-Mobile modem in Android 12? Sorry if it's been answered already but I couldn't find details anywhere despite searching. I'm looking for a no-root solution since that defeats the purpose of doing this to get Intune working.
SmartMart92 said:
Hi,
First off I'm pretty new to the Forum so I'm just starting to understand some of the existing threads posted here.
My TMO OnePlus 9 Pro was updated to Android 12 back in March and since that time I've been having several issues the primary of which is that Microsoft Intune is no longer able to validate the configuration of my device. This has locked me out of company apps on my phone for the past several months and it's a real pain.
I looked into the issue and from what I can see it seems to be a bug in oxygen OS 12 relating to Android work profile. I have heard that this bug was fixed in later versions of oxygen OS but unfortunately T-Mobile have not made any new version available since March.
I tried converting my device to T-Mobile EU using the MSM tool and, while I was initially successful I wasn't able to get the T-Mobile modem to work on Android 12. I sent reverted back to T-Mobile US using that MSM.
The way I see it I have two options.
1. Wait and/or work with T-Mobile support to get a newer Oxygen OS build pushed to my device.
2. Figure out a way to fix the modem issues I was facing after upgrading to A12 following the EU MSM conversion.
Is there a fix available for the T-Mobile modem in Android 12? Sorry if it's been answered already but I couldn't find details anywhere despite searching. I'm looking for a no-root solution since that defeats the purpose of doing this to get Intune working.
Click to expand...
Click to collapse
My TMo OP9P LE2127 had updated to OOS12 before I had a chance to root it. I hadn't read enough about it to worry about trying to block the update. Well, I hated OOS12 and I eventually downgraded back to Stock OOS11 and then converted it EU with the MSM tool. Currently running a rooted OOS11.2.10.10 on both slots.
Not once did I have to touch the modem and my 5G works just fine. Everything worked out of the box (aka conversion MSM). My phone is even still SIM locked. I believe others have experienced the same thing with a LE2127 that updated to the stock TMo OOS12 firmware. The modem seems to stick after that upgrade, even after downgrading it back to OOS11.
I've blocked my phone from manually checking for updates and I'm perfectly happy with my phone for the time being. That said, I have not tried updating my phone to any EU versions of OOS12 (C.48 being the latest, I think?).
So, that's my experience, but your mileage may vary.
SmartMart92 said:
Hi,
First off I'm pretty new to the Forum so I'm just starting to understand some of the existing threads posted here.
My TMO OnePlus 9 Pro was updated to Android 12 back in March and since that time I've been having several issues the primary of which is that Microsoft Intune is no longer able to validate the configuration of my device. This has locked me out of company apps on my phone for the past several months and it's a real pain.
I looked into the issue and from what I can see it seems to be a bug in oxygen OS 12 relating to Android work profile. I have heard that this bug was fixed in later versions of oxygen OS but unfortunately T-Mobile have not made any new version available since March.
I tried converting my device to T-Mobile EU using the MSM tool and, while I was initially successful I wasn't able to get the T-Mobile modem to work on Android 12. I sent reverted back to T-Mobile US using that MSM.
The way I see it I have two options.
1. Wait and/or work with T-Mobile support to get a newer Oxygen OS build pushed to my device.
2. Figure out a way to fix the modem issues I was facing after upgrading to A12 following the EU MSM conversion.
Is there a fix available for the T-Mobile modem in Android 12? Sorry if it's been answered already but I couldn't find details anywhere despite searching. I'm looking for a no-root solution since that defeats the purpose of doing this to get Intune working.
Click to expand...
Click to collapse
In order to get the modem working in A12, you have to have root and flash a Magisk module that fixes your build.prop. Unfortunately, your need to be unrooted prevents that from happening.
If you're OK with rooting temporarily, you could modify your build.prop to have "ro.vendor.oplus.radio.multisim.config=ssss" after flashing EU, then unroot afterwards by flashing stock boot.img.
razercortex said:
In order to get the modem working in A12, you have to have root and flash a Magisk module that fixes your build.prop. Unfortunately, your need to be unrooted prevents that from happening.
If you're OK with rooting temporarily, you could modify your build.prop to have "ro.vendor.oplus.radio.multisim.config=ssss" after flashing EU, then unroot afterwards by flashing stock boot.img.
Click to expand...
Click to collapse
Yeah, that could work. Does build.prop need to be updated after each OTA update?
SmartMart92 said:
Yeah, that could work. Does build.prop need to be updated after each OTA update?
Click to expand...
Click to collapse
Shouldn't need to be updated.
Also, you could try unlocking bootloader, rooting, modifying build.prop, unrooting, then relocking bootloader if you're ok with testing. It may/may not work. If it works, then you don't need to modify ever again, at least until a future update touches that file.
If I have no sims detected am I able to flash something to regain sim detection and data?