10 ms·

If you're wondering for a possible reason and whether google is just being "lazy", see [1]. Tl;Dr: google has certain commitments they need to make depending o

If you're wondering for a possible reason and whether google is just being "lazy", see [1]. Tl;Dr: google has certain commitments they need to make depending on when the source code is released. Expect more delays moving forward thanks to this law. [1]: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AJOL_2023_214_R_0003 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AJOL...

charcircuit 10mo ago
>google has certain commitments It reads to me like the opposite. Another case of manufacturers being unable to release updates in a prompt manner. Google delaying the release gives them more time to update.
userbinator 10mo ago
it has an integrated touch screen display with a viewable diagonal size of 10,16 centimetres (or 4,0 inches) or more, but less than 17,78 centimetres (or 7,0 inches); I wonder if 3.99 inch and 7.01 inch smartphones will start appearing again.
- pmontra 10mo ago
  That should be easy for foldables: an external sub 4" display and an over 7" main display.
- tensegrist 10mo ago
  > where the device has a foldable display or has more than one display, at least one of the displays falls into the size range in either opened or closed mode. also this: does this mean that foldable phones with three 3.99" screens are excluded
realusername 10mo ago
Parts of AOSP like the apps have been in limbo for way longer than that, maybe since Android 12.
codethief 10mo ago
> certain commitments they need to make depending on when the source code is released …or when OS updates are released, see Annex II B 1.2 (6) (c) and (d) ("Smartphones" > "Design for reliability" > "Operating system updates") So given that the updates were already released months ago, the release of the source code is irrelevant.
- aboringusername 10mo ago
  And what does 'released' mean in this context? GrapheneOS has very publicly stated that security patches are under embargo, and they already have patches for the March 2026 release. See [1]: > 2025110800: All of the Android 16 security patches from the current December 2025, January 2026, February 2026 and March 2026 Android Security Bulletins are included in the 2025110801 security preview release. List of additional fixed CVEs: So, have they been released? No. So the clock hasn't started ticking yet. This EU law made security worse for everyone as patches that are done today are not released for 4+ months. Note: These are CLOSED source blobs GrapheneOS is shipping. If they were open source, the 4 months clock would trigger immediately but they are not allowed to do this themselves as they get the patches from an OEM partner. GrapheneOS shipping these CLOSED source blobs, that Google has NOT released does not trigger the timer. I do accept that QPR1 was 'released' by Google on Pixel months ago, and therefore the timer started, however, Google will likely pick and chose what is best for OS updates/security patches. It explains why AOSP is now private/closed source and embargos are being used to get around the laws requirements. [1]: https://grapheneos.org/releases#2025110800 https://grapheneos.org/releases#2025110800 From the EU law: > (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;
