Gguser39
- Joined Mar 19, 2023
other8026 wtf kind of UI genius at Google decided to hide a submenu like this. As a long-term Android user I remembered these existing at one point but I lost track of them and assumed they'd been removed. :(
It was configured as optimized. I've switched it to unrestricted and will test it later this weekend.
splattergames "allow background usage" is enabled for the app.
Just tested it. The music app stops playing after 24 minutes of sitting on my table (no interactions with the device). The device is connected to a charging port and the music app has the "allow background usage" enabled.
I do not have a stock Pixel device to compare with. So, I can't say if this is an upstream bug or not. My device is running GOS 2024102400.
I've also noticed this with my music app. If I leave it running it gets killed after a while.
- Edited
This sounds like you're using a secondary (non-owner) profile and incoming calls won't use Bluetooth. If this is the case, then you're not crazy and there is nothing you can do. It's an upstream Android bug.
You can track and comment: https://issuetracker.google.com/issues/232112722
- Edited
flighty_sloth it's an upstream design choice by Signal.
To be clear, this is not a choice by Signal. It is a choice by Molly, and more generally one made by developers of many projects. Version changes can lead to differences in database structures and other quirks. So, it could lead to problems and data loss if you attempt to use data when there is a version mismatch.
Molly documents this on their migrating from Signal and warning about backups project pages. Turn off autoupdates for Signal and wait a week or two.
It's an upstream bug most likely: https://issuetracker.google.com/issues/232112722
Check this upstream bug. Does this seem like what you're experiencing? If so, I recommend following up there.
GrapheneOS there's still regular networking between the different isolated virtual machines.
This is incorrect. Network communication between individual qubes is blocked and requires the user to manually allow for such communication.
https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes
GrapheneOS It doesn't make the operating systems or applications harder to exploit and doesn't contain them better within the workspaces.
This isn't exactly true or at least it ignores the context of Qubes OS functionality. For example
- It is easy to open (and edit) office and PDF documents in completely separate (and disposable) qubes. This can significantly lower the risk to an important qube.
- It is very easy to isolate a qube at the network-level so that even if a malicious document is opened it would be unable to phone home. Important files such as password vaults, SSH/GPG keys, banking documents, etc can all be isolated from the Internet.
You don't need to worry as much about containment within a workspace because it's often disposable or would have limited impact. So while the defaults are not particularly hardened at a per-qube level there are system architecture elements that can mitigate and improve upon a singular workspace/desktop setup.
I can confirm similar behavior with Signal.
- Attaching an image from Gallery > screenshots will show PNG and JPG.
- Attaching an image from File > screenshots will only show JPG.
- Edited
It appears to be both. If you take a full screenshot it will be PNG and if you edit the screenshot (e.g., crop) it will be JPG.
evalda 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.
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.
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?