Database Develop

[TOOL][ROM] UpdateEngine UI -- Flash Android O beta without wiping data

I highly recommend @JamFlux's work instead. Currently, this has got way more complicated than it should be (in the past 24 hours, only 40% users have managed to accurately follow the procedure, and even less for the latest beta). However, I will continue working on this project in order to make it compatible across more devices. The app is now open-source and you can visit the GitHub repo here. Thanks for using UpdateEngine Interface and I hope to see you folks again soon.
I've created the UpdateEngine Interface, a tool to install OTAs that haven't been assigned to your device. It talks to Android's update_engine binary to flash the block-based updates just the way the original updater does, ensuring that your data is preserved and your system partition's signature doesn't change.
TLDR: It allows you to install Oreo without using someone else's TWRP backup or losing data.
Now has the latest build (20th December)
Installation:
Install Magisk
Install the attached Magisk module (named UpdateEngine_1.2.zip) and reboot
Open the newly installed UpdateEngine app and press start
Wait for the installation to complete and restart your device to boot into Android O
If you wish to update to the latest beta, use Magisk to install UpdateEngine_1.3.zip afterwards
Note: If you're a FlashFire user, please uninstall it and reboot before continuing.
Note #2: You must install Oreo via v1.2 before installing the latest beta (via v1.3).
XDA:DevDB Information
UpdateEngine User Interface, Device Specific App for the Xiaomi Mi A1
Contributors
ur0
Version Information
Status: Stable
Current Stable Version: 1.1
Created 2017-12-19
Last Updated 2017-12-19

Does it need a virgin /system?

I love you! thats what we need.

konradit said:
Does it need a virgin /system?
Click to expand...
Click to collapse
Yeah. It requires that the system hasn't been modified since the December OTA (just like the original updater) since the updates are applied block-by-block.

Which beta does it have currently? THE first one or newer?

jazzthe#1 said:
Which beta does it have currently? THE first one or newer?
Click to expand...
Click to collapse
I only have the first build, since that's the only one that people captured (I'm not in the beta, so I can't get the newer ones myself).

Okay

@ur0 wow, thats awesome, thank you bro)

This looks interesting, although I'm waiting for Xposed Oreo. A question though, I've heard the leaked Oreo build is rooted, does this method install untouched boot.img?

@Filip013 yes, this installs the untouched boot.img.
@rostifaner and @TerQQ, You're welcome!

so this tool can install android O ota beta without twrp ? and without losing data ? and how to install this tool ? sorry for many question .

is possible to add feature "choose ota file from device" or something similar ?

TerQQ said:
is possible to add feature "choose ota file from device" or something similar ?
Click to expand...
Click to collapse
I'm looking into adding this -- the only problem is that it also requires a bit of metadata (which is inconvenient to type manually). I'll look into defining a format which the app can read directly.

It doesn't seem to be working for me. When I press Start, it opens FlashFire app & nothing happens. Even if I come back to this app, there will two buttons Pause & Stop, but nothing will be happening. Also can you please make it open source?

ghpranav said:
It doesn't seem to be working for me. When I press Start, it opens FlashFire app & nothing happens. Even if I come back to this app, there will two buttons Pause & Stop, but nothing will be happening. Also can you please make it open source?
Click to expand...
Click to collapse
That's weird -- can you please post the logcat outputs after this happens (maybe after restarting and trying again)?
I'm sure that it's something with flashfire since the app doesn't use it or depend on it.
I'm definitely going to open-source this after I fix a few hacks I made to get the initial version working.

Any chance of posting your work to github? would be interesting to see the source if possible

How to install?
How to install magisk and update engine. Will we have to root and flash these file from TWRP? Please give the tutorial in detail.

for me its working great.

I don't understand what purpose this tool serves. You're saying that using this we can install the oreo update without someone's twrp bakup?

I keep getting a crash when i press start, then the app won't open again until I reboot and even then no download... am i missing something?
I have magisk 15.6 and i disabled all my other modules just in case...
EDIT:
12-19 11:32:16.564 3121-3267/? E/DatabaseUtils: Writing exception to parcel
java.lang.SecurityException: Permission Denial: reading com.android.providers.media.MediaProvider uri content://media/external/fs_id from pid=9022, uid=10111 requires android.permission.READ_EXTERNAL_STORAGE, or grantUriPermission()
at android.content.ContentProvider.enforceReadPermissionInner(ContentProvider.java:608)
at android.content.ContentProvider$Transport.enforceReadPermission(ContentProvider.java:483)
at android.content.ContentProvider$Transport.query(ContentProvider.java:212)
at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:112)
at android.os.Binder.execTransact(Binder.java:565)
I think you need to add the read/write premission to your app. not sure how its working for others
EDIT 2: Selinux is denying your app.. had to use a selinux disabler app to get it not to crash... might want to look into that..
EDIT 3: Not working... Nothing happens when i click start...

