Replying to Avatar Final

#GrapheneOS version 2025012600 released.

This update adds workarounds for various apps banning aftermarket operating systems using techniques outside of the Play Integrity API. Revolut is the most common app known to do this.

There is now a menu to access a list of apps using the Play Integrity API from sandboxed Google Play. You can also choose to block the Play Integrity API for apps entirely, which could potentially help with some apps.

Messaging app was ported to Android 15 APIs as a beginning for overhauling all the default / system apps.

Changes since the 2025011500 release:

• disable standard Android feature holding a 10 minute screen wake lock after the screen brightness is raised at least 2 times within 5 minutes since this is confusing for users and it's far better if keep awake is done explicitly

• always show KASAN kernel crash notifications instead of only when system crash reporting is enabled by users

• Messaging: begin under the hood overhaul including fully porting to target API 35 (Android 15)

• recovery: remove spurious warning after update installation fails on A/B update devices

• change build username to build-user and build hostname to build-host instead of setting both to grapheneos due to bad actors using it to ban using GrapheneOS

• return green as the value of ro.boot.verifiedbootstate outside of specific parts of the base OS due to bad actors using it to ban using GrapheneOS

• SettingsIntelligence: don't show preference summaries in search results since it doesn't work properly for ones depending on dynamic string formatting and isn't done by SettingsIntelligenceGoogle on the stock Pixel OS

• Contact Scopes: fix spoofing of OP_GET_CONTACTS for apps not requesting WRITE_CONTACTS

• Sandboxed Google Play compatibility layer: improve infrastructure

• Sandboxed Google Play compatibility layer: allow blocking the Sandboxed Google Play is running notification

• Sandboxed Google Play compatibility layer: add per-app Play Integrity menu in the per-app Settings configuration that's shown after an app uses the Play Integrity API

• Sandboxed Google Play compatibility layer: add per-app toggle for blocking using the Play Integrity API via the per-app Play Integrity menu as a workaround for apps which ban devices based on it but don't require providing it to their service yet

• Sandboxed Google Play compatibility layer: add shortcut to the per-app Play Integrity API menu for contacting the app developer by leaving a review through the Play Store page

• Sandboxed Google Play compatibility layer: add menu for viewing all apps which have used the Play Integrity API with a shortcut in the per-app Play Integrity API menu

• Sandboxed Google Play compatibility layer: show optional notification upon detection of Play Integrity usage providing a shortcut to the per-app Play Integrity API menu and another for hiding further notifications for the app which is also available as a toggle in the per-menu

• hardened_malloc: update libdivide to 5.2.0

• TalkBack (screen reader): update dependencies

• TalkBack (screen reader): make builds fully reproducible by removing the use of __DATE__ and __TIME__ by brltty along with making the liblouis translation table zip use deterministic file order and timestamps

• kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.124

• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.68

• Vanadium: update to version 132.0.6834.122.0

https://grapheneos.org/releases#2025012600

For anyone installing the latest update (in Alpha currently) please let us know if an app that previously didn't work is now working. Interested to see results. Some users reported other apps other than Revolut working.

nostr:nevent1qqspp6laynusgka43a2nu3rm9q22nu4zaud9m3v7xcqglzt49q68g2qpzpmhxue69uhkummnw3ezumt0d5hsyg9e3hk5e6h2ypusm09ncv2qq6fqp8f5clueylpgdq66nxm5sxjuygpsgqqqqqqsmj7rqh

Reply to this note

Please Login to reply.

Discussion

I have a question regarding new feature which is login (PIN + fingerprint). I set up both but in reality PIN only works. I can hold whatever finger a couple of times and it proceed to PIN unlock. Then I type PIN and bang - phone unlocked!

Is it a bug or I did something wrong or there is something wrong with the phone?

It appears you misunderstood the feature, in after-first unlocks, users have the choice to use your OS credentials instead of their fingerprint when doing unlocks.

If you use a PIN as your OS credentials than it will ask for a PIN regardless of if it's wrong or right as the OS prevents the unlock after 5 incorrect attempts. Get the fingerprint wrong, it's your OS PIN, if it's right, then it's the 2FA PIN you set up.

The feature is used for users who use passphrases, not PINs. If you turn your default PIN into a password, try the same thing and see what happens. You'll be asked for your password instead.

Android/GrapheneOS has two unlock methods:

- Primary unlock: credential used to decrypt the device there is the only credential available at boot and can be used to unlock the device no matter what. Can be a PIN or password.

- Secondary unlock: Other credential used to prevent access to the device when the device is still active after the first unlock. Only available after first unlock. On Android, only Fingerprint is an acceptable secondary unlock and is used to unlock the device quickly. GrapheneOS adds an additional optional PIN for the secondary unlock.

The PIN you are seeing is your primary unlock which you always have the option to do, it's forced when you get the fingerprint wrong multiple times. If you use the same PIN for primary unlock and the 2FA PIN then it defeats the purpose of the feature since you can just primary unlock the device. It works best when you have a password as your primary unlock.

If you were planning on setting the same PIN to unlock then you're just better off changing one of the PINs or not really having the feature enabled

What do you think about this option I was thinking about first? PIN + fingerprint without additional password as a back up. Wouldn't it be better to have this option with just those 2 options? If one of them fails you loose access to your phone. What if device is compromised? Isn't it easier to exctract password or PIN than fingerprint? Fingerprint requires physical finger to touch the device.

In current option fingerprint can be skipped if you know the passphrase

Fingerprints or values derived from fingerprints cannot be used as a key to decrypt the device because they naturally change all the time and also risk being destroyed from injury. Technically impossible to do and also very difficult to preserve. It needs to be a static credential that doesn't change like a key derived from a passphrase or PIN.

> Isn't it easier to extract password or PIN than fingerprint?

The device doesn't store your PIN or password. It generates a long, secure key derived off of the input and then if it is correct the keys are stored in RAM to allow decrypting data to use it. When the device is in "Before First Unlock" a secure passphrase makes credential-encrypted data extraction impossible because keys aren't in memory.

If the device was in "After First Unlock" then those keys are in RAM and data is accessible regardless of the unlock method used providing there's an exploit to bypass the lock screen. Cellebrite's exploits do this with the original Android OS and some iOS devices and they don't need to know fingerprint, password etc. Their tools don't work on GrapheneOS but we have the automatic reboot feature for this reason as a protective measure.