• Announcements
  • Request for testing and feedback with Bluetooth on Android 14 QPR2 GrapheneOS

pinpin The Bluetooth module may be the main case it's happening. They seem to be forgetting to tag the releases because it's not an official mainline module yet.

@GrapheneOS What do your statements mean? We need to wait for google? From your experience how long would that take? Is this already addressed to google? Will you address this? Should we? Does google even give a shit about that? What is the difference in the module? Is the code on github to compare versions? And last but not least, why do we have a different version as plain android from google? Tbh I don't get it.

    PeterPan We're using the standard Android Bluetooth module from AOSP. They're not using that. They're using a mainline module variant of it but haven't started shipping it through the Play Store so there aren't tags for it yet. This likely causes the additional issues because there are additional changes in what we're using via AOSP while they don't have all the QPR2 changes and may have other changes. We're looking into it.

    I have the Google Pixel 6 and Galaxy Watch 6 Classic. Can't reconnect the watch after it has been disconnected. Release: 2024031400

    GrapheneOS Just FYI, somewhat unrelated to this discussion, the alpha I'm now on has pretty substantial battery drain. I can usually get about 3 days out of a single charge and I'm now getting a warning after only half a day. I'm not sure it's related to the bluetooth issues though since the bluetooth connection issues are exactly the same with both my pebbles regardless of the toggles.

    Thanks for adding those though, I'm really glad you are working with the community to figure this out, even if there ends up being nothing that can be done.

    Pixel 7 Pro - Alpha release - Build: 2024031400
    bluetooth device: OBDLink MX+

    No change using alpha release for me.

    Also tried the "Hardened memory allocator" off on two apps and still unable to connect.

    Have used the OBDLink MX+ on a spare phone in the meantime and confirmed it works normally (not QRP2 tho)

    Since the 2 workarounds we added don't appear to have accomplished anything, they'll be removed in the next release. We'll try to figure out something else to fix the issues for the next release. The main issue is that we don't have one of the few devices with an issue to debug it ourselves. We need to purchase one of these Bluetooth accessories for one of our developers.

    Galaxy Watch 5 and 6 seem like the main devices with an issue and the OBDLink MX+ / OBDLink LX are a secondary one. We expect the old medical device mentioned above is broken for a separate reason and may not work on Android 14 QPR2 with stock OS either, so we can't do much about that beyond waiting for them to work around it if they do that. We'd like to get the Galaxy Watch 5 / 6 and OBDLink issue resolved ASAP but again it's very hard to debug it without access to one.

      GrapheneOS I have a spare OBDLink LX adapter if you want it for testing. If so, just let me know where to send it to.

      GrapheneOS

      Like I already said. I would donate some bucks. Price for the 5 Pro (non LTE) is round about 245€.

      Who's with me? And where to with the money? PayPal fine? 20€ from me for sure. Let's see how many ppl we can find who would donate.

        Does it have to be a pro? Could be cheaper If there's another model we can use.

        Just donated 25.00. All we need is 85.00 more and the team has a watch.

        GrapheneOS I also have a spare obdlink mx if needed .
        Is your PayPal account back up and running for donations ?

        We've purchased a Galaxy Watch 6 Classic with eSIM support for a bit under 250 USD for one of the developers. It should arrive in a few days.

        We've determined that the stock Pixel OS is using a different Bluetooth module version from what's available in AOSP. This is almost certainly what leads to the issues not occurring on the stock OS. They appear to have done something like taking a snapshot of the main branch, applying security patches and testing it via the CTS, etc. without doing real world testing. The stock OS is using different code which was properly tested and fixed up before release. They either pushed the wrong Bluetooth module tag to AOSP due to a mistake or they are building it from an APEX (mainline) module despite it not being updated as a Google Play mainline module yet. It's likely the latter, and they forgot to push APEX tags for it because it's not an official mainline module yet. We've contacted them and hopefully they'll resolve this by pushing tags soon. As soon as proper tags are available, we can get to work building the code they shipped rather than the broken code in AOSP.

        This is an unfortunate situation beyond our control. Anyone building AOSP QPR2 will face the same issues. There isn't a Google Play mainline module for Bluetooth yet which would result in there being tags since mainline modules are fully open source.

        We can only hope they push tags quickly. It's unrealistic for us to figure out how to fix the issues ourselves.

        AOSP Bluetooth code in QPR2 likely DOES pass the CTS, but they didn't do enough real world testing and are unaware that it's broken with specific devices. Stock Pixel OS code appears somewhat older, not newer, and we likely got new bugs from the main branch they forked for QPR2 AOSP which they avoided for stock Pixel OS by building something older. The issues we got from AOSP QPR2 may be fixed in main already but it may have new issues and we also can't simply use that code since it won't build due to dependencies on changes elsewhere.

        We're doing our best and this is in fact not caused by any GrapheneOS changes or features.