이전 출시와 마찬가지로 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 thejava.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 theDISALLOW_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 anIllegalArgumentException
during deserialization. To enable or disable this change while testing, toggle theENABLE_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 whetherClass.forName("java.lang.ClassValue")
returns a class or not. If your app was developed against an older version of the runtime without thejava.lang.ClassValue
class available, then these optimizations might remove thecomputeValue
method from classes derived fromjava.lang.ClassValue
.
JobScheduler는 콜백 및 네트워크 동작 강화
JobScheduler는 도입 후부터 앱이
onStartJob
또는 몇 초 내의 onStopJob
. Android 14 이전에는
작업이 너무 오래 실행되면 작업이 중지되고 자동으로 실패합니다.
앱이 Android 14 (API 수준 34) 이상을 타겟팅하고
기본 스레드에서 허용된 시간을 초과하면 앱에서 ANR을 트리거합니다.
'onStartJob
에 대한 응답 없음' 오류 메시지 또는
'onStopJob
에 대한 응답 없음'
이 ANR은 다음 두 가지 시나리오로 인해 발생할 수 있습니다.
1. 기본 스레드를 차단하는 작업이 있어 콜백 onStartJob
또는 onStopJob
가 예상 시간 제한 내에 실행되고 완료되지 않습니다.
2. 개발자가 JobScheduler 콜백 onStartJob
또는 onStopJob
내에서 차단 작업을 실행하여 콜백이 예상 시간 제한 내에 완료되지 않도록 합니다.
1번 문제를 해결하려면 ANR이 발생할 때 기본 스레드를 차단하는 항목을 추가로 디버그해야 합니다. 이를 위해 ApplicationExitInfo#getTraceInputStream()
를 사용하여 ANR이 발생할 때 tombstone 트레이스를 가져오면 됩니다. ANR을 수동으로 재현할 수 있는 경우
시스템 트레이스를 기록하고 다음 중 하나를 사용하여 트레이스를 검사할 수 있습니다.
Android 스튜디오 또는 Perfetto에서 실행 중인 애플리케이션을 더 잘 이해할 수 있습니다.
기본 스레드에 저장됩니다.
이는 JobScheduler API를 직접 사용하거나 androidx 라이브러리 WorkManager를 사용할 때 발생할 수 있습니다.
두 번째 문제를 해결하려면 다음을 제공하는 WorkManager로 이전하는 것이 좋습니다.
onStartJob
또는 onStopJob
에서 처리 래핑 지원
비동기 스레드에 있을 수 있습니다
또한 JobScheduler
는 setRequiredNetworkType
또는 setRequiredNetwork
제약 조건을 사용하는 경우 ACCESS_NETWORK_STATE
권한을 선언해야 하는 요구사항을 도입합니다. 앱이 작업을 예약할 때 ACCESS_NETWORK_STATE
권한을 선언하지 않고 Android 14 이상을 타겟팅하는 경우 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는 내보내기 동작을 지정해야 함
Apps and services that target Android 14 (API level 34) or higher and use
context-registered receivers are required to specify a flag
to indicate whether or not the receiver should be exported to all other apps on
the device: either RECEIVER_EXPORTED
or RECEIVER_NOT_EXPORTED
, respectively.
This requirement helps protect apps from security vulnerabilities by leveraging
the features for these receivers introduced in Android 13.
Exception for receivers that receive only system broadcasts
If your app is registering a receiver only for
system broadcasts through Context#registerReceiver
methods, such as Context#registerReceiver()
, then it
shouldn't specify a flag when registering the receiver.
더 안전한 동적 코드 로드
If your app targets Android 14 (API level 34) or higher and uses Dynamic Code Loading (DCL), all dynamically-loaded files must be marked as read-only. Otherwise, the system throws an exception. We recommend that apps avoid dynamically loading code whenever possible, as doing so greatly increases the risk that an app can be compromised by code injection or code tampering.
If you must dynamically load code, use the following approach to set the dynamically-loaded file (such as a DEX, JAR, or APK file) as read-only as soon as the file is opened and before any content is written:
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);
Handle dynamically-loaded files that already exist
To prevent exceptions from being thrown for existing dynamically-loaded files, we recommend deleting and recreating the files before you try to dynamically load them again in your app. As you recreate the files, follow the preceding guidance for marking the files read-only at write time. Alternatively, you can re-label the existing files as read-only, but in this case, we strongly recommend that you verify the integrity of the files first (for example, by checking the file's signature against a trusted value), to help protect your app from malicious actions.
백그라운드에서 활동 시작에 관한 추가 제한사항
Android 14(API 수준 34) 이상을 타겟팅하는 앱의 경우 시스템은 앱이 백그라운드에서 활동을 시작하도록 허용되는 시점을 추가로 제한합니다.
- 앱이
PendingIntent#send()
또는 유사한 메서드를 사용하여PendingIntent
를 전송할 때 대기 중인 인텐트를 시작하기 위해 자체 백그라운드 활동 실행 권한을 부여할지 이제 앱이 선택해야 합니다. 선택하려면 앱에서setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)
가 포함된ActivityOptions
번들을 전달해야 합니다. - 표시되는 앱이
bindService()
메서드를 사용하여 백그라운드에 있는 다른 앱의 서비스를 바인딩하는 경우 이제 표시되는 앱은 바운드된 서비스에 자체 백그라운드 활동 실행 권한을 부여할지 선택해야 합니다. 선택하려면 앱에 다음 항목이 포함되어야 합니다.BIND_ALLOW_ACTIVITY_STARTS
플래그bindService()
메서드를 사용하여 지도 가장자리에 패딩을 추가할 수 있습니다.
이러한 변경사항으로 인해 기존 제한사항이 확대되어 악성 앱이 불편을 초래하는 API를 악용하지 못하도록 방지하여 사용자를 보호합니다. 할 수 있습니다.
압축 파일 경로 순회
Android 14 (API 수준 34) 이상을 타겟팅하는 앱의 경우 Android는 다음과 같은 방법으로 ZIP 경로 순회 취약점을 방지합니다. ZIP 파일 항목 이름에 '..'가 포함되거나 '/'로 시작하면 ZipFile(String)
및 ZipInputStream.getNextEntry()
에서 ZipException
이 발생합니다.
앱은 dalvik.system.ZipPathValidator.clearCallback()
를 호출하여 이 유효성 검사를 선택 해제할 수 있습니다.
각 MediaProjection 캡처 세션에 사용자 동의가 필요합니다.
For apps targeting Android 14 (API level 34) or higher, a SecurityException
is
thrown by MediaProjection#createVirtualDisplay
in either of the following
scenarios:
- Your app caches the
Intent
that is returned fromMediaProjectionManager#createScreenCaptureIntent
, and passes it multiple times toMediaProjectionManager#getMediaProjection
. - Your app invokes
MediaProjection#createVirtualDisplay
multiple times on the sameMediaProjection
instance.
Your app must ask the user to give consent before each capture session. A single
capture session is a single invocation on
MediaProjection#createVirtualDisplay
, and each MediaProjection
instance must
be used only once.
Handle configuration changes
If your app needs to invoke MediaProjection#createVirtualDisplay
to handle
configuration changes (such as the screen orientation or screen size changing),
you can follow these steps to update the VirtualDisplay
for the existing
MediaProjection
instance:
- Invoke
VirtualDisplay#resize
with the new width and height. - Provide a new
Surface
with the new width and height toVirtualDisplay#setSurface
.
Register a callback
Your app should register a callback to handle cases where the user doesn't grant
consent to continue a capture session. To do this, implement
Callback#onStop
and have your app release any related resources (such as
the VirtualDisplay
and Surface
).
If your app doesn't register this callback,
MediaProjection#createVirtualDisplay
throws an IllegalStateException
when your app invokes it.
업데이트된 비 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.
이 Android 버전의 변경사항을 자세히 알아보려면 Android 14의 비 SDK 인터페이스 제한사항 업데이트를 참고하세요. 비 SDK 인터페이스에 관해 전반적으로 알아보려면 비 SDK 인터페이스 제한사항을 참고하세요.