slannmage

Like why can't I just make the gesture bar invisible? It's super annoying.

It works the same way as the stock OS. Android 15 requires apps to implement edge-to-edge.

Or why does every app cut off the top where the camera is? Why can't I just zoom to fullscreen or just have it working like normal android?

No, it works the same ways as the stock OS. Perhaps you changed the the display cutout mode in developer options. Turn off developer options.

Why can't I have forward swipe on one side and back on the other like how IOS works and the way it makes the most sense?

No, iOS doesn't work that way. You're talking about app specific gestures and comparing them to Android system navigation.

Then you add all that with how there isn't any contactless payment options and it's a big bummer to use. I know they cannot control that one.... I thought Android would have at least one alternative option, but I cannot find one other than buying a Garmin watch.

No, there are multiple contactless payment options working with GrapheneOS.

It's just like why can't they make my life easier in other ways? Hiding the gesture bar, allowing you to select swipe options and sorting the full screen thing cannot be that hard to do.

These things already don't work the way you think they do.

    Matthai It doesn't matter how noisy a tiny minority people are about what they want and it doesn't reflect what the overall community wants. Certain features are disproportionately requested by a tiny minority of power users who will never be satisfied and will never be supportive of the project or development team. We're not going to prioritize a very vocal minority of people who are very entitled and rude towards us over the overall community we have today and the future community that's being built. Most of the community doesn't even use these platforms.

    Most of our users happily use the OS and appreciate the steadily growing number of improvements on top of what's offered by the Android Open Source Project. If they didn't like it they largely wouldn't be using it. If we want more happy users then we have to provide what future users want in order to use GrapheneOS: near perfect app compatibility, ease of use, an easier initial setup, many more compelling privacy/security improvements to make it worth their time, etc.

    Recording every single carrier-based call isn't something the vast majority of people want. It's an incredibly niche feature wanted by a tiny minority that's extremely vocal about it. We can spend our limited resources far better on nearly anything else. The way for something like this to be implemented is for someone to start working on things we consider priorities and then implement a good automatic call recording implementation after they've proven themselves. The problem is that hardly anyone wants this, so that's unlikely.

    The automatic call recording issue has been deleted due to misuse of the issue tracker and has been replaced by https://github.com/GrapheneOS/os-issue-tracker/issues/4740. It will be discussed internally instead of publicly, similar to how we dealt with the charge limit feature. The issue tracker is not a place for people to make complaints and attack the project or developers. If it's used that way, it will be taken away. It's now less likely that the feature will be implemented in the next year or two.

        • Xtreix

          • Post #20
          • Edited

          Well, I'm reassured that such a request is only being made by a noisy minority because I hope such a feature never becomes available.

          What's more, call recording is already available with the default Telephone app, and you should be very careful when using it according to the laws of your country, GrapheneOS cannot be held responsible for any possible consequences.

          Well, I agree, it is noisy minority.

          However, my proposal is to "put the ball in their court". So - make a list of requested features (but only those that developers think they can/could be implemented), put a price tag, and then users can vote with their money.

          If they want to be noisy, let them be with donations.

          Anyway, just an idea. I didn't want to point out specific wishes, my proposal is more general how to deal with this problem.

          • de0u replied to this.

            • N1b

              • Post #22
              • Edited

              You can always throw suggestions their way. In my experience the important and useful ideas or bug reports get attention. But what I appreciate a lot is that there's no feature bounty or community request page like elsewhere.

              99% of us have no idea what we need or what it takes to sustain a highly secure OS. Let the experts do their magic and enjoy the result. Also please let's donate to the project because it's a great privilege that we shouldn't take for granted. If GOS would cease to exist because they lack funding, we'd have to go back to less secure and private solutions.

              Matthai

              "Users can vote with their money" has also been proposed before, and not adopted.

              The project just described (GrapheneOS ) an influence process based on coding, not voting:

              The way for something like this to be implemented is for someone to start working on things we consider priorities and then implement a good automatic call recording implementation after they've proven themselves.

                    de0u
                    This smells of a “buy a feature” approach.

                    No wonder it didn't’ fly.

                        Blastoidea I think part of the problem is that the voting approach and the bounty approach both by definition shift limited developer time away from issues the developers believe are the most important.

                        The "BYOD" (Bring Your Own Developer) approach -- if it goes well -- could result in more developers.

                        So they're opposites.

                          When new features come along they are only a bonus in my opinion. I like im sure many others are just so grateful and appreciative of the hard work the devs put in literally 24hrs per day to keep us secure.

                          Blastoidea
                          Well, my proposal is explicitly trying to avoid that, because I am saying that developers would select a final wish list. So no users buying any features, but paying for a features approved by developers.

                          And of course, this "wish list" would not consist of core functionalities. It should be only (a small) additional list of functionalities that are developers willing to put on a higher priority list.

                          Maybe I am not clear enough, but the idea is that basically everything stays as it is, just users would have an option to do more direct donations for one or two additional feature per year (of their choice but approved by developers).

                          Anyway, just an idea and discussion, though.

                              Matthai what if people who donate don't find their feature in the shortlist? Won't it give them all the more reason to moan about it?

                                ISTM that GOS is primarily devoted to "hardening" AOSP, which is/was otherwise not as secure as it "should" be - in the eyes of Daniel Micay (origonator, lead guru and working geek). Wisely, he was not interested in developing applications or increasing function per se; he wanted a platform that could use EXISTING Android APPS in a safer way - primarily security, with privacy an additional goal.

                                Somewhere along the line GOS had to develop their own PDF reader and heavily customized browser - tools that are very central to smartphone use; and I'd guess the off-the-shelf alternatives were simply too vulnerable to allow. GOS also developed SCOPES - don't know the rationale.

                                Given AOSP is evolving rapidly, I imagine it's a FULL-TIME job just keeping up with AOSP and new hardware.

                                (However, there are lower-priority "enhancements" that the devs are working on, and it might(?) be useful if they got feedback from users on which of those the users would appreciate.

                                E.G. My candidates for prioritizing ongoing enhancements would be IPC Scopes, and anonymized Vanadium.)

                                But the priority has to be maintaining the quality hardening of evolving AOSP on evolving Pixel hardware; and they seem to be doing a good job with limited resources.

                                Enhancements? Dev's call.

                                Matthai Maybe I am not clear enough, but the idea is that basically everything stays as it is, just users would have an option to do more direct donations for one or two additional feature per year (of their choice but approved by developers).

                                It remains unclear how this approach for shifting
                                around items on the todo list would result in more development occurring.

                                Meanwhile there is an approach described by the project that plausibly would implement features on the developer-approved list and would plausibly increase the total amount of development happening. That's different from just shifting resources around.

                                  • Zzzz

                                    • Post #31

                                    People serious about prioritizing their favorite features should crowdfund an independent developer to implement it and post the code to Github.

                                    Seems like other approaches are unwelcome and a waste of everyone's time.

                                      zzz Yes........ PROVIDED the independent developer coordinates with the Devs before during and after, and uses the GOS "style".
                                      The Devs would have to proof-read and test donated apps, and because of various programming approaches and styles, proof-reading and testing a (big) new program in many cases would take more time and energy than writing from scratch.
                                      (There are doubtless many badly-written apps out there - a fact that makes protective GOS even more important)
                                      This approach might be useful if we're talking about small "tweaks" to existing code - still important to coordinate with GOS Devs.