phoronixrly 10mo ago
What? Please explain what commitments exactly are causing Google to not release source code at the same time as the update. Until you do that, your statement is as valuable as writing 'Thanks, Obama!'
- berkes 10mo ago
  Yea, GP sounds like they want to drag "EU Bad" into this discussion. I fail to see how this EU regulation promotes releasing software Closed Source and demotes releasing it Open Source.
  - aboringusername 10mo ago
    > (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.
    - phoronixrly 10mo ago
      So EU mandates that security updates in either source OR binary form must hit all users in at most 4 months after they are first published, therefore Google started delaying releasing source code and will start delaying it even more? 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.
xzjis 10mo ago
This has absolutely nothing to do with that law, and even Google doesn't dare use it as an excuse for its behavior (as they did with GDPR by deliberately creating user friction that the European regulation did not require, and even partially forbids). In reality, it's a purely political decision to curb the development of third-party ROMs, because the AOSP source code exists with all the merges and is distributed to vendors (like Samsung). However, it's not necessarily just to target GrapheneOS and LineageOS; it might also be to target the Chinese market, particularly Huawei, which uses this source code for HarmonyOS.
- aboringusername 10mo ago
  It absolutely has everything to do with this new law. For the first time, depending on when Google releases source code, or releases a Pixel update, the timer (4 months for security, 6 months functionality) starts. This has never existed before in Android OS' history that updates are timed (in law) according to Pixel updates/software updates or open source releases. This law also applies to Apple but they will have no problems as they are compliant anyway as they control software/hardware entirely and it's closed source. This is the entire reason AOSP went private/closed source, and why Google is delaying security patches as per GrapheneOS. The March 2026 patches are already released by GrapheneOS as closed source blobs. They are not allowed to release them as open source by embargo (essentially NDA). Why do you think Pixel hasn't shipped security patches earmarked for March 2026? There are some critical bugs those patches fix, why not release them today, right now or next month? Because if Pixel releases just a single patch, via a Pixel update or posts it on AOSP, the 4 month timer begins for every single OEM with a phone in the EU. By making the patches under embargo, Google gets to control exactly when the timer starts to coordinate with their OEMs. So the slowest OEM gets to control the entirety of Androids security model. Ask yourself, why doesn't GrapheneOS just release their patches publicly/open source? Why have different 'security releases' with closed source blobs? Because if they did: 1: They lose their partner OEM access to these patches 2: Every OEM would be required to release those same patches 4 months to the day GrapheneOS releases them.
  - zb3 10mo ago
    > Because if Pixel releases just a single patch, via a Pixel update or posts it on AOSP, the 4 month timer begins for every single OEM with a phone in the EU. And that's exactly what the law was about, this timer is a good thing. Now they should close the "artificial delay" loophole.

charcircuit 10mo ago

>google has certain commitments It reads to me like the opposite. Another case of manufacturers being unable to release updates in a prompt manner. Google delaying the release gives them more time to update.

userbinator 10mo ago

it has an integrated touch screen display with a viewable diagonal size of 10,16 centimetres (or 4,0 inches) or more, but less than 17,78 centimetres (or 7,0 inches); I wonder if 3.99 inch and 7.01 inch smartphones will start appearing again.

pmontra 10mo ago
That should be easy for foldables: an external sub 4" display and an over 7" main display.
tensegrist 10mo ago
> where the device has a foldable display or has more than one display, at least one of the displays falls into the size range in either opened or closed mode. also this: does this mean that foldable phones with three 3.99" screens are excluded

realusername 10mo ago

Parts of AOSP like the apps have been in limbo for way longer than that, maybe since Android 12.

codethief 10mo ago

> certain commitments they need to make depending on when the source code is released …or when OS updates are released, see Annex II B 1.2 (6) (c) and (d) ("Smartphones" > "Design for reliability" > "Operating system updates") So given that the updates were already released months ago, the release of the source code is irrelevant.

aboringusername 10mo ago
And what does 'released' mean in this context? GrapheneOS has very publicly stated that security patches are under embargo, and they already have patches for the March 2026 release. See [1]: > 2025110800: All of the Android 16 security patches from the current December 2025, January 2026, February 2026 and March 2026 Android Security Bulletins are included in the 2025110801 security preview release. List of additional fixed CVEs: So, have they been released? No. So the clock hasn't started ticking yet. This EU law made security worse for everyone as patches that are done today are not released for 4+ months. Note: These are CLOSED source blobs GrapheneOS is shipping. If they were open source, the 4 months clock would trigger immediately but they are not allowed to do this themselves as they get the patches from an OEM partner. GrapheneOS shipping these CLOSED source blobs, that Google has NOT released does not trigger the timer. I do accept that QPR1 was 'released' by Google on Pixel months ago, and therefore the timer started, however, Google will likely pick and chose what is best for OS updates/security patches. It explains why AOSP is now private/closed source and embargos are being used to get around the laws requirements. [1]: https://grapheneos.org/releases#2025110800 https://grapheneos.org/releases#2025110800 From the EU law: > (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;

phoronixrly 10mo ago

What? Please explain what commitments exactly are causing Google to not release source code at the same time as the update. Until you do that, your statement is as valuable as writing 'Thanks, Obama!'

berkes 10mo ago
Yea, GP sounds like they want to drag "EU Bad" into this discussion. I fail to see how this EU regulation promotes releasing software Closed Source and demotes releasing it Open Source.
- aboringusername 10mo ago
  > (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.
  - phoronixrly 10mo ago
    So EU mandates that security updates in either source OR binary form must hit all users in at most 4 months after they are first published, therefore Google started delaying releasing source code and will start delaying it even more? 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.

xzjis 10mo ago

This has absolutely nothing to do with that law, and even Google doesn't dare use it as an excuse for its behavior (as they did with GDPR by deliberately creating user friction that the European regulation did not require, and even partially forbids). In reality, it's a purely political decision to curb the development of third-party ROMs, because the AOSP source code exists with all the merges and is distributed to vendors (like Samsung). However, it's not necessarily just to target GrapheneOS and LineageOS; it might also be to target the Chinese market, particularly Huawei, which uses this source code for HarmonyOS.

aboringusername 10mo ago
It absolutely has everything to do with this new law. For the first time, depending on when Google releases source code, or releases a Pixel update, the timer (4 months for security, 6 months functionality) starts. This has never existed before in Android OS' history that updates are timed (in law) according to Pixel updates/software updates or open source releases. This law also applies to Apple but they will have no problems as they are compliant anyway as they control software/hardware entirely and it's closed source. This is the entire reason AOSP went private/closed source, and why Google is delaying security patches as per GrapheneOS. The March 2026 patches are already released by GrapheneOS as closed source blobs. They are not allowed to release them as open source by embargo (essentially NDA). Why do you think Pixel hasn't shipped security patches earmarked for March 2026? There are some critical bugs those patches fix, why not release them today, right now or next month? Because if Pixel releases just a single patch, via a Pixel update or posts it on AOSP, the 4 month timer begins for every single OEM with a phone in the EU. By making the patches under embargo, Google gets to control exactly when the timer starts to coordinate with their OEMs. So the slowest OEM gets to control the entirety of Androids security model. Ask yourself, why doesn't GrapheneOS just release their patches publicly/open source? Why have different 'security releases' with closed source blobs? Because if they did: 1: They lose their partner OEM access to these patches 2: Every OEM would be required to release those same patches 4 months to the day GrapheneOS releases them.
- zb3 10mo ago
  > Because if Pixel releases just a single patch, via a Pixel update or posts it on AOSP, the 4 month timer begins for every single OEM with a phone in the EU. And that's exactly what the law was about, this timer is a good thing. Now they should close the "artificial delay" loophole.