Super Funicular

Posted on Aug 22

One Microphone, Everything Else: Why Android Gives a Background Recorder Silence Instead of an Error

#android #kotlin #mobile #webdev

Short answer: When more than one app on a phone wants the microphone, Android does not stop the loser. It feeds it silence. In Google's words: "if a new app acquires the audio input, the previously capturing app continues to run, but receives silence." For a phone left recording where nobody is watching it, that produces the one failure that looks exactly like success — the service is alive, the file is the right length, the picture is fine, and the sound is flat. The platform publishes both the priority rules that decide it and an API that reports it. Background Camera RemoteStream is what I build; everything below is Android behaviour, quoted from Android's own documentation.

Every other way a phone-as-camera can let you down ends with nothing to play. The battery ran out, the process went away, the storage filled. You go looking, there is a gap, and you know at once what you are dealing with.

Losing the microphone ends with something to play: a file of the right duration, with the right picture, and a soundtrack that is nothing at all — for a documented reason, at a moment you will never be able to identify afterwards, because nothing was written down.

Here is the mechanism, quoted from Android's guide to sharing audio input, and a test that takes about three minutes.

The rule changed in Android 10, and the new rule is worse for unattended devices

Before Android 10, microphone access was first come, first served, and the loser was told:

"Before Android 10 the input audio stream could only be captured by one app at a time. If some app was already recording or listening to audio, your app could create an AudioRecord object, but an error would be returned when you called AudioRecord.startRecording() and the recording would not start."

An error is a fine thing to receive. An error can be logged, retried, surfaced, counted. Android 10 replaced it:

"Android 10 imposes a priority scheme that can switch the input audio stream between apps while they are running. In most cases, if a new app acquires the audio input, the previously capturing app continues to run, but receives silence. In some cases the system can continue to deliver audio to both apps."

Note "while they are running". This is not a decision made once at start-up, which you could check for and react to. It is a decision the system re-makes every time anything else on the device starts capturing, for as long as your recording lasts.

And note the choice the framework made about how to enforce it, spelled out in the section on configuration changes:

"When several apps are capturing audio simultaneously, only one or two them are 'active' (receiving audio); the others are muted (receiving silence)."

Muted, not stopped. The recording carries on. For a phone in a hand that is obviously the right call — you do not want a voice memo to crash because a system component opened the microphone for a moment. On a device doing a job for eight hours with nobody in the room, the same decision means the only person who could notice is not there.

Who wins

The page lists the priority rules in full. They are worth reading as an operator rather than as a developer, because they tell you which apps on the device are actually dangerous to leave installed:

"Privileged apps have higher priority than ordinary apps.

Apps with visible foreground UIs have higher priority than background apps.

Apps capturing audio from a privacy-sensitive source have higher priority than apps that are not.

Two ordinary apps can never capture audio at the same time.

In some situations, a privileged app can share audio input with another app.

If two background apps of same priority are capturing audio, the last one started has higher priority."

"Privileged" has a specific meaning here, and it is not about the microphone permission:

"'Ordinary' apps are installed by the user. 'Privileged' apps come pre-installed on the device. These include the Google Assistant, and all accessibility services."

So the contest is not between apps you chose. It is between an app you chose and the software that shipped on the handset.

There is one piece of good news buried in the third rule, and it is worth knowing about because it is the reason this does not happen constantly. Android treats certain capture uses as privacy-sensitive by default:

"an app is treated differently if it uses a 'privacy-sensitive' audio source: CAMCORDER or VOICE_COMMUNICATION."

An app capturing from a privacy-sensitive source outranks apps that are not, and the Assistant rule is explicit about the consequence:

"The Assistant can receive audio (no matter whether it's in the foreground or background) unless another app using a privacy-sensitive audio source is already capturing."

Whether a given recorder is in that category is an app-level choice rather than something you can read off the screen, and since Android 11 it is settable outright:

"When setPrivacySensitive() is true, the capture use case is private and even a privileged Assistant cannot capture concurrently. This setting overrides the default behavior that depends on the audio source."

A recorder that is already going, on a privacy-sensitive source, is in a strong position. It is not in an unassailable one — because of the rule about ties:

"If both apps are privacy-sensitive, the app which started capturing most recently receives audio and the other gets silence."

Most recently. The device that has been recording since Tuesday is, by construction, never the most recent starter.

The one contender that always wins

The page devotes a scenario to it:

"A voice call is active if the audio mode returned by AudioManager.getMode() is MODE_IN_CALL or MODE_IN_COMMUNICATION."

and then, in a single line:

"The call always receives audio."

An ordinary app does not share with a call. Note what the rule actually keys on: an audio mode, not a particular app. I am not going to enumerate everything on a phone that can put it into one.

The useful lesson is the general one rather than a checklist of things to uninstall: on a general-purpose handset, the set of software that can legitimately take an input away from you is not a set you can enumerate in advance. What you can do is know the failure exists, and be able to see it.

An app can be silenced with nothing to compete against

There is a second, older rule that catches people out, and it has nothing to do with contention:

