Bluetooth headphones not working when receiving a call

guser39 "Upstream" for GrapheneOS means AOSP, not Google's Pixel OS, which contains all sorts of proprietary code. Edit: If the issue is absent from DivestOS on Pixels, then it might be a GrapheneOS issue.

This happens with other Android phones too.

Try these quick fixes:

Restart Bluetooth or forget/re-pair headphones.
Update phone and headphone software.

de0u this is kind of why I'm asking. Does this occur on other AOSP derivatives or not? There is no mention of upstream bug trackers or issues. So, this just seems like a hand waving "upstream" label.

I'm totally fine with issues being upstream but no evidence has actually been presented that supports this conclusion. If there is a known upstream issue then why not include that in the GOS issue when marking it as upstream?

guser39 this is kind of why I'm asking. Does this occur on other AOSP derivatives or not? There is no mention of upstream bug trackers or issues. So, this just seems like a hand waving "upstream" label.

Please note that I do not speak for the GrapheneOS project. That said, I can imagine multiple ways that a GrapheneOS developer might determine to assign an issue upstream:

1. Finding the issue in the AOSP issue tracker,
2. Reproducing the issue on a device running AOSP,
3. Finding the issue in an issue tracker for some non-GrapheneOS AOSP variant,
4. Reproducing the issue on a device running some non-GrapheneOS AOSP variant,
5. Skimming relevant code and observing a plausible problem,
6. Believing that GrapheneOS has not modified the relevant code areas, and that this provides sufficient certainty for the issue in question to assign it as upstream.

guser39 I'm totally fine with issues being upstream but no evidence has actually been presented that supports this conclusion. If there is a known upstream issue then why not include that in the GOS issue when marking it as upstream?

Both AOSP and GrapheneOS are open-source projects, so you have opportunities to volunteer!

1. You could search for the issue in the AOSP issue tracker and, if something is found, add it to a GrapheneOS issue,
2. You could build and install AOSP and try to reproduce the issue on AOSP (presumably filing an AOSP bug if you do reproduce it),
3. You could search some trackers for some non-GrapheneOS AOSP variants,
4. You could install one or more non-GrapheneOS AOSP variants and see which might exhibit the issue,
5. You could try reading relevant code.

de0u

de0u Finding the issue in the AOSP issue tracker,

Then it should be simple for them to link to the issue so that we can track and provide our own experiences there to promote its importance.

Anyway, this thread doesn't seem to going anywhere. I asked the simple question of proof for the upstream tag, not a philosophical debate. If GOS doesn't have actual proof for the upstream tag then they should just admit that's the case.

I am well aware that I could volunteer but don't have the time to do. My experience is in Python, not Kotlin, C, or whatever AOSP uses. That's why I support GOS financially and occasionally here in the forums.

guser39 Bruh Bluetooth is not reliable on AOSP... Fact of life... Still many reasons to love GOS

DeletedUser115 this is not a helpful response.

All I asked was for proof supporting the upstream label, such as an upstream bug report.

Let's say that I was interested in contributing and working on the buggy Bluetooth behavior. At this point, I have no starting point. Just a GOS bug issue that points upstream with no further guidance or bug reports to investigate. Supposedly, GOS maintainers know of upstream bugs or the buggy sections of code. Wouldn't it be helpful if they annotated that? By not providing any context, they only make it harder for potential contributors and the upstream maintainers, because now people don't know where to focus their efforts or bug reports. I'm not asking them to solve the problem, just provide some additional context for why it's upstream, not GOS.

Bluetooth may be a lost cause but problems (in general) don't get resolved when people just throw up their hands and stop even tracking or linking data.

@guser39 The developers have many things on their plates. I don't see why they should waste their time finding proof of issues being from upstream. Have you checked out the upstream issue tracker? It's a nightmare to find stuff in it because it's filled with so many issues, many of them duplicates or invalid or just out of place. I'd rather the developers spend their valuable time working on GrapheneOS, not hunting down issues to copy and paste links to.

GrapheneOS developers don't usually fix upstream issues because doing so would be a waste of their valuable time. Also, this specific issue has little to nothing to do with mobile privacy or security. GrapheneOS does sometimes fix some upstream issues, but it doesn't look like this one will be one of them.

Someone already listed different reasons why they could know the issue is from upstream. If an issue isn't linked, it could be that they just simply know that the issue isn't caused by changes made by GrapheneOS. It's not difficult for them to say certain things are upstream bugs when they know they haven't touched any of the relevant code. Even if they do know for sure that there's an issue in the upstream issue tracker, why should they go find it? Upstream issues are upstream devs' problems.

Even if a member of the community did fix this issue, it would still take up GrapheneOS developers' time. They'd have to review the code, very likely have to spend a lot of time doing that and suggesting improvements, etc. Then even after the contributor should maintain the fix in case it breaks after future updates, which would take up even more of the GrapheneOS developers' time. If the contributor just doesn't do that, then GrapheneOS developers then have to maintain the fix themselves. The upstream project should fix the problem.

guser39 Let's say that I was interested in contributing and working on the buggy Bluetooth behavior. At this point, I have no starting point.

If you want to work on this, you can ask in the issue tracker. Part of the point of the issue tracker is to collaborate on identifying and fixing issues. If someone expressed genuine interest in fixing something, the developers will discuss there. But you've already said that you don't have the time to contribute, so please don't ask them for clarification just for your benefit.

Finally, I do have to say that a couple of your responses on here come off as rude. Being rude is no way to get help or to get answers. You say you don't have time to contribute, but instead you come to the forum to complain that the developers didn't provide enough evidence that an issue is from AOSP to satisfy you. This is no way to get answers.