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!Maniac2k said:You need to download a custom rom. From what ive seen, a stock rom even if debloated will still download the ota.
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.klm22 said: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...klm22 said:just use your favorite root file explorer and rename /system/etc/security/otacerts.zip to something else. no more ota pushes.
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.Chris3D said: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.
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.abqnm said: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.
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 said: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
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.abqnm said: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.
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. +$.02linuxmotion said: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
Hmm you make a very good point.abqnm said: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
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.abqnm said: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