"One more change was added in Android 9: only apps running in the foreground (or a foreground service) could capture the audio input. When an app without a foreground service or foreground UI component started to capture, the app continued running but received silence, even if it was the only app capturing audio at the time."

Even if it was the only app capturing audio at the time. The same response — keep going, receive silence — is the platform's answer to a background app that has no business holding a microphone at all.

For screen-off recording this is one more reason the foreground service is not a formality. It is the thing that makes an app eligible to hear anything. If you have ever wondered why a camera app that works fine with the screen on produces a soundless file when you lock the phone, this rule is a better first suspect than anything to do with the camera.

How an app can know — and the wrinkle in it

Android does not leave developers without a way to detect this. It is just opt-in, which means whether any given app reports it to you is a property of that app and not of the platform.

"Since an active app might be silenced when a higher-priority app becomes active, you can register an AudioManager.AudioRecordingCallback on the AudioRecord or MediaRecorder object to be notified when the configuration changes."

The callback delivers an AudioRecordingConfiguration, and one of its methods answers the question directly:

"isClientSilenced() — Returns true if the audio returned to the client is currently being silenced due to the capture policy."

There is a device-wide view too: "You can get a general view of all active recordings on the device by calling AudioManager.getActiveRecordingConfigurations()."

Now the wrinkle, which the documentation states plainly and does not resolve:

"You must call AudioRecord.registerAudioRecordingCallback() before the capture is started. The callback is executed only when the app is receiving audio and a change occurs."

Read those two sentences together. Registration has to happen before capture begins — fine, that is an ordering requirement. But the callback fires only when the app is receiving audio. A transition from receiving audio to being silenced is a change that occurs while the app is still receiving audio, so that is covered. What the sentence does not say is what happens on the way back: whether an app that has been sitting silenced gets told when the higher-priority app goes away.

I am not going to guess, and the honest reading is the useful one. Do not treat "the app did not warn me" as evidence that the audio was fine. Treat the file as the evidence.

The three-minute test, for any recording app

You do not need source access to find out how a given app behaves — only a second app that captures audio, and one playback.

Put the phone where it actually lives and start it recording the way you actually use it — screen off, if that is the arrangement.
Give it two minutes of ordinary room sound, so you have a known-good stretch at the head of the file.
On the same phone, start something else that captures audio. A plain voice recorder is the cleanest choice; anything that clearly holds the microphone for a while will do. Leave it going for a minute, then stop it.
Let the original recording run another two minutes, then stop it and play the file back.

Listen for three things, in order of how much they tell you: whether the middle stretch is silent, whether the sound comes back afterwards, and whether anything anywhere — a notification, a log entry, a marker in the file — told you it happened. The third is the answer that matters: it is the difference between a device you can leave alone and a device you have to audit by ear.

Run it once per handset. The rules above are platform behaviour, but which pre-installed software is on the device is not the same on two phones from different manufacturers.

The camera side of this is a different question, and a friendlier one

The nearest neighbour to this piece is the camera version of exactly the same contest, which I wrote up separately: when two apps want the same lens, Android picks a winner on priority and a 24/7 recorder is the one that loses. Read the two together, because the difference between them is the entire reason this article exists.

Lose the camera and the platform calls you back. The evicted app receives CameraDevice.StateCallback.onDisconnected(), which means the app knows, at the moment it happens, and can log it, retry, or surface it to you.

Lose the microphone and nothing is called at all unless you registered a callback before capture began — and even then, per the sentence above, only while the app is still receiving audio. The recording carries on. The file keeps growing. Same phone, same eviction policy, opposite epistemics: one failure announces itself and the other is designed not to.

A third case sits at the friendly end of the same scale. Whether a phone can drive several camera outputs at once — recording and live streaming from one sensor — is a capability question: a published answer per device, checkable before you deploy anything, and settled once you have configured it. Microphone input is the far end — a contest, re-run continuously, decided by a policy, with the loser told nothing. Of the three, only one can be retired in advance.

What to actually do

Decide whether this deployment needs sound at all. A great many do not. If the reason the camera is there is answered entirely by the picture, then a recording with no audio track has no failure mode to worry about, and you have removed a whole category of problem rather than managing it.

If it does need sound, verify the file rather than the app. "The recording ran" and "the audio recorded" are separate claims on Android, and the platform is explicitly designed to let the first be true while the second is false.

Check the phone's own inventory once. Which pre-installed assistant is on it, which accessibility services are enabled, what else you have installed that listens. You are not building a threat model — you are learning, on one device, what the plausible contenders are, so that a silent stretch six weeks from now is something you can explain rather than a mystery.

Keep the sound question separate from the storage and power questions. Those fail loudly — an empty card, a dead battery, a power cut — and a glance at the file list finds them. This one you will only find by listening.

Silence is a plausible recording. That is the whole difficulty: it does not look like a fault, it looks like a quiet room. The platform will not tell you which one you have, and the file cannot tell you either. Only you can, and only if you know to ask.

DEV Community