Replies (45)
preach!! most apps push notifications not working 😕 weird asF
It's not BS. I tried running Signal AppStore and Signal APK without GMS/Firebase and battery consumption jumped from roughly 2% to 10%. Funny thing though, having no Google stuff running in the background added roughly 20% battery life. :D pick your poison.
It’s for the battery > It’s for the kids
This is pretty obvious from the simple fact that we're not talking about a default setting, we're talking about a limit on what settings users are allowed to have.
Vitor, thank you for Amethyst. Its still my fav nostr app, and it keeps getting better. And i can log in with Amber.
Looks like a Signal issue. Pokey does a similar thing and uses less than 1% in my phone
I think the same 😤
On Android you can use a bound foreground service and keep it running into perpetuity.
Must bind/start with applicationContext
No need for requesting user opt out of battery optimizations
This is what kmp-tor does
Sad story.
The bright side: All the more reasons to touch grass and ignore push notifications.
Does it still kill apps if plugged in?
Signal uses the socket-io library to maintain an open socket with their backend; it's incredibly resource intensive.
Tutanota uses the SSE API for their push noticication service and does a pretty good job on their end as it relates to battery consumption.
That said, if every app were to implement their own push notification service, 5+ apps doing on a device that turns a "mobile" phone into something that always needs to be plugged in. It does not scale.
I ran a test on Android using kmp-tor and a ktor server exposed as a hidden service, pinging it every 5 min via cronjob from my server at home. Over 24h, battery consumption was about 5%-7% depending on the test device.
Working on a product right now for drop in replacement to google/apple services, but it's far from ready.
Any chance you can help Pokey instead of building another product? I would love to keep it alive and just get Amethyst users to install Pokey instead of running a Pokey service inside of Amethyst.
Wait. Is google trying to stop the usage of background services by non-google apps?
Always been
Idk about background, but we ran a lightweight Bitcoin node as foreground service on android, and it works fine. AFAIK, that's impossible on IOS.
Hope they don't restrict thay.
Yup, which is why my notification tray is littered with apps that just display a notification to get around it.
Which one works best?
My GrapheneOS now shows, that around 70% of all battery is used by the LTE-signal. I have a phone without SIM at work. Since the work phone is enduring roughly 5 times longer, this estimation of the phone seems plausible to me.
Some android friends have said that Telegram does a fine job of push without draining the battery when not using Google Push.
Aren’t there some API to align background fetch events from multiple apps so they run at the same time? I think macOS does that even on sleeping intel machines, timer coalescing ensures less “power naps” wake up the machine less frequently”.
mobile platforms are completely cucked
I'd say apphider which is a cloning app. They all work equally but that one prompts the user to give it notification management access to then hide the dummy. So its there but I got prompted not to see it. The other ones are viper4android, adguard, amber, ntfy, the vpn and kde connect.
I'd love too, but am booked for the next couple of months under a sponsorship from
@OpenSats
to work on kmp-tor. After that, I resume work on that project.
Nice! I think Pokey might need a service-like lib, just like the Tor one, that any app can import and start the service by itself. But if many apps do this, only one service runs.
@KoalaSat
In that way, we can all run Pokey internally and as long as one Nostr app is active, everybody benefits.
None that would supplement google/apple services like OP desires.
The coordination needed to do that is tremendous, especially when you get into versioning. A dedicated companion app is better. "Hey user, if you want to use this feature XYZ in my app, install this other app so mine can register with it".
Makes the UX dead simple for both users and developers by moving the overhead to a single application & thin IPC client library for other apps to import and configure (just like registering with Play Services Framework).
Seems like a good opportunity for de-googled Android forks to work on.
As appealing as a gapps drop in replacement sounds, it would lean towards a not-google but still centralized alternative.
It can be done in a decentralized manner; that is exactly what I'm building now... Device to device. No centralized server. Can ping any app on my phone (as long as it's registered with my app) from my laptop using terminal, curl and tor.
Server is embedded in the application that other apps on the device can register with. Http calls hit the server and get routed to the registered app.
It's a one click install for users. All overhead is pushed to developers to setup the client library for IPC, and then me to maintain the app & client library. UX is dead simple consumer wise, unlike other products that may require users to run a server at home or something.
It shouldn't be that hard to do since I already implement it as a Service. Bad news is that I have no idea how to define it as a lib, I need to dig into it.
...but any help is always welcome!
A third option is coming. #HarmonyOS by Huawei. For Desktop & mobile devices. Built *specifically to be impervious to NSA and Western snooping*.
It seems like you’re headed in a good direction but then it’s no longer a drop in replacement, right?
I was referring to projects that aim to provide a Google Play Services reimplementation that can be just dropped in place, which doesn’t require any changes to make existing apps work. And that’s the approach that I think would lead to centralization.
Still, I think it’s important for OS developers to ensure that, to be able to let the device sleep as long as possible, they should provide app developers with APIs that would allow the OS to effectively “sync” background tasks so they’re executed simultaneously, resulting in a shorter timeframe where the device is woken up.
Then it shouldn’t matter all that much if you have multiple apps delegating this work to one or few other push provider apps, like it was proposed by another guy in this thread, or if you have many apps fetching individually.
What I found out is that our devices are damn fine at sleeping but once you do need to wake up, you better ensure you’re making use of every milliwatt “while you’re at it”, and synchronized timers work for both reducing the wakeup count and overall time spent at this higher energy state.
You might need to do a Content Provider for your DB. Otherwise each service will have their own DB.
Ideally if Primal and Amethyst both import Pokey, we can start a single Pokey service while sharing the same user settings. Starting from Amethyst or from Primal should yield the same service.
Will only allow China snooping
It's because your cell signal is weak
This can be. But is also nothing I can personally influence. I will not move based on a weak signal 🙂
there are some things that allow passively boosting cell signal inside buildings IIRC
Thanks for the tip. Have you used them successfully? I think, when I am at home, I can charge my phone. So probably does not really help in my case.
I did not use any of them
Primal seems to use a lot more battery since I updated it.
(note my screen has been full brightness the entire time since last full charge)
I would highly advise against such a setup, where every app imports the server. Logistically, that is a nightmare due to how aggressive Android is in killing processes.
Instead, I'd create a dedicated companion application users can install, and a client SDK with a thin API/protocol for developers to hook into and communicate locally via IPC.
The separation is a huge benefit for everybody (especially users) because the less code in that SDK, the more you can huck into the app and manage from 1 place. Security wise, this is beneficial too.
So, is the plan for your Tor lib to also only work on a specific app and people have to install that app to use it?
Never. kmp-tor's Android service is configured to export=false. Developers can lock down notification action Intents even further by declaring a signature permission in their manifest, and configuring the service with their custom string. Giving any app on the device access to a Service or BroadcastReceiver requires careful work given the security implications.
Most app's only need access to the tor network while they're running. kmp-tor provides that for them. Archiving kmp-tor and doing something like an Orbot app would be asinine.
The application I am working on uses kmp-tor, but yes, I have baked into the SDK's IPC protocol InetSocketAddress and UnixDomainSocketAddress information for immediate access to a tor socks/http proxy, either by requesting it via Intent, and always being sent along with the forwarded http calls.
