And the HDR+ they are currently providing to other apps, at least on 2nd, 3rd, 4th and 5th gen is not as good as the HDR+ in Google Camera. Note we have not tested how it compares on Pixel 6. It's possible the gap is smaller now since they'd have had to redo it for Pixel 6.
Conversation
Also worth noting: Google Camera is entirely based on the normal Camera2 API. Other apps can use the same APIs. They use Camera2 scene modes for Portrait, Night, etc. but they do all the actual processing themselves including for HDR+ with Google Camera.
1
1
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.
1
1
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.
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.
1
2
Show replies