Android 14 포그라운드 서비스 타입, 권한·런타임 조건·시작 실패를 나누는 법
AI를 활용하여 생성한 이미지입니다.
Android 앱이 화면 뒤에서 음악을 재생하거나 위치를 기록하거나 파일을 업로드할 때 포그라운드 서비스를 선택할 수 있어요. 하지만 Android 14(API level 34)부터는 서비스 타입을 선언하지 않거나 타입에 맞는 권한·런타임 조건을 갖추지 않으면 시작 단계에서 문제가 생길 수 있습니다.[1][2] 서비스 하나를 오래 실행하는 방법보다, 작업의 성격과 필요한 권한을 먼저 맞추는 방식이 안전해요.
포그라운드 서비스는 무엇을 보장할까
포그라운드 서비스는 사용자에게 계속 표시되는 알림과 함께 실행되는 장시간 작업 경로예요. 그렇다고 백그라운드 제한을 모두 없애거나 어떤 작업이든 허용하는 만능 우회로는 아닙니다. Android 문서는 사용자가 알아야 하는 작업인지, 더 적합한 목적별 API가 있는지 먼저 판단하도록 안내해요.[1]
| 먼저 물을 것 | 예시 | 다음 선택 |
|---|---|---|
| 사용자가 진행을 알아야 하나 | 음악 재생·통화·운동 기록 | 적합한 FGS 타입 검토 |
| 작업이 짧고 예약 가능한가 | 주기적 동기화·조건부 업로드 | WorkManager 등 대체 API 검토 |
| 특정 권한이 필요한가 | 위치·카메라·마이크 | 매니페스트와 런타임 권한을 함께 점검 |
Android 14부터 달라진 세 가지
서비스 타입을 매니페스트에 선언합니다
Android 14 이상을 대상으로 하는 앱은 각 포그라운드 서비스에 맞는 타입을 매니페스트에 선언해야 해요. 기본 FOREGROUND_SERVICE 권한만 넣고 끝나는 구조가 아닙니다. 타입에 따라 추가 권한과 런타임 조건이 붙을 수 있어요.[2]
<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_LOCATION" />
<service
android:name=".TrackingService"
android:foregroundServiceType="location" />위 예시는 위치 타입을 설명하기 위한 형태예요. 실제 앱의 작업이 위치 추적인지, 미디어 재생인지, 데이터 전송인지에 따라 타입과 권한을 바꿔야 합니다. 서로 다른 작업을 한 서비스에 억지로 합치면 선언과 실제 동작의 경계가 흐려져요.
타입에 맞는 추가 권한을 요청합니다
Android 문서는 타입별로 선언할 권한, startForeground()에 넘길 타입 상수, 런타임 전제 조건을 구분해 설명합니다.[2] 예를 들어 위치 서비스는 위치 권한 상태와 앱이 서비스를 시작하는 시점을 함께 봐야 하고, 카메라나 마이크를 쓰는 작업은 해당 런타임 권한을 확보하기 전에는 시작할 수 없는 상황이 생깁니다. 매니페스트만 맞추고 앱 화면에서 권한을 받지 않는 방식은 충분하지 않아요.
백그라운드 시작 제한을 따로 봅니다
서비스 타입과 별개로, 앱이 백그라운드에 있을 때 포그라운드 서비스를 시작할 수 있는지도 확인해야 해요. Android 문서는 제한된 백그라운드 시작과 예외 조건을 별도로 다룹니다.[3] “알림을 띄우는 서비스니까 언제든 시작된다”라고 가정하면 특정 버전이나 특정 권한 조합에서만 재현되는 오류를 놓치게 됩니다.
진단 순서
- 작업을 한 문장으로 씁니다. “사용자가 운동을 기록하는 동안 위치를 계속 수집한다”처럼 실제 작업을 적습니다.
- 타입을 하나씩 매칭합니다. 위치·미디어·데이터 전송 등 공식 타입 설명과 비교하고, 목적이 맞지 않으면 다른 API를 검토합니다.[2]
- 매니페스트를 확인합니다. 기본 권한, 타입별 권한, 서비스의
android:foregroundServiceType이 같은 작업을 가리키는지 확인합니다. - 런타임 권한 시점을 확인합니다. 권한 결과를 받기 전에 서비스가 시작되지 않는지, 앱이 허용된 상태인지 로그로 확인합니다.
- 시작 위치를 확인합니다. 포그라운드 화면에서 시작한 것인지, 백그라운드 이벤트가 시작을 유발한 것인지 나눕니다.[3]
- 알림을 확인합니다. 서비스 시작 직후 사용자에게 보이는 알림이 생성되는지, 알림 채널이 차단되어 진단을 가리고 있지 않은지 봅니다.
오류를 원인별로 나누기
타입 또는 권한 선언 오류
앱이 Android 14 이상을 대상으로 하고 서비스 타입을 빠뜨렸다면 선언 단계의 문제부터 해결해야 해요. startForeground() 호출에 전달한 타입이 매니페스트와 다르거나, 서비스에 필요한 권한이 빠진 경우도 같은 범주로 봅니다. 코루틴이나 스레드를 바꾸기 전에 APK의 최종 매니페스트를 확인하세요.
런타임 권한 오류
위치·카메라·마이크처럼 사용자의 허용 결과가 필요한 타입은 권한 요청이 끝난 뒤에 서비스를 시작하는지 확인합니다. 권한이 거부됐는데 서비스 내부에서 예외를 삼켜 버리면 “간헐적으로 안 된다”는 상태가 됩니다. 시작 전 권한 상태와 시작 직후 예외를 함께 기록하세요.
백그라운드 시작 오류
앱이 화면에 보일 때는 되고 화면을 닫거나 재부팅한 뒤에는 안 된다면 시작 제한과 예외 조건을 먼저 의심하세요. 목적에 따라 사용자가 버튼을 누르는 시점에 시작하거나, WorkManager·알람·시스템이 제공하는 목적별 경로로 바꾸는 편이 맞을 수 있어요.[1][3]
서비스를 써야 할지 자체가 애매한 경우
짧은 작업, 지연되어도 되는 동기화, 조건을 만족할 때 한 번 실행하는 작업이라면 포그라운드 서비스를 늘리는 것이 답이 아닐 수 있습니다. 서비스 타입을 억지로 골라 권한을 늘리기보다 작업 지속성, 사용자 가시성, 재시도 요구를 기준으로 대체 API를 비교하세요.
구현 전에 확인할 체크리스트
- 작업 목적이 공식 FGS 타입 하나와 맞는가?
- 매니페스트의 서비스 타입과 추가 권한이 맞는가?
- 런타임 권한을 받은 뒤 서비스를 시작하는가?
- 앱이 포그라운드인지 백그라운드인지 재현 조건을 나눴는가?
- 서비스 시작 직후 알림·로그·예외를 확인할 수 있는가?
- WorkManager나 목적별 API로 더 단순하게 처리할 수 없는가?
정리
Android 14의 포그라운드 서비스 문제는 “서비스가 죽었다” 하나로 묶기보다 타입 선언, 타입별 권한, 런타임 권한, 백그라운드 시작 조건으로 나누어야 해요. 이 네 가지를 분리하면 코드 자체의 문제와 플랫폼 정책 문제를 구분하기 쉬워지고, 필요하지 않은 장기 실행 서비스도 줄일 수 있습니다.
관련 글
- Android WorkManager 제약 조건, 네트워크·배터리·재시도를 한 작업에 섞지 않는 법
- Android Work Profile VPN, always-on과 lockdown을 나눠 설계하는 법
공식 출처
- Android Developers: Foreground services overview [1]
- Android Developers: Foreground service types [2]
- Android Developers: Launch a foreground service [3]
최종 확인일: 2026년 10월 1일 (KST). Android Developers 공식 문서의 Android 14 이상 서비스 타입·권한·시작 제한 설명을 기준으로 정리했어요.
