Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Activity recognition API #2539

Open
rugk opened this issue Sep 12, 2024 · 0 comments
Open

Support Activity recognition API #2539

rugk opened this issue Sep 12, 2024 · 0 comments

Comments

@rugk
Copy link

rugk commented Sep 12, 2024

Is your feature request related to a problem? Please describe.
The app NeoStumbler has a full version and an fdroid version, but with microg even the full version is somewhat limited, see what Google APIs it uses here: mjaakko/NeoStumbler#233 (comment)

Fused location is apparently supported just as the usual location provider, but anything else is hard?

This is the use case for NeoStumbler, where you can start some work:

Automatic scanning means that the scanning service can be started automatically when you're moving (this uses Activity Recognition API to do it in a battery-friendly way)

Describe the solution you'd like
Google Play Services do have a Activity Recognition API apps can e.g. use to detect when someone starts walking etc.

It basically returns the state/what a user/phone/tablet device or so might be currently doing:

type const description
int IN_VEHICLE The device is in a vehicle, such as a car.
int ON_BICYCLE The device is on a bicycle.
int ON_FOOT The device is on a user who is walking or running.
int RUNNING The device is on a user who is running.
int STILL The device is still (not moving).
int TILTING The device angle relative to gravity changed significantly.
int UNKNOWN Unable to detect the current activity.
int WALKING The device is on a user who is walking.

How that is calculated/detected… heck I know?

Describe alternatives you've considered
Apps like NeoStumbler could implement something like this by themselves, but of course that may be a little hard technically (I don't know how Google detects this?) and also battery-consuming.
So implementing and exposing it in a central place seems like a good idea.

Additional context

  • Its (support status) also missing in the wiki table, BTW.
  • Like exposure notifications, the functionality itself could be implemented as a library, so apps could also include it as/in their OSS/F-Droid versions without any proprietary Google lib, and users could choose to use this or the Google version. The lib version would of course loose the battery advantage, but if you e.g. only have one app using it, this might be okay(?).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant