동작 변경사항: Android 14 이상을 타겟팅하는 앱

이전 버전과 마찬가지로 Android 14에는 앱에 영향을 미칠 수 있는 동작 변경사항이 포함되어 있습니다. 다음 동작 변경사항은 Android 14 (API 수준 34) 이상을 타겟팅하는 앱에만 적용됩니다. 앱이 Android 14 이상을 타겟팅한다면 이러한 동작을 올바르게 지원하도록 앱을 수정해야 합니다(적용되는 경우).

앱의 targetSdkVersion과 관계없이 Android 14에서 실행되는 모든 앱에 영향을 미치는 동작 변경사항 목록도 검토해야 합니다.

핵심 기능

포그라운드 서비스 유형은 필수 항목임

If your app targets Android 14 (API level 34) or higher, it must specify at least one foreground service type for each foreground service within your app. You should choose a foreground service type that represents your app's use case. The system expects foreground services that have a particular type to satisfy a particular use case.

If a use case in your app isn't associated with any of these types, it's strongly recommended that you migrate your logic to use WorkManager or user-initiated data transfer jobs.

BluetoothAdapter에서 BLUETOOTH_CONNECT 권한 적용

Android 14 enforces the BLUETOOTH_CONNECT permission when calling the BluetoothAdapter getProfileConnectionState() method for apps targeting Android 14 (API level 34) or higher.

This method already required the BLUETOOTH_CONNECT permission, but it was not enforced. Make sure your app declares BLUETOOTH_CONNECT in your app's AndroidManifest.xml file as shown in the following snippet and check that a user has granted the permission before calling getProfileConnectionState.

<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />

OpenJDK 17 업데이트

Android 14 continues the work of refreshing Android's core libraries to align with the features in the latest OpenJDK LTS releases, including both library updates and Java 17 language support for app and platform developers.

A few of these changes can affect app compatibility:

  • Changes to regular expressions: Invalid group references are now disallowed to more closely follow the semantics of OpenJDK. You might see new cases where an IllegalArgumentException is thrown by the java.util.regex.Matcher class, so make sure to test your app for areas that use regular expressions. To enable or disable this change while testing, toggle the DISALLOW_INVALID_GROUP_REFERENCE flag using the compatibility framework tools.
  • UUID handling: The java.util.UUID.fromString() method now does more strict checks when validating the input argument, so you might see an IllegalArgumentException during deserialization. To enable or disable this change while testing, toggle the ENABLE_STRICT_VALIDATION flag using the compatibility framework tools.
  • ProGuard issues: In some cases, the addition of the java.lang.ClassValue class causes an issue if you try to shrink, obfuscate, and optimize your app using ProGuard. The problem originates with a Kotlin library that changes runtime behaviour based on whether Class.forName("java.lang.ClassValue") returns a class or not. If your app was developed against an older version of the runtime without the java.lang.ClassValue class available, then these optimizations might remove the computeValue method from classes derived from java.lang.ClassValue.

JobScheduler가 콜백 및 네트워크 동작 강화

Since its introduction, JobScheduler expects your app to return from onStartJob or onStopJob within a few seconds. Prior to Android 14, if a job runs too long, the job is stopped and fails silently. If your app targets Android 14 (API level 34) or higher and exceeds the granted time on the main thread, the app triggers an ANR with the error message "No response to onStartJob" or "No response to onStopJob".

This ANR may be a result of 2 scenarios: 1. There is work blocking the main thread, preventing the callbacks onStartJob or onStopJob from executing and completing within the expected time limit. 2. The developer is running blocking work within the JobScheduler callback onStartJob or onStopJob, preventing the callback from completing within the expected time limit.

To address #1, you will need to further debug what is blocking the main thread when the ANR occurs, you can do this using ApplicationExitInfo#getTraceInputStream() to get the tombstone trace when the ANR occurs. If you're able to manually reproduce the ANR, you can record a system trace and inspect the trace using either Android Studio or Perfetto to better understand what is running on the main thread when the ANR occurs. Note that this can happen when using JobScheduler API directly or using the androidx library WorkManager.

