The one-line version of the problem

I build Background Camera RemoteStream, an Android app whose entire reason to exist is recording video while the screen is off. On Android 13 and below, that was a wake lock and a foreground service and you were done. On Android 14 (API 34) and up, the exact pattern the app depends on — holding the camera open with no Activity on screen — is the pattern the OS now treats as a privacy red flag. Get one of three things wrong and the service throws a SecurityException at the moment you call startForeground(), and the camera never opens at all.

This post is the thing I wish I'd had when I migrated: the full contract for running a camera in a foreground service on Android 14/15/16, why each piece exists, and the non-obvious failure modes that only show up on real devices.

This is the foreground-service companion to two earlier deep-dives: keeping Camera2 running with the screen off (the wake-lock and session-lifecycle side) and embedding a Ktor web server inside the app (the remote-control side). Here I'm focused narrowly on the foreground-service type system that Android 14 introduced, because that's where most screen-off camera apps quietly break.

Why "screen off" is the hard case

A normal camera app is easy for the OS to reason about: there's an Activity in the foreground, the user can see the viewfinder, and when they leave, the camera closes. The system trusts that flow because it's perceptible — the user can tell the camera is on.

Screen-off recording deliberately removes the perceptible surface. There's no viewfinder. The Activity is gone. From the platform's point of view, "an app holding the camera open with nothing on screen" is indistinguishable from spyware unless you tell it, explicitly and in three coordinated places, that this is a legitimate user-initiated capture. Android 14's foreground-service-type system is how you make that declaration.

The three-part contract

To legally hold the camera in a foreground service on Android 14+, all three of these must line up. Miss any one and you crash:

1. A manifest permission — FOREGROUND_SERVICE_CAMERA, in addition to the base FOREGROUND_SERVICE.
2. A typed service declaration — android:foregroundServiceType="camera" on the <service> element.
3. A legal place to start it — you cannot start a camera foreground service while your app is in the background.

Let's take them one at a time.

1. The manifest permissions

Beginning with Android 14, every foreground service must declare a type, and each type carries its own permission. For camera you need both of these:

<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_CAMERA" />
<uses-permission android:name="android.permission.CAMERA" />

The FOREGROUND_SERVICE_CAMERA permission is normal (granted at install), but it must be present. The runtime CAMERA permission is the one the user actually approves in a dialog — and crucially, it's a while-in-use permission, which is the root of the second failure mode below.

2. The typed service declaration

<service
    android:name=".camera.CameraService"
    android:foregroundServiceType="camera"
    android:exported="false" />

Then, when you promote the service, you pass the matching type constant:

val notification = buildCaptureNotification()
ServiceCompat.startForeground(
    this,
    NOTIFICATION_ID,
    notification,
    ServiceInfo.FOREGROUND_SERVICE_TYPE_CAMERA
)

If the manifest type and the runtime type don't match, or the permission is missing, startForeground() throws a SecurityException and the service is torn down immediately. There's no soft-fail and no degraded mode — the camera pipeline never even gets to openCamera(). The first time you hit this in production it looks like a random crash on Android 14 devices only; it's actually the type system doing exactly what it's designed to do.

3. You cannot start it from the background

This is the one that surprises people, and it's a direct consequence of the CAMERA permission being while-in-use. A while-in-use permission is only held while the app is in the foreground. So if your app is in the background and you try to spin up a camera-type foreground service, the system checks: does this app currently hold the camera permission? It doesn't — it's backgrounded — so it throws SecurityException before the service starts.

In practice that means a screen-off camera app cannot legitimately start recording from:

• a BOOT_COMPLETED receiver,
• a bare background JobScheduler / WorkManager task with no user-visible trigger,
• an alarm that fires while the app is fully backgrounded.

The capture has to be user-initiated from a visible surface. The documented escape hatches are narrow and deliberate: the service may start from the background only if the app is transitioning from a user-visible state such as an Activity, if it receives a high-priority Firebase Cloud Messaging message, if the service is started by the user interacting with a notification, or via a PendingIntent sent from a different, currently-visible app.

For us, the natural and honest design is the first one: the user opens the app, taps record, and that tap — from a visible Activity — is what launches the foreground service. The screen can go off a half-second later and the camera keeps running, because the permission was held at the moment of the start. This isn't a workaround; it's the model the platform wants, and it happens to match what an honest screen-off recorder should do anyway.

The order of operations that actually works

The sequence matters more than any single call. The pattern that survives Android 14–16:

// 1. From a VISIBLE Activity (user just tapped Record):
val intent = Intent(this, CameraService::class.java)
ContextCompat.startForegroundService(this, intent)

