How does a typical OTA update happen?

graphenediscoverer4

Let's say a new build is released, is there a prompt for the user to agree downloading and installing it, or is it done automatically at night while charging if user opted for it?

I've read some stuff saying that memory is partitionned in OS_A and OS_B so that phone is never bricked when an upgrade fails (battery extincts, etc.). Are endusers able to revert back to their older build if the new one doesn't suit them?

GGORG

Screenshot of the System Update Settings screen: https://i.imgur.com/fiew2CT.png

I think these options describe it perfectly.
So unless you disable it, updates are downloaded and installed automatically, after which your phone also reboots without any confirmation prompt.
This is very, very useful. Sometimes I don't even know that my phone has updated besides the notification "Finishing system update..." and the fact that I need to enter in my PIN instead of using my fingerprint.

graphenediscoverer4

GGORG

Thank you, is updating system apps from Apps possible while not updating the OS ?

I read that as of December 2023 android Auto works in gOS. Does it come from the playstore or is it served by the "Apps" gOS app repo ? Will it work with older builds?

de0u

graphenediscoverer4 Is updating system apps from Apps possible while not updating the OS ?

Though not recommended, it will often mostly-work for a limited time. But at some point a new version of some app will require some feature of a newer OS release. There is some support for holding back a new version of an app until the underlying requirements are met, but it is possible for a dependency to fall through the cracks (presumably the GrapheneOS developers have limited resources for testing new versions of apps on old versions of the OS, and things that aren't tested don't work as well as things that are).

Meanwhile, a large fraction of security fixes are to the base system, so being behind poses risks.

GrapheneOS

graphenediscoverer4 It's unsafe to remain on an older release of the OS without current privacy and security patches. You shouldn't be considering it. You should make sure you're always on the most recent patch level.

Sandboxed Google Play is only supported on the latest release for the device. If you're on an end-of-life device, that means being on the latest extended support or legacy extended support release. Once extended support and legacy extended support end for a device, sandboxed Google Play will gradually degrade due to continuing to receive Google Play updates without the required changes for newer versions.

We also can't provide support to users on older releases in general. We can't accept issue reports or support requests if you aren't staying updated. The older releases of the OS have no support.

GrapheneOS

@graphenediscoverer4 You will not have the basics of privacy and security until you move to a fully supported device and remain updated. Currently, you're holding yourself back from having the benefits of GrapheneOS. You seem to have stayed on that outdated device because you didn't consider using USB-C headphones, but holding back updates or purposely moving to an ancient release will make things even worse. At the moment, you're inherently missing several months of privacy/security patches for drivers, firmware and other device specific components. If you stay on an older release, you'll be missing far more than that. There's little point spending so much effort trying to learn about and improve your privacy and security if you're going to ruin it with these choices. Strongly recommend that you take a look at what you're missing if you hold back updates. This is for February:

https://source.android.com/docs/security/bulletin/2024-02-01
https://source.android.com/docs/security/bulletin/pixel/2024-02-01

You inherently have many unpatched Qualcomm driver and firmware privacy and security vulnerabilities from an end-of-life device. Holding back updates will leave you with further unpatched privacy and security issues.

Note that Moderate and Low severity Android vulnerabilities are fixed in the monthly/quarterly/yearly Android releases but aren't listed in the Android Security Bulletin because they aren't backported.

graphenediscoverer4

GrapheneOS you didn't consider using USB-C headphones

Yes because it would accelerate significantly the degradation of the USB-C port, and sadly google has made the choice, on models newer than p4a, to solder it to the main board. I'm good at microsoldering, but dead USB-C (24 tiny pins), like HDMI ports, require a microscope to be replaced, which I don't have yet, and even stuffed and experienced repairmen that do it as their daily job risk tearing the mainboard.
Even if the backup process in gOS was seamless, I personally don't have the financial ressources to store a spare modern pixel in case the dailydriver wears out. So in my opinion the usage options really narrow down to BT listening only on newer models.

Anyway thank you very much for the sources, so far I always thought as a moron that some upstream google patches were broadcasted to increase their control over users, thank you so much for demystifying it and enabling me to actually check their commits

graphenediscoverer4

GrapheneOS At the moment, you're inherently missing several months of privacy/security patches for drivers, firmware and other device specific components.

Also I read elsewhere that p4a not supporting exFAT thumbdrives was due to its kernel, now I remember that back in the days there used to be flashable .zip kernels in the wild(xda). Yet I don't know if

it's as easy as grabing an already tailored one and incorporating it (if its sources are public) in the next compilation,
nor if "extended support" for p4a means not supported anymore (anyway it soon won't be anymore at least so I'd understand that it's not worth it for you guys on a mission)