[0] https://grapheneos.social/@GrapheneOS/113917226566692707
Such a bizarre phenomenon to me that people are still griping about a software update that stops a 4-year-old battery from detonating when the same company will also fix the phone for free or just hand you $50 if you prefer that.
Not really just handing it to you https://arstechnica.com/gadgets/2025/03/how-google-nerfed-my...
The $50 "cash" offer came with so many downsides that just ignoring it would be the smarter choice for anyone who values their time (someone already provided a link).
I doubt that they'll give me any sort of money or do repairs on a phone that I opened up.
It's frustrating as I thought I would be able to get several more years of life out of this phone.
Does this mean my pixel 4a battery was unaffected for some reason... or simply that the lawyers managed to weasel out of paying 100% of active pixel 4a owners back and my phone is still dangerous or degraded? ¯\_(ツ)_/¯
https://23.social/@mj1982/114210416377875387
54% Battery consumption is lower under GrapheneOS
13% Battery consumption is lower under stock Android
33% Can't tell the difference.
For users with a single profile with sandboxed Google Play installed before other apps, it should be very similar to the stock Pixel OS if you installed the dozens of Google apps they bundle on GrapheneOS and disable the various privileged apps they integrate which aren't usable on GrapheneOS. The stock OS drains more power with a typical simple setup because it has so much more installed and running. If you make it similar, it's nearly the same. If you use a more complex setup with multiple profiles and multiple push implementations on GrapheneOS, that's going to use more power. It still shouldn't drain nearly as much as you said above without something seriously wrong with the setup.
It's very easy to make battery life much worse. Using multiple push messaging implementations simultaneously is inefficient. As an example, using sandboxed Google Play in your Owner user, sandboxed Google Play in a work profile and a Private Space without it with various apps doing their own push would of course be far less efficient than a single Firebase Cloud Messaging push connection shared across the entire device. Having 2 installations of sandboxed Google Play you always keep running would be less efficient than privileged Google Play. Regular privileged Google Play shares the same processes and connections across profiles since it's built deeply into the OS and is implemented that way for efficiency like many OS services. If you compare having a single privileged Google Play vs. multiple sandboxed Google Play alongside apps doing their own push, of course privileged Google Play would be more efficient. You can use GrapheneOS with a similarly efficient setup and battery life will not be worse. You likely just have an inefficient setup. It can still be hard to narrow down what's really draining battery usage despite Android's battery stats getting much better over time.
I would recommend people to install the play services and play store in the main profile. Then, install apps in the main profile too but remove all permissions and abilities, restrict and disable them. After that, enable them in a "banking" profile. One can then selectively enable and disable the play store to update these apps which propagate to the other profiles. The disabled apps are still updated normally by the play store.
I do believe that they are working on a feature to limit app intercommunication in a similar vein as the other scopes. This would be cool because it would allow one to allow "point to point" communication of certain apps with the play services but otherwise restrict them. Though I don't know the state of development for this feature.
On my 6 pro, I got 2x advertised battery life until I installed one copy of Google Play services. Then I got advertised battery life.
It should be easy enough to uninstall Google’s stuff for a week and measure battery drain, then put it back.
Even with it though, I wasn’t losing 30% overnight. There’s probably some other problem. Maybe wipe + reinstall, then try with and without the 24/7 surveillance daemons?