Short answer: On the older Camera API the framework could overrule your code: a field reported whether the capture sound could be switched off, and where it could not, the call to switch it off simply failed. On camera2 — the API a current app is built on — the framework plays nothing by itself, and instead offers a boolean,
MediaActionSound.mustPlayShutterSound(), reporting whether regional rules require a sound. The documentation's verb is "recommended". So the audible-capture rule most people assume Android enforces is, on the modern path, carried out by each app's own source code. For the phone in your hand that is trivia. For a phone given a second life watching a hallway, it is the whole question. Background Camera RemoteStream is the thing I build, and nothing below asks you to take my word for anything.
The old contract: the framework could tell your code no
The original Camera API carried a field on Camera.CameraInfo, added in API level 17 and deprecated in API level 21, summarised in one line: "Whether the shutter sound can be disabled." The detail underneath it is the part worth reading twice:
"On some devices, the camera shutter sound cannot be turned off through enableShutterSound. This field can be used to determine whether a call to disable the shutter sound will succeed."
And then the consequence, spelled out:
"If this field is set to true, then a call of enableShutterSound(false) will be successful. If set to false, then that call will fail, and the shutter sound will be played when takePicture is called."
Read that as a contract between two parties. The app asks for quiet; the framework answers, and its answer binds. It is not a hint, and not a warning in the log — the call fails and the sound plays anyway. Whatever an app's author intended, on a device where that field was false the outcome was decided above the app. That is the model most people still carry in their heads: the phone will not let a camera app be quiet, because somebody decided phones should not be quiet.
The new contract: the framework asks
Both of those pieces are deprecated now. A current Android camera app is built on camera2, or on CameraX sitting above it, and the platform documentation is unusually blunt about what changed:
"This class is recommended for use with the android.hardware.camera2 API, since the camera2 API does not play any sounds on its own for any capture or video recording actions."
Not a quieter sound. Not a sound unless you opt out. Nothing, for any capture or video recording action.
What replaced the binding flag is a question the app is merely invited to ask. MediaActionSound.mustPlayShutterSound() arrived in API level 33:
"Returns true if the application must play the shutter sound in accordance to certain regional restrictions."
And immediately after it, the sentence that changes the character of the whole arrangement:
"If this method returns true, applications are strongly recommended to use MediaActionSound.play(SHUTTER_CLICK) or START_VIDEO_RECORDING whenever it captures images or video to storage or sends them over the network."
Strongly recommended. CameraX carries the same idea for apps that must run below API level 33, with a method documented as returning "whether the shutter sound must be played in accordance to regional restrictions", plus a note that it and the platform method "serve the same purpose".
So the word must survives, in the return value; the enforcement does not survive anywhere. The framework has gone from being a party to the contract to being a party offering advice, and an app that ignores the advice meets no exception, no failed call, and no sound played over its objection. It is simply an app that did not call the method.
Nobody will tell you which regions
The obvious next question is: where? Which countries?
The platform reference does not say. Its phrase is "certain regional restrictions". CameraX is slightly more explicit about being unhelpful:
"This method provides the general rule of playing shutter sounds. The exact requirements of playing shutter sounds may vary among regions."
I could close that gap with the answer everyone repeats in forum threads. I am not going to. I have not checked it against a primary legal source, and an article that launders a widely repeated claim into a confident sentence is doing the opposite of its job — and in any case the method exists precisely so that an app does not need to know. The device answers at runtime, for wherever it currently is. Any app that hard-codes a country list is wrong the moment somebody travels.
The honest statement is the narrow one. Some places require it; Android knows which and will tell your code; the public developer documentation deliberately declines to enumerate them. If you need the legal answer for a specific country, that is a question for a lawyer in that country — not for an API reference, and not for me.
The rule is shaped like an event, and a monitoring camera is not an event
This part falls out of the API's own vocabulary rather than out of anybody's opinion. Look at what the platform actually offers to play — three constants, each documented as the sound for one specific moment:
-
SHUTTER_CLICK— "The sound used by Camera.takePicture to indicate still image capture." -
START_VIDEO_RECORDING— "The sound used by MediaRecorder.start() to indicate the start of video recording." -
STOP_VIDEO_RECORDING— "The sound used by MediaRecorder.stop() to indicate the end of video recording."
CameraX repeats the shape in its guidance: "For video capture, it's recommended to play the start recording sound when receiving VideoRecordEvent.Start and the stop recording sound when receiving VideoRecordEvent.Finalize."
Every one of those is a transition. Something begins; something ends. The whole design presupposes a person holding a device, doing a discrete thing, in a room with other people in it, with the sound arriving at roughly the same moment as the act it describes. For that situation it is a good design.
Now apply it to a handset that has been repurposed to watch a room. It starts once. It runs for a week. On the documented model that is one start sound, then seven days of nothing, then one stop sound that nobody is present to hear. No rule has been evaded and no app has misbehaved. The event simply happened once, at a moment chosen by whoever set the phone up, and the interesting period — every hour after that — contains no event to attach a sound to.
I am not claiming this is a loophole somebody should close, nor that a continuously recording device is unregulated. The narrow claim is this: the platform's audible-capture vocabulary is built out of start-and-stop events, and a device whose defining property is that it does not start and stop is a poor fit for that vocabulary. Whatever protection an audible shutter offers is protection against a phone being used, not against a phone being installed.
The uncomfortable symmetry
An honour-system rule protects and exposes in the same motion, and it would be dishonest to write the flattering half and stop. When I wrote about Stealing Photos Through Android Cameras, what struck readers hardest was not the capture itself but how ordinary it was: a capture with no sound and no on-screen confirmation, because on the modern camera path there is nothing to suppress. That deserves stating plainly. Software that captures without the user's knowledge is not defeating a protection when it stays quiet. It is declining an invitation.
The same sentence describes a camera an owner installed deliberately in their own hallway and does not want beeping at three in the morning. Same mechanism, same absence of a sound, wildly different situation — and the operating system, at the point where the sound would or would not be played, cannot tell the two apart. All it knows is that the app did not call a method. I would rather readers hold both halves at once than have me pretend the design only ever cuts my way. If you have concluded from this article that the phone would make a noise if it were recording is not a safety check worth relying on, you have read it correctly, and that conclusion is inconvenient for every camera vendor there is, this one very much included.
You cannot hear the answer, so you have to read it
If the sound is not a reliable signal, the question becomes what is. Two earlier pieces apply directly, and neither is sufficient alone. Read an Android Camera App's Architecture covers what a manifest and a dependency graph will and will not admit. You Cannot Audit a Promise, But You Can Audit a Router covers measuring whether video leaves a building, which is a different question with a much better instrument.
But there is an honest gap between those pieces and this one, and it is the kind of gap that gets papered over. Neither method answers the shutter-sound question. A manifest lists permissions and components, and there is no permission for plays a sound on capture, because it is not a permission — it is a method call, or the absence of one, somewhere inside the code. Network measurement is further away still: a sound is not traffic. The only way to know from the outside is the crude, effective one. Put the device in front of you, in the region you are actually in, at a volume you can hear, and start a capture. That is a worse instrument than a router readout, and it is also the only one there is, which is itself a finding.
Four things this article cannot tell you
What a specific device build does below the API. Everything above describes the documented public API surface. Device makers ship their own camera stacks, and I have no visibility into whether a given firmware also forces a sound at a level an app never sees. The documentation I quoted does not say, and I am not going to guess on your behalf.
How the boolean is computed. The method reports whether a sound is required. The reference does not describe the inputs — locale, hardware configuration, carrier, something else — and I found no public statement of the algorithm. Treat the return value as an answer, not an explanation.
Which path a given app takes. The distinction drawn here is specific to camera2 and CameraX. The older interfaces behave differently, and the platform says so directly: "There is no need to play sounds when using Camera.takePicture or MediaRecorder for still images or video, respectively, as the Android framework will play the appropriate sounds when needed for these calls." An app on those paths gets the sound played for it. So does this app make a noise depends partly on an implementation choice invisible from a store listing.
Anything legal. An API reference is documentation, not statute, and I am not a lawyer. A note about regional restrictions in a javadoc tells you what Google's platform team built for. It does not tell you what any jurisdiction requires of you, and those are not the same document.
Apply it to me
I build a camera app for repurposed Android handsets, so the fair reading of this article is that I have just spent several thousand words explaining why the audible signal a stranger might rely on is, on modern Android, up to the developer. I am not going to settle that with a reassuring sentence about my own code, because a reassuring sentence is exactly the thing this article argues you should stop accepting. The check runs in about thirty seconds and needs no cooperation from me: hold the device, turn the volume up, start a capture, listen. Do it to my app, and to every camera app on the phone. Whatever you hear is a fact you own, and it beats anything either of us could write about it.
The broader point outlives the method name. A meaningful share of what people believe the operating system guarantees turns out, on inspection, to be a value it hands to an application along with a recommendation. Knowing which of your assumptions sit in which category is worth the ten minutes, and the only reliable way to find out is to go and read the paragraph.
Related reading: One Microphone, Everything Else, on what the platform hands a background recorder when a resource is unavailable, and Stealing Photos Through Android Cameras, on the same mechanism used badly.
Sources, all first-party: MediaActionSound, Camera.CameraInfo and CameraX CameraInfo.
More on running an old Android as a local camera at superfunicular.com.
Top comments (0)