[–] 1 point 10 minutes ago

It's not much, but I would say pretty much everyone who uses some kind of continuous glucose measurement has a more powerful tool provided by the manufacturer or an open source alternative. The feature is pretty basic in Google Health anyways (it just shows the data), but at least it now is usable by anyone and not just those who happen to use the same units as Google. It opens it up to new integrations.

  • source
  • parent
  • context
  • [–] 2 points 58 minutes ago (2 children)

    You can finally change the unit of blood glucose measurements.

    For those not into this matter: There are two units of measurement that can be easily converted into each other (simple multiplication). But previously Google Health was limited to the one more prevalent in the US - now you can switch.

  • source
  • parent
  • context
  • [–] 1 point 1 hour ago

    It's not on Play (Google rejected the accessibility use), so it's an APK from GitHub releases, built by GitHub Actions from the source.

    Did you explain its use as an accessibility aid being its core feature for differently abled people? If you have explained that as a core feature google could've budged. You would've needed to limit the API to select few like OpenAI, Gemini, Claude with additional guardrails and use reporting. But, it could've been accepted by google.

  • source
  • A much safer accessibility method would be a flutter webview. Local user will be confined to the webview instance and will still need to resolve ai agent challenges themselves.

    Accessibility-from-scratch utilizing a server\client with a linux shell is what something like Shizuku was made for. Elevated privileged activities like listing installed apps, running apps, running a url (elevated) are not normal in ai agent workflows. MCP server resources can be "patched" this way from a very specific call... hence offloading somebody else's token work.

  • source
  • parent
  • context
  • [–] [S] 4 points 2 hours ago

    One: someone who can't see the screen can just talk to it, with live voice, and it does the tapping and reads things back. For a lot of people, that's the difference between using a phone app themselves and needing someone to do it for them.

  • source
  • parent
  • context
  • [–] [S] -2 points 3 hours ago (1 child)

    It's just an MCP server for the phone with an app to control it, basically computer use, but for Android. Agents using computers are already normal, so I'm not sure why phones would be different. And it runs on your own plan, or on local models if you'd rather keep it off the cloud entirely.

  • source
  • parent
  • context
  • [–] [S] 1 point 3 hours ago

    Fair question, so here are real ones:

    • Accessibility: with live voice (real-time, through your ChatGPT plan) you just talk to it. It does the tapping and reads things back, which helps people who can't easily see or use a touchscreen.
    • Testing apps: it exposes the phone as an MCP server, so Claude Code or Codex can drive your app on a real device for UI testing.
    • Building apps on the phone itself: Buddy was mostly developed that way, with Claude Code running on the phone and using Buddy's own phone tools to install and test each build.

    It asks before anything is sent or bought and stops when you touch the screen. Not for everyone, and that's fine.

  • source
  • parent
  • context
  • [–] [S] 0 points 3 hours ago (1 child)

    Thanks, and thanks for the crosspost! Local models already work: in Settings you can add a custom OpenAI-compatible address (llama.cpp, Ollama or LM Studio on your network) and use it with OpenCode. It works best with models that are good at tool calling, since everything goes through phone tools.

    Other devices: it's built for phones, but someone already forked it to run on a Nintendo Switch with Android, with Joy-Con navigation: https://github.com/Lendss/buddy-switch. So other Android devices are clearly possible, I just haven't tested watches, TVs or XR myself.

    F-Droid: good timing. Buddy now builds all its native parts (proot, talloc and friends) from source in CI, with no prebuilt binaries in the repo, which was the main thing in the way. So an F-Droid build should be doable now. Until then, releases are on GitHub and the app updates itself.

  • source
  • parent
  • context
  • [–] 4 points 3 hours ago* (last edited 3 hours ago) (2 children)

    Excellent for local models running via OpenCode and helping with UAT on Android. Well done. What else is on your roadmap for this? Will you support Watch/TV/XR? F-Droid might take this.

  • source
  • [–] [S] 0 points 4 hours ago

    Fair concern, and it's not for everyone. The agent only sees the screen while it's doing a task you gave it, it asks before anything is sent, and it's open source, so you can check exactly what it does. If you'd rather not hand that to an AI, that's a completely reasonable choice.

  • source
  • parent
  • context
  • [–] 6 points 5 hours ago*

    Curious why. Seems people vote against datacenters in their vicinity, against the flood of self-promote by AI agents in the remaining somewhat human corners of the internet, against the flood of dubious vibe-coded projects which for some reason all have the same description that starts with "I built ..."

  • source
  • parent
  • context
  • view more: next β€Ί