We don't keep support for end-of-life devices very long since it's not possible to provide a reasonable level of security. We tend to do it for a while mainly so we can inform people about it via a notification at boot. At a certain point, we're doing more harm than good.

It's quite doable to port a device to new major Android system image versions now due to Treble. However, it likely does more harm than good to do it without patches for what's underneath.

LineageOS won't provide those hardware-related patches. It has a significantly weakened security models and delayed patches even on a supported Pixel. That makes little difference on a Pixel 3a since the userspace AOSP patches don't matter more than the missing kernel patches. It has an end-of-life Linux kernel with barely anything backported.

It would still have remotely exploitable radio vulnerabilities even with Linux 6.18 with full rewrites of the drivers.

It has gone over 4 years without updates the firmware, kernel, drivers and HALs. That includes many critical vulnerabilities usable to take over the device remotely or from an app. It's also essentially not going to have working encryption in After First Unlock state. The secure element wasn't as hardened and is known to have been exploited by commercial exploit vendors but encryption would work with a strong passphrase when at rest. It's not a good situation.

We're partnered with Motorola Mobility which is a wholly owned subsidiary of Lenovo. It's an entirely separate company from Motorola Solutions.

Those haven't been part of the same company since all the way back in 2011 when they were split apart. Motorola Mobility was subsequently acquired by Google in 2012 and sold to Lenovo in 2014.

We're partnered with Motorola Mobility which is a wholly owned subsidiary of Lenovo. It's an entirely separate company from Motorola Solutions.

Those haven't been part of the same company since all the way back in 2011 when they were split apart. Motorola Mobility was subsequently acquired by Google in 2012 and sold to Lenovo in 2014.

We're partnered with Motorola Mobility which is a wholly owned subsidiary of Lenovo. It's an entirely separate company from Motorola Solutions.

Those haven't been part of the same company since all the way back in 2011 when they were split apart. Motorola Mobility was subsequently acquired by Google in 2012 and sold to Lenovo in 2014.

It isn't possible to provide GrapheneOS in the form of a GSI. GrapheneOS has core privacy and security protections requiring kernel and driver changes. The project you linked doesn't include the kernel hardening, USB protection, hardened_malloc, MTE, various userspace features depending on kernel changes, verified boot and other unlisted features. Various other features were disabled by default. Many features only partially work. GrapheneOS is based on AOSP 17 but this isn't yet.

It happens very late in the boot process after the boot is considered successful. It can complete before unlocking but it's common to have time to unlock before it finishes. It's asynchronous and doesn't block the booting process.

The OS disables automatic rollback prior to updating the anti-rollback values for both the OS and the firmware. For the firmware, it triggers updating fuses to the current value in the firmware rather than a specific hard-wired value.

We've seen a lot of hardware failures. It can be hard to tell if it's a hardware failure initially especially since it's a pain for people to test a factory reset or flashing the stock Pixel OS again. We end up learning which kinds of tracebacks from the Bluetooth stack, Linux kernel, etc. are caused by hardware failures and can quickly identify a lot of them. If it's a frequent issue then people can usually confirm by flashing stock. We deal with it regularly.

Fastboot mode is a boot mode of the littlekernel-based bootloader. It's the same component which loads the Linux kernel and transfers control to it but booted into a user-facing interface mode where it enables a USB stack instead.

SoC firmware including the littlekernel-based bootloader and earlier stages is simply stored on the SSD. Initial stage is loaded, verified and run by the boot ROM. A dead or corrupted SSD can break fastboot, but so can other hardware.

No, since fastboot mode is provided by the littlekernel-based bootloader loaded by the SSD. If the current boot slot bootloader is broken and the device isn't in a post-update mode where it automatically rolls back to the other slot then the device is bricked. This can't generally happen when the device is locked. An unlocked device is a lot less reliable even without using fastboot mode directly. Verified boot helps it avoid getting bricked in multiple ways.

Updating is very demanding for both the CPU and SSD. It's a lot more demanding than how people typically use a phone. If it's approaching failure then updates are a common place that's going to happen. Pixels don't seem to be particularly unreliable but rather something like 1% to 2% of hardware failing is the norm. Some models are less reliable than others though. 8th gen had a lot of Wi-Fi/Bluetooth chip failures. A few 'a' series had a lot of battery failures.