If these are actually the problems, then why not throw 200 dollars of GPT 5.6 at these instead of shutting it down? Were these systematic problems (Apple/Google hegemony, for example) that couldn't be beat with code?
The locking down of the Android platform, IME, is a massive, decade-long process[2] with "full speed ahead" corporate backing. Even just a few years ago, you could maybe code around some of the restrictions (if supported by users going into settings and tapping some checkboxes); today it's impossible even with root. To get working "push notifications" outside of the official channel, you need to hack the support into the OS - or accept that you probably will get the notification, but it can be anytime from a few minutes to a quarter hour before your app receives it.
[1] In which case, making them use tens of thousands of AI-generated code "for security" is a clear moral hazard you probably don't want to walk into.
[2] I don't want to judge whether it's a move in the right direction or not - that's a separate matter. But it is happening.
In this specific case, though - especially given that the project had no iPhone version due to technological constraints - Android as a platform moving in that direction is probably the biggest reason why it became too hard to develop the project further. And the direction of Android development is set by BigTech, so you probably could justify calling them "the big obstacle".
It's important to note that the movement towards security-by-default is larger than just some subset of BigTech. It's how the whole industry tries to cope with computing becoming ubiquitous and trusted at the same time. It's Eternal September, but now the new users have banking apps on their phones. It's a hard problem, and every attempt to date has always resulted in users and developers losing some freedom. This OP just highlights the consequences of this movement for a particular project.
To begin with, that 200 dollars need to come from somewhere. Are you going to personally contribute to that 200 dollars? If not, someone needs to find money from somewhere. Then, I can assure you it's going to be much more than 200 dollars before you realize it.
But yeah that's why I was asking if this was a non-code issue? Because they're presenting it as hey, we couldn't figure out the battery life in this post.
I would never say it's "reasonable" to expect anyone (including maintainers) to contribute money or code to an open source project.
Must be easy for you to type these things from your comfortable armchair.
And I would like if someone could please confirm is this related to literal code problems or systemic problems with Apple and Google?
If you don't know what open source software is or how projects are typically run (including where the funding, if any, comes from), educate yourself before posting meaningless texts in a forum.
It would be good, IMO, if people could come together and build out an open mobile platform not subject to SV hegemony, so I think what you're saying is the way to go, actually. Because building out AOSP and or just something forked/from scratch is... actually... accessible now in my opinion. I think it doesn't make sense _not_ to be oriented in this direction anymore. There's no reason to remain cautious because, well, right now we have _nothing_ :(. We are subject to the fancies of the behemoths that exist to self perpetuate. Working around them and depending on them is demoralizing and not fun.
It would, but I would argue that it wouldn't solve Briar's problem here.
The problem on Android is not that Google doesn't want P2P to work. It's that Android optimises aggressively for the battery. You can install a mobile Linux and run a P2P service on it, that's not a problem at all. But you will have to charge it multiple times a day, and nobody wants that from a phone.
Have you ever tried running an Android-based system without the Play Services (and without migroG)? Try running e.g. Signal without FCM, and see the impact on your battery life. You want to fork the OS to solve that? You will probably end up rebuilding something as centralised as FCM.
There is a fundamental question there: does it work, without major downsides, to have a P2P system where the nodes are mobile phones? Until now it has always been a tradeoff, and people clearly choose battery life. Also you don't need P2P for privacy.
> There's no reason to remain cautious because, well, right now we have _nothing_
Android is open source. There are big alternatives like LineageOS and GrapheneOS. I don't think we have nothing. There is a lot of great technical stuff in Android/iOS. While iOS is out of bounds because proprietary, Android is open source, so we have all that great stuff. We don't have nothing.
From what I understand (based on pretty basic research into using old smartphones (which I already have a full drawer of) as home appliances), the main problem is that device manufacturers only provide binary blobs for drivers and firmware, and they are not too happy to share them with non-Google parties. And it's non-trivial to handle those blobs, even if you get them (they weren't written for your tech stack, so you need infrastructure around them to make them useful).
> Because building out AOSP and or just something forked/from scratch is... actually... accessible now in my opinion.
Starting such a project, and even getting to 0.0.1 release, is now simpler than any time in the past.
Getting from 0.0.1 to 1.0-alpha did not get any easier at all. The current AI requires both a great harness and a skilled operator to add meaningful code to a large project without going nuclear on code quality.
It'll be quite a few years until things like "make me a custom ROM with AOSP modified to do X" result in anything other than absolute tragedy.
> We are subject to the fancies of the behemoths that exist to self perpetuate. Working around them and depending on them is demoralizing and not fun.
That's true, especially the "not fun" part. However, I expect the vast majority of users don't want any fun on their devices, aside from games (and even then, only with kernel-level anti-cheat). Normally, this is solved by companies offering one product for "casuals" and another for devs or power-users. This works, but breaks down for social things: a messaging app that won't run unless you buy a Pixel and flash a custom ROM is DOA as an app (it might function as a solution in case of people who are really desperate for the features the app provides, but that's probably too small a population to keep the project afloat).