Automatic call recording

Apparently its been unassigned. Anyone interested in actually implementing it? There's even sample code in the feature request.

I noticed there is so much people asking for automatic call recording. Today phone calls are a blend of cellular/WhatsApp/Signal and others. How do you deal with call recording from messaging apps ?

This is exclusively for actual phone calls. You can't really do universal voip call recording since the data comes in all kinds of different ways.

Found this after a search. I'd definitely like this feature. Surely since the recording feature is already implemented, a switch for automatic shouldn't be too cumbersome.

riddlemethis Surely since the recording feature is already implemented, a switch for automatic shouldn't be too cumbersome.

"easy to do" is easy to say.

ve3jlg Who are you quoting.

riddlemethis Surely since the recording feature is already implemented, a switch for automatic shouldn't be too cumbersome.

It might be instructive to code it up and report back how much code a baseline implementation is. But that's only the tip of the iceberg.

Recently there was a post about a situation where a user had inadvertently filled up device storage by accidentally leaving video recording on overnight. Luckily, restoring the device to usability was possible without a factory reset, but the situation was still a bit of a sticky wicket.

So automatic call recording, to be safely deployed to the masses, arguably needs a bunch of code to suspend its own operation if storage space is getting low. How low? Once that point is reached, how should the user be alerted? Should the user be alerted before automatic call recording is disabled? What if the user disabled notifications for the dialer app? How about folder structure? If a user is likely to collect thousands of recordings, should they all be dumped in one folder, or should they be split by year and month?

It would arguably be prudent to have some sort of carrier testing plan. The initial roll-out of call recording was complicated because the "record" button was off the bottom of the screen for some users whose carriers supported some optional in-call features that, apparently, the developers didn't encounter in their testing.

What looks like one simple toggle on the screen might have a lot of code behind it, and also a lot of testing work.

de0u

de0u Recently there was a post about a situation where a user had inadvertently filled up device storage by accidentally leaving video recording on overnight.

Notice how the first and only response was a link to the Google Android support page? That's because this is a ROM of Android and thus an Android problem. Not a GrapheneOS problem.

de0u So automatic call recording, to be safely deployed to the masses

Automatic call recording wouldn't be deployed to the masses enabled. It would be opt-in by a settings toggle.

de0u if storage space is getting low. How low?

Are you comparing tremendously large video files (probably 4K) to low bitrate audio files recorded during a phone call, as the same thing? :\

de0u The initial roll-out of call recording was complicated because the "record" button was off the bottom of the screen for some users whose carriers supported some optional in-call features

Completely irrelevant to this discussion.

The record button & functionality exits. It's on every call. It has been for a long long time. This is a really simple concept which logically designates 'when call comes in: button automatically enabled'. It's not rocket science.

de0u What looks like one simple toggle on the screen might have a lot of code behind it, and also a lot of testing work.

It certainly does when there are entirely moot and irrelevant purview's being made about it ;)

riddlemethis Call recording is already a feature. Unless I am missing something, it was implemented by someone who isn't a project member (see the commit for it).

GrapheneOS project members have a lot on their plates already. I think somebody from the community will have to put in the work for this to be added.

i've noticed another issue with call recording. when the dialer is on call and when the dialer is closed the recording stops and we have to start the recording again. this does not happen on the other phone that i have where same type of dialer call recording is implemented.

yourmother
Automatic call recording isn't currently a feature. An issue is open for it, though its not a priority as the last comment says. Someone self assigned themselves 2 weeks ago, so who knows when it could be added?

Issue 2083 was deleted, new one 4740 is locked, so I'm just curious - what is the current status of this feature request? Any unofficial patches to try?

Some background - 30+ years experienced Debian user here (yes I still remember the Internet before Google even existed), but totally new to Android hacking, I came here looking for a solution because sometimes I get phone calls with threats, but without any recording as a proof, the police will most likely do nothing until something bad actually happens. So I want to protect myself better, and yes it is 100% legal to record my own conversations here in Poland without telling anyone. So I started researching how to record my own calls, got surprised how hard the big tech companies try to make it (even though they like to record everything when you call them), what kind of phone to buy to do it anyway etc. I've just got myself a used Pixel 4a with LineageOS already installed to play with, and discovered that GrapheneOS should be even better in many ways, but is still missing that one feature which would be useful to have (yes I know I can enable it manually in each call, the point is I'd rather have that enabled by default and delete the unnecessary recordings, and it used to be possible long long ago when my main phone was a Nokia N900).

Not complaining, actually great to see there are more open alternatives to Android with better security and privacy, many thanks and please do keep up the good work! :)

marekm72 I suspect this post from a year ago is still accurate: other8026 .