This is bullcrap. And it's an AT&T thing, no matter how much they want to deny it. And it's all handled locally. I performed this test to verify.
1) Perform a full Nandroid backup.
2) Check for software update via Settings > Software Update (of course I got a communication error)
3) Try again.. Oops, you have to wait 24 hours.
4) Restore Nandroid backup I created step 1.
5) Check for software update via Settings > Software Update (wow it works again)
This is how I think it works:
1) You tap "Check for update" in Settings > Software Update
2) The Settings application (or perhaps Software Update is a separate app) looks at some cache file SOMEWHERE on the filesystem (probably an XML) for a Unix timestamp
3) The Unix timestamp in this cache is compared to the current Unix timestamp. 4) If (current - previous) < 86400 then you are not allowed to check for updates.
5) If (current - previous) > 86400 then you are allowed to check for updates and the timestamp in the cache file is then updated to the current Unix timestamp.
My friend Don has a Vibrant and this restriction does not exist so I know it's an AT&T thing. I need to track this cache file down.
Old news, work around is to set system date ahead one day and check again. AT&T did this to limit the hit on their update servers.
Sent from my SAMSUNG-SGH-I897 using XDA App
. .
Just curious how often you really need to check for an update considering there has only been one.
Sent telepathically using vulcan mind meld app.
This method is better than setting the clock ahead - http://forum.xda-developers.com/showpost.php?p=8394579&postcount=4
cappysw10 said:
Old news, work around is to set system date ahead one day and check again. AT&T did this to limit the hit on their update servers.
Sent from my SAMSUNG-SGH-I897 using XDA App
Click to expand...
Click to collapse
Not a solution. Next time I try to udpate it's 48, etc. Regardless of how often I should update, this is unacceptable. AT&T needs to get on the ball so the servers don't fail.
Furthermore, from a coding standpoint the update process should work like this if they MUST limit you to once every 24 (pseudo-code)...
upon tapping "Check for updates...."
$timestamp = check_timestamp()
if ((now() - $timestamp) > 86400) {
echo "Sorry, blah blah blah 24 hours"
} else {
check_update_sever()
]if (exit_code == 0) {
update_timetamp()[
}
If the exit code from the attempt to hit the servers is non-zero (failed to connect or what have you) then that timestamp should NOT be updated.
I tried this with little success..
* Full nandroid backup so I could restore it later
* Set clock ahead 20 years (so unix timestamp would be very different 19xxxx versus 12xxxx)
* Check update, of course it failed
* busybox find / -type f -exec busybox grep 1918 {} \;
I found a few files with the 2030 timestamp but none pertaining to the software update. They have it hidden well. I could also dissect their app and patch it.
i am wondering why you think its needed to be able to check for updates all the time from ATT?
As already stated, there has been exactly ONE update from ATT. what do you think you are going to get to update if you do connect?
Since I'm mostly a lurker and I rarely run into issues that someone hasn't already run into, I don't have the post count to post on the actual Dynamic 1.4 thread. But I'm a little stumped. I seem to have lost root, and when I run anything in SS I get multiple I/O errors referencing data/data/chainfire su files.
I came from knoxraid. Installed new safestrap. wiped. Installed 1.0 from SS then 1.4 from SS. Set up the phone. Restored apps. Set up my favorite xposed modules. All was good for a few hours then I noticed I didn't get a full screen call ID on a call. I went in to check xposed and all the modules were unchecked. I tried to install/update but it said xposed wasn't compatible with my version. So I uninstalled xposed and tried reinstalling. Now it errors on install with "Can't install, free up space and try again" I have plenty of space, but I noticed the last I/O error I get in SS refers to data/data/xposed something or other. So I did the whole wipe and start with 1.0 process over, but nothing changed. No root. And I don't know if the I/O errors are keeping SS from wiping system when it installs, so I'm wary about installing another rom just to see if it works. But I can still boot into SS.
So I'm not sure which direction to go from here.
The errors are:
E:error: I/O error
E:error opening '/data/data/eu.chainfire.supersu/logs'
E:error opening '/data/data/de.robv.android.xposed.installer'
" " " /data/data/eu.chainfire.supersu/requests
fix permissions didn't work. An extra error was "unable to chmod data/data/eu.chainfire.supersu/requests"
I can't access those files using file explorer in SS.
Well if anyone runs into a similar issue- I wasn't able to install any applications after that as well.
A wipe from stock recovery fixed it. Although it wiped a lot more than I had anticipated
Was the installation on the stock slot? That is where it needs to be. Get your post count up so you can join us!
bri315317 said:
Was the installation on the stock slot? That is where it needs to be. Get your post count up so you can join us!
Click to expand...
Click to collapse
Yeah I made sure to use stock slot. And everything was fine for a few hours. I really don't think it had anything to do with the rom. I'm leaning towards and install/enable/unistall/disable process that I was burning through on xposed, since the locked up files were su and xposed. And I had other apps downloading and installing in the background. I just gotta learn to slow down. Got everything set up today and it's running beautifully. I was on your Dynamic GPE for JB and it was my favorite. I gave the KK version of knoxraid a shot but got super excited when I saw SS had updated and I could go back to dynamic without odin.
It was fun now that it's fixed. I hadn't been into stock recovery since the old DX days. I didn't realize a data wipe from there took out just about everything on internal storage. Good thing I had the important stuff backed up.
I've been following your work for a while. And you sir, are fantastic. :good:
I’m using a Galaxy Note 8 (SM-N950U) with Verizon. I’m getting a message saying that System Update 19 will be installed in four days or the next time I restart my phone.
I’d like to block further system updates, as I don’t like the constant UI changes. Updating could also make it more difficult to root this device in the future (I’ll want to modify the HOSTS file to block ads).
Any suggestions on how to put an end to forced system updates?
diovanti said:
I’m using a Galaxy Note 8 (SM-N950U) with Verizon. I’m getting a message saying that System Update 19 will be installed in four days or the next time I restart my phone.
I’d like to block further system updates, as I don’t like the constant UI changes. Updating could also make it more difficult to root this device in the future (I’ll want to modify the HOSTS file to block ads).
Any suggestions on how to put an end to forced system updates?
Click to expand...
Click to collapse
I think if u boot into recovery and delete cache should delete the download?
MystaMagoo said:
I think if u boot into recovery and delete cache should delete the download?
Click to expand...
Click to collapse
But when you boot into the stock recovery, it tries to install the update, right?
SnowFuhrer said:
But when you boot into the stock recovery, it tries to install the update, right?
Click to expand...
Click to collapse
Not that I understand,double check 1st though.
MystaMagoo said:
Not that I understand,double check 1st though.
Click to expand...
Click to collapse
What I am saying is, that if there is a downloaded update and you reboot to recovery, will it not install the update?
SnowFuhrer said:
What I am saying is, that if there is a downloaded update and you reboot to recovery, will it not install the update?
Click to expand...
Click to collapse
I heard you and as far as I know it should not but as said double check 1st.
diovanti said:
I’m using a Galaxy Note 8 (SM-N950U) with Verizon. I’m getting a message saying that System Update 19 will be installed in four days or the next time I restart my phone.
I’d like to block further system updates, as I don’t like the constant UI changes. Updating could also make it more difficult to root this device in the future (I’ll want to modify the HOSTS file to block ads).*
Any suggestions on how to put an end to forced system updates?
Click to expand...
Click to collapse
Open up an adb connection via a computer.. You also need an eng kernel to do this and then you switch back to the kernel you were using at first so your phone doesn't get all slow or anything.. In the adb terminal type adb shell pm disable-user --user 0 com.samsung.sdm and possibly adb shell pm disable-user --user 0 com.samsung.sdmviewer
Thanks everyone for the suggestions. But it turns out, I was able to root the phone with the "[Root][SM-N950U/U1][Snapdragon][V6_Bootloader][EDL_Method][Safestrap]" thread. No more unwanted updates.
Hi,
I have a Pixel 5 (Android 11 stock, but rooted) with Magisk (canary) version 6d88d8ad (21201). I also have the Developer setting for "Automatic system updates" turned off.
It seems to me like the phone is not able to detect (and thus never notifies about) any available OTA, such as the Dec 2020 "201205" OTA, since it has been out for a long time now. Note: I am not talking about installing OTA updates. Just checking for them and getting notifications of them being available.
Is this a known issue? If so, is it documented in an easy-to-find official up-to-date place, such as:
1) Within the Magisk manager app
2) On the Magisk github readme, github site, or github issues list (edit: in an OPEN issue, not a closed one)
3) In the official locked release thread
Hard-to-find or unofficial or outdated places where this would be documented would include:
1) Some XDA forum post somewhere (like this one. hypocrisy noted
2) A tweet by topjohnwu
Is it related to MagiskHide or hiding Magisk Manager? I didn't enable those until just now. Is there a specific package/app that can be toggled in the MagiskHide list to allow OTA update checks/notifications to work?
EDIT: Possible theories discussed below and elsewhere include:
1) Having your bootloader unlocked (independent of Magisk) prevents OTA updates from being made available to you [which to me is absolutely in conflict with my personal experience in the past]
2) Having Magisk installed prevents OTA updates from being made available to you [consistent with my experience]
3) Even after uninstalling Magisk, OTA updates are not made available to you for either some time or forever due to a theory that Google knows you had Magisk and penalizes you (either on purpose or perhaps as a protection from update failures including some time buffer for extra safety) [consistent with my experience]
4) If you ever manually check for updates while Magisk is installed, it prevents them from being made available to you then and subsequently (for how long I dunno). But for a Pixel device I find this to be nonsensical, since even with "Automatic system updates" turned off, a Pixel device will still check for updates (daily?) and notify about them. It just won't install them and prompt for reboot. With this setting on (the default), it will actually install them and prompt for reboot.
5) "if you even have magisk zip on your sd card, the update will detect and prevent OTA check/notification. This stays set until the next month's update"
6) "took a logcat while checking for updates and saw the update program errored complaining about a corrupt partition"
7) The carrier has actually delayed the update, and as usual very rarely is this information proactively posted in an official public place by the carrier even if the update is over a month delayed. See here for fun details on how carriers can delay updates that are created by, led by, and distributed by Google.
8) If you somehow have a current update from one carrier installed but your SIM card is for another carrier, this can prevent updates.
9) If you don't have the latest "Google Play system update" (Under Settings->Security), which is perhaps indicated by the icon next to it being red, that may stop OTA updates from coming. But this presents another issue if the "Google Play system update" can't be updated either. This type of update is also known as "Project Mainline".
10) Devices that say their "Play Protect Certification" is uncertified (Play Store Settings) may not receive OTA updates. In fact Google has a help page on this that actually says "Devices that aren't Play Protect certified may not get Android system updates or app updates"
11) Google has delayed or staggered the rollout of the update more than usual, but in my case this delay was longer than 1 month and I would imagine that this would be covered by the media if the delay took that long on Pixel devices, since it actually went past the release date of the next month's update.
Thanks
There's nothing official, but there has been similar reports here in the Magisk forums from time to time (you'll likely find finding if you search for a bit).
There's also been Github issues opened, like here:
No OTAs available with Magisk · Issue #2657 · topjohnwu/Magisk
Please see a reddit discussion I created for this issue. Since owning my Pixel 4XL since launch, and being rooted with Magisk, I've yet to receive one OTA update via the settings app. When a monthl...
github.com
I do not have any answers to your closing questions, but there are some tips and hints found here and there (like in the above linked GitHub issue).
Didgeridoohan said:
There's also been Github issues opened, like here:
No OTAs available with Magisk · Issue #2657 · topjohnwu/Magisk
Please see a reddit discussion I created for this issue. Since owning my Pixel 4XL since launch, and being rooted with Magisk, I've yet to receive one OTA update via the settings app. When a monthl...
github.com
Click to expand...
Click to collapse
Thanks! Actually after uninstalling Magisk (restoring stock boot image), I still have no OTA update showing as available, so for now it does seem that for whatever reason it really is not available for me and I presume it is unrelated to Magisk.
However, if you look at the comments on that github issue and the related reddit thread, several overlapping/conflicting theories are presented, including:
1) Having your bootloader unlocked (independent of Magisk) prevents OTA updates from being made available to you [which to me is absolutely in conflict with my personal experience in the past]
2) Having Magisk installed prevents OTA updates from being made available to you [consistent with my experience]
3) Even after uninstalling Magisk, OTA updates are not made available to you for either some time or forever due to a theory that Google knows you had Magisk and penalizes you (either on purpose or perhaps as a protection from update failures including some time buffer for extra safety) [consistent with my experience]
4) If you ever manually check for updates while Magisk is installed, it prevents them from being made available to you then and subsequently (for how long I dunno). But for a Pixel device I find this to be nonsensical, since even with "Automatic system updates" turned off, a Pixel device will still check for updates (daily?) and notify about them. It just won't install them and prompt for reboot. With this setting on (the default), it will actually install them and prompt for reboot.
5) See the first post for other items. The list in this post is no longer being updated.
But in general I wish this were better understood with supporting evidence on what is really happening, and can certainly try to contribute to that research myself if someone has suggestions on how.
Yes. I haven't seen anyone with any proper info on what is actually going on. Only (more or less credible) theories... But I haven't actually looked into it.
If I had a Pixel device I might have been tempted to do some research myself. The only possible piece of info I've got that could be remotely related is that OnePlus (at least used to, I haven't used an OEM build in years) detect root with their OTAs and would only offer the full ROM package unless you added the OTA service to MagiskHide.
I found that if you even have magisk zip on your sd card, the update will detect and prevent install of system updates. This stays set until the next month's update (at least that was my experience with pixel 3xl and my current 1+ 8 5g.)
Cheers,
B.D.
BostonDan said:
prevent install of system updates
Click to expand...
Click to collapse
Prevent the installation, or the OTA check/notification?
Didgeridoohan said:
Prevent the installation, or the OTA check/notification?
Click to expand...
Click to collapse
Didgeridoohan, you are correct. Prevent OTA check/notification. Sorry for my misleading verbiage.
Cheers,
B.D.
I have a Pixel 3, and I've had the problem off and on for the last 18 months or so. I've never been able to find any pattern on what causes it to start or stop working. I received OTA notifications and updates for several months after rooting my phone, then one month OTA notifications just stopped working (no longer detecting updates). I took a logcat while checking for updates and saw the update program errored complaining about a corrupt partition.
That continued until the end of September. The Android 11 update came out at the beginning of September, and I was still getting "no updates available". I delayed manually installing the update, and near the end of September the updater suddenly notified me of the update and was nagging me to install it.
I installed the update, and for a couple of months after that, I could check and install OTA updates by restoring the stock boot image. That stopped working after two or three months, and OTA notification has not worked since.
If you want to investigate further, check logcat for the OTA error.
Didgeridoohan said:
... OnePlus (at least used to, I haven't used an OEM build in years) detect root with their OTAs and would only offer the full ROM package unless you added the OTA service to MagiskHide.
Click to expand...
Click to collapse
Anybody know the package that is responsible for this on a Pixel? Is it com.android.google.gms?
dcarvil said:
... I took a logcat while checking for updates and saw the update program errored complaining about a corrupt partition.
...
If you want to investigate further, check logcat for the OTA error.
Click to expand...
Click to collapse
It's possible that "corrupt partition" just means a partition that is checked for integrity before an update has been modified, which could mean if you were rooted that the rooting (and for example magisk's modification of the boot partition on a pixel) was detected somehow. I'll try checking logcat too.
BostonDan said:
I found that if you even have magisk zip on your sd card, the update will detect and prevent install of system updates. This stays set until the next month's update (at least that was my experience with pixel 3xl and my current 1+ 8 5g.)
Click to expand...
Click to collapse
Thanks. In my case I do have the magisk apk and a magisk patched boot image in /sdcard/Download/, so I guess I could try removing those, but...
I checked with my carrier, who did in fact confirm that the update is delayed using language like:
"As of right now there is a delay and we don't have any additional info on it just yet"
"It is defiantly [sic] a delay. We are working with Google to resolve . You are able to check back for updates"
So I guess I would say I am like 75%+ confident that this is accurate and the cause of the delay for me.
After even more discussion with the carrier, they have revoked their prior statement and now say that because they do not sell the pixel 5 themselves, they do not ever delay updates for it and they are 100% up to google.
Since the January update is out, I got another logcat of my OTA update error. When I manually did the "Check for Update", the updater found the update, said it was starting the download, then said "Your system is up to date" without doing the update.
If I am interpreting this correctly, the reason for the update failure is system_b does not have the expected checksum. Magisk does not modify system, so whatever caused this is not Magisk. As far as I know, I have never modified system. I've never encountered any problems other than these OTA failures, so I am not convinced there really is a problem with system_b.
The same error occurs with both the stock boot image and the magisk patched image.
Code:
[ 01-05 11:51:13.144 1205: 1205 I/update_engine ]
[INFO:dynamic_partition_control_android.cc(319)] Loaded metadata from slot B in /dev/block/bootdevice/by-name/system_b
[ 01-05 11:51:13.151 1205: 1205 I/update_engine ]
[INFO:dynamic_partition_control_android.cc(938)] boot_b is not in super partition metadata.
[ 01-05 11:51:13.153 1205: 1205 I/update_engine ]
[INFO:dynamic_partition_control_android.cc(319)] Loaded metadata from slot B in /dev/block/bootdevice/by-name/system_b
[ 01-05 11:51:13.162 1205: 1205 E/update_engine ]
[ERROR:delta_performer.cc(1158)] The hash of the source data on disk for this operation doesn't match the expected value. This could mean that the delta update payload was targeted for another version, or that the source partition was modified after it was installed, for example, by mounting a filesystem.
[ 01-05 11:51:13.163 1205: 1205 E/update_engine ]
[ERROR:delta_performer.cc(1163)] Expected: sha256|hex = CC6CD98FB684FDEE9B4E8253338D4E8B34CAEC90FA533E638C45132C89DAA175
[ 01-05 11:51:13.164 1205: 1205 E/update_engine ]
[ERROR:delta_performer.cc(1166)] Calculated: sha256|hex = 8950BA8882AE17BC240BA54603811E50AC22FFE7E54706004F4D42ECF41FF24B
[ 01-05 11:51:13.165 1205: 1205 E/update_engine ]
[ERROR:delta_performer.cc(1177)] Operation source (offset:size) in blocks: 0:1,7916:1
[ 01-05 11:51:13.190 3159:14736 E/SystemUpdate ]
[Execution,PreDownloadValidateAction] UpdateEngine.verifyPayloadMetadata() failed.
@dcarvil That's different from the described issue in this thread though. Here, the update isn't even found at all...
dcarvil said:
[INFO:dynamic_partition_control_android.cc(938)] boot_b is not in super partition metadata.
[ 01-05 11:51:13.153 1205: 1205 I/update_engine ]
[INFO:dynamic_partition_control_android.cc(319)] Loaded metadata from slot B in /dev/block/bootdevice/by-name/system_b
[ 01-05 11:51:13.162 1205: 1205 E/update_engine ]
[ERROR:delta_performer.cc(1158)] The hash of the source data on disk for this operation doesn't match the expected value. This could mean that the delta update payload was targeted for another version, or that the source partition was modified after it was installed, for example, by mounting a filesystem.
[ 01-05 11:51:13.163 1205: 1205 E/update_engine ]
[ERROR:delta_performer.cc(1163)] Expected: sha256|hex = CC6CD98FB684FDEE9B4E8253338D4E8B34CAEC90FA533E638C45132C89DAA175
[ 01-05 11:51:13.164 1205: 1205 E/update_engine ]
[ERROR:delta_performer.cc(1166)] Calculated: sha256|hex = 8950BA8882AE17BC240BA54603811E50AC22FFE7E54706004F4D42ECF41FF24B
Click to expand...
Click to collapse
You could probably look in /data/system/system-update-info.xml or maybe see here to find the URL of the OTA update zip that it is attempting to install.
Then download the zip somewhere, open it, and find where in the update script in it looks for the quoted expected checksum and verify what partition it is looking at.
And then you could just try to re-flash that partition from a factory image to get it back to normal.
Didgeridoohan said:
@dcarvil That's different from the described issue in this thread though. Here, the update isn't even found at all...
Click to expand...
Click to collapse
Correct. In my case, I don't see any error like this in logcat when checking for an update.
Although @dcarvil's symptom is that it seems to only say there is an update available for a split second and then go back to saying there isn't one.
scootley said:
You could probably look in /data/system/system-update-info.xml or maybe see here to find the URL of the OTA update zip that it is attempting to install.
Then download the zip somewhere, open it, and find where in the update script in it looks for the quoted expected checksum and verify what partition it is looking at.
And then you could just try to re-flash that partition from a factory image to get it back to normal.
Click to expand...
Click to collapse
The control.installation.current_update_url tag in the xml file is empty. I got a checksum of the system.img file in the December factory image, which is currently installed, and it does not match the expected checksum. That makes me a bit reluctant to try to fix system_b, as I am used to manually installing updates anyway.
Thanks for the suggestion, though.
dcarvil said:
I got a checksum of the system.img file in the December factory image, which is currently installed, and it does not match the expected checksum.
Click to expand...
Click to collapse
Is it possible that you have the December update installed for one carrier and your phone is checking for the OTA for another carrier? Did you switch SIMs or carriers? Looks like Verizon has its own OTA and other carriers use a separate one.
scootley said:
Is it possible that you have the December update installed for one carrier and your phone is checking for the OTA for another carrier? Did you switch SIMs or carriers? Looks like Verizon has its own OTA and other carriers use a separate one.
Click to expand...
Click to collapse
I suppose it is possible, but I don't think so. I have a non-carrier branded phone purchased directly from Google, with a Verizon SIM from an MVNO. I've always thought my OTA updates came from Google, but don't know how I would confirm that. I've never switched SIMs. All my manually applied updates have been Pixel Factory images (the non-Verizon version) direct from Google at https://developers.google.com/android/images.
Since I have had successful OTAs at times in the past, that doesn't seem likely.
dcarvil said:
I've always thought my OTA updates came from Google, but don't know how I would confirm that. I've never switched SIMs. All my manually applied updates have been Pixel Factory images (the non-Verizon version) direct from Google at https://developers.google.com/android/images.
Click to expand...
Click to collapse
Yes they come from Google but you can see on that link you sent that there are Verizon-specific Pixel 3 images (lately).
So if you you manually applied the non-verizon one from that page for a month when there was a verizon one (on the same site, listed right below/above the other images for that month), then later OTAs would presumably fail due to a checksum mismatch.
See here too.
EDIT: I don't think it matters where you bought your phone, but I could be wrong. In other words if you are on Verizon and there is a Verizon pixel image then that is the image that your phone will install even if you bought that phone from Google unlocked and without a carrier designation at purchase.
scootley said:
Yes they come from Google but you can see on that link you sent that there are Verizon-specific Pixel 3 images (lately).
So if you you manually applied the non-verizon one from that page for a month when there was a verizon one (on the same site, listed right below/above the other images for that month), then later OTAs would presumably fail due to a checksum mismatch.
See here too.
EDIT: I don't think it matters where you bought your phone, but I could be wrong. In other words if you are on Verizon and there is a Verizon pixel image then that is the image that your phone will install even if you bought that phone from Google unlocked and without a carrier designation at purchase.
Click to expand...
Click to collapse
That's interesting. Thanks for the info.
I downloaded the Verizon December factory image, but the system.img checksum in that image does not match the expected checksum either. I'm just going to stick with my manually applied updates for now. I do not want to get any Verizon software on my phone, even if that resolves the OTA issue.
Here's an update:
I got an OTA update notification for the December 2020 Pixel 5 update on 13-January 2021. This is about 7 days after re-rooting and enabling "MagiskHide Props Config" and using it to get SafetyNet to pass and to get my device to be Play Protect certified.
My regular MagiskHide settings have it enabled for:
1) com.android.dynsystem (including every sub-item within it)
2) com.google.android.gms (including every sub-item within it)
3) com.android.vending (including every sub-item within it)
I have no idea if those things are connected or if it's just a coincidence and something else (see my original post at the top of the thread) caused the delay.
Anybody out there who rooted their Pixel 5 with Magisk ever receive an OTA update notification?
I rooted mine during initial setup after I got it and never received a notification for the December 2020 or Jan 2021 update. Checking for an update says there isn't one available.
(The November 2020 update was out when I got the phone and I installed it before rooting)
I also have the Developer setting for "Automatic system updates" turned off and didn't enable MagiskHide or hiding Magisk Manager until a few days ago. But have since unrooted with no luck either.
My "Google Play system update" says "September 1, 2020" and has a red icon and I assume is also out of date.
I asked about this before here but in a different way. Not trying to spam.
See this thread and use it for discussion of more details, causes and solutions.
But you can reply here if you ever received an OTA update notification, or if you are like me and haven't.
The main reason I am asking about this is purely a curiosity on the cause and interest in whether there are other issues that result from the same underlying cause, whatever it is.
Also incremental OTA updates are faster to download/install, can be done without a PC, and nobody consistently publishes their URLs anymore (lots of permutations) so the only practical way to find yours is via the normal process. The OTA images google publishes online are not incremental. They are full. Just like the system images.
Note:
1) I would not intend to try to install the OTA while rooted
2) I know I can download the install the OTA image myself. My main concern is the OTA update check/notification here.
Here's an update:
I got an OTA update notification for the December 2020 Pixel 5 update on 13-January 2021. This is about 7 days after re-rooting and enabling "MagiskHide Props Config" and using it to get SafetyNet to pass and to get my device to be Play Protect certified.
My regular MagiskHide settings have it enabled for:
1) com.android.dynsystem (including every sub-item within it)
2) com.google.android.gms (including every sub-item within it)
3) com.android.vending (including every sub-item within it)
I have no idea if those things are connected or if it's just a coincidence and something else (see here) caused the delay.
I get OTA updates regularly. However, I can't find where the downloads reside. Since these are large files, if I don't delete them, they will grow big time, unless of course, the updater deletes them automatically after installation. My googling tells me they should be under /data/lineageos_updates, but I simply don't see this directory on my phone.
luckysoul777 said:
I get OTA updates regularly. However, I can't find where the downloads reside. Since these are large files, if I don't delete them, they will grow big time, unless of course, the updater deletes them automatically after installation. My googling tells me they should be under /data/lineageos_updates, but I simply don't see this directory on my phone.
Click to expand...
Click to collapse
Your Googling is flawed. Are you running LineageOS?
Android OTAs are stored in a temp directory. They aren't going to fill up your storage.
xunholyx said:
Your Googling is flawed. Are you running LineageOS?
Android OTAs are stored in a temp directory. They aren't going to fill up your storage.
Click to expand...
Click to collapse
Yes, I'm running LOS. I am also glad to know the OTA downloads don't go under /data/lineageos_updates, though it's mentioned all over the Internet. In fact, I haven't come across anyone else mentioned that the downloads go under a temp directory. If this is indeed the case, great. I am just surprised why no one else has mentioned if you google with keywords, "LineageOS OTA download directory"