|
 |
 |
 |
 |
 |
 |
| Based on |
AOSP |
AOSP |
LineageOS |
LineageOS |
AOSP |
AOSP |
Freedom |
| | | | | |
| Free and open source (FOSS)? |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
| Deblobbed? |
Yes, significantly |
Yes, significantly |
Yes, minimal |
Yes, minimal |
Yes, minimal |
No |
| Can install apps from any source or developer? |
Yes |
Yes |
Yes |
Yes |
Yes |
Whitelisted developers (2026/27) or via adbGoogle has announced that from 2026-27 (depending on country), apps can only be "sideloaded" (installed from an APK file or alternative app store) if the developer has registered with Google. To register, developers need to pay a fee and reveal their identity to Google. The only workaround to install apps from outside the Play Store from non-approved developers will be via adb (when connected to a PC or using Shizuku). These restrictions only apply to "certified" Google devices, i.e. those that have Play Services and Play Protect preinstalled, meaning it will not affect "custom ROMs" or Chinese phones. |
Major Features |
| | | | | |
| Network controls for appsThe controls on LineageOS-based operating systems are leaky as their approach only disabled direct network access (socket) but doesn't disable indirect access via the INTERNET permission, which provides multiple ways of bypassing them not requiring collusion between apps. This functionality is regularly used by apps with no malicious intent. Collusion between apps is an issue for all kinds of granted access, permissions, etc. and not specific to the INTERNET permission. If INTERNET permission is not blocked though, no collusion is required. |
Direct and indirect access |
Direct access only |
Direct access only |
Direct access only |
Direct access only |
No |
| System-wide connection/tracker blocking |
Private DNS setting, or via VPN app |
Private DNS setting, or via VPN app |
iode-snort app, Private DNS, or VPN |
Private DNS setting, or via VPN app |
Private DNS setting, or via VPN app |
Private DNS setting, or via VPN app |
| Network-based location (without GNSS) |
Opt-in with server choiceNetwork-based location is disabled by default (GNSS-based location is used instead), but if it is enabled the user can choose between the Apple location service or a GrapheneOS proxy to it, or alternatively can use the Google Play location service if sandboxed Google Play is installed |
Yes, using microG location |
Yes, using microG location |
Yes, using microG location |
No |
Yes, using Play Services |
| E2E-encrypted phone backups |
Yes (Seedvault) |
Yes (Seedvault) |
Yes (Seedvault) |
Yes (Seedvault) |
Yes (Seedvault) |
Yes, but requires Google login |
| Android Auto compatible |
Yes (sandboxed), see hereGrapheneOS has permission toggles to enable the user to provide the least amount of permissions necessary (e.g. wired Android Auto requires only USB access). |
Yes (w/ privileged permissions), see here |
Yes (w/ privileged permissions), see here |
Yes (w/ privileged permissions), see here |
No |
Yes (w/ privileged permissions) |
| Google Pay compatible |
No (blocked by Google) |
No (blocked by Google) |
No (blocked by Google) |
No (blocked by Google) |
No (blocked by Google) |
Yes (w/ privileged permissions) |
| RCS support in Google Messagesrequires Google Play Services and to work |
Yes, see here |
No (blocked by Google) |
No (blocked by Google) |
No (blocked by Google) |
No (blocked by Google) |
Yes |
Advanced & device-specific features |
| | | | | |
| Factory reset protection (for stolen devices) |
No |
No |
No |
No |
No |
Yes, but requires Google loginIf the device is stolen and then factory reset, it will not allow setup and use until the original Google account credentials used on the device are entered. To disable FRP before factory reset, one must remove all Google accounts from the device (requiring the passwords). If the device was used without a Google account it will not trigger FRP meaning the device can be reset and reused freely. |
| Duress PIN (to wipe device) |
Yes, see here |
No |
No |
No |
No |
No |
| Parental controls |
No |
No |
YesIodeOS has built-in parental controls focused on blocking unwanted data transmission rather than detailed activity monitoring like Family Link. The parental controls in IodeOS allow parents to block categories of content and "recipients," such as "Porn" to censor adult websites and "Social" to block social network apps. It also allowed parents to disable Internet access for specified apps (with password protection). |
No |
No |
Yes, but requires Google loginGoogle Family Link requires a Google account but provides a comprehensive parental control experience, including detailed app usage monitoring and screen time management, the ability to remotely approve or block apps from being downloaded, device location tracking, and content and privacy restrictions enforced through Google Play Services. |
| Call recording |
Yes |
Only in selected regions, see here |
Only in selected regions, see here |
Only in selected regions, see here |
Only in selected regions, see here |
Depends on regions and manufacturer |
| Notification forwarding from other user profiles |
Yes |
No |
No |
No |
No |
No |
Option to enable screenshots in all appsincluding apps blocking screenshots (FLAG_SECURE) |
No |
No |
No |
No |
No |
No |
| Hardware-backed attestation API supportHardware-backed attestation works through a standard Android hardware attestation API that is available on every device launched with Android 8 or later. This hardware attestation API can be used by apps independently of Google Play Services, meaning apps do not have to rely on the Play Integrity API or other Google Play Services components for device integrity verification. The Play Integrity API itself is based on this hardware attestation API but adds Google's additional layers, including licensing checks. Using the native hardware attestation API allows for verifying security on devices or OSes that do not license Google Mobile Services. |
Yes, see here |
No |
No |
No |
No |
Yes |
| Charging limit (e.g. 80%) on supported devices |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
(Pixel only:) Force VoLTE, VoNR, 5G, VoWiFiPreviously, users of Pixel phones could change or set carrier network features like VoLTE (Voice over LTE), VoNR (Voice over New Radio, i.e. 5G voice), and WiFi Calling (VoWiFi), which is useful for users of imported Pixel phones in regions where these features are not supported. This carrier settings override was possible using adb shell commands or apps like Pixel IMS. With the December 2025 Android Security Bulletin patches (published in October 2025), Google removed support for these carrier override settings via adb, although as of 14 October 2025, the developer behind the Pixel IMS app has implemented a workaround.
Note that this was only possible on Pixel phones as they uniquely allowed this override because Google's implementation of the Android telephony framework granted higher-than-usual privileges to adb on Pixel devices. This was originally intended as a test and debugging mechanism for developers and engineers, making it possible to override carrier-related telephony settings through ADB commands. Google's decision to open this up for Pixels (until Q4 2024) was a quirk and it was never part of general Android policy or documentation for end users. |
Yes (for Google Pixel)In "Carrier settings overrides" in the Settings app. |
via Pixel IMS appRemoved in AOSP code with a security update in October 2025 (which has NOT yet been implemented by CalyxOS); although as of 14 October 2025, the developer behind the Pixel IMS app has implemented a workaround, though it can also be patched by Google in the future. |
via Pixel IMS appRemoved in AOSP code with a security update in October 2025 (which has NOT yet been implemented by IodeOS); although as of 14 October 2025, the developer behind the Pixel IMS app has implemented a workaround, though it can also be patched by Google in the future. |
via Pixel IMS appRemoved in AOSP code with a security update in October 2025 (which has NOT yet been implemented by /e/); although as of 14 October 2025, the developer behind the Pixel IMS app has implemented a workaround, though it can also be patched by Google in the future. |
via Pixel IMS appRemoved in AOSP code with a security update in October 2025 (which has NOT yet been implemented by LineageOS); although as of 14 October 2025, the developer behind the Pixel IMS app has implemented a workaround, though it can also be patched by Google in the future. |
via Pixel IMS appRemoved in AOSP code with a security update in October 2025; although as of 14 October 2025, the developer behind the Pixel IMS app has implemented a workaround, though it can also be patched by Google in the future. |
Degoogling (connections to Google)
COLOURSLOGIC FOR COLOUR SCHEME:
RED
- connects to Google, no opt-out
LIGHT RED
- connects to Google by default but function can be turned off (no option of using another provider)
YELLOW
- function is off by default but can connect to Google if needed (no option of using another provider)
LIGHT GREEN
- connects to Google by default but can be changed to another provider
GREEN
- does not connect to Google by default but instead connects to the developer of the operating system (no third party needs to be trusted)
- multiple providers offered and user can decide
- no data shared with any provider
BLUE
- does not connect to Google by default but instead connects to another (non-Google) third party provider
WHITE
- function is not supported |
| | | | | |
| eSIM activation |
Google eUICC w/o data sharingDisabled by default. Unlike the regular Google eUICC management app, it doesn't require Google Play and cannot share data with it. It doesn't communicate with Google servers unless the carrier is hosting with them, which would involve using their servers regardless. |
Google eUICC (preinstalled) |
Google eUICC (preinstalled) |
Google eUICC (preinstalled) |
Google eUICC (preinstalled) |
Google eUICC (preinstalled) |
| Provider for network-based location |
None default, GrapheneOS, Apple, or GoogleNetwork-based location is disabled by default (GNSS-based location is used instead), but if it is enabled the user can choose between the Apple location service or a GrapheneOS proxy to it, or alternatively can use the Google Play location service if sandboxed Google Play is installed |
microG location |
microG location |
microG location |
n/a |
Google |
| SUPL (for Assisted GNSS) |
GrapheneOS default, Google or none |
Google default, or none |
Google default, or none |
None default, or Google |
Google default, or none |
Google |
PSDS/XTRA ("Standard" depends on GPS chipset)The standard server used depends on the GPS chipset, which is usually Qualcomm, Broadcom, or Samsung, or in the case of Tensor chips (Google Pixel 6 and later) they connect to a Google server. Some ROMs override these settings.
Click here for details and which device information are sent. |
GrapheneOS default, StandardGoogle / Broadcom / Qualcomm / Samsung depending on the device. At the moment, only Google Pixels are supported by GrapheneOS, for which the standard connection is Google (since the Pixel 6), or none |
Standard (excl. Google)Broadcom / Qualcomm / Samsung depending on the device, for Google Pixel 6 and later (Tensor chip) the standard connection to Google is replaced with a connection to Broadcom instead (source) default, or none |
Standard (excl. Google)Broadcom / Qualcomm / Samsung depending on the device, for Google Pixel 6 and later (Tensor chip) the standard connection to Google is replaced with a connection to Broadcom instead (source) default, or none |
None default, or StandardGoogle / Broadcom / Qualcomm / Samsung depending on the device |
StandardGoogle / Broadcom / Qualcomm / Samsung depending on the device default, or none |
StandardGoogle / Broadcom / Qualcomm / Samsung depending on the device |
| Connectivity check/captive portal |
GrapheneOS default, Google, or none |
Google (can be changed)can be changed with `adb` command |
Kuketz.de (can be changed)can be changed with `adb` command |
Murena.io (related to /e/) (can be changed)can be changed with `adb` command |
Google (can be changed)can be changed with `adb` command |
Google (can be changed)can be changed with `adb` command |
| DNS connectivity check |
GrapheneOS default, or Google |
Google |
Google |
Google |
Google |
Google |
| DNS server fallback |
Cloudflare |
Cloudflare |
Quad9 |
Quad9 |
Google |
Google |
| Network time |
GrapheneOS default, or none |
Google (can be changed)can be changed with `adb` command & carrier |
NTP.org (can be changed)Server pool with arbitrary providers, which can include Google-hosted servers or even malicious servers. NTP server can be changed with `adb` command. & carrier |
NTP.org (can be changed)Server pool with arbitrary providers, which can include Google-hosted servers or even malicious servers. NTP server can be changed with `adb` command. & carrier |
Google (can be changed)can be changed with `adb` command & carrier |
Google (can be changed)can be changed with `adb` command & carrier |
| Hardware attestation provisioning |
GrapheneOS default, or Google |
Google |
Google |
Google |
Google |
Google |
| DRM (Widevine) provisioning |
GrapheneOS default, or Google |
Google |
Google |
Google |
Google |
Google |
Google Play Services |
| | | | | |
| Implementation |
GmsCompat (sandboxed Google Play)GrapheneOS does not include Google Play as a preinstalled app, but it includes an open source compatibility layer for users who choose to use it. Users can alternatively install microG on GrapheneOS, albeit GrapheneOS does not support signature spoofing. Not all microG functionality requires signature spoofing, for example FCM works with microG without signatures spoofing to the extent it works without special privileges (e.g. microG needs to use a privileged API to wake apps and keep them awake for a short period of time to handle FCM messages). |
microG |
microG |
microG |
None by default.
It's possible to install microG manually (LineageOS supports signature spoofing for microG since 2024). Alternatively, there are ROMs with microG preinstalled or one can add Google apps during the installation process, but this is not officially supported by LineageOS.
| Google Play Services |
| Optional? |
Yes (not preinstalled) |
Yes (preinstalled but opt-out) |
Yes (preinstalled but opt-out) |
Can be disabled via developer mode |
No (preinstalled without opt-out) |
| Runs in standard app sandbox? |
Yes |
NoRuns in the `priv_app` SELinux domain instead of `untrusted_app`, which gives it access to internal system APIs and data along with it being much less isolated. |
NoRuns in the `priv_app` SELinux domain instead of `untrusted_app`, which gives it access to internal system APIs and data along with it being much less isolated. |
NoRuns in the `priv_app` SELinux domain instead of `untrusted_app`, which gives it access to internal system APIs and data along with it being much less isolated. |
NoRuns in the `priv_app` SELinux domain instead of `untrusted_app`, which gives it access to internal system APIs and data along with it being much less isolated. |
| Can be limited to user or work profile? |
Yes |
Yes |
? (TBC) |
? (TBC) |
No |
| Signature spoofing needed/allowed? |
No |
Only for Google signature |
Only for Google signature |
Only for Google signature |
No |
| Push notifications via Google FCM? |
Yes |
Optional |
Optional |
Optional |
Yes |
| Google Play Integrity?From Android 13 onwards, MEETS_BASIC_INTEGRITY can only be met if the app was installed through the Play Store, which is only possible when logged in to a Google account. However, even if you later log out from your Google account, or if you install the app from elsewhere but spoof it as installed from Google Play, some apps may still refuse to run as they run additional checks that the user is currently logged in to their Google account. |
Passes Basic Integrity only, see herePasses MEETS_BASIC_INTEGRITY but not MEETS_DEVICE_INTEGRITY or MEETS_STRONG_INTEGRITY which require a certification from Google. |
Passes Basic Integrity onlymicroG v0.3.6.244735, which is part of CalyxOS since 2024-12-31, passes MEETS_BASIC_INTEGRITY but not MEETS_DEVICE_INTEGRITY or MEETS_STRONG_INTEGRITY which require a certification from Google. |
Passes Basic Integrity onlymicroG v0.3.6.244735 and above pass MEETS_BASIC_INTEGRITY but not MEETS_DEVICE_INTEGRITY or MEETS_STRONG_INTEGRITY which require a certification from Google. |
Passes Basic Integrity onlymicroG v0.3.6.244735 and above pass MEETS_BASIC_INTEGRITY but not MEETS_DEVICE_INTEGRITY or MEETS_STRONG_INTEGRITY which require a certification from Google. |
Yes |
| Disables Play Integrity install checks?These checks, undertaken by Play Store, involve validating the app's developer credentials, authenticity, and confirming the app is a genuine Play Store version via cryptographic signatures or developer verification services provided by Google. These checks are about confirming the app is genuine and unmodified, but they are fundamentally anti-competitive as they enforce the use of Play Store linked to a Google account to download apps. While these checks purport to ensure app authenticity and security, they are fundamentally anti-competitive since they restrict users to obtaining apps only from the Play Store and require Google services licensing, thereby locking out alternative app sources or operating systems. Many apps use the Play Integrity API to block apps installed from alternative sources such as APK sideloads or Aurora Store, which harms user choice and fair competition. Disabling these checks can be useful for use apps that were "sideloaded", e.g. installed from Aurora Store or APK. |
Yes (if signature matches)GrapheneOS disables or bypasses certain restrictive Play Store install checks after cryptographically verifying the Play Store source stamp signature of the app. This allows apps to run even if installed from alternative sources like Aurora Store or APKs. However, some apps may perform their own installation source (PackageManager.getInstallerPackageName) checks independently, which is why spoofing the install source might still be necessary to pass those app-specific checks. |
No |
No |
No |
No |
No |
Option to mark apps as installed by Play Store?In addition to the the checks undertaken by Play Integrity (see above), apps can check if they were installed by querying the system's installer package name (e.g. com.android.vending for Play Store). Some apps block or restrict functionality if installed from outside the Play Store based on this check. |
No, only via adbGrapheneOS is not spoofing the installation source at the moment but there are plans to eventually add such a feature.
adb can spoof the installation source, using a command like adb shell pm install -i com.android.vending -r /path/to/app.apk. Shizuku is an Android app that allows users to do it using wireless debugging and without an external device (PC). |
Done if installed from Aurora StoreApps installed from Aurora Store are automatically marked as installed from Play Store, without further signature checks |
Done if installed from Aurora StoreApps installed from Aurora Store are automatically marked as installed from Play Store, without further signature checks |
No, only via adb
adb can spoof the installation source, using a command like adb shell pm install -i com.android.vending -r /path/to/app.apk. Shizuku is an Android app that allows users to do it using wireless debugging and without an external device (PC). |
No, only via adb
adb can spoof the installation source, using a command like adb shell pm install -i com.android.vending -r /path/to/app.apk. Shizuku is an Android app that allows users to do it using wireless debugging and without an external device (PC). |
No, only via adb
adb can spoof the installation source, using a command like adb shell pm install -i com.android.vending -r /path/to/app.apk. Shizuku is an Android app that allows users to do it using wireless debugging and without an external device (PC). |
Privacy |
| | | | | |
| Storage scopes |
Yes, see here |
No |
No |
No |
No |
No |
| Contact scopes |
Yes, see here |
No |
No |
No |
No |
No |
| Per-app sensor controls |
Yes, see here |
No |
No |
No |
No |
No |
| Per-connection DHCP state flushing |
Yes |
No |
No |
No |
No |
No |
| MAC address randomization |
Per connection, see here |
Per network |
Per network |
Per network |
Per network |
Per network |
| SUPL: IMSI or phone number sent? |
No |
No |
No |
No |
No |
Yes |
| Qualcomm XTRA: user agent sent?Only relevant for phones with Qualcomm GPS chips. Doesn't apply to Broadcom or Samsung. May include chipset serial number, device manufacturer and model, carrier, and Android version. Click here for details and which device information are sent. |
No |
Partially (for Qualcomm chips)Chipset serial number is stripped out but other less unique device information remain |
Partially (for Qualcomm chips)Chipset serial number is stripped out but other less unique device information remain |
Partially (for Qualcomm chips)Chipset serial number is stripped out but other less unique device information remain |
Partially (for Qualcomm chips)Chipset serial number is stripped out but other less unique device information remain |
for Qualcomm GPS chips |
| Closed cross-profile package leaks? |
Yes |
No |
No |
No |
No |
No |
| Closed device identifier leaks? |
Yes, see here |
No |
No |
No |
No |
No |
| Metadata stripping for screenshots |
Yes, see here |
Yes, see here |
No |
No |
No |
No |
| EXIF metadata stripping for photos |
Yes, see here |
No |
No |
Available as option |
No |
No |
| Location tagging for photos |
Opt-in |
Opt-in, see here for more info |
Opt-in |
Opt-in |
Opt-in |
Opt-out |
| Tracking through Android Advertising ID? |
Not part of the systemif Play Services are installed by the user, the Advertising ID can be deleted in settings |
Randomized IDmicroG will generate a random advertising ID for each request |
Randomized IDmicroG will generate a random advertising ID for each request | Randomized IDmicroG will generate a random advertising ID for each request |
Not part of the systemif microG is installed by the user, it will generate a random Advertising ID for each request; if Play Services are installed by the user, the Advertising ID can be deleted in settings |
Yes, but can be deleted in settings |
Security |
| | | | | |
| Verified boot (if supported by device)? |
Yes, incl. system app updates |
Yes, but excl. system app updates |
Yes, but excl. system app updates |
w/ test keys; excl. system app updates |
No |
Yes, but excl. system app updates |
| Hardware-based security verification |
Yes, see here |
No |
No |
No |
No |
Yes, mandatory since Android 8 |
| System app downgrade protection |
For updates and boot, with fs-verity |
For updates (incomplete) |
For updates (incomplete) |
For updates (incomplete) |
For updates (incomplete) |
For updates (incomplete) |
| Secure application spawning? |
Yes (exec) |
No |
No |
No |
No |
No |
| Hardware memory tagging? |
Yes, if supported by device |
No |
No |
No |
No |
Advanced Protection, very limited scopeIf Advanced Protection mode is enabled, it enables hardware memory tagging (when supported by the hardware) but only for apps that are explicitly opting in to it and not for the kernel or most of the base OS. |
| Android Runtime JITJust-In-Time compilation/profiling |
AOTAhead-Of-Time compilation w/o profiling |
Interpreter/JITJust-In-Time with profiling |
Interpreter/JITJust-In-Time with profiling |
Interpreter/JITJust-In-Time with profiling |
Interpreter/JITJust-In-Time with profiling |
Interpreter/JITJust-In-Time with profiling |
| Dynamic code loading prevention for appssee here for details |
System, opt-in for non-system apps |
None |
None |
None |
None |
None |
| Secure TLS for SUPL? |
TLSv1.3 or TLSv1.2GrapheneOS still uses TLSv1.2-only for SUPL on Broadcom GNSS devices but moved to TLSv1.3-only for SUPL on Samsung GNSS devices. |
TLSv1.3/1.2/1.1/1.0 depending on deviceSome older end-of-life devices only support TLSv1.1 or TLSv1.0 |
TLSv1.3/1.2/1.1/1.0 depending on deviceSome older end-of-life devices only support TLSv1.1 or TLSv1.0 |
TLSv1.3/1.2/1.1/1.0 depending on deviceSome older end-of-life devices only support TLSv1.1 or TLSv1.0 |
TLSv1.3/1.2/1.1/1.0 depending on deviceSome older end-of-life devices only support TLSv1.1 or TLSv1.0 |
TLSv1.3/1.2/1.1/1.0 depending on deviceSome older end-of-life devices only support TLSv1.1 or TLSv1.0 |
| Fallback DNS server with DNSSEC? |
Yes |
Yes |
Nouses Quad9's unsecured endpoint (9.9.9.10) with provides no security blacklist and no DNSSEC |
Yes |
Yes |
Yes |
| Secure connection to network time server? |
HTTPS via GrapheneOS server |
NTP w/o NTS and carrier-based timeinsecure because cellular networks lack proper authentication |
NTP w/o NTS and carrier-based timeinsecure because cellular networks lack proper authentication |
NTP w/o NTS and carrier-based timeinsecure because cellular networks lack proper authentication |
NTP w/o NTS and carrier-based timeinsecure because cellular networks lack proper authentication |
NTP w/o NTS and carrier-based timeinsecure because cellular networks lack proper authentication |
| Can disable USB-C and pogo pins data?See here for details: [1], [2], [3] |
Default (while locked), see here |
No |
No |
No |
No |
No |
| Can disable USB-C charging?See here for details: [1], [2], [3] |
Opt-in (after boot), see here |
No |
No |
No |
No |
No |
| Can disable USB connections?See here for details: [1], [2], [3] |
Default (while locked), see hereHardware and software |
Default (while locked), software onlyIncomplete implementation. Can only disable high level software attack surface. Lacks a way to block new USB connections without ending existing connections. The mode for disabling USB connections while locked continues allowing new connections until existing connections end, including a connection through another method such as a pogo pins USB connection to a stand. |
? (TBC - like Lineage or stock?) |
? (TBC - like Lineage or stock?) |
Opt-in, software onlyIncomplete implementation. Can only disable high level software attack surface. Cannot disable USB until after early boot. Lacks a way to block new USB connections without ending existing connections. The mode for disabling USB connections while locked continues allowing new connections until existing connections end, including a connection through another method such as a pogo pins USB connection to a stand. |
Advanced ProtectionWhen Advanced Protection Mode is enabled, it blocks new USB connections at a software level after the device is locked or Device admin APIRequires installing a device admin app like Sentry. Can only disable high level software attack surface. Cannot disable USB until after early boot. Lacks a way to block new USB connections without ending existing connections. |
| Can auto-disable WiFi if unused? |
Yes |
Yes |
Yes |
No |
No |
No |
| Can auto-disable Bluetooth if unused? |
Yes |
Yes |
Yes |
No |
No |
No |
| Can auto-disable NFC if unused? |
NoThis featured was removed in July 2025 due to bugs |
No |
No |
No |
No |
No |
| Auto-reboot timer for locked devices |
Yes |
Yes, with flaws (no proper BFU state)CalyxOS has a disabled-by-default port of an older GrapheneOS implementation of the auto-reboot feature, which was determined to not be as robust due to being able to bypass it by crashing system_server. It also lacks the memory clearing required to get the device properly back at rest for reboots. Therefore it can't return the device to a proper BFU (before first unlock) state like the GrapheneOS and iOS implementations. |
No |
No |
No |
Advanced Protection mode, with flawsIf Advanced Protection Mode is enabled, it provides a 72 hour auto-reboot timer. However, it appears to lack memory zeroing and therefore can't return the device to a proper BFU (before first unlock) state like the GrapheneOS and iOS implementations. It is unclear if the implementation is protected from a core system process crashing (system_server) preventing a trigger of the auto-reboot. |
| 2-factor fingerprint unlock |
Yes (fingerprint + PIN), see here |
No |
No |
No |
No |
No |
| Hardened system components |
Yes, hardened memory allocator, kernel, libc, webview (Vanadium), SELinux policy, and additional hardening. See here |
No (same as AOSP) |
No (same as AOSP) |
No (same as AOSP) |
No (same as AOSP) |
No (same as AOSP) |
Updates |
| | | | | |
| Security preview releasesSince 2025 H2, Google will distribute security patches to OEMs (phone manufacturers) 3-4 months before the "official" publication date. Until that date, they are not allowed to publish source codes or details, but it is allowed to publish the binaries and list the fixed CVEs. This change in Google's policy delays getting patches to users and sophisticated attackers will have no issue getting the patches from one of many people at Android OEMs with early access. It furthermore restricts the ability of open source and non-commercial Android distributions to patch security issues on time as the security patches are only distributed to official OEMs and it is not allowed to republish the source code before the embargo ends. |
Yes (optional)Users can opt in to security patches that are still under the embargo for source code and details. Thanks to a cooperation with an Android OEM, GrapheneOS is able to ship these security patches as binaries before the "offical" publication date. However, the patches can't be included in the regular open-source releases until the embargo ends. |
No |
No |
No |
No |
NoAs of September 2025, No OEMs are actually publishing updated binaries during the embargo period despite Google's policy allowing a "binary-only exception" to ship patches earlier. This exception exists in theory to allow shipping binary-only patches without the typical source code embargo delay, but it is not being used in practice by OEMs, including Google for Pixels. |
Security update speed (AOSP subset of ASB)It doesn't explain how the device-specific patches in the second half of each Android Security Bulletin are actually delivered, or if they ever make it to end users. Since autumn 2025, Google no longer publishes all security fixes immediately into AOSP each month. Instead, they distribute patches under embargo to OEMs, and the corresponding changes only appear publicly in the source code 3–4 months later. This means that full security patching now depends even more on keeping up with your vendor's own releases, because relying on AOSP directly will always leave you months behind. Falling behind on quarterly or yearly OEM releases results in missing many security fixes until the next major release for that device. The situation varies greatly: Pixels still set the standard because Pixel updates track the embargoed patches promptly, while many vendors are slow to roll out quarterly or yearly releases. Some devices that fail to ship a timely new Android version make it almost impossible for an alternate OS to provide complete patches. If the vendor doesn't ship updated firmware or drivers, alternate OS projects have no path to apply those fixes themselves. For example, Fairphone historically trailed by 1–2 months even before the embargo change, and therefore projects like CalyxOS or LineageOS on Fairphone remain at least that far behind.
Click here for update speed data |
Usually same day |
Currently no updates |
2-4 weeks, sometimes longer |
1-2 months, sometimes longer |
1-2 weeks, sometimes longer |
Depends on phone vendor |
| Full patches on fully supported devicesRequires 1. being on the latest OS release (as Android doesn't backport all security patches), 2. shipping all the vendor code |
Several days |
Currently no updates |
Several to many months |
Many months to over a year |
Several to many months |
Depends on phone vendor |
| Partial security updates (ASB) after EoL datemissing most driver and firmware patches after the phone's end of life date |
until 5 years from launche.g. 2 years of extended support for 4th and 5th generation Pixels |
Currently no updates |
Several years |
Several years |
Several years |
By definition: No |
| Number of Android versions supportedOnly the latest major release of AOSP has full security patches. Most privacy fixes are in fact only included for the new OS versions, not in the security patches. The ASB patches patches rarely include fixes for permission model / sandbox flaws resulting in privacy leaks since they're given Moderate severity and often require invasive changes including potential compatibility breaks. |
Usually 1 Android version |
Currently no updates |
Usually 1 Android version |
2-3 Android versions |
Usually 3 Android versions |
Usually 3 Android versions |
| Webview update speedClick here for details |
<1 day |
Currently no updates |
<2 weeks |
Several weeks/months |
<2 weeks |
Depends on phone vendor |
Supported devices |
Hardware requirements | Hardware requirements | | | | |
| Asus* |
No |
No |
No |
Older devices only |
Older devices only |
Yes (ZenUI) |
| Fairphone |
No |
Currently not available |
Yes |
Yes |
Yes |
Yes |
| Google |
Yes |
Currently not available |
Yes |
Yes |
Yes |
Yes |
| Motorola |
No |
Currently not available |
Yes |
Yes |
Yes |
Yes |
| Oneplus |
No |
No |
Yes |
Older devices only |
Yes |
Yes (OxygenOS) |
| Samsung* |
No |
No |
Older devices only |
Older devices only |
Older devices only |
Yes (OneUI) |
| Shiftphone |
No |
No |
Yes |
Yes |
Older devices only |
Yes |
| Sony |
No |
No |
Yes |
Older devices only |
Yes |
Yes |
| Xiaomi |
No |
No |
Older devices only |
Older devices only |
Yes |
Yes (HyperOS) |
| * these manufacturers don't support bootloader unlocking anymore for all or most of their new devices. "Older devices only" = no devices released since 2023. |
| | | | | |