// 2. Inside the service, promote to foreground IMMEDIATELY
//    (within ~5s, or you get an ANR/timeout)
override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
    ServiceCompat.startForeground(
        this, NOTIFICATION_ID, buildCaptureNotification(),
        ServiceInfo.FOREGROUND_SERVICE_TYPE_CAMERA
    )
    acquireWakeLock()   // PARTIAL_WAKE_LOCK — keeps CPU alive, screen off
    openCameraSession() // Camera2: now safe to openCamera()
    return START_NOT_STICKY
}

Three subtleties hide in there. First, you must call startForeground() before you do anything slow, because the system gives you only a few seconds after startForegroundService() before it declares an ANR. Second, the wake lock is a PARTIAL_WAKE_LOCK — it keeps the CPU running with the screen and keyboard off, which is the whole trick; the Camera2 screen-off deep-dive covers why the capture session itself doesn't need the display. Third, START_NOT_STICKY is deliberate: you do not want the OS silently relaunching a camera service after a process death, because that relaunch would happen from the background and re-trigger the SecurityException — and even if it didn't, an un-prompted camera restart is exactly the behavior the type system exists to prevent.

Running the web server in the same service

Because the screen is off, the user can't tap the phone to control it — so the app exposes a small control surface over the local network instead. The embedded Ktor server runs inside the same foreground service as the camera. That's a design decision worth calling out: co-locating them means one notification, one lifecycle, one wake lock, and one place where teardown happens. When the service stops, the camera session closes and the Ktor engine shuts down together, so you never leak a half-open camera or a dangling socket.

It also keeps the foreground-service-type story honest. The service's reason to be in the foreground is the camera — that's the perceptible, user-initiated capability. The web server is an implementation detail riding along on that lifecycle, not a separate dataSync-type service trying to justify its own existence. One service, one type, one user-understandable purpose.

The Google Play Console gate

Declaring the type in code is only half of it. Google Play independently requires you to declare, in the Play Console, why your app uses each foreground service type — with a written description, the user-facing impact, and in many cases a short demo video showing the user-initiated, perceptible use. Camera is one of the most scrutinized types precisely because "background camera" is a phrase that, out of context, sounds alarming.

The thing that makes this passable is having a use that is genuinely user-initiated and perceptible: the user explicitly starts a recording from inside the app, there's a persistent notification the entire time the camera is live, and nothing starts without that tap. If you've architected around the while-in-use constraint honestly — start from a visible Activity, never from the background — then the Play Console justification basically writes itself, because the app already behaves the way the policy wants. Privacy-by-architecture and policy-compliance turn out to be the same work done once.

Android 15 and 16: what changed, what didn't

Migrating forward, the good news is that the camera type was left largely alone. The newer time-limit restrictions that landed in Android 15 and tightened in 16 target dataSync and the new mediaProcessing type — services the OS wants to cap because they can run open-endedly with no user attention. Camera, being user-initiated and perceptible, is not subject to those timeout cutoffs, so a long recording doesn't get guillotined at a fixed duration the way a dataSync job now can.

What did change is broader and worth a line: on Android 16, background jobs spawned from a foreground service must now obey their own runtime quotas, regardless of target SDK. That doesn't touch the camera capture itself, but if your service kicks off background uploads or post-processing jobs, those are now metered. For a local-only, zero-cloud app this is mostly a non-event — there's nothing being uploaded — but it's a reminder that "I'm in a foreground service so my background work is free" stopped being true.

What I'd tell my past self

If you're building anything that holds a sensor open with the screen off, the mental model that saves you is this: Android 14's foreground-service types aren't a permission checkbox, they're a contract about when and how you're allowed to start. The manifest type and permission are the easy 20%. The hard 80% is internalizing that a while-in-use capability means the start point must be a visible, user-driven moment — and then designing your whole UX so that the only way to begin a capture is a deliberate tap, never an alarm, a boot event, or a silent background trigger.

That constraint felt annoying when I first hit the SecurityException. It turned out to be a forcing function toward exactly the architecture a privacy-first recorder should have anyway: nothing starts without you, a notification is visible the whole time, and the recording lives and dies on your phone with no cloud in the loop. If you want the broader story of building the whole app this way — across 75+ AI-assisted sessions — that's written up here.

If you want to see the result rather than read about it, Background Camera RemoteStream is on Google Play (one-tap install, no sideloading), and the project lives at superfunicular.com.

Background Camera RemoteStream records with the screen off, streams to YouTube Live, runs a built-in local web server for remote viewing, and stores everything on-device with zero cloud dependency. Built in Kotlin on Camera2, Ktor, and the foreground-service APIs described above.