Every foreground service we ship, on video
Google Play asks for a screen recording whenever an app declares a foreground service type. Here are ours — seven apps, one page each, recorded on a real Pixel — plus what each service actually does and why it exists.
Since Android 14, an app that runs a foreground service has to say what kind of work it is: location, mediaPlayback, mediaProjection, dataSync, specialUse, and so on. Google Play then asks the developer to justify each declared type — and for most of them, to attach a screen recording that shows the feature in use.
That is a reasonable thing to ask for. A manifest line is cheap; a video of the feature actually running is not. So rather than mailing a one-off clip to review and forgetting about it, we recorded every foreground service we ship and put each one on its own page. The same link goes to Play review and to anyone curious about what the app does while it is not on screen.
Every recording below was made on a real device — a Pixel 10 Pro XL running Android 17 — not an emulator. Each one follows the same shape: open the app, start the feature, leave the app, pull down the notification shade, and show the service’s own notification sitting there with its controls. That is the part reviewers need to see: the service announces itself, and the user can stop it from the shade without going back into the app.
The demos
| App | Type | Service | Demo |
|---|---|---|---|
| GPS Speedometer | location | TripRecordingService, FloatingSpeedService | watch |
| Volume Booster | mediaPlayback | AudioEffectService | watch |
| Interval Timer | mediaPlayback | TimerService | watch |
| Tuner & Metronome | mediaPlayback | MetronomeService | watch |
| Screen Mirror | mediaProjection, microphone | MirrorService | watch |
| Battery Health | specialUse | ChargeMonitorService | watch |
| Device Info | specialUse | MonitorService | watch |
Why each one exists
GPS Speedometer — location. Recording a trip is the whole point of the app, and a trip that stops recording the moment you put the phone in your pocket is worthless. TripRecordingService keeps the GPS fix alive while the screen is off, with a notification that shows the live speed and distance and carries a single Stop button. The floating speedometer bubble uses the same type for the same reason. Nothing is uploaded: the coordinates stay in the app’s own database on the device.
Volume Booster — mediaPlayback. The boost and the equalizer are attached to the system audio session; they have to outlive the app’s UI or the effect dies the second you switch to your music player, which is exactly when you want it. The notification shows the active preset and offers Turn off / Turn on and Stop, so the effect can never be running invisibly.
Interval Timer — mediaPlayback. A HIIT timer that pauses when you lock the screen is not a timer. The service keeps the round countdown and the interval cues running with the screen off, and the notification is the remote control: current round, time left, pause and stop.
Tuner & Metronome — mediaPlayback. The metronome is real audio playback with hard timing requirements. Running it in a foreground service is what keeps the click steady while you look at a chord chart in another app.
Screen Mirror — mediaProjection + microphone. Screen capture on Android is only legal for an app inside a foreground service, and the projection consent dialog is the user’s own decision each session. The microphone type is there because commentary audio is optional and off by default.
Battery Health and Device Info — specialUse. These two are the honest odd ones out. Both watch a system signal over time — charge current, temperature, and voltage during a charge session for Battery Health; CPU, memory and thermal state for Device Info — and neither fits any of the named types, because Android has no category for “sample a sensor while the user is away”. specialUse is what remains, and each declares its subtype in the manifest (battery_monitoring and device_stats_monitoring) alongside the written justification Play requires. Both services are started by an explicit user action, both post a visible notification for the whole time they run, and both stop themselves when the work is done.
What you will not see in the videos
No account, no login, no network call. None of these apps have a server; the services above read a sensor or push audio, write to local storage, and stop. The notification shade in the recordings is redacted — the phone belongs to a person, and their messages and email are none of Google’s business or yours — so anything that is not our own notification is covered with a solid block. The app’s own notification is never masked, since that is the entire point of the recording.
For other developers
If you are staring at the same review form: record on a real device, show the notification shade, and make the stop control visible. A reviewer is checking three things — that the service does what the declared type says, that the user starts it deliberately, and that the user can end it without hunting through the app. Thirty seconds of video answers all three. Hosting the clip at a stable URL instead of attaching a file also means the next review, on the next release, is a copy-paste.