I absolutely want this feature! This is a killer feature for me.
I know it's not a lot but I will contribute USD 100 to its development, this offer expires if not claimed within 2 years from today.

Conditions:

  1. can't depend on specific dialer.
  2. Recordings have to be from the original audio stream, not some workaround via the accessibility API or switching to speaker and recording the mic.
    The stream should be the original audio stream or reencoded with a high quality codec like AAC.
    Bonus points if the audio recording has separate tracks for mic and for remote audio.
  3. Recodings have to be sorted by remote phone number and timestamped.
    Bonus points if if the recordings can be sorted depening on if they were made with SIM1 or SIM2.
  4. Should not crash or bug out. Even if output is changed e.g. from internal speaker to Bluetooth and back.
  5. The code for the API should be open source of course and licensed so it can be used and improved if necessary

Basically I wish it would work like the old Call Recording APIs and apps ( https://stackoverflow.com/a/6688569 ) before Google systematically broke their functionality.

Toasty GrapheneOS currently does not have and does not plan to add the call recording feature. And as far as I know there are no open source way to do it without rooting (which according to my knowledge breaks the GOS's security model).

Absolutely there is a way to do this without "rooting". NONE of the call recording applications that are available actually use root! The mistake you are making is in understanding the nature of the elevated privileges required and how that relates to Magisk.

The reality is that how programs are installed determines what kind of privileges they have access to. If an application is installed as a privileged system application (which means that the APK is installed in /system/priv-app/), then it gains access to an additional set of privileges that a regular user-installed application won't have access to, and THESE privileges are sufficient to enable call recording.

Magisk has a way of placing an application in the privileged location without actually modifying the filesystem. THAT is what is being used to make call recording work. It does NOT grant root privileges to the call recording application!

So if you want to make call recording work on GrapheneOS without Magisk, you need only place the application in the privileged location DURING SYSTEM BUILD.

BCR is a very concise and open source call recording application that could easily be audited for safety and included. GrapheneOS has come up with a huge heaping pile of excuses against including it, such as "the GPLv3 license is not compatible with GrapheneOS" -- which is totally nonsense since GrapheneOS has a TON of GPL components already! The kernel itself is GPLv2, which is close. There are also a bunch of GPLv2 and GPLv3 components in /external/

    intelligence BCR is a very concise and open source call recording application that could easily be audited for safety and included. GrapheneOS has come up with a huge heaping pile of excuses against including it, such as "the GPLv3 license is not compatible with GrapheneOS" -- which is totally nonsense since GrapheneOS has a TON of GPL components already! The kernel itself is GPLv2, which is close. There are also a bunch of GPLv2 and GPLv3 components in /external/

    It's not "nonsense". You're misunderstanding how things work. GPLv2 is nothing like GPLv3. In fact, the Linux kernel is GPLv2, as well as Vanadium.

    Are the GPLv3 stuff you supposedly found in the OS, or are they third party tools to build the OS?

    Regardless, for the call recording stuff, the approach of including an app like BCR is not one that the project is going to take. If a minimal way to include this functionality in the dialer app was submitted which could be maintained going forward, it may be considered.

      As a follow-up, I should also make it clear that even if this did happen, and someone was paid to include this functionality into GrapheneOS, there is absolutely no guarantee that it would be accepted into the project, as it would hinge on the implementation being minimal, sound, and easy to maintain, which isn't a given.

        matchboxbananasynergy I'm wondering if (and I realize maybe not!) it might be possible to provide potential contributors, for this or other features, some parameters... Maybe "We can't review features with more than 3kloc of code, pure Kotlin only, must not depend on any packages GrapheneOS doesn't already use, must be tested on all supported devices, must pass these static testers, must be tested in work profiles & secondary profiles, ..."?

        matchboxbananasynergy I misunderstand nothing. There is absolutely no reason whatsoever for a STANDALONE application to be disqualified as a result of GPLv3.

        If it was a patch to an existing application it would be a different story, because then the licenses would have to be compatible, but the call recording program is completely standalone and isn't even linked to other libraries.

          What are we doing here, trying to buy our pet “feature”?

          intelligence Being installed as a privileged app only makes an app run in the priv_app domain instead of untrusted_app. It doesn't provide privileged permissions unless the app both requests them in the manifest and has them whitelisted in the privileged permission whitelists within the OS. Privileged apps can't simply do anything with privileged permissions.

          GPLv3 components will not be included in GrapheneOS. There are no GPLv3 components included in GrapheneOS. Not everything within the AOSP source tree is included in the OS. A substantial portion of the AOSP source tree provides development and testing tools including the Android SDK, NDK, etc. It also has sample code and much more. GNU toolchain used to be used to build the OS and kernels, and that's still around. There has never been GPLv3/LGPLv3/AGPLv3 code included in AOSP and likely never will be any. GrapheneOS won't be including it either. It would make the licensing of the overall OS more restrictive in a way that we don't want to do, since we want it to be a drop in alternative to AOSP for companies to be able to use.

          Auditing a large existing application would not be easy and the result of a review of the code would likely be that it has issues which prevent us from including it.

          intelligence Anything included in GrapheneOS cannot be GPLv3. It's fine for it to be GPLv3 as a standalone application not included in the OS. We could package a GPLv3 app in our app repository but we won't include one in the OS.

            Paying someone to implement and maintain call recording for years would take a significant amount of money, not dozens of people contributing $20-$50. Getting an existing implementation into shape would only be the start. If it's based on AOSP Dialer, then it will need to deal with AOSP Dialer changing over time. If it's not based on AOSP Dialer, that brings new issues since most dialers aren't a fully compatible replacement without lost functionality so that's less likely to be the approach. They also wouldn't benefit from improvements in new major AOSP releases like AOSP Dialer, which is still maintained to an extent. The best approach would likely be extending AOSP Dialer. People making commitments to donate after something is implemented won't be taken into account at all. We don't accept those kinds of feature bounties.

              GrapheneOS Being installed as a privileged app only makes an app run in the priv_app domain instead of untrusted_app. It doesn't provide privileged permissions unless the app both requests them in the manifest and has them whitelisted in the privileged permission whitelists within the OS. Privileged apps can't simply do anything with privileged permissions.

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

              GrapheneOS Auditing a large existing application would not be easy and the result of a review of the code would likely be that it has issues which prevent us from including it.

              SMALL application. BCR is very small.

              GrapheneOS GPLv3 components will not be included in GrapheneOS.

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

                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.