If you do get ADB access, a filesystem write vulnerability or exploit the device to get code execution then this app is irrelevant since you already have more a

If you do get ADB access, a filesystem write vulnerability or exploit the device to get code execution then this app is irrelevant since you already have more access. A real attack vector has not been presented, which is why Google determined that it wasn't valid security vulnerability. That's their standard operating procedure. That doesn't mean they won't fix a bug or remove attack surface. They removed Showcase from Android 15, which is visible in the Android 15 Beta. However, you do need more than physical access with a Pixel to enable this and set it up. They have full verified boot with a specific per-device key (which is how key rotation gradually happens) and anti-rollback fuses to prevent downgrade attacks to old vulnerable versions. The OS images are completely verified with anti-rollback via the secure element which has authenticated encryption between it and the main SoC. The data partition for the OS has every block encrypted, although it's not authenticated encryption yet. The firmware is quite locked down and reset attack mitigation for firmware boot modes was added in April based on a vulnerability report from us in January. RAM isn't fully encrypted yet but it's quite difficult to tamper with modern RAM or even dump it without controlling the OS / SoC firmware unless there's debugging functionality left enabled in production. Fully encrypted RAM is the main thing they're missing aside from a more hardened OS. Cellebrite can successfully exploit up-to-date Android and iOS devices with physical access as part of their Cellebrite Premium product, but it's increasingly not easy for them. They often fall behind with updates, but they consistently catch up again. Leaked July 2024 documentation showing the current capabilities is available here: https://grapheneos.social/@GrapheneOS/112826067364945164 https://grapheneos.social/@GrapheneOS/112826067364945164 For GrapheneOS, our aim is defending the device long enough for our auto-reboot timer after locking to activate combined with zero-on-free and firmware reset attack mitigation. They haven't been very successful at exploiting GrapheneOS but did develop exploits for older versions from 2022 and earlier. Physical access is not an entirely lost cause, the goals just need to be well defined. Defending the device for 18 hours since it was locked (our default auto-reboot timer) is our goal. Users can set auto-reboot as low as 10 minutes but then they'd be missing notifications.