- Like
- SHARE
- Digg
- Del
- Tumblr
- VKontakte
- Flattr
- Buffer
- Love This
- Save
- Odnoklassniki
- Meneame
- Blogger
- Amazon
- Yahoo Mail
- Gmail
- AOL
- Newsvine
- HackerNews
- Evernote
- MySpace
- Mail.ru
- Viadeo
- Line
- Comments
- Yummly
- SMS
- Viber
- Telegram
- JOIN
- Skype
- Facebook Messenger
- Kakao
- LiveJournal
- Yammer
- Edgar
- Fintel
- Mix
- Instapaper
- Copy Link
For two years, Google has been trying to make it easy for businesses to run and deploy reliable Android devices through its Android Enterprise Recommended (AER) program. It’s essentially a collection of certified hardware with certain minimum guarantees: They must be eligible for zero-touch enrollment, carrier-unlocked, and should receive security updates no later than 90 days of release for a minimum of three years. As XDA Developers reports, the latter requirement might soon be significantly relaxed in favor of more nebulous transparency requirements.
According to some leaked, nonfinal documents, Google is looking into dropping the 90-day security update requirement altogether. Instead, manufacturers have a new rule to work with: Transparency. On their websites, OEMs have to publish the date when their participating phone will receive its last security update and which patch is currently available. They also have to share how frequently they’ll update it. The same is true for new Android releases: Customers must be able to know which software the phone initially shipped with, which version it’s currently on, and which update you can expect to be the last.
The mandatory 3-year support for Emergency Security Maintenance Releases (ESMR) remains active, though. That means that critical security flaws must be patched for at least three years, even if the phone doesn’t receive regular system updates any longer.
Take a look at the leaked table below for all the minuscule changes. If you wonder why it says “30-day security updates” and not 90 in the Android 10 section, it seems like Google has updated the requirement to be more rigorous, but has only informed manufacturers, not the general public.
Category | Serial Number | MUST / MAY | Attribute and Implementation | Comments | |
Q (Android 10) | R (Android 11) | ||||
Device Security | 1 | MAY | Operate an OEM Vulnerability Rewards Program (VRP) | Operate an OEM Vulnerability Rewards Program (VRP) | |
2 | MAY | StrongBox support | StrongBox support | ||
3 | MAY | Hardware backed Keystore support | Hardware backed Keystore support | ||
4 | MAY | Device ID attestation support | Device ID attestation support | ||
5 | MAY | Key attestation support | Key attestation support | ||
6 | 30-day security updates | Requirement removed | Replaced with Security transparency requirement | ||
7 | MUST | 3 yr support for Emergency Security Maintenance Release (ESMR) | 3 yr support for Emergency Security Maintenance Release (ESMR) | Replaced with Security transparency requirement | |
8 | File-based encryption – on by default. Uses AOSP implementation. | Requirement removed | This is a GMS requirement enforced for all devices | ||
9 | 90-day security updates | Requirement removed | Replaced with Security transparency requirement | ||
10 | 3 year security update support (may sub 3rd year ESMR) | Requirement removed | Replaced with Security transparency requirement | ||
11 | Publish latest security patch level | Requirement removed | Replaced with Security transparency requirement |
Above: Revision to Device Security requirements. Below: New transparency requirements.
Category | Serial Number | MUST / MAY | Attribute and Implementation | Comments | |
Q (Android 10) | R (Android 11) | ||||
Security/OS Updates transparency | 1 | MUST | MUST publish following updates information on OEM website – SMR support end-date (last date when the device will receive SMR) – Latest security patch available – Frequency of updates the device will receive – Fixes contained in security patch, including any OEM-specific fixes | Changing the requirement from SMR support to SMR/patches/updates transparency | |
2 | MUST | MUST publish following OS information on OEM website – OS that the device is shipped with – Current major OS ver – All major OS version update that the device will receive | Changing the requirement from support to transparency eg: Pixel 3 – Shipped ver – Android 9 – Current Ver – Android 10 – Expected major ver – Android 11 | ||
3 | MUST | Submit the device to IoXT certification | IoXT scoring adds to transparency |
Keep in mind that these are just proposed changes. The new rules aren’t carved in stone, and Google might decide against them before it publishes the next finalized version of the AER guidelines. We can also only speculate as to why Google considers making the rules less strict. It’s possible that these requirements are now part of the secret contract Google and manufacturers enter when they want to use Android. We once had a glance at such a document back in 2018, when a leak showed that phones had to be updated for at least two years. If that’s the case, the extra requirement for the AER program would be unnecessary.
In the end, the transparency requirement could be beneficial for all phone owners — we’d finally be able to reliably find update information on all manufacturers’ websites, helping us judge which phones will be the most secure and long-lasting.
- Source:
- XDA Developers