|
> (c) security updates or corrective updates mentioned under point (a) need to be available to the user at the latest 4 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand; > (d) functionality updates mentioned under point (a) need to be available to the user at the latest 6 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand; So if Google releases an update for Pixel, the 'clock' starts ticking from that date, otherwise, it goes by when the source code is released. Google can pick and choose what works best for them and their partners according to these rules. Hence why delaying the source code may be preferable. This is why security patches are being delayed as per GrapheneOS (under embargo) For example: Google releases Android 20, under embargo to all OEMS, this is not released on Pixel, is entirely closed source (hence why AOSP is now private) and therefore doesn't trigger the law. Android 20 could be ready for months, but until it's released on Pixel or open source, those clauses are not triggered. This is already happening to security patches, see my comment above. |
A more correct expectation would be that now Google will start delaying all security updates (both binary and source) until all their important downstream vendors are able to release in time.
Even that is doubtful, as Google would have to take the reputational damage for an ongoing exploitation of a security issue.
The functional updates though might get slowed down.