This makes no sense, Android already will reboot itself after receiving an update and being inactive for a while (generally while charging it will install the update in its secondary partition, do some verification checks and reboot if there is no user interaction).
This sounds vendor-specific and not general for Android. I've never had that happen on any device but Windows and I would be very upset if it did happen.
This is default on iOS and on many Android versions.
It's often configurable, but e.g. carrier policy or local vendors can enforce it.
To have updates automatically install overnight is the maximally desirable scenario - waiting for user approval usually result in open vulnerabilities, and if you interact with a prompt you are by definition using your device and it is therefore a much worse time than while you're asleep.
On Android, my experience has been that new major versions are often unstable / involve some risk of bricking / include feature regressions (dumbing down of multi-task in Android 13 if I remember well). Waiting for a few month before installing a major update, while not optimal for security, is necessary to make sure that the most critical bugs are fixed beforehand.
Regarding applications, today there's so many applications being always updated all the time that there's no way it's good for the flash memory to constantly rewrite it every day. Plus this often leads to random application restarts while they are updated automatically. (and non-OSS applications updates can result in unwanted changes such as more ads, random changes in UI...).
It's still possible to disable automated updates on Android and I am glad that they allow it.
Major version upgrades are a different type of upgrade altogether. They are optional while the previous major is still maintained.
Minor upgrades is what should always be automatic.
> Flash wear
No, it doesn't matter.
Total write endurance (i.e., the number of bytes written the device is designed to handle under some standard load) is usually a large multiple of the chip size itself - say, 200x-400x, so e.g. 100TB of writes for a 256GB setup. A particular workload is only really meaningful to flash wear if it is in the scale of several full storage rewrites during the lifetime of the device.
The exact write endurance depends on the exact configuration (specific chip selection, allocated reserve), but even microSD cards have wear levelling these days.
Your device is going to die or be retired with a certain flash write wear, but I find it extremely unlikely that your device will die of a flash write wear. The wear endurance is dependent on the specific flash setup.
A much larger cause of wear is app caches (e.g., streaming video continously overwriting a disk cache, browsing social media). If you take pictures, those might end up written multiple times as first the original is written, then the automatically processed version, then any edits you make, then if storage saving measures is enabled maybe its deleted and a compressed version is written, if you later open the app the original is downloaded and written again, ...
> They are optional while the previous major is still maintained.
I don't think there is such a choice on Pixel phones but I'd be happy to be proven wrong. When the next major update is available the phone just asks to update to it every few days (but won't do it without user consent). I don't think there's security updates on a given phone for old major versions when a new one is available (there likely are for older phones that don't get the major update however).
Thank you for your explanations on flash wear, makes sense. Taking a low value of 13TB endurance (64GB times 200), this is still 7GB per day for five years and I don't think app updates can consume that much.
On Android? It must be an app-specific issue because it's possible for apps to implement alarms so that they work before unlocking the device after a reboot, but I don't know the technical details behind it.
I've had that happen a few times and the alarms went off on time but they used the default alarm tune instead of the one I had selected, presumably that data was still encrypted.
Android actually have a special mode for apps that needs to work after a reboot (e.g.: while the FS encryption is still locked), and Alarms is one of the apps that uses this special mode. I don't remember how it is called though so sorry for the lack of sources, you will have to trust me on this one.
The amount of misinformation in this thread is huge though. I generally read every changelog for major Android updates and the amount of engineering going on is amazing. People just assumes that a few things doesn't work while they do.
Unless of course OP is using a custom alarm app this may be true, but then it is the app fault and not Android.
I haven't had that happen on iOS, but I have woken up in the night needing my flashlight just to find my phone applying a lengthy update. I have it set to download automatically and install manually now, I believe.
I haven't had any problems in at least 7+ years, but I work in coffee and I can remember at least two instances where an Apple update made half the staff late by turning off their alarms, myself included.
I like an amber booklite, it isn't as compact but the light is better for keeping in the sleep mode. We used those as our lights to help develop our child's sleep hygiene. Cupped our hands around the light part as we puttered around.
I do, in my nightstand. In the event of an emergency where we’re without power, I do not want to waste my phone’s battery power by using it as a flashlight.
