Comment by OkGoDoIt | Hacker News Reader

Comment by OkGoDoIt | Hacker News Reader

Parent Full thread

1. Apps that track sensor data to determine sleep quality or other nonstandard movement calculation (and thus can't use alternative step counting API's)

2. I'm working on an app that constantly records audio in the background and later allows me to search for things I might have said throughout the day

3. Apps that track location long-term, like the defunct Moves app. Sure it kills the battery and is a major privacy concern so it should be opt-in, but I personally love this functionality and I'm sad there doesn't seem to be a modern equivalent (Google Maps location history is less accurate and there's no good API). Apps that record location short-term like MapMyRun do not solve the same problem.

... I'm sure there's other use cases. I kind of feel like the only developers allowed to really innovate on mobile anymore are Google (and Apple) themselves. Bad developers abusing privacy/battery/data have made it so Google/Apple have to lock down anything interesting. It's frustrating, because the current state of affairs is definitely better than the free-for-all it used to be, but I wish I had more control to override what my own device is able to do.

For #2, how do you avoid recording all the things people around you are saying throughout the day? Custom microphone to minimise picking up surrounding sounds? Some kind of speaker recognition to identify and isolate your own voice (does that work when you have a cold)?

And if you're not avoiding recording other people, how do you succinctly notify everyone in capture range that you are recording them?

This seems problematic from a standpoint of social norms and etiquette. In public/shared space contexts people know they can be heard by bystanders, but that is very different from being recorded and having your utterances indexed for later retrieval.

Sounds like all these apps can use a foreground service to do that.

Am I missing something ?

The only case I see this change not covering is apps like Cerberus. They would need to ask their users to go to settings and hide their notification. Not the nicest UX, but that's a pretty rare use case.

Define foreground/background.

If I’m using Strava and Spotify I don’t want either to stop working when I switch to the user interface of the other one.

A foreground service needs to display a notification.

Not really an issue for Spotify since media apps want to display the media notification anyway.

For other apps, the idea is that foreground services should be visible to the user. One of the reasons would be this very capability to access sensors.

Another difference between foreground and background is that a background service is eligible to be killed on low memory events.

Isn't #2 likely to be illegal in many states?

We are developing an app that does #3 (Smarter Time) and manage it with a foreground service. The constant notification is slightly annoying for some users, but overall it works well and does not use too much battery (after tons of tweaks and optimizations)

#2 sounds super interesting to me. Is it open source?

Well it's also my first foray into Android development since Google Glass years ago, so not much good source to share. Maybe someday if I get it in a state where it works and isn't too embarrassing, I may open source it.

Regardless it's encouraging to hear that other people find this interesting, most of the feedback has been along the lines of "that's so creepy/illegal"

#2 sounds brilliant, so many times I've wished I could Ctrl+F for things in conversations I had earlier in the day.

Reply on news.ycombinator.com