To address #2, consider migrating to WorkManager, which provides support for wrapping any processing in onStartJob or onStopJob in an asynchronous thread.

JobScheduler also introduces a requirement to declare the ACCESS_NETWORK_STATE permission if using setRequiredNetworkType or setRequiredNetwork constraint. If your app does not declare the ACCESS_NETWORK_STATE permission when scheduling the job and is targeting Android 14 or higher, it will result in a SecurityException.

타일 실행 API

14 이상을 타겟팅하는 앱의 경우 TileService#startActivityAndCollapse(Intent)가 지원 중단되었으며 다음 오류가 발생합니다. 예외가 발생할 수 있습니다. 앱이 카드에서 활동을 실행하는 경우 다음을 사용합니다. 대신 TileService#startActivityAndCollapse(PendingIntent)를 사용하세요.

개인정보처리방침

사진 및 동영상에 대한 일부 액세스 권한

Android 14 introduces Selected Photos Access, which allows users to grant apps access to specific images and videos in their library, rather than granting access to all media of a given type.

This change is only enabled if your app targets Android 14 (API level 34) or higher. If you don't use the photo picker yet, we recommend implementing it in your app to provide a consistent experience for selecting images and videos that also enhances user privacy without having to request any storage permissions.

If you maintain your own gallery picker using storage permissions and need to maintain full control over your implementation, adapt your implementation to use the new READ_MEDIA_VISUAL_USER_SELECTED permission. If your app doesn't use the new permission, the system runs your app in a compatibility mode.

사용자 환경

전체 화면 인텐트 보안 알림

Android 11 (API 수준 30)에서는 휴대전화가 잠겨 있을 때 앱에서 Notification.Builder.setFullScreenIntent를 사용하여 전체 화면 인텐트를 전송할 수 있었습니다. AndroidManifest에서 USE_FULL_SCREEN_INTENT 권한을 선언하여 앱 설치 시 이를 자동으로 부여할 수 있습니다.

전체 화면 인텐트 알림은 수신 전화 또는 사용자가 구성한 알람 시계 설정과 같이 사용자의 즉각적인 주의가 요구되는 매우 높은 우선순위의 알림을 위해 설계되었습니다. Android 14 (API 수준 34) 이상을 타겟팅하는 앱의 경우 이 권한을 사용할 수 있는 앱은 통화 및 알람만 제공하는 앱으로 제한됩니다. Google Play 스토어에서는 이 프로필에 맞지 않는 앱의 기본 USE_FULL_SCREEN_INTENT 권한을 취소합니다. 정책 변경 기한은 2024년 5월 31일입니다.

이 권한은 사용자가 Android 14로 업데이트하기 전에 휴대전화에 설치된 앱에는 계속 사용 설정됩니다. 사용자는 이 권한을 사용 설정 또는 사용 중지할 수 있습니다.

새 API NotificationManager.canUseFullScreenIntent를 사용하여 앱에 권한이 있는지 확인할 수 있습니다. 권한이 없으면 앱에서 새 인텐트 ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT를 사용하여 사용자가 권한을 부여할 수 있는 설정 페이지를 실행할 수 있습니다.

보안

암시적 인텐트와 대기 중인 인텐트 제한사항

For apps targeting Android 14 (API level 34) or higher, Android restricts apps from sending implicit intents to internal app components in the following ways:

  • Implicit intents are only delivered to exported components. Apps must either use an explicit intent to deliver to unexported components, or mark the component as exported.
  • If an app creates a mutable pending intent with an intent that doesn't specify a component or package, the system throws an exception.

These changes prevent malicious apps from intercepting implicit intents that are intended for use by an app's internal components.

For example, here is an intent filter that could be declared in your app's manifest file:

