[jay]

I'm running leftys incredbly debloted rom and it keeps trying to perform an ota and reboots and gets stuck at the recovery until I clear the cache. How can I stop this ota?

Sent from my DROID2 using RootzWiki Forums

 

[AndroidAddict]

I just started having the same issue with the rooted stock ROM. I've frozen the bloatware which is I guess the reason it stalls while trying to install the OTA. I don't like that it didn't ask me to download it first. I'm restoring my phone to right after I rooted it and before removing anything to see what happens.

 

[Maniac2k]

You need to download a custom rom. From what ive seen, a stock rom even if debloated will still download the ota.

 

[excaliber88]

You need to download a custom rom. From what ive seen, a stock rom even if debloated will still download the ota.

This is what got me on to custom ROMs as well. I rooted my phone and froze all the bloatware, but kept getting prompted to install an update. I would ignore the update until one day it was sent automatically and my phone would boot loop (could not install the update). Going with a custom ROM was the best thing that I have done, highly recommended!

 

[klm22]

just use your favorite root file explorer and rename /system/etc/security/otacerts.zip to something else. no more ota pushes.

 

[linuxmotion]

just use your favorite root file explorer and rename /system/etc/security/otacerts.zip to something else. no more ota pushes.

From what i understand this will cause massive battery use. The proper fix is to edit the build.prop file to say the rom is the latest release for your phone.

Sent from my Incredible using Tapatalk

 

[Chris3D]

just use your favorite root file explorer and rename /system/etc/security/otacerts.zip to something else. no more ota pushes.

From what I've read, while this will stop the OTA from installing, it does so by making the downloaded update fail the cert check. This can apparently lead to the OTA being repeatedly downloaded over and over. Download, fail check, download, fail check...

I believe the actual update process is com.smithmicro, which is contained in the DmClient.apk file. The process can be frozen with Titanium, or prevented from starting by renaming or deleting DmClient.apk in /system/app using Root Explorer. This will ensure the OTA is never even downloaded in the first place.

 

[abqnm]

From what I've read, while this will stop the OTA from installing, it does so by making the downloaded update fail the cert check. This can apparently lead to the OTA being repeatedly downloaded over and over. Download, fail check, download, fail check...

I believe the actual update process is com.smithmicro, which is contained in the DmClient.apk file. The process can be frozen with Titanium, or prevented from starting by renaming or deleting DmClient.apk in /system/app using Root Explorer. This will ensure the OTA is never even downloaded in the first place.

That is correct. I would also recommend the otacerts.zip renaming as well since that should prevent it from installing should it download anyway or is already downloaded.

 

[linuxmotion]

That is correct. I would also recommend the otacerts.zip renaming as well since that should prevent it from installing should it download anyway or is already downloaded.

The correct fix is to have the build.prop the same as the latest ota. Hmm think about it. If the phone thinks its at the latest ota already why would it download the update. Think about it. This is the fix.

Renaming or removing the oatcerts will cause excessive battery use. Fix the build.prop

Sent from my Incredible using Tapatalk

 

[abqnm]

The correct fix is to have the build.prop the same as the latest ota. Hmm think about it. If the phone thinks its at the latest ota already why would it download the update. Think about it. This is the fix.

Renaming or removing the oatcerts will cause excessive battery use. Fix the build.prop

Sent from my Incredible using Tapatalk

Agreed that the build.prop mod should prevent the update as well, but editing the build.prop version info can cause market issues and is a lot more involved for beginners and is more dangerous. As for otacerts.zip causing battery issues, I agreed on that part. Renaming the otacerts.zip will not cause battery issues if you rename it IN ADDITION to renaming the smithmicro download manager because it won't be able to download the update anyway. The reason for renaming both is so it doesn't download and so if it has already downloaded, it will not install.

 

[linuxmotion]

Agreed that the build.prop mod should prevent the update as well, but editing the build.prop version info can cause market issues and is a lot more involved for beginners and is more dangerous. As for otacerts.zip causing battery issues, I agreed on that part. Renaming the otacerts.zip will not cause battery issues if you rename it IN ADDITION to renaming the smithmicro download manager because it won't be able to download the update anyway. The reason for renaming both is so it doesn't download and so if it has already downloaded, it will not install.

Really this should not even be left to the user. The rom developer should resolve this issue. I think that this users should kindly ask the developer to fix that issue. As for smithmicro that is good to know.

Though i don't have an inc2 this was a problem for us as well on the inc1. I hope the OP got the problem resolved

Sent from my Incredible using Tapatalk

 

[abqnm]

Really this should not even be left to the user. The rom developer should resolve this issue. I think that this users should kindly ask the developer to fix that issue. As for smithmicro that is good to know.

Though i don't have an inc2 this was a problem for us as well on the inc1. I hope the OP got the problem resolved

Sent from my Incredible using Tapatalk

Agreed that the ROM devs should have fixed that before release, but I don't think that all the devs knew and/or know what the smith micro dm does. I don't hold it against them since we are not buying the roms. If they were for sale, I would expect it though. As for the dev making the build.prop correct, when it was released, it likely was correct. Many of these ROMs are not updated frequently, if at all, so if that is all they did to block it, then the next release would require it to be updated again. Without the DM there it won't matter what the current version is. +$.02

 

[linuxmotion]

Agreed that the ROM devs should have fixed that before release, but I don't think that all the devs knew and/or know what the smith micro dm does. I don't hold it against them since we are not buying the roms. If they were for sale, I would expect it though. As for the dev making the build.prop correct, when it was released, it likely was correct. Many of these ROMs are not updated frequently, if at all, so if that is all they did to block it, then the next release would require it to be updated again. Without the DM there it won't matter what the current version is. +$.02

Hmm you make a very good point.

Sent from my Incredible using Tapatalk

 

[sic789]

ive had luck pushing FOTAKILL.apk from cm7 ive used it on stock rooted roms to kill the ota

 

[Chris3D]

Many of these ROMs are not updated frequently, if at all, so if that is all they did to block it, then the next release would require it to be updated again. Without the DM there it won't matter what the current version is. +$.02

Exactly, if all one does is change the version in the build prop, they could very easily get updated when the next official version is released if they don't re-update the version in time. For that reason, removing/renaming the otacerts.zip and the DmClient.apk are the easiest and most reliable way to prevent any future ota update.