algaeita

  • 17 Feb
  • Joined Aug 17, 2022
  • missing-root I've heard a lot of people say this (and yes, I've read akc3n's article in full many times) but I haven't seen any proof.

    Much research has been done (already linked) showing that a charge level of around 4.05V/cell provides extreme benefits to total battery life (not just cycles but total lifetime).

    I'd like to at least see some data showing that this is the maximum charge given to e.g. Pixel phones at 100% based on the actual phone or a reliable app reporting as such. In my experience the charge at 100% is 4.2v or higher.

    If someone can show that Pixels are limited to 4.05v then I'd be impressed.

    I think a feature that would shut off a phone at 25% would be worth adding as well.

  • JJGadgets
    I successfully installed SingPass from the Play Store on GrapheneOS. Everything seems to work, but I can't confirm that all functionalities do because I haven't exhaustively explored them. The profile services (like documents, including viewing vaccination certificates and corresponding QR codes) all appear to work perfectly. IIRC there was some weird message the very first time I opened the Singpass app (something about my phone running a custom OS, don't fully remember what it said cuz it was weeks ago), but it didn't stop me from using the App; it was just a one-time popup.

    • I use Niagara Launcher with the network privileges revoked. Their beta apks can be downloaded from Github and they allow icon customization, including setting custom app icons individually.

    • lberrymage

      I think the original message was thinking of the following case:

      • app1 has location permission and allows communication with Play Services via mutual consent
      • Play Services has location permission revoked (i.e. not granted) and allows communication with app1 via mutual consent

      In this case, Play Services can access your location without being granted the Location permission by proxy. It can't access it directly via the location APIs and hence can't decide to access it on its own accord, but it can still get the same data when the app provides it to it.

      This raises a few questions I've had, including:

      • How do we know which apps have allowed communication via mutual consent with which other apps?
      • How do we know what data will be shared between two apps with mutual consent? Are there any limitations on this, e.g. say an app wants to use FCM for notifications, the only thing it really needs is to be on the receiving end of a communication stream of only obtaining the notifications from Play Services... do the minimal permissions required to achieve this also allow that app to send arbitrary data to Play Services?
      • Would it theoretically be possible to revoke either side of the mutual consent via toggles that could be provided by the OS?

      Sorry if this is straying again too far from the original discussion, but I think this is especially relevant for Play Services. I know I can look in the app's manifest and ultimately get information for my first question (maybe not all of the information I'd want, I'm not sure), but it's quite complicated to figure out and requires a lot of knowledge to understand exactly what each intent (or other relevant aspect) means. For example, say I want to use Gboard. Gboard has intents that interact with Play Services (as far as I can tell from looking in the manifest), but it works just fine without Play Services installed. I'd like to use Gboard in my profiles that have Play Services, but I'm worried that it might be sharing the content of what I type to Play Services. But, in a profile without Play Services, I don't have to be worried about this.

      • My carrier is definitely triggering the problem (since it doesn't happen with my other SIM card), and I also came to the conclusion that VoWIFI could likely be the source of it. But this isn't normal VoWIFI behavior, right? I don't think enabling VoWIFI shouldn't be resulting in these constant pings to my phone I don't know how VoWIFI works but this feels broken. Maybe there's a mismatch between my carrier and the Pixel 6a hardware. I am fairly certain that GOS doesn't touch the VoWIFI implementation, but I think it's premature to completely rule out the fact that GOS might be playing a role. Like I said, this issue wasn't present on the vanilla Pixel OS.

        I had set this aside and hadn't done any debugging for a while, but (after writing the above) just plugged in my problematic SIM and disabled VoWIFI, and voila, the requests stopped happening! More interesting though is that when I re-enabled, it, my phone seems to be doing exponential backoff with these requests now rather than sending a request every 10 seconds. I'm still sitting here and watching it to be sure, but I got gaps between the requests of 10, 20, 40, 80, and then 160 seconds so far. This should be far less problematic for my battery life than the much weaker backoff (if any) that I was seeing before, where I had pings consistently for the whole night while my phone was totally unused.

        Also, I totally agree that "tinkering with system apps" is definitely not a permanent solution. I'm doing it as a debugging step to figure out what's wrong so I can solve the problem. Without Rethink or some similar app or program I wouldn't have been able to tell that there were these requests happening in the first place. From there, I wanted to see if those network requests were really the cause of my battery drain. Before taking that step, for all I knew, the battery drain could have been due to a totally different cause.

        Seems that I've got a full understanding of what's going on now, though! So I'm happy to mark this as resolved, though I would still like to confirm that this ISAKMP+UDP request pair with exponential backoff are expected behavior for VoWIFI, and I'm curious if GrapheneOS does make any changes to VoWIFI (couldn't find anything on the website pages about that -- seems to just say that it should work with the normal caveats about carriers limiting it).

      • Blocking network access through Rethink solved my battery drain problems, and there were four IP addresses that were being interchangeably used for data transfers every 10 seconds; just blocking those IPs solved the problem too. The data being sent every 10 seconds are an ISAKMP request over UDP on port 500 followed by a request over UDP on port 4500.

        Checking the IP addresses, they were associated with my mobile provider, which is quite weird, given that this issue wasn't happening on mobile data only, and still happened when I was just on Wi-Fi (in addition to happening when both Wi-Fi and mobile data were toggled on). Why would my mobile data provider be establishing a connection every 10 seconds but only when I am connected to Wi-Fi?

        Luckily I have a second SIM card and when I switched to it, the problem went away as well (even though I remember the battery drain problem happening on both SIMs, but who knows). I'll try swapping my new SIM back in and doing some other debugging related to the SIM card and see if I can't get my first SIM to behave properly. This may still be some GrapheneOS-specific issue -- maybe my mobile service provider is trying to do some kind of hardware attestation which is repeatedly failing -- but I'm starting to doubt it.

      • I believe that IMEI is not accessible to Sandboxed GPS because GPS is treated as a user app.

        To quote chillcat from the GrapheneOS matrix room (sorry chillcat if this is inappropriate, note I'm not speaking for chillcat by quoting them) when re sponding to: "Is there any identifier the sandboxes play services can see which would allow this sort of cross-profile correlation (like IMEI on a normal installation)?"

        mainly battery level, full list of apps in a profile, storage left, sim country code and ip address can theoretically be used to correlate 2 user profiles

        From this and my own understanding, I assume that means IMEI and MAC address are not available to Sandboxed GPS. Someone please correct me if I'm wrong.

      • Bumping this because I'm still facing this issue completely.

        I installed RethinkDNS + Firewall to monitor my traffic and it's showing that "Dynamic System Updates + 11 other app(s)" are hitting the network every 10 seconds on Wi-Fi, but not on mobile data. Those apps are:

        • Android System
        • com.android.localtransport
        • com.android.wallpaperbackup
        • com.google.android.iwlan
        • Dynamic System Updates
        • Fused Location
        • Input Devices
        • Key Chain
        • Phone Calls
        • Settings
        • Settings Storage
        • Setup Wizard

        as these apps are all blocked by Rethink if I block the app shown as transferring data. I haven't gone to manually check them all, but most of the ones I checked have network permissions and those permissions can't be removed through the app settings.

        I'm going to try blocking their network access through Rethink's firewall and see if that fixes my battery drain problems. If so, I assume something is either messed up with my hardware or software because these apps aren't really configurable and shouldn't be causing this kind of problem. I guess I'll try a factory reset in that case. Some crude guess as to what might be happening: maybe some update checking process got confused and is checking every 10 seconds instead of at the normal interval?

      • Whenever my phone is connected to my home Wi-Fi, my battery is dropping by about 5-10% every hour. After a night of staying on Wi-Fi, my phone will drop from 100% to nearly 60%, sometimes worse. When using the stock Pixel OS briefly before installing Graphene OS I was not experiencing this problem at all, with standby drain on Wi-Fi at less than 1% per hour, and maybe 2-5% overnight. This is similar to what i've gotten on my 4g mobile data connection on both stock Pixel OS and Graphene OS.

        Some observations:

        • When looking at my "Battery usage" stats, the Wi-Fi module is showing as the top battery draining process, and there are clear changes in the slope of the battery percentage curve when I go on and off Wi-Fi.
        • Going on "Data saver" doesn't make a difference.
        • Changing the Wi-Fi configuration from Unmetered to Metered or Restricted doesn't make a difference.
        • I have barely any other apps installed in my main profile. The only apps that could be using the internet are Vanadium and Element, both of which are set up to behave exactly the same on Wi-Fi and mobile data.
        • I've reset my modem and router, and my router is configured with the same SSID and password on both the 2.4Ghz and 5Ghz bands. Changing this and forcing my phone to use either one or the other also doesn't make a difference.
        • Changing the DTIM Interval setting on my router from 1 (the default) to 3 didn't make a difference. The rest of my router settings are at the default. My router is an Asus RT-ACRH17.

        Happy to provide any diagnostics that might be useful and really hoping to find a solution to this, since using my phone at home for high data consumption tasks is really a drag right now!