[General Questions and Answers] Lusty Rugnuts:
Ok, the synopsis of the Google OTA (Over The Air) updates issue...

TL;DR version:

Google OTA updates disregard Settings > Developer Options > Automatic system updates setting, downloads update_s.zip to /cache, then forces an unannounced and unsolicited reboot to try to install the update. I suspect this is so Google can surreptitiously reinstall deleted apps and regain retracted permissions for their apps, as means of continuing to gather personal data via the phone.

The long version:

When the phone boots, Google dynamically writes GoogleOtaBinder into /service_contexts, which registers it as an OTA system update provider. The GoogleOtaBinder disregards Settings > Developer Options > Automatic System Updates being disabled by the user, downloads the update_s.zip file to /cache, then reboots the phone (I assume it expects to reboot into fastboot mode to install the update).

With a rooted phone and with TWRP as bootloader, there is no fastboot mode anymore, so the phone boots to the TWRP recovery mode main screen and just sits there until it's manually rebooted. Google Play Services forces the reboot at exactly midnight each night if the update_s.zip file is sitting in /cache. If not, it'll try to download the update_s.zip file, then it'll reboot the phone.

If the update_s.zip file is deleted from /cache, and Google Play Services cannot connect to download it, no reboot occurs.

It just so happens that the first time this occurred, I was installing an Xposed Framework module. The unannounced forced reboot by Google Play Services borked the module installation, and rendered the phone unusable. Luckily, I had a recent backup which I pushed to the phone from the computer, then used TWRP Restore.

There remains the nagging questions:

- Why does Google's OTA system updater disregard user settings which disable automatic system updates?

- Why does Google reboot the phone unannounced?

- Why does Google reboot the phone unannounced, at midnight, when the phone is least likely to be monitored?

- Why does Google dynamically write GoogleOtaBinder into /service_contexts at boot, rather than hard-coding it in so it can easily be commented out, thereby disabling Google OTA updates?

- Why doesn't Google provide a user-interface-accessible means of turning off Google OTA updates?

I have my suspicions that they do all the above because it allows them to surreptitiously push system updates to reinstall apps and regain permissions so that they can continue to collect personal data via the phone, personal data collection and monetization being their modus operandi.

I'm still searching to find where Google is writing to /system_contexts from during boot, so I can permanently quash their OTA 'feature'.

Until then, I've renamed /system/etc/security/otacerts.zip so GoogleOtaBinder cannot communicate with the OTA update server.

{UPDATE}

If you rename /system/etc/security/otacerts.zip to /system/etc/security/otacerts_bak.zip, the GoogleOtaBinder will still download update_s.zip to /cache and attempt to install it... I'd surmise that the prominent search results pertaining to this recommend renaming the file to otacerts_bak.zip, so Google, in an attempt at regaining deleted apps and retracted permissions so they could continue to collect personal data to earn money, decided to simply code for that so they could still push system updates surreptitiously, without the user's knowledge or consent.

I've renamed that file... something else.

{/UPDATE}