Does the camera foreground service type also let my app use the microphone?
No. They are separate types, and you need both.
If your app targets Android 11 or higher and touches the microphone from a foreground service, the platform documentation is explicit: "If your app targets Android 11 or higher and accesses the camera or microphone in a foreground service, you must include the camera and microphone foreground service types."
Two types. Declared together with the | operator:
android:foregroundServiceType="camera|microphone"
Miss the second one and you don't get a helpful build error. You get a camera that works and audio that doesn't — which, on a device recording unattended with the screen off, is a thing nobody discovers until they go looking for footage that matters.
I build Background Camera RemoteStream, an Android app whose entire premise is keeping a camera alive while the screen is off. The camera half of that problem I've written about before, in FOREGROUND_SERVICE_TYPE_CAMERA: Keeping a Camera Alive With the Screen Off on Android 14+. This piece is about the half that gets skipped: the microphone is a different subsystem, gated a different way, and as of Android 17 it fails differently too.
Three gates, not one
Developers tend to picture a single permission wall. There are three independent ones, and audio has to clear all of them.
Gate 1 — the runtime permission. RECORD_AUDIO is its own dangerous permission. Holding CAMERA grants you nothing here. The user sees a separate prompt, and can deny audio while allowing video. That asymmetry is a feature, and a well-behaved camera app should treat "video granted, audio denied" as a normal, supported state rather than an error.
Gate 2 — the foreground service type. Covered above. Note what changed historically: before Android 11, foreground services picked up camera and microphone capability automatically. From Android 11 they only receive those capabilities when the corresponding type is declared. Code written against Android 9 that "worked fine" is exactly the code that breaks here.
Gate 3 — the lifecycle. This is the one that surprises people. From the same Android 11 document: "If your app starts a foreground service while running in the background, the foreground service cannot access the microphone or camera."
Read that carefully. It is not about whether you have permission. You can hold RECORD_AUDIO, declare microphone, and still get nothing, because of where the service was started from. The platform calls the capability you're missing while-in-use (WIU), and describes its purpose plainly: "WIU acts as a security gate–it prevents FGS started from the background from engaging in certain sensitive behaviors when the user might not be aware of the app's activity."
The practical consequence for anything camera-shaped: you cannot bootstrap a recording service from a BOOT_COMPLETED receiver and expect the microphone. The platform documentation for Android 17 gives that exact example — "if your app starts a foreground service in response to BOOT_COMPLETE and attempts to interact with audio, it will be suppressed." I've written separately about why the same constraint bites the camera on reboot; the short version is that "starts itself after a power cut" and "has while-in-use capability" are close to mutually exclusive by design.
What Android 17 actually changed — and what it didn't
Here is where I want to be careful, because this is the part most summaries get wrong.
Android 17 introduces background audio hardening. In the documentation's words: "Starting in Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user."
Note the three things named: playback, focus, volume. Not recording. The new hardening targets apps that make noise, or that mute and duck other apps' noise, from the background — the music app that resumes hours later after being unfrozen, the app that grabs audio focus and never gives it back.
Microphone capture was already gated, by the WIU rules above. What Android 17 does is extend the same gate to the audio-output APIs: "It prevents the app from accessing sensitive data like location, camera, or microphone, and beginning in Android 17, it also blocks audio APIs that typically require a visible UI context."
So the accurate statement is: recording was always gated; Android 17 closed the playback side of the same door. If you see a post claiming Android 17 newly restricts microphone recording, that is a conflation of two different restrictions.
One detail worth flagging for anyone with a long-running service: the baseline rule applies regardless of target SDK. "All apps running on Android 17 that have these background audio interactions must have a visible activity or must be running a foreground service that is not of type SHORT_SERVICE. This applies whether or not the app targets API level 37." You do not get to opt out by not bumping targetSdk.
The expensive part is that it fails quietly
This is the design decision with the largest blast radius, and it deserves to be quoted exactly:
"If the app tries to call audio APIs while the app is not in a valid lifecycle, the audio playback and volume change APIs fail silently without throwing an exception or providing a failure message. The audio focus API fails with the result code
AUDIOFOCUS_REQUEST_FAILED."
The documented failure modes, per the platform's own table:
| Audio function | What happens |
|---|---|
| Audio playback | Playback is silenced. No exception, no failure message from any API. |
| Audio focus request | Returns AUDIOFOCUS_REQUEST_FAILED. No focus acquired. |
| Volume and ringer mode | Method call is silently ignored. No exception, no failure message. |
Exactly one of those three is detectable by checking a return value. The other two are indistinguishable from success unless you go looking.
For a security camera this is the worst possible ergonomics. A crash gets noticed on day one. Silence gets noticed the day you need the recording — which is, definitionally, the day the device was supposed to be earning its keep. It is the same class of problem as a camera that quietly stops when the screen turns off, which I dug into in Why Does My Android Camera Stop Recording When the Screen Turns Off? — the bug isn't loud, it's absent.
How to actually see it
Google shipped a diagnostic, which is the genuinely useful part of the document. On Android 17 or higher (from Beta 3):
adb shell cmd audio set-enable-hardening <enable|disable|throw>
enable turns the restrictions on for all apps regardless of target SDK. throw is the one to reach for during development: it converts the silent failures into loud ones, throwing IllegalStateException for volume and focus interactions.
To confirm after the fact, use adb dumpsys audio or logcat and look for entries prefixed AudioHardening with your package name. The level tells you which gate you're on:
-
level: full— you are running a foreground service, but it does not have while-in-use capability. -
level: partial— you are not running a foreground service at all.
That distinction maps cleanly onto the three gates. partial means you skipped gate 2. full means you cleared gate 2 and failed gate 3 — the service exists, but it was started from the wrong place.
What this means if you are building a camera
A few conclusions I'd defend:
Treat audio as opt-in, not as a free extra. It clears fewer gates than video, it fails more quietly, and a meaningful number of users want video without it. Designing for "audio off unless explicitly enabled" is less work than designing for a permission that may vanish.
Start the service from a visible activity. That single decision is what grants while-in-use capability, and it is what separates a service that can use the microphone from one that merely appears to.
Surface the state. If RECORD_AUDIO was denied, or the service came up without WIU, the app knows. The user should too — before the recording they cared about, not after.
There is also a non-technical reason to make audio deliberate. In many jurisdictions, recording audio of a conversation is governed by a different and stricter body of law than recording video of a space, and the rules vary considerably by country and by state. I'm a developer, not a lawyer, and this isn't legal advice — but "the microphone is a separate decision" happens to be true both in the Android permission model and in the legal one, which is a convenient alignment for anyone shipping a camera.
What the documentation does not tell you
Three honest gaps:
It does not say what OEMs do on top. Every rule above is AOSP-level. Device manufacturers layer their own background-execution restrictions, and those are not in this documentation and not consistent between vendors.
The
throwtesting mode is a development aid, not a production signal. It changes behavior for all apps on the device. It tells you whether your code path is affected; it does not tell you what a user's device is doing.It does not cover recording-side failure reporting at all. The failure table is about playback, focus, and volume. What your app observes when microphone capture is denied by the WIU gate is a separate question, and the background-audio-hardening document is not where it is answered.
And one thing I'm deliberately not claiming: I have not inspected any other camera app's implementation. Everything above is from Android's published documentation and from building against it.
If you want the user-facing version of this problem — what Android actually promises to show you when a device is recording — I wrote that up in Denied, Dismissed, Delayed.
Background Camera RemoteStream is on Google Play, and there's more about the architecture at superfunicular.com. It records with the screen off, stores locally by default, and serves a LAN web console for remote viewing — built in Kotlin on Camera2 and a Ktor embedded server.
Sources
Top comments (0)