DEV Community

Super Funicular
Super Funicular

Posted on

Denied, Dismissed, Delayed: What Android Actually Guarantees You Will See When a Phone Is Recording

#android #privacy #security #mobile

If you run an old Android phone as a security camera, one thing stands between "a camera running in the background" and "a hidden camera": the notification the system makes it post.

That notification is weaker than almost anyone assumes. The user can deny it, dismiss it, or simply not see it for the first ten seconds — three documented mechanisms, added in three separate releases. Meanwhile two other signals exist that an app has no documented way to touch at all, and almost nobody looks at them.

Every claim below is quoted from Google's developer documentation, the AOSP platform docs, or the Compatibility Definition Document, with the gaps stated plainly where the documentation simply does not say.

How can you tell if an Android phone is recording video in the background?

Short answer: Check three places, not one. The camera indicator in the status bar (Android 12 and up) and the Active apps list in the notification drawer (Android 13 and up) are both required by Android's Compatibility Definition Document, and neither the device nor the app can switch them off. The app's own ongoing notification is the least reliable of the three.

The notification is the signal everyone was taught to look for, and it is the one with three documented off-switches. The other two are compatibility requirements. That ordering is the whole article.

Can an Android app record video without showing a notification?

Short answer: Not by its own choice. Background recording requires a foreground service, and Google's docs say apps "must include a notification when they start a foreground service." An app cannot push it below PRIORITY_LOW without the system adding its own drawer message. But the user can remove that notification in three documented ways.

Once the user has, the recording is still disclosed — by the camera indicator and the Active apps list, neither of which any app can suppress. Background Camera RemoteStream is bound by every one of these rules exactly like any other app.

Three tiers of disclosure, and only one is under the app's control

Surface Introduced Controlled by Can the user remove it?
Foreground service notification Permission-gated since Android 13 App posts it, user permission gates it Yes — three ways
Active apps / Task Manager Android 13 System No (AOSP: "can't be turned off")
Camera privacy indicator Android 12 System No documented way

The app controls only the first. That is the one people rely on, and the only one that goes away.

Tier 1: the notification, and the three ways it disappears

Denied

Android 13 turned notifications into a runtime permission, and foreground services were not exempted from the consequences:

"If the user denies the notification permission, they don't see notices related to foreground services in the notification drawer. However, users still see notices related to foreground services in the Task Manager, regardless of whether the notification permission is granted."

One permission tap removes the only in-shade evidence that a camera is running. The permission guide adds that "apps don't need to request the POST_NOTIFICATIONS permission in order to launch a foreground service. However, apps must include a notification when they start a foreground service." The notification object is still required. Its display is not guaranteed.

There is a trap for older apps too. If an app targets API 32 or lower, "the system shows the permission dialog the first time your app starts an activity after you create a notification channel" — and if the user taps Don't allow even once, "they aren't prompted again until they uninstall and reinstall your app, or you update your app to target Android 13 or higher." One reflexive tap during setup, months ago, is enough.

Dismissed

Here two first-party Google pages disagree. Android 13 behaviour changes, flatly:

"On devices that run Android 13 or higher, users can dismiss notifications associated with foreground services by default."

Android 14 behaviour changes, claiming the change for itself:

"If your app shows non-dismissable foreground notifications to users, Android 14 has changed the behavior to allow users to dismiss such notifications... The behavior of FLAG_ONGOING_EVENT has changed to make such notifications actually dismissable by the user."

Both pages are live and carry the same last-updated date. They cannot both be a complete description. Only the Android 14 page states exceptions, and they are useful ones: the notification stays non-dismissible "When the phone is locked" and "If the user selects a Clear all notification action (which helps with accidental dismissals)." Whole categories are excluded from the change — "CallStyle notifications", enterprise device-policy controllers, "Media notifications", the default Search Selector package. A third-party camera app is none of those.

The Android 13 sentence's own supporting link is dead: it points at an anchor (#user-dismiss-notification) on a page that no longer contains that section. So cite Android 14 for this behaviour, and test dismissal on the phone you are actually deploying rather than trusting either page.

Delayed

The third mechanism is older and gets misattributed constantly. From the Android 12 behaviour-changes page:

"To provide a streamlined experience for short-running foreground services, devices that run Android 12 or higher can delay the display of foreground service notifications by 10 seconds, with a few exceptions."