[GUIDE] Re-locking the bootloader on the OnePlus 6t with a self-signed build of LOS

What is this tutorial?
This tutorial will:
Creating an unofficial build of LineageOS 17.1 suitable for using to re-lock the bootloader on a OnePlus 6/6t
Take you through the process of re-locking your bootloader after installing the above
This tutorial will NOT:
Remove *all* warning messages during boot (the yellow "Custom OS" message will be present though the orange "Unlocked bootloader" message will not)
Allow you to use official builds of LineageOS 17.1 on your device with a re-locked bootloader (more details near the end of the tutorial)
This tutorial will assume you are working on an Ubuntu 18.04 installation, if you are using Windows or another Linux distro, the commands may be different.
Supported devices:
Current both the OnePlus 6 (enchilada) and 6t (fajita) have been tested, but newer phones should work as well.
For simplicities sake, all further references will only be to the 6t (fajita).
Pre-requisites:
a mid level knowledge of terminal commands and features
a supported phone
a PC with enough CPU/RAM to build LineageOS 17.1 (recommended 8 cores, 24g of RAM)
a working USB cable
fastboot/adb installed and functional
LineageOS 17.1 source code downloaded
at least one successful build of LineageOS
at least one successful signing of your build with your own keys
Misc. notes:
the basics of building/signing of LineageOS is outside the scope of this tutorial, refer to the LineageOS Wiki for details on how to complete these tasks
you'll be modifying some code in LineageOS, so if you are not comfortable using basic editing utilities as well as patch, do not proceed any further
the path to your LineageOS source code is going to be assumed to be ~/android/lineageos, if it is somewhere else, substitute the correct path in the tutorial
the path to your private certificate files is going to be assumed to be ~/android-certs, if it is somewhere else, substitute the correct path in the tutorial
*** WARNING ****
This process may brick your device. Do not proceed unless you are comfortable taking this risk.
*** WARNING ****
This process will delete all data on your phone! Do not proceed unless you have backed up your data!
*** WARNING ****
Make sure you have read through this entire process at least once before attempting, if you are uncomfortable with any steps include in this guide, do not continue.
And now on with the show!
Step 1: Basic setup
You need a few places to store things, so create some working directories:
Code:
mkdir ~/android/fajita
mkdir ~/android/fajita/oos
mkdir ~/android/fajita/images
mkdir ~/android/fajita/images_raw
mkdir ~/android/fajita/patches
mkdir ~/android/fajita/pkmd
You also need to add "~/android/lineageos/out/host/linux-x86/bin" to your shell's profile path. Make sure to close and restart your session afterwards otherwise the signing will fail later on with a "file not found" error message .
Step 2: Download the latest OxygenOS from OnePlus
Go to https://www.oneplus.com/support/softwareupgrade and download the latest OOS update, store it in ~/android/fajita/oos
Step 3: Extract the vendor.img from OOS
Run the following commands to extract the vendor.img from OOS:
Code:
cd ~/android/fajita/oos
unzip [oos file name you downloaded] payload.bin
cd ../images_raw
python ~/android/lineageos/lineage/scripts/update-payload-extractor/extract.py --partitions vendor --output_dir . ../oos/payload.bin
You should now have a ~1g file named vendor.img in the images_raw directory.
Step 4: Update fajita's BoardConfig.mk
You will need to add a few parameters to the end of ~/android/lineageos/device/oneplus/fajita/BoardConfig.mk, they are:
Code:
BOARD_PREBUILT_VENDORIMAGE := /home/<userid>/android/fajita/images_raw/vendor.img
AB_OTA_PARTITIONS += vendor
BOARD_AVB_ALGORITHM := SHA256_RSA2048
BOARD_AVB_KEY_PATH := /home/<userid>/.android-certs/releasekey.key
Note you cannot use "~"" in the path names above to signify your home directory, so give the full absolute path to make sure the files are found.
Step 5: Update sdm845-common's BoardConfigCommon.mk (optional)
LineageOS by default disables Android Verified Boot's partition verification, but you can enable it now as all the required parts will be in place. However, you may not want to if you intend to make other changes to the system/boot/vendor partitions (like Magisk, etc.) after you have re-locked the bootloader.
To enable partition verification do the following:
Code:
cd ~/android/lineageos/devices/sdm845-common
sed -i 's/^BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS += --flag 2/#BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS += --flag 2/' BoardConfigCommon.mk
Step 6: Patch the AOSP/LineageOS releasetools
Two releasetools included with LineageOS need to be patched as they otherwise will not properly process a pre-built vendor.img.
The required patches can be found here:
https://raw.githubusercontent.com/W.../source/add_img_to_target_files.py-17.1.patch
https://raw.githubusercontent.com/W...r/source/sign_target_files_apks.py-17.1.patch
Download both and store in ~/android/fajita/patches.
Now apply them with the following commands:
Code:
cd ~/android/lineageos/build/tools/releasetools
patch add_image_to_target_files.py ~/android/fajita/patches/add_image_to_target_files.py-17.1.patch
patch sign_target_files_apks.py ~/android/fajita/patches/sign_target_files_apks.py-17.1.patch
Step 7: Build LineageOS
You are now ready to build:
Code:
cd ~/android/lineageos
source build/envsetup.sh
croot
breakfast fajita
mka target-files-package otatools
Step 8: Prepare vendor.img
As part of the build process above, your raw vendor.img will been copied to the $OUT directory and a new hashtree (what AVB uses to verify the image) will have been added to it.
You need to use this new version in the signing process but due to how the build system works, this is not done by default.
So, let's put it where it is needed:
Code:
cp $OUT/obj/PACKAGING/target_files_intermediates/lineage_fajita-target_files-eng.*/IMAGES/vendor.img ~/android/fajita/images
Step 9: Sign the APKs
You are now ready to sign the apks with sign_target_files_apks:
Code:
./build/tools/releasetools/sign_target_files_apks -o -d ~/.android-certs --prebuilts_path ~/android/fajita/images $OUT/obj/PACKAGING/target_files_intermediates/*-target_files-*.zip signed-target_files.zip
Note the new "--prebuilts_path" option, which points to where your new vendor.img file is located.
Step 10: Build the OTA
Now it is time to complete the OTA package:
Code:
./build/tools/releasetools/ota_from_target_files -k ~/.android-certs/releasekey --block signed-target_files.zip lineage-17.1-[date]-UNOFFICIAL-fajita-signed.zip
Note, replace [date] with today's date in YYYYMMDD format.
Step 11: Create pkmd.bin for your phone
Before you can lock your phone, you have to tell it what your public key is so it knows it can trust your build.
To do this you need to create a pkmd.bin file:
Code:
~/android/lineageos/external/avb/avbtool extract_public_key --key ~/.android-certs/releasekey.key --output ~/android/fajita/pkmd/pkmd.bin
Step 12: Flashing your LineageOS build
It's time to flash your build to your phone. The following steps assume you have already unlocked your phone and have flashed an official version of LineageOS to it. You don't need to have flashed LineageOS yet, you could use TWRP through "fastboot boot" if you prefer.
Reboot your phone in to recovery mode
In LineageOS Recovery select "Apply update"
From your PC, run:
Code:
adb sideload ~/android/lineageos/lineage-17.1-[date]-UNOFFICIAL-fajita-signed.zip
When the sideload is complete, reboot in to LineageOS. Make sure everything looks good with your build.
You may also need to format your data partition at this time depending on what you had installed on your phone previously.
Step 13: Flashing your signing key
Now it's time to add your signing key to the Android Verified Boot process. To do so, do the following:
Reboot your phone in to fastboot mode
From your PC, run:
Code:
fastboot flash avb_custom_key ~/android/fajita/pkmd/pkmd.bin
fastboot reboot bootloader
fastboot oem lock
On your phone, confirm you want to re-lock and it will reboot
Your phone will then factory reset and then reboot in to LineageOS.
Which of course means you have to go through the first time setup wizard, so do so now.
Step 14: Disable OEM unlock
Congratulations! Your boot loader is now locked, but you can still unlock it again using fastboot, so it's time to disable that as well.
Unlock you phone and go to Settings->About phone
Scroll to the bottom and find "Build number"
Tap on it you enable the developer options
Go to Settings->System->Advanced->Developer options
Disable the "OEM unlocking" slider
Reboot
Step 15: Profit!
Other things
The above will build a standard USERDEBUG version of LineageOS, however this will still allow LineageOS Recovery to sideload non-signed files. If you have implemented step 5 above, then this protects your system/vendor/boot/dtbo partitions, but none of the others. Likewise USERDEBUG builds will allow for rolling back to a previous version. To increase security and disallow both of these scenarios you may want to build a USER version of LineageOS to install. However this brings in other issues, such as flashing newer firmware from OnePlus so make sure you understand the implications of both choices. For more details on build types, see https://source.android.com/setup/develop/new-device#build-variants.
In the above example the releasekey from your LineageOS install has been used to sign AVB, but AVB supports other key strengths up to SHA512_RSA8192. You could create a key just for signing AVB that used different options than the default keys generated to sign LineageOS.
If you want to remove you signing key from your phone, you can do it by running "fastboot erase avb_custom_key".
The changes you made to the make files and releasetools may conflict with future updates that you pull from LineageOS through repo sync, if you have to reset the files to get repo sync to complete successfully, you'll have to reapply the changes afterwards.
So why can't I do this with official LineageOS builds?
For Android Verified Boot (AVB) to work, it must have the hash values for each of the system/vendor/boot/dtbo partitions stored in vbmeta. Official LineageOS builds do not include the vendor.img in them (for fajita at least, other phones may), instead simply using the existing partition on the phone.
That means that there is no vendor.img information in vbmeta for the official builds, which means AVB will fail to verify it during boot and give the red corruption message and halt the boot process after you have re-locked the bootloader.
And since you cannot add to vbmeta without the LineageOS private key, which only the LineageOS signing server has, you cannot add it.
This means you must do a full build with new signing keys to make it work.
Theoretically you could pick apart a LineageOS release, rehash the system/vendor/boot/dtbo and then recreate vbmeta and the payload.bin file, but that brings a host of other issues. For example, since such a "build" would look like a full LinageOS release, if you ever accidentally let the updater run it would brick (soft) that slot and you'd have swap back to your other slot to boot again. In an extreme case, if you managed to corrupt the second slot somehow you'd have to wipe your entire and recover from the brick with one of the available tools to do so.
Ok, what messages do I see during the boot process then?
During a boot you will of course see the standard OnePlus power up screen, followed by the yellow "custom os" message an then the stardard LineageOS boot animation.
For more details on AVB boot messages, see https://source.android.com/security/verifiedboot/boot-flow
So what do those two patches to the release tools do?
AOSP/LineageOS's add_image_to_target_files.py detects if a vendor.img file already exists, and if so, simply includes it in the build process. The patch adds one extra step, so that AVB is being enabled for the build, it will replace the existing hashtree on vendor.img using the same salt and other options as will be used on system/boot/dtbo. This ensure that when vbmeta is generated, it has the right information from vendor.img.
The script is called from the make system as part of the "mka target-files-package otatools" and the appropriate parameters from the make system, like "BOARD_PREBUILT_VENDORIMAGE", are used to create arguments to the script to build the standard image files as well as include the prebuilt vendor.img.
This script is used both during the initial build as well as the signing process, but this change is only targeted at the build time implementation. During signing, the script uses whatever hashtrees are in place and does not regenerate them.
AOSP/LineageOS's sign_target_files_apks.py is responsible for signing the APKs that have been built as part of "mka target-files-package otatools", unfortunately it is not part of the "make" system, so settings like "BOARD_PREBUILT_VENDORIMAGE" do not impact the script. This means that sign_target_files_apks.py does not have any knowledge that it should be including a pre-built vendor.img, even though it is in the $OUT directory waiting to be used.
The patch adds a new parameter to the script (--prebuilts_path), so that during the signing process, any image files found in the provided path, will be included in the process. So make sure that only vendor.img is in the provided directory. This is a directory instead of a single file as future uses may be to include things like firmware, other partition types, etc. in to the signing process.
Thank you's
Obviously to all of the members of the LineageOS team!
LuK1337 for supporting fajita
optimumpro for the OnePlus 5/5t re-locking guide (https://forum.xda-developers.com/oneplus-5/how-to/guide-relock-bootloader-custom-rom-t3849299) which inspired this one
Quark.23 for helping with the process and testing on enchilada

Nice , Will this enable widewine L1?

jsidney96 said:
Nice , Will this enable widewine L1?
Click to expand...
Click to collapse
I don't believe there is a connection between the two.

WhitbyGreg said:
I don't believe there is a connection between the two.
Click to expand...
Click to collapse
If you unlock bootloader on phones supporting L1 they drop to L3. I know some Oneplus phones (op6 etc.) did not support L1 even on stock.

cowgaR said:
If you unlock bootloader on phones supporting L1 they drop to L3. I know some Oneplus phones (op6 etc.) did not support L1 even on stock.
Click to expand...
Click to collapse
Yeah.. It brings it to L1
Great writeup @WhitbyGreg
As Android security gets tighter and tighter, hoping one day all ROMs would support AVB by default..
---------- Post added at 06:16 PM ---------- Previous post was at 05:48 PM ----------
Curious question here,
WhitbyGreg said:
*** will build a standard USERDEBUG version of LineageOS, however this will still allow LineageOS Recovery to sideload non-signed files. If you have implemented step 5 above, then this protects your system/vendor/boot/dtbo partitions, but none of the others. Likewise USERDEBUG builds will allow for rolling back to a previous version. To increase security and disallow both of these scenarios you may want to build a USER version of LineageOS to install. However this brings in other issues, such as flashing newer firmware from OnePlus so make sure you understand the implications of both choices***
Click to expand...
Click to collapse
After a launch of any phone, how drastic are such firmware updates to bother about? In other words, Unless we're in stock ROM is it mandatory to update phone firmware?

arvindgr said:
Yeah.. It brings it to L1
Click to expand...
Click to collapse
Good to know.
arvindgr said:
Great writeup @WhitbyGreg
As Android security gets tighter and tighter, hoping one day all ROMs would support AVB by default..
Click to expand...
Click to collapse
That would be nice but more importantly, more phones need to support re-locking.
arvindgr said:
Curious question here,
After a launch of any phone, how drastic are such firmware updates to bother about? In other words, Unless we're in stock ROM is it mandatory to update phone firmware?
Click to expand...
Click to collapse
Reasonably important, after all, if you never get firmware updates you'll have outdated security patching for the firmware. Some official LOS builds require newer versions of the firmware as they are released and won't install without it.

This guide was very helpful to me when re-locking my Oneplus 7T and enabling hash/hashtree verification. A dude on telegram had actually sent me the link and I only briefly skimmed over. Ironically when looking for patches to fix my issues after attempting to include pre-built vendor/odm and failing I cross referenced and ended up back here.
Here's where I originally found them:
https://review.lineageos.org/c/LineageOS/android_build/+/278015
https://review.aosip.dev/c/AOSIP/platform_build/+/13385
I myself have made some more patches to ensure every possible pre-built image gets signed on my builds. After some experimentation I have found it possible to have Magisk with hash verification enabled
https://github.com/Geofferey/omni_android_build/commits/geofferey/android-10
There is also a fix to ensure appropriate args get passed when regenerating hashtree for pre-built vendor.

Geofferey said:
This guide was very helpful to me when re-locking my Oneplus 7T and enabling hash/hashtree verification.
Click to expand...
Click to collapse
So you can confirm you have relocked the bootloader on the 7T with AVB enabled?
Geofferey said:
A dude on telegram had actually sent me the link and I only briefly skimmed over. Ironically when looking for patches to fix my issues after attempting to include pre-built vendor/odm and failing I cross referenced and ended up back here.
Here's where I originally found them:
https://review.lineageos.org/c/LineageOS/android_build/+/278015
https://review.aosip.dev/c/AOSIP/platform_build/+/13385
Click to expand...
Click to collapse
Yes, those are my patches that I've submitted to LOS, I also have two other patches submitted to allow for other prebuilt images (aka firmware images) to be included in the build process.
Geofferey said:
I myself have made some more patches to ensure every possible pre-built image gets signed on my builds. After some experimentation I have found it possible to have Magisk with hash verification enabled
https://github.com/Geofferey/omni_android_build/commits/geofferey/android-10
There is also a fix to ensure appropriate args get passed when regenerating hashtree for pre-built vendor.
Click to expand...
Click to collapse
I'll take a look and see if I need to update any of my submissions, thanks.

I will have to update those commits with you as author. I messed that up and set person who picked yours as author. I am sorry. BTW thank you for those patches they were a lifesaver and inspired me.
Yes, I can confirm re-lock with AVB enabled on 7T works and also with hash verification. If I flash an image not signed by the build process with hash verification enabled I go red. Currently I am working on getting magisk directly integrated with build instead of using prebuilt patched imgs that cause builds to not pass CTS.

Geofferey said:
Currently I am working on getting magisk directly integrated with build instead of using prebuilt patched imgs that cause builds to not pass CTS.
Click to expand...
Click to collapse
Why do you want to put Magisk if you went to all the trouble of having avb with a locked bootloader? Isn't rooting defeating the purpose of avb?

quark23 said:
Why do you want to put Magisk if you went to all the trouble of having avb with a locked bootloader? Isn't rooting defeating the purpose of avb?
Click to expand...
Click to collapse
No, it does not defeat the purpose... Hashtree verification will still happen since root can be included in the build as opposed to flashing after the fact. In a way it's actually even more advised. The way I think, having root may lead to a means of being exploited but true AVB closes the door to any persistent rootkits that may try to modify partitions at block level. If ANYTHING modifies the verified partitions phone will refuse to boot and I will be protected. Doing exactly what AVB is supposed to do, verify the phone is in it's intended state. I also think of phone as a computer, you have root access on Linux, Windows and even Mac for Christ sake, why shouldn't it be the same for phones? The ONLY reason we don't by default is so manufacturers and carriers can stay in control. I've been rooting and modifying phones for years without AVB and yet to have a known breech of my data besides the Google apps constantly collecting on me. This just adds another level of security that I used to sacrifice in order to have root access.
Here is my PoC to include Magisk in builds so dm-verity can be kept enabled. Just two commits. If someone could make this better that would be really cool.
https://github.com/Geofferey/omni_android_build/commit/d60958780e6b26d7cb0cec5939b82df3df74a68f
https://github.com/Geofferey/android_vendor_magisk

I have rooted for testing and you don't gen any warning. The way avb works on my phone is it discards any modification after reboot. With no warning at boot time. If you get hacked, you can have persistent hacks with root. Make a modification from twrp with avb enabled and see for yourself.
You break the Android security model by rooting the phone. If you need certain things you can include them at build time, such as a custom hosts file.
Also, what can you do with root that does not alter the hashtree?
The power you mention is of no real use yet you expose yourself by having it. Sure, you can go by without any issues. The problem is if you happen to get hacked, the attacker has full control over your phone. You won't br able to get rid of it by rebooting.
Also I see no way for google to collect data in this setup, with or without root. Afwall has an equivalent in android 10 (that mobile data & wifi setting) and inter process comms are the real issue if you are worried about rogue apps. Afwall leaks dns requests like crazy anyway.
I say you are better off letting root go and include what you need at build time. I see that as better spent effort than trying to add root.

quark23 said:
I have rooted for testing and you don't gen any warning. The way avb works on my phone is it discards any modification after reboot. With no warning at boot time. If you get hacked, you can have persistent hacks with root. Make a modification from twrp with avb enabled and see for yourself.
Click to expand...
Click to collapse
So you built your ROM from source with root included, had TWRP go through signing and was able to modify system and other partitions without receiving a device corrupt message? I highly doubt AVB is even implemented appropriately if you were able to do so. If it is implemented it sounds like the old version, tho I remember if I violated FS too much it wouldn't be able to fix and failed to boot. Having a locked bootloader because AVB is enabled does not mean dm-verity is enabled. Also, it should be nearly impossible to just write things like files to /system or w.e. if you are on a device that ships with 10.
quark23 said:
You break the Android security model by rooting the phone. If you need certain things you can include them at build time, such as a custom hosts file.
Click to expand...
Click to collapse
I know it does, but I am not doing such small things as modifying a host file. The kinds of things I include in my personal ROMs require such a high level of access to the point where I can not write SE polices that will allow me to pass CTS and spit out user builds without serious modifications to the build env.
quark23 said:
Also, what can you do with root that does not alter the hashtree?
The power you mention is of no real use yet you expose yourself by having it. Sure, you can go by without any issues. The problem is if you happen to get hacked, the attacker has full control over your phone. You won't b able to get rid of it by rebooting.
Click to expand...
Click to collapse
The act of flashing Magisk is what breaks AVB, if you include it in the ROM at build time like I am doing then it doesn't need to be flashed. It makes modifications to the system by binding data from the wipeable data partition to /system/. If something utilizes that to install a backdoor or tunnel it goes bye-bye when I wipe. If something utilizes it to flash anything or modify system device no boot.
quark23 said:
Also I see no way for google to collect data in this setup, with or without root. Afwall has an equivalent in android 10 (that mobile data & wifi setting) and inter process comms are the real issue if you are worried about rogue apps. Afwall leaks dns requests like crazy anyway.
Click to expand...
Click to collapse
You're kidding right? Android solely exist as a mean for Google to collect data. That was the whole idea behind Android. Buy & develop an OS that any manufacturer can put on their device, let them certify for Google Play Services and collect the data that powers their ad platform. They certainly didn't opensource their baby for free. If you allow ports 80 and 443 out with inbound related allowed, that's all they need.
quark23 said:
I say you are better off letting root go and include what you need at build time. I see that as better spent effort than trying to add root.
Click to expand...
Click to collapse
I'd just rather the manufactures and Google would implement a root solution that plays nice with Androids security instead of making us resort to violating it. It's funny to me that we find it acceptable for these fools to maintain control of something you purchased with your hard earned dollars because they think we are too stupid to have it. Like I stated root and admin privileges are fully available to us on nearly any PC but phones for some reason are an exception.
_________________________________________________
I could rant and debate about this forever... Fact of matter is, you don't have to disable every Android security feature to have root.

I didn't build with magisk, I just flashed after building.
But you can try and modify anything on /system or /vendor from twrp, without magisk, without locking the bootloader, and see what happens. Avb discards the modification, but doesn't warn you. Curious of your findings regarding this. If you then flash magisk, you ofc break the hashtree and avb and the mods remain persistent.
I understand that you are building with magisk included in the hashtree. What I am wondering is what exactly are you wanting root for? What are you doing with root that does not break the hashtree?
Regarding the data collection, you lost me. What exactly is being collected on a LOS userbuild without google services? Got any dns logs or mitm wireshark packets to show? What service exactly is collecting what kind of data? Google's dns servers can be replaced before building, Greg has some scripts for that. Captive portal can also be replaced or turned off. Apart from that, and any apps you add yourself, what kind of data is being collected as I want to check it out myself. I've monitored my phone and it's pretty silent. Whatever goes out is from additional apps I use. But I don't see anything from LOS. Really curious about this.
Regarding your last point I think it's something akin to risking shooting yourself in the foot by having root by default. I understand (somewhat) the security model and I find it smart to not have it by default. Also Android uses selinux more than your standard linux distro does. There are some differences in the security models between android and pc linux distro.
I'm really hapoy that AOSP exists. Also pretty happy with the LOS project. My problem is with the outdated blobs. Maybe I'll get a Pixel at some point and give GrapheneOS a go. Seems like a really nice project.
Managed to get hardened malloc + Vanadium on LOS atm and I'm liking the browser. Overall I think AOSP is a great project. Not a fan of google's privacy policy but they do make great stuff.

quark23 said:
I understand that you are building with Magisk included in the hashtree. What I am wondering is what exactly are you wanting root for? What are you doing with root that does not break the hashtree?
Click to expand...
Click to collapse
Ah, there lies the real question. I am including in my personal builds a Debian Linux chroot that gets extracted to /data/ so I can run Linux services, etc. I have customized the chroot with Openvpn so that it connects to my server and essentially allows me back into device wherever it may lay. Basically I am adding in the stuff of nightmares that all this security is supposed to prevent. That is why I want dm-verity, because I know I am leaving my self partially open by doing so. I have a decent understanding of dm-verity and have confirmed that it does and will protect me against the scenarios I imagine. BTW it operates completely differently in locked state vs. unlocked.
quark23 said:
Regarding the data collection, you lost me. What exactly is being collected on a LOS userbuild without google services?
Click to expand...
Click to collapse
Well, if you're the type of person who doesn't require Google Play Services, nothing of course. I was merely stating that Google had open sourced Android in hopes that manufacturers would adopt the OS and qualify their devices for Google PS so that it could be used as a data collection platform. You won't easily see all the information Google collects in a Wireshark log because it is encrypted of course. LOS better be silent as hell without it or I'd contact that dev with a strongly worded message lmfao.
quark23 said:
Regarding your last point I think it's something akin to risking shooting yourself in the foot by having root by default. I understand (somewhat) the security model and I find it smart to not have it by default. Also Android uses selinux more than your standard linux distro does. There are some differences in the security models between android and pc linux distro.
Click to expand...
Click to collapse
Oh I DO NOT think it should just be enabled by default. If I had my way it would be enabled in dev ops requiring authentication and protected via a different password than the one you use to unlock the device once setup. You'd also require those "root" privileges to OEM unlock once enabled. While those features were enabled you'd be warned on boot as well but without locking you out of apps etc because that kind of sensitive data should be handled by TEE and TZ. In a real Linux operating system that hasn't been fundamentally raped to offer a false sense of security in the name of protecting carriers and manufactures you can modify SE linux policies etc, not while live but without compiling from source. A lot of us forget most these security features exist more to protect their interest and attempt to hide what's going on behind the scenes. I've actually heard of some pretty shady stories where manufacturers in China place ad-tappers that run in background on devices running GooglePS to be sold in US, so it definitely doesn't protect you if the person building your phone is shade.
quark23 said:
I'm really hapy that AOSP exists. Also pretty happy with the LOS project. My problem is with the outdated blobs. Maybe I'll get a Pixel at some point and give GrapheneOS a go. Seems like a really nice project.
Managed to get hardened malloc + Vanadium on LOS atm and I'm liking the browser. Overall I think AOSP is a great project. Not a fan of google's privacy policy but they do make great stuff.
Click to expand...
Click to collapse
Me too mate. . AOSP has taught me a lot about development and coding in general. Sadly outdated blobs are a usually a by-product of using pre-builts from manufacturers that don't update as often. Pixel would be way to go if that's a concern. I honestly just think a lot of the security is abused to suit their needs. I am just trying to turn it around to work for me where it can.

If you repo sync you should run the vendor files script as there's a couple of new files added. The Muppets github has been updated with them as well. If you don't your build will fail at first power on.

A quick question, forgive me if this is obvious: am I correct in assuming that one the above has been completed and the device is using a locally-built copy of Lineage OS, that I cannot take advantage of OTA updates? I just want to know what I'm getting in to before wiping my phone multiple times.
Thanks in advance, this thread is massively helpful.

nictabor said:
A quick question, forgive me if this is obvious: am I correct in assuming that one the above has been completed and the device is using a locally-built copy of Lineage OS, that I cannot take advantage of OTA updates? I just want to know what I'm getting in to before wiping my phone multiple times.
Thanks in advance, this thread is massively helpful.
Click to expand...
Click to collapse
Correct, though if you setup your own update server you can still use the inbuilt updater app if you want.

I just happened across this thread searching for a proper way to generate the custom avb key. I thought i had found it at one time on aosp documentation but i lost/forgot where it was.
Anyways, I have a quick q about this. Would I be correct in assuming that if i wanted gapps to be available in my build, I would need to include it during build time and not be able to flash it as per the typical methods?
I am pretty sure I won't be able to but wanted to ask here for you guys' experiences.
Also, @WhitbyGreg you should be able to i believe. just setup the url properly and host it somewhere with direct download links. (This also requires setup of json for the updater to monitor for updates)

klabit87 said:
Would I be correct in assuming that if i wanted gapps to be available in my build, I would need to include it during build time and not be able to flash it as per the typical methods?
Click to expand...
Click to collapse
Correct (at least as far as I know), once the bootloader is relocked any modification of the system partition (like adding the play services) would trigger an AVB failure.

Does Magisk prevent OTA update checks/notifications (Pixel 5)?

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.

Has anyone with a Magisk rooted Pixel 5 ever received an OTA update notification?

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"

Question Ozip updates

[SOLVED]
[SOLVED] OTA manual update for every version to last possible [FIXED] - FINALLY
SOLVED : https://forum.xda-developers.com/t/ota-manual-update-finally.4368411/post-86021225 [ORIGINAL] New quest : https://github.com/R0rt1z2/realme-ota/ Thx to Roger Ortiz R0rt1z2 When I'll have time to do that ... Looking forward for...
forum.xda-developers.com
Greetings.
I still cannot find any official os updates in *.ozip for RMX3801
like : https://download.c.realme.com/osupdate/RMX2170PU_11_OTA_0410_all_I1IugkGtNk13.ozip for RMX2170PU from Egypt.
Need an possible update from .28 --> .41
Getprop infos :
[persist.sys.oppo.otaversion.before]: [RMX3081NV44_11.A.28_1280_202104090211]
[persist.sys.oppo.otaversion.last]: [RMX3081NV44_11.A.28_1280_202104090211]
[ro.build.display.ota]: [RMX3081NV44_11_A.41]
[ro.build.version.ota]: [RMX3081NV44_11.A.41_1410_202108181828]

Currently trying to install wireless adapter to be able to spy on communication on computor as use of AP to phone and checking the protocol headers to gain url to official servers for OTA update. I know that the .28, .41 and .42 ota are on server, but since I cannot gain access (ROOT) the folder on phone i can't get the upgrade files from the phone.
Official updates (IN) in https://www.realme.com/in/support/software-update is not available for R8 Pro.

Been able to get sniff packages via vpn traffic sniff.But since the HTTPS was used the diagnostic would be extremely hard.
Anyone know how to decode package trafic via SSL (HTTPS).
If any1 can use proxy/VPN like PolarProxy to intercept TLS traffic (When checking update status or downloading the update) and save the decrypted data to a PCAP file or get the download location and possible GET/POST headers it would be nice to get update zip binary from this zip or the whole ozip file, so we can flash files/images wia current recovery.