intelligence You need to actually READ THIS THREAD and associated PR.

I believe @Volen suggested a FAQ change (different from a GOS change). Perhaps I misread the post I replied to?

    de0u Hopefully so. However, you replied to me, my message is even quoted in yours.

    So, is this issue still a thing or has it been solved by a recent update? I'm wondering why only a few people are experiencing this issue - or report on it. I did not find any reports on the GOS subreddit, a place where I would assume many users would express their complaints about it, which is by no means any reliable metric, of course. But in my experience the frequency of reading about a certain issues often correlates with the probability to encounter that issue. Judging by the github comment every P7 and P7P should be affected by this, right? So it's not much of a question IF I encounter this problem but how much I am annoyed by it?

      Phead Probably so few people complaining about it because;

      1) The GrapheneOS camera software is NOT affected -- only google camera.
      2) Google camera still works, just that some computational functions are slower since it can't use dedicated hardware.
      3) Only Pixel 7 is affected -- 6 and lower is not.
      4) Pixel 7 has a hell of a CPU, so its not really THAT slow.

        intelligence

        1. 1+2) Yes, however, as someone pointed out not all features are available to the GOS cam. So if you happen to spend your money on one of the new pixels you probably want to make use of the extra camera and its feature set. Personally I am way too old to care about a few seconds here and there. But, as someone else pointed out, the camera locks down after 3 or so shots (portrait mode) and thats less cool if that's a recurring problem
          3) True, did not take that into account
          4) Apparently the slow down is intense enough to cause the camera to lock down for some time if you happen to take more than one shot.

        Personally, I can live with some downsides to GOS as its fundamentals focus on something else than flashy pics and bokeh effects. But as a soon-to-be GOS User
        I would like to know as many downsides as possible before plugging in the cable and press the button. So if this problem persists on all p7 devices ir should be stated somewhere as known issue, just as a heads-up before you dive in.

          Phead "it should be stated somewhere"

          I don't know about that. GOS' mission is essentially to provide a usable de-googled experience. That any Google app is usable in GOS', perhaps say with altered network permissions, is a bonus. Many users of GOS would never even attempt to install or use Google Camera.

            spiral

            Right. On the other hand they have a specific section for just the camera: https://grapheneos.org/usage#google-camera

            Don't get me wrong, I'm not saying a lack of camera features is a no-go. As you said most users won't even be using Google apps. But they specifically say that gcam is fully functional which is apparently not the case for P7 devices (yes, they work just fine except when taking portrait pictures, but you know what I mean) Again I'm not compalinig. GOS is awesome and they're doing a great job. I just think it's good to manage expectations there.

              Phead
              Hmm. Well considering there is a section on it, perhaps i was incorrect.

              • [deleted]

              Considering that Google Camera has these issues on stock P7 line, isn't this a job for Google to do rather than discussing it here? I mean there's nothing wrong with discussion, it just happens in the wrong room.

                • [deleted]

                intelligence I apologize for misreading OP

                "This happens with both stock Google Camera and modded GCam.

                For comparison, in stock OS, portrait picture processing takes just 1-2 seconds."

                Phead
                So they're saying "Google Camera can be used with the sandboxed Google Play compatibility layer and can take full advantage of the available cameras and image processing hardware as it can on the stock OS"

                But on the 7 series, this is not the case. I think it should be at least noted there.

                16 days later

                To confirm - its still an issue and I don't think it will be fixed anytime soon.

                As already discussed, the root cause is that Google Camera does all the processing on its own and uses special SELinux domain for hardware acceleration. That SELinux domain is removed in GOS for security reasons.

                So the only way to make it work is either GOS team bringing it back (which they confirmed they won't) or Google fixing their Camera app to change the SELinux domain (which they say they are working on but its been months and months with no progress so its most likely never be fixed).

                GOS camera (and any other 3rd party camera) are using the same (restricted) API that lacks all the processing Google Camera offers hence the quality is not comparable. It doesn't matter what 3rd party Camera app we will use - they all use the same API so the quality will be more or less the same (and not good vs Google Camera).

                Maybe if many people ask GOS developers, they will consider to implement a toggle or something similar that will enable SELinux domain in Google Camera with user accepting potential risks associated with this. I am not a developer so not sure if this is a feasible option but maybe it will be possible to implement a toggle?

                Currently, Google Camera is really slow in processing images, especially, portrait pictures or when taking multiple pictures at once.

                  Volen

                  I think it's not so much a question of how to add this option, but if it's part of their philosophy and vision for GOS. From what I've read it's not and I can accept that (even though it gets annoying when that tiny ring in the lower left corner is literally a couple of pixels away from a full circle but takes another 20s to compete) . The focus of GOS is on privacy and security and part of that mission is to control software privileges. If that commitment breaks the cam app, it's bad and annoying but on the other hand I gain control over my privacy. So, not sure if a switch would ever make the cut.

                    Volen So the only way to make it work is either GOS team bringing it back (which they confirmed they won't) or Google fixing their Camera app to change the SELinux domain (which they say they are working on but its been months and months with no progress so its most likely never be fixed).

                    Is there a publicly-visible issue on Google's Android web site which people could upvote?

                    For the GrapheneOS developers it probably isn't "just a toggle". It would need some sort of disclaimer, plus probably it would need to include a PIN prompt. Then there would be code to activate/deactivate the supplemental SELinux rules. And then if Google eventually fixes the issue on their end there might need to be some GrapheneOS migration code to get rid of the stale preference. Probably this wouldn't be a mountain of code, but it also probably wouldn't be just a rainy-afternoon project.

                    On the other hand, maybe it would be short and sweet, in which case maybe if somebody submitted a pull request it would go in, and if it were rejected instead then all that would be lost is a rainy afternoon.

                      Phead

                      Whilst I agree with your thoughts, there are still many compromises that devs take - for example, sandboxed Google Play services. Even though they are much less intrusive and restricted, these are still Google services that can transfer data to Google (if they have Network access) and/or communicate with other installed apps and try to harvest data. Users are using these at their own risk. The same applies to pretty much any non-foss and non-privacy friendly app, for example, banking apps, shopping apps, etc - users acknowledge that these apps might use telemetry, collect data, communicate with other apps, etc. The same applies to Google Camera - I am not sure if its hard/feasible to do so, but if its achievable than it definitely won't hurt if users will have an option to grant elevated permissions to the policy in question to sort out processing speeds (just like they have the option to install sandboxed Google services or other 3rd party apps, acknowledging the associated risks).

                        de0u

                        There is an SR with Google (link is in this thread above) but it has nothing to do with GOS - its just an open ticket with Google with a request to modify their camera app which they say they are working on but there are no news for months.

                        The upvote thing to add a toggle/ability to grant elevated permissions to the domain in question should be done on GOS forum/github/other official GOS channel so that devs will see that there are many people interested in this feature.

                        But, again, we don't know if its a feasible option - maybe its not even possible to add a toggle. Only devs will know.

                          Volen The whole point of sandboxed Google Play is that they're regular apps which cannot do anything beyond what regular apps can do. They are not simply less intrusive and restrictive. They cannot do absolutely anything more than any other user installed app. They have no special access to any data of any kind. They have no special ability to communicate. Apps can only communicate with mutual consent within a profile. Apps could directly send data to their server instead of sending it to another app, so you're focusing on something that doesn't really make sense. Network is not and has not been presented as a full toggle for data exfiltration. It's a full toggle for both direct network access and indirect network access via the OS. In terms of communication with other apps, it only controls access to interfaces they mark as requiring the INTERNET permission. It is not a toggle for app communication and is never going to be one since that's not the purpose of it. We do plan to add app communication control toggles which has no direct connection to the Network toggle.

                          Volen Do not send us more requests for something that has been rejected for clearly explained reasons.

                            Volen

                            As already discussed, the root cause is that Google Camera does all the processing on its own and uses special SELinux domain for hardware acceleration. That SELinux domain is removed in GOS for security reasons.

                            It is removed because we don't give special privileged access to Google apps. It would only be possible to do it behind a special toggle which is not planned since nearly everything works fine without it. Portrait mode on 7th generation Pixels is the only thing there have been complaints about and they're working on fixing it in Google Camera.

                            GOS camera (and any other 3rd party camera) are using the same (restricted) API that lacks all the processing Google Camera offers hence the quality is not comparable. It doesn't matter what 3rd party Camera app we will use - they all use the same API so the quality will be more or less the same (and not good vs Google Camera).

                            This is completely wrong. Google Camera on the stock Pixel OS has no special access to any additional camera APIs. Other apps can provide the same features and quality. Features and quality vary quite a lot across apps. There is no special magic in Google Camera that's unavailable to others in terms of features and quality. The only special access it has is to hardware acceleration features for more quickly doing the processing when treated by the OS as a specifically privileged app.

                            GrapheneOS Camera provides hardware accelerated HDR+ on Pixels via the standard Camera2 APIs since the OS and hardware implement it. Google Camera implements their own comparable HDR+ although they have more control over it, meaning they can adjust it to be more aggressive in low light conditions. HDR+ provided by the OS can and should do that too, and they're working on improving it to match Google Camera in all conditions. Night mode, Portrait mode, etc. will be provided via CameraX extensions via the OS in the future. There won't be any special access required to use them, because the OS camera service will implement them itself. Google Camera will almost certainly continue doing it separately in the short term. In the long term, they may move most of the features into the OS instead of doing the processing in Google Camera and only needing the APIs needed to obtain the data in the OS.

                            Currently, Google Camera is really slow in processing images, especially, portrait pictures or when taking multiple pictures at once.

                            GrapheneOS Camera provides hardware accelerated HDR+ on Pixels via the standard Camera2 APIs since the OS and hardware implement it. It will have hardware accelerated Night and Portrait modes on Pixels when those CameraX extensions are available. This is our focus.