Android 12, not Android 13 — "10 seconds" appears nowhere on either Android 13 behaviour-changes page. For a camera running for hours the delay barely matters. For a ten-second clip it matters completely: the recording can finish before its own notification is drawn. The "few exceptions" are asserted, but the link to their list is also dead.

And the one thing an app cannot do

An app cannot quietly demote the notification out of sight:

"The status bar notification must use a priority of PRIORITY_LOW or higher. If your app attempts to use a notification that has a lower priority than PRIORITY_LOW, the system adds a message to the notification drawer, alerting the user to the app's use of a foreground service."

IMPORTANCE_LOW is silent but stays in the status bar. IMPORTANCE_MIN is silent and leaves the status bar, but sits below that floor. And regardless of level, "all notifications, regardless of importance, appear in non-interruptive system UI locations, such as in the notification drawer and as a badge on the launcher icon." Silence is available. Invisibility is not.

Tier 2: Active apps, the list that cannot be turned off

Android 13 added a surface most people have never opened:

"Starting in Android 13 (API level 33), users can complete a workflow from the notification drawer to stop an app that has an ongoing foreground services, regardless of that app's target SDK version. This affordance, called the Task Manager, shows a list of apps that are currently running a foreground service." — and "This list is labeled Active apps. Next to each app is a Stop button."

Two properties make this the signal that actually matters.

First, AOSP states it is not optional: "The Task Manager adds an information bar on the Quick Settings display to inform users of the apps running in the background... Note: This feature can't be turned off."

Second, the CDD mandates it. Android 13's [8.5/H-0-1] requires a handheld to "provide a user affordance in the Settings menu with the ability to stop an app that is running a foreground service and display all apps that have active foreground services and the duration of each of these services since it started." Android 16 splits it into two requirements and drops "in the Settings menu" — which reads as a correction to match where the feature actually shipped, since both the SDK docs and AOSP put it in the notification drawer.

Pressing Stop is not gentle. Per Google: "The system removes your app from memory. Therefore, your entire app stops, not just the running foreground service", "The notification associated with the foreground service is removed", and — the part that bites — "The system doesn't send your app any callbacks when the user taps the Stop button." No chance to close a file cleanly or tell a viewer the stream ended. Any app that records long files has to survive an unannounced kill, which is the same problem from a different direction as what the low memory killer does to a foreground service on a 2 GB phone.

Tier 3: the camera indicator, which the device is forbidden to hide

Since Android 12, "when an app accesses the microphone or camera, an icon appears in the status bar." AOSP describes the lifecycle: "An icon shows first, then transitions to a dot that persists until the app is either dismissed or closed."

This one is a hard compatibility requirement. Android CDD [9.8.2/H-5-1]: handhelds "MUST display the camera indicator when an app is accessing live camera data", with narrow carve-outs for system roles no third-party app qualifies for. The CDD defines the term in a way that forecloses the obvious workarounds:

"A 'camera indicator' refers to a view on screen, which is constantly visible to the user and cannot be obscured, which users understand as a camera is in use."

And [9.8.2/H-5-3] blocks the device itself from suppressing it: implementations "MUST not hide the camera indicator for system apps that have visible user interfaces or direct user interaction."

The only app-facing API here is read-only. WindowInsets.getPrivacyIndicatorBounds() "returns the Rect of the maximum bounds of the system privacy indicator" — so an app can move its own UI out from under the dot, not move the dot. There is no documented opt-out, for anyone, at any API level.

The asymmetry that matters most on a budget phone

Here is the part that should change how you think about this, and it is good news if your camera is a handset from 2022 rather than something new.

The disclosure is mandatory. Camera indicator: CDD-required on handhelds since Android 12. Active apps: CDD-required since Android 13, and per AOSP it cannot be switched off. Neither depends on the manufacturer's goodwill, the price of the phone, or a Google account.

The control is optional. The Quick Settings camera and microphone kill-switches are described by Google as available "on supported devices", and the CDD section covering them, 9.8.13, is conditional — it opens "If device implementations provide the user a software affordance to turn off the camera and/or microphone input..." Nothing in the Android 12 through 16 CDDs requires a phone to ship those toggles at all.

So the cheap handset is guaranteed to tell you the camera is on. It is not guaranteed to give you a one-tap way to stop it. Before you leave a phone running in a shop or a shared house, check whether that specific device has the Quick Settings toggles — and if it does not, the Active apps Stop button is the fallback the CDD does require.

Two Google pages that disagree about what the camera toggle does

If the toggles exist and someone flips one, what does a running camera app see? Google documents two answers.

