Android의 앱 호환성
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Android에서 앱 호환성이라는 용어는 앱이 플랫폼의 특정 버전(일반적으로 최신 버전)에서 올바르게 실행되는 것을 의미합니다. 버전마다 개인 정보 보호와 보안을 향상하는 필수 변경사항과 OS 전반에 걸쳐 전반적인 사용자 환경을 개선하는 변경사항 구현을 포함합니다.
이러한 변경사항이 앱에 영향을 줄 수 있으므로 각 출시 버전에 포함된 동작 변경사항을 살펴보고 이를 테스트한 다음 사용자를 위해 호환성 업데이트를 게시하는 것이 중요합니다.
앱 호환성이 중요한 이유
앱 호환성은 사용자가 새 기기를 구매했거나 현재 기기에서 업데이트를 설치하여 최신 버전의 Android로 업데이트하면 즉각 영향을 미칩니다. 사용자는 최신 버전의 Android를 살펴보는 데 흥미가 있으며 좋아하는 앱에서 이를 경험해 보고 싶어 합니다. 앱이 올바르게 작동하지 않으면 앱과 개발자 모두에게 심각한 문제가 발생할 수 있습니다.
플랫폼 동작 변경사항 유형
앱은 새 플랫폼 버전에서 실행될 때 다음 두 가지 유형의 변경사항으로 영향을 받을 수 있습니다.
모든 앱의 변경사항
이러한 변경사항은 앱의 targetSdkVersion
과 관계없이 변경사항이 적용된 버전의 Android에서 실행되는 모든 앱에 영향을 줍니다.
새로운 Android 버전이 출시될 때마다 개발자 프리뷰 및 베타 버전으로 사전에 이러한 변경사항에 관해 앱 호환성을 테스트해야 합니다. Pixel 및 다른 기기의 업데이트는 새로운 Android 버전이 Android 오픈소스 프로젝트(AOSP)에 최종 버전으로 게시되는 즉시 시작되므로 이러한 변경사항을 사전에 테스트하면 사용자가 이러한 기기에서 최신 버전의 Android로 원활하게 전환하는 데 도움이 됩니다.
타겟팅된 변경사항
이러한 변경사항은 변경사항이 적용된 버전의 Android를 타겟팅하는 앱에만 영향을 미칩니다.
이러한 변경사항의 경우 안정적인 최신 API 버전에 타겟팅을 준비할 때 호환성 테스트를 실행해야 합니다. 안정화된 최신 API는 Android 16 (API 수준 36)입니다. 당장 새로운 Android 버전을 타겟팅할 계획이 없더라도 이러한 변경사항을 반영하는 데 상당한 규모의 개발이 필요할 수 있습니다. 가능한 한 이러한 변경사항을 빨리 숙지해야 합니다. 각 새로운 Android 버전의 개발자 프리뷰 및 베타 버전에서 변경사항을 반영하는 것이 가장 이상적이며 그렇게 하면 사전 테스트를 실행하고 의견을 제공할 수 있습니다.
호환성 프레임워크 도구
호환성 테스트를 돕기 위해 호환성 프레임워크의 각 버전에는 최대한 많은 브레이킹 체인지가 포함되도록 하고 있습니다. 호환성 프레임워크에 포함된 변경사항은 전환이 가능하므로 개발자 옵션 또는 ADB에서 이러한 변경사항을 개별적으로 강제 사용 설정하거나 중지할 수 있습니다. 호환성 프레임워크를 사용하면 앱의 targetSdkVersion
을 변경하거나 기본 테스트용으로 앱을 다시 컴파일할 필요가 없습니다.
자세한 내용은 앱의 플랫폼 동작 변경사항 테스트 및 디버그를 참고하세요.
비 SDK 인터페이스 제한사항
개발자들이 비 SDK API를 점차 사용하지 않도록 하기 위한 지속적인 노력의 일환으로 Google에서는 각 Android 버전의 제한된 비 SDK 인터페이스 목록을 업데이트합니다. 늘 그랬듯 여러분의 의견과 비 SDK 인터페7이스에 대응하는 공개 API 요청은 언제나 환영입니다.
최신 Android 버전에 관해 자세히 알아보세요.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-08-27(UTC)
[null,null,["최종 업데이트: 2025-08-27(UTC)"],[],[],null,["For Android, the term *app compatibility* means that your app runs properly on a\nspecific version of the platform, typically the latest version. With each\nrelease, we make integral changes that improve privacy and security, and we\nimplement changes that evolve the overall user experience across the OS.\nSometimes these changes can affect your apps, so it's important to take a look\nat the behavior changes that are included in each released version, test against\nthem, and publish compatibility updates for your users.\n\nWhy app compatibility is important\n\nApp compatibility starts to affect your users immediately when they update to\nthe latest version of Android, whether they've purchased a new device or\ninstalled an update on their current device. They're excited to explore the\nlatest version of Android, and they want to experience it with their favorite\napps. If their apps don't work properly, it can cause major issues both for them\nand for you.\n\nTypes of platform behavior changes\n\nYour app can be affected by two different types of changes when running on a new\nplatform version:\n\nChanges for all apps\n\nThese changes affect all apps that run on that version of Android, regardless of\nan app's `targetSdkVersion`.\n\nYou should test your app's compatibility with these changes proactively during\nthe developer preview and beta releases of each new Android version. Updates to\nPixel and other devices start as soon as a new Android version reaches its final\nrelease to [Android Open Source Project (AOSP)](https://source.android.com/), so when you test proactively\nfor these changes, you help ensure that your users can seamlessly transition to\nthe latest Android version on these devices.\n\nTargeted changes\n\nThese changes only affect apps that are targeting that version of Android.\n\nFor these changes, you should perform compatibility testing as you prepare to\n[target the latest stable API version](/distribute/best-practices/develop/target-sdk), which is\nAndroid 16 (API level 36). Even if you aren't planning to target a new\nAndroid version immediately, addressing these changes can require a significant\namount of development. You should learn about these changes as early as\npossible---ideally during the developer preview and beta releases of each new\nAndroid version---so you can do preliminary testing and provide feedback.\n\nCompatibility framework tools\n\nTo help you test for compatibility, we include as many of the breaking changes\nas possible each release in the compatibility framework. Including a change in\nthe compatibility framework makes it toggleable, letting you force-enable or\ndisable the changes individually from developer options or ADB. When using the\ncompatibility framework, you don't need to change your app's `targetSdkVersion`\nor recompile your app for basic testing.\n\nTo learn more, see [Test and debug platform behavior changes in your app](/guide/app-compatibility/test-debug).\n\nRestrictions on non-SDK interfaces\n\nAs part of our ongoing effort to gradually move developers away from non-SDK\nAPIs, we update the [lists of restricted non-SDK interfaces](/guide/app-compatibility/restrictions-non-sdk-interfaces) in each Android\nrelease. As always, your feedback and [requests for public API equivalents](/guide/app-compatibility/restrictions-non-sdk-interfaces#feature-request)\nare welcome.\n\nPlatform releases\n\nLearn more about the latest Android releases:\n\n- [Android 15 (API level 35)](/about/versions/15)\n- [Android 14 (API level 34)](/about/versions/14)\n- [Android 13 (API level 33)](/about/versions/13)\n- [Android 12 (API levels 31, 32)](/about/versions/12)\n- [Android 11 (API level 30)](/about/versions/11)"]]