<activity
    android:name=".AppActivity"
    android:exported="false">
    <intent-filter>
        <action android:name="com.example.action.APP_ACTION" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

If your app tried to launch this activity using an implicit intent, an ActivityNotFoundException exception would be thrown:

Kotlin

// Throws an ActivityNotFoundException exception when targeting Android 14.
context.startActivity(Intent("com.example.action.APP_ACTION"))

Java

// Throws an ActivityNotFoundException exception when targeting Android 14.
context.startActivity(new Intent("com.example.action.APP_ACTION"));

To launch the non-exported activity, your app should use an explicit intent instead:

Kotlin

// This makes the intent explicit.
val explicitIntent =
        Intent("com.example.action.APP_ACTION")
explicitIntent.apply {
    package = context.packageName
}
context.startActivity(explicitIntent)

Java

// This makes the intent explicit.
Intent explicitIntent =
        new Intent("com.example.action.APP_ACTION")
explicitIntent.setPackage(context.getPackageName());
context.startActivity(explicitIntent);

런타임 등록 broadcast receiver는 내보내기 동작을 지정해야 함

Android 14(API 수준 34) 이상을 타겟팅하고 컨텍스트 등록 수신기를 사용하는 앱과 서비스는 수신기를 기기의 다른 모든 앱으로 내보내야 하는지 나타내는 플래그를 지정해야 합니다(각각 RECEIVER_EXPORTED 또는 RECEIVER_NOT_EXPORTED). 이 요구사항은 Android 13에 도입된 이러한 수신기의 기능을 활용하여 보안 취약점으로부터 앱을 보호하는 데 도움이 됩니다.

시스템 브로드캐스트만 수신하는 수신기 예외

앱이 Context#registerReceiver()와 같은 Context#registerReceiver 메서드를 통해 시스템 브로드캐스트용으로만 수신기를 등록하는 경우 수신기를 등록할 때 플래그를 지정하면 안 됩니다.

더 안전한 동적 코드 로드

앱이 Android 14 (API 수준 34) 이상을 타겟팅하고 동적 코드 로드 (DCL)를 사용하는 경우 동적으로 로드된 모든 파일은 읽기 전용으로 표시해야 합니다. 그러지 않으면 시스템에서 예외가 발생합니다. 가능하면 항상 코드를 동적으로 로드하지 않는 것이 좋습니다. 이렇게 하면 코드 삽입이나 코드 조작으로 인해 앱이 손상될 위험이 크게 증가하기 때문입니다.

코드를 동적으로 로드해야 하는 경우 다음 방법을 사용하여 동적으로 로드된 파일(예: DEX, JAR 또는 APK 파일)을 파일을 여는 즉시 그리고 콘텐츠가 작성되기 전에 읽기 전용으로 설정합니다.

Kotlin

val jar = File("DYNAMICALLY_LOADED_FILE.jar")
val os = FileOutputStream(jar)
os.use {
    // Set the file to read-only first to prevent race conditions
    jar.setReadOnly()
    // Then write the actual file content
}
val cl = PathClassLoader(jar, parentClassLoader)

Java

File jar = new File("DYNAMICALLY_LOADED_FILE.jar");
try (FileOutputStream os = new FileOutputStream(jar)) {
    // Set the file to read-only first to prevent race conditions
    jar.setReadOnly();
    // Then write the actual file content
} catch (IOException e) { ... }
PathClassLoader cl = new PathClassLoader(jar, parentClassLoader);

이미 있는 동적으로 로드된 파일 처리

동적으로 로드된 기존 파일에 예외가 발생하지 않도록 하려면 앱에서 파일을 다시 동적으로 로드하기 전에 파일을 삭제하고 다시 만드는 것이 좋습니다. 파일을 다시 만들 때 앞의 안내에 따라 쓰기 시간에 파일을 읽기 전용으로 표시하세요. 또는 기존 파일의 라벨을 읽기 전용으로 다시 지정할 수 있지만 이 경우에는 앱을 악의적인 행위로부터 보호할 수 있도록 먼저 파일의 무결성을 확인하는 것이 좋습니다(예: 신뢰할 수 있는 값을 기준으로 파일의 서명 확인).

