Production releases with Google Camera are given direct access to the Qualcomm DSP and 4th gen Pixel Neural Core via a custom SELinux domain. Google Camera works fine without the custom domain but the processing takes a bit longer since it loses that hardware acceleration.
Conversation
On GrapheneOS, we remove the custom domain since it's barely noticeable on modern devices and we don't want Google apps having privileged access. Google Camera still works fine for us. We could allow it to use that but removing is part of the whole sandboxed Google Play approach.
1
2
Pixel 6 got rid of the custom domain for Google Camera. They moved all of that stuff into the OS via a vendor APEX with the camera HAL implementation. It's really inexplicable that they don't support all the Camera2 and CameraX extensions. They have 99% of the work done already.
1
1
The reason the CameraX Night extension is missing is because the Pixel camera people wanted fancier extension support so they waited until that shipped via Camera2 extension API to support it. CameraX still has to finish implementing the advanced extension API. Bad coordination.
1
2
And then the problem is that once CameraX ships that, which it has largely done now, Pixels still need to take advantage of it by shipping the 1 extension they provided for CameraX in addition to Camera2. It's frustrating for us Samsung has 5/5 CameraX extensions and they have 0.
1
1
Most GrapheneOS Camera users are on GrapheneOS where none of the extensions are available since Pixels don't provide it yet. If Samsung had proper alternate OS support keeping hardware security features supported and published easy to use AOSP support we could support those...
1
2
Samsung's flagships actually do meet our baseline security requirements for the stock OS but they don't support using a bunch of the hardware security via an alternate OS. Also, way too many variants of their phones and way too hard to support them not just because that mess.
1
1
Replying to
I remember with the Galaxy fold 2 they disabled cameras on the stock rom if the bootloader was unlocked. Very not alternate OS friendly
1
Replying to
That's essentially how it works with many of the hardware security features on almost every single non-Pixel. It's mostly that they don't want to bother implementing them. Some devices had partially working verified boot for alternate OSes but it was insecure/broken.
1
1
Samsung seems to be the only non-Pixel phone currently available with Weaver support (grapheneos.org/faq#encryption) which is one of the hardware security features we consider mandatory. Problem is that most devices have fallen literally years behind Pixels in a lot of security areas.
1
2
To sum up the importance of Weaver: on Samsung flagship or Pixel, a random 6 digit PIN gives you highly secure encryption that can only be bypassed by exploiting the secure element.
On nearly all other Android devices, 6 digit PIN is trivially bypassed. You just need OS exploit.
On other devices, you literally need a 7 diceware word passphrase (~90 bit entropy or higher) to have working encryption. That seems quite important for most users, and yet no one talks about it. There are many other examples. Most vendors really don't care about security.
1
2
You still ideally have a high entropy passphrase on a Pixel, but 6 digit random PIN does hold up to even sophisticated attackers unless they find a secure element exploit, which is increasingly hard, especially with Pixel 6 Titan M2 where ARM Cortex secure element was replaced.
1
2
Show replies