microg / microg/GmsCore

Support Activity recognition API

Open
#2,539 0 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Java
Stars
14.6k
Forks
3.2k
Avg merge
12d 11h
Merged PRs (30d)
4

Description

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: https://github.com/mjaakko/NeoStumbler/issues/233#issuecomment-2342683996

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(?).

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked Activity Recognition API and DetectedActivity documentation, then review the NeoStumbler use case and the missing support entry in the wiki table. Done should mean Activity Recognition support is exposed for apps and its support status is documented, with the implementation approach and battery trade-offs resolved.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, java
Domain
api, mobile
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.