intelligence

Recording calls is one of those things that being privileged allows.

It's a privileged permission and GrapheneOS enforces privileged permission whitelisting as required by the standard Android security model.

SMALL application. BCR is very small.

It's quite large in the sense we're talking about. Small is a few thousand lines of code like Auditor.

That's a major problem and a very poor position for you to try to support since it makes absolutely NO sense.

We've explained why that's the case. GPLv3 imposes additional restrictions which AOSP avoids including forbidding making devices with an immutable root of trust. This is a problem because we don't want to forbid making a device with GrapheneOS without support for unlocking. What if we want to sell a special variant of a GrapheneOS device without support for that to reduce attack surface, particularly since it's something many companies prefer? It's not anywhere close to the lowest hanging fruit for verified boot attack surface but it is attack surface.

      GrapheneOS It's quite large in the sense we're talking about. Small is a few thousand lines of code like Auditor.

      Auditor is 4,769 lines of code.
      BCR is 4,036

          GrapheneOS we don't want to forbid making a device with GrapheneOS without support for unlocking.

          Would not forbid it, the component may be left out without affecting the rest of the system since it is absolutely 100% standalone and nothing depends on it.

            intelligence perhaps your efforts would be best spent convincing BCR to change to GPLv2 now?

            GOS has been very clear that they won't include GPLv3 code.

            You've shown that BCR has a small codebase.
            A maintainer could probably be found.
            But, GOS is firm on no GPLv3.

                guser39 If you feel strongly enough to harass BCR for a license change, then that's on YOU. My position is that there is no need to.

                    intelligence If you feel strongly enough to harass BCR for a license change, then that's on YOU.

                    lol. No. It isn't.

                    You and several others are the ones that seem to be highly invested in GOS adopting BCR. I was just suggesting that there is a second way to address the GPLv3 licensing issue, especially given that GPLv3 appears to be incompatible with a core part of GOS: verified boot and not modifying the system.

                      I would suggest against doing that. Changing the license of a project is not an easy affair. Please don't bug developers to do that; they likely won't. Even if they did, GrapheneOS is still very unlikely to add an app like BCR into the OS. LoC isn't the only thing that matters here.

                      The project account has already detailed what approach might be considered, please respect that.

                      intelligence
                      Auditor is 4,769 lines of code.
                      BCR is 4,036

                      If BCR depends on a lot of libraries that existing parts of GrapheneOS don't, the sizes of those matter too.

                      And if the GrapheneOS developers won't accept GPLv3 code, then code size including libraries is not enough.

                      Aside from app code size, library code size, and licensing, code quality matters too. Not having even glanced at BCR, I am not insinuating anything! But it would need to be evaluated.

                      Meanwhile, building one's own copy of GrapheneOS remains an option, and might be faster than achieving policy changes.

                        It would have been great to have the ability to simply access "system sound" as you can do in windows. That way you could just record the entire sound output of the OS. If the entire sound output could be exposed using permission system that could be granted to apps, then you wouldn't even need specialized apps. You could have a simple app that records system sound using permission and using microphone sound using permission and that would be it.

                        I wonder how much effort it would take to introduce such a permission to the OS. I wonder if this would be much simpler option with almost no upkeep to worry about.

                          User2288 I agree, not sure how technically challenging this could be, but this would add an option to record calls not only in dialers but also in messenger apps like Telegram, Viber, Signal, etc. At least in my area these apps seem to be used for calls more often than the regular calls.

                            In fact, I'd go one step further and say, doesn't the built-in screen recorder already record system "video" AND "sound"? If so then the code to capture system sound is already build in. I'd think its just a matter of extracting that code, adapting it and putting it under a permission. I wish I was an android developer, I'd have sure looked into this.

                            BTW I too support the pay to support call recording. But I think what I've suggested is a much better solution. As @thetraveller1 said, this way you can also record any source/app, and you wouldn't be locked into a particular dialer/call app for the recording feature.

                              User2288 I just tried - and the screen recorder doesn't seem to record voice of the conversational partner that is played through the earpiece speaker, only your own voice and sounds that are played with the loudspeaker.

                                  GrapheneOS

                                  How about we restore the old Android APIs ( https://stackoverflow.com/a/6688569 ) for call recording that worked great for years before Google purposely broke them.

                                  The users could then reuse the myriad of already existing old recorder apps. No changes to maintain in the caller app or in the settings. No GUI to adapt. No additional recording file logic to implement. No root privileges required. "Just" make some legacy APIs public again. Maybe modernize them by requiring a permission that the user can give for extra security. Have you considered this?

                                    Does recording whatsapp/telegram/signal work with the screen recorder? Anyone know?

                                    thetraveller1 I just tried - and the screen recorder doesn't seem to record voice of the conversational partner that is played through the earpiece speaker, only your own voice and sounds that are played with the loudspeaker.

                                    So if you put the conversation on loud-speaker and low volume, is the other person's voice recorded? If yes, does it sound like the other person's voice is recorded from the speaker reflecting back into the microphone or does it sound like the original good quality sound stream?

                                    If other person's voice is not audible when through the ear piece then obviously the sound channel is totally isolated. But I think it could be exposed using a permission as another audio channel, to be captured. It has to get baked into the OS.

                                        In my organization, GrapheneOS would be welcomed but the lack of voice recording is a no-go for now:

                                        • some users do need it for legal purpose.
                                        • many use it to ease the process of taking notes and/or to write meeting summaries or verbatims (sometimes using voice recognition afterwards).
                                        • de0u replied to this.

                                          Carbon14 In my organization, GrapheneOS would be welcomed but the lack of voice recording is a no-go for now.

                                          Depending on the size of your organization, it might have an IT person who could do custom builds of GrapheneOS including BCR (or something else). The build directions are clear enough that even I was able to do it, despite never having written any Android code at all. Arguably the build directions could be improved by adding an explicit list of the steps necessary to re-badge the resulting OS (i.e., so it doesn't advertise itself as "GrapheneOS", uses a different boot logo, etc.). A "private label" OS for your organization could probably be deployed in a week or two (including an update server).

                                          At the other end of the timeline spectrum, contributing call recording to Google's AOSP project, if successful, would likely result in it showing up downstream in GrapheneOS. That could easily take more than a year -- again, if successful: Google might just not be interested in adding call recording to AOSP. I suspect they would not at all want to incorporate GPLv3 code such as BCR or any derived work (which would also be GPLv3).

                                          Please note that I don't in any way speak for the GrapheneOS project (and certainly not for Google!).

                                            aguttfx This would kill any potential implementation as it would violate states that have two-party consent laws to recording phone calls.