The developer guide and the CDD say a blank feed with no error: "When the user turns off camera access, your app receives a blank camera feed", and CDD 9.8.13 [C-1-3] requires implementations to "only pass blank (or fake) camera and audio data to apps and not report an error code."

AOSP's sensors-off page says the opposite: "If an app is using the camera when Sensors off is enabled, an error is sent to the onError callback method and CameraDevice is closed", specifically ERROR_CAMERA_DISABLED.

These may be two related-but-distinct features — the AOSP page describes itself as a developer-options tile from Android 10, while the Quick Settings toggles are the Android 12 user-facing ones — but both run through the same sensor-privacy service, and no first-party page says which behaviour a third-party camera app should expect from the user-facing toggle. Practical reading: treat "blank feed" as the documented contract and handle ERROR_CAMERA_DISABLED anyway. Black frames and a closed camera device look identical from the next room and nothing alike in code.

What the documentation does not tell you

These gaps matter more than most of what is documented:

  • Whether the camera indicator appears while the screen is off is not documented anywhere. The CDD defines the indicator as "a view on screen" and says nothing about display power state. Neither the AOSP privacy-indicators page, the developer guide, the Android 12 behaviour-changes page, nor Google's consumer help article addresses screen-off or always-on-display behaviour. For an app whose entire premise is recording with the screen off, the most relevant question about the indicator has no published answer.
  • Whether it appears on the lock screen is likewise undocumented, as is whether the Active apps bar is reachable without unlocking.
  • No page states that an already-running foreground service keeps running after the notification permission is denied. The docs say only that the permission is not needed to launch one. "The service keeps running, the notification is just hidden" is a reasonable inference from the Task Manager sentence. It is not a documented guarantee, and we will not present it as one.
  • The list of apps exempt from the Active apps affordance does not exist in public form. The Android 13 and 14 CDDs say some apps "MAY be exempted... as described in the SDK document"; the SDK document they link to has no exemptions section. The only published criterion is an AOSP note that the Stop button is hidden for apps "core to the functionality of the device, such as Dialer and Camera" — preinstalled system apps, which cannot cover a third-party app.
  • The default lock-screen visibility of a foreground service notification is not stated. The three VISIBILITY_* constants are documented; which applies when an app sets none is not.
  • None of this describes any specific competitor's behaviour. We cannot see inside other people's apps and neither can you from a store listing. What we can tell you is what the platform requires of all of us equally.

A three-minute test, on the phone you actually plan to use

Documentation gaps are not a reason to guess:

  1. Start any background camera recording. Watch the status bar: an icon should appear, then shrink to a dot.
  2. Pull down the shade. Find the ongoing notification, then scroll to Active apps and confirm the app is listed with a Stop button.
  3. Turn the screen off, wait ten seconds, turn it back on without unlocking. Note whether the dot is there. That one observation answers, for your device, the question Google has not published.
  4. Try to swipe the notification away. Whether it goes tells you which of the two contradicting pages describes your phone.
  5. Open Quick Settings and look for camera and microphone toggles. If they are absent, this device does not have that kill switch.
  6. Press Stop in Active apps and confirm the app copes. It gets no warning.

Where this leaves phone-as-camera

The disclosure story on Android is better than its reputation and worse than its documentation. Better, because two of the three signals are compatibility requirements a manufacturer cannot remove and an app cannot suppress — including on inexpensive hardware, which is where most of these cameras actually run. Worse, because the signal everyone was taught to look for is the one with three documented off-switches, and the behaviour that matters most for screen-off recording is simply unwritten.

If you are deploying this deliberately, the notification is for you, not for the room: check the indicator and the Active apps list, and check them on the specific phone. If you are worried about the opposite case — a phone in a room you did not set up — those same two surfaces are the ones that cannot be turned off, and the full check is in a five-sign, sixty-second self-audit.

Background Camera RemoteStream records inside a camera-type foreground service for exactly the reasons above — it is what the platform requires, and the mechanics are in our deep-dive on FOREGROUND_SERVICE_TYPE_CAMERA. It keeps video on the phone rather than in anyone's cloud and serves the live view from a small web server on the device. None of that exempts it from a single rule above, which is the point: the platform's disclosure guarantees are the same for everyone, and they should be. (If your worry is what a mounted camera phone displays to the room rather than whether it is recording, that is a different problem — Your Camera Phone Is Still Signed In.)

The app is on Google Play, and the rest of the architecture write-ups are at superfunicular.com.

Sources

Top comments (0)