백그라운드에서 활동 시작에 관한 추가 제한사항

Android 14 (API 수준 34) 이상을 타겟팅하는 앱의 경우 시스템은 앱이 백그라운드에서 활동을 시작하도록 허용되는 시점을 추가로 제한합니다.

  • 앱이 PendingIntent#send() 또는 유사한 메서드를 사용하여 PendingIntent를 전송할 때 대기 중인 인텐트를 시작하기 위해 자체 백그라운드 활동 실행 권한을 부여할지 이제 앱이 선택해야 합니다. 선택하려면 앱에서 setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)가 포함된 ActivityOptions 번들을 전달해야 합니다.
  • 표시되는 앱이 bindService() 메서드를 사용하여 백그라운드에 있는 다른 앱의 서비스를 바인딩하는 경우 이제 표시되는 앱은 바운드된 서비스에 자체 백그라운드 활동 실행 권한을 부여할지 선택해야 합니다. 선택하려면 앱은 bindService() 메서드를 호출할 때 BIND_ALLOW_ACTIVITY_STARTS 플래그를 포함해야 합니다.

이러한 변경사항은 기존 제한사항을 확장하여 악성 앱이 백그라운드에서 방해가 되는 활동을 시작하기 위해 API를 악용하는 것을 방지함으로써 사용자를 보호합니다.

압축 파일 경로 순회

Android 14 (API 수준 34) 이상을 타겟팅하는 앱의 경우 Android에서는 다음과 같은 방법으로 ZIP 경로 순회 취약점을 방지합니다. ZIP 파일 항목 이름에 '..'이 포함되거나 이름이 '/'로 시작되는 경우 ZipFile(String) 및 ZipInputStream.getNextEntry()에서 ZipException이 발생합니다.

앱은 dalvik.system.ZipPathValidator.clearCallback()을 호출하여 이 유효성 검사를 선택 해제할 수 있습니다.

Android 14 (API 수준 34) 이상을 타겟팅하는 앱의 경우 다음 시나리오 중 하나에서 MediaProjection#createVirtualDisplay에 의해 SecurityException이 발생합니다.

앱은 각 캡처 세션 전에 사용자에게 동의를 요청해야 합니다. 단일 캡처 세션은 MediaProjection#createVirtualDisplay의 단일 호출이며 각 MediaProjection 인스턴스는 한 번만 사용해야 합니다.

구성 변경 처리

앱에서 MediaProjection#createVirtualDisplay를 호출하여 구성 변경사항 (예: 화면 방향 또는 화면 크기 변경)을 처리해야 하는 경우 다음 단계에 따라 기존 MediaProjection 인스턴스의 VirtualDisplay를 업데이트할 수 있습니다.

  1. 새 너비와 높이를 사용하여 VirtualDisplay#resize를 호출합니다.
  2. 새 너비와 높이가 포함된 새 Surface를 VirtualDisplay#setSurface에 제공합니다.

콜백 등록

앱은 사용자가 캡처 세션을 계속하는 데 동의하지 않는 경우를 처리하는 콜백을 등록해야 합니다. 이렇게 하려면 Callback#onStop를 구현하고 앱에서 관련 리소스 (예: VirtualDisplay 및 Surface)를 해제하도록 합니다.

앱이 이 콜백을 등록하지 않으면 앱에서 호출할 때 MediaProjection#createVirtualDisplay이 IllegalStateException을 발생시킵니다.

업데이트된 비 SDK 제한사항

Android 14 includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.

If your app does not target Android 14, some of these changes might not immediately affect you. However, while you can currently use some non-SDK interfaces (depending on your app's target API level), using any non-SDK method or field always carries a high risk of breaking your app.

If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you cannot find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API.

To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 14. To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces.