이 페이지는 Cloud Translation API를 통해 번역되었습니다.

동작 변경사항: 모든 앱

Android 12 플랫폼에는 앱에 영향을 줄 수 있는 동작 변경사항이 있습니다. targetSdkVersion과 관계없이 Android 12에서 실행되는 모든 앱에 적용되는 동작 변경사항은 다음과 같습니다. 이러한 변경사항을 적절히 지원해야 하는 경우 앱을 테스트한 후 필요에 따라 수정해야 합니다.

또한 Android 12를 타겟팅하는 앱에만 영향을 주는 동작 변경사항 목록을 검토해야 합니다.

사용자 환경

스트레치 오버스크롤 효과

Android 12 이상을 실행하는 기기에서 오버스크롤 이벤트의 시각적 동작이 변경됩니다.

Android 11 이하에서 오버스크롤 이벤트는 시각적 요소에 발광 효과가 나도록 합니다. Android 12 이상에서는 시각적 요소가 드래그 이벤트에 늘어났다가 다시 돌아오고 플링 이벤트에 플링되었다가 다시 돌아옵니다.

자세한 내용은 스크롤 동작 애니메이션 가이드를 참고하세요.

앱 스플래시 화면

이전에 Android 11 이하에서 맞춤 스플래시 화면을 구현한 경우 SplashScreen API로 앱을 이전하여 Android 12부터 올바르게 표시되도록 해야 합니다. 앱을 이전하지 않으면 앱 실행 환경이 저하되거나 의도치 않게 진행됩니다.

자세한 내용은 기존 스플래시 화면 구현을 Android 12로 이전을 참고하세요.

또한 Android 12부터 시스템은 항상 모든 앱의 콜드 및 웜 스타트 시 새로운 Android 시스템 기본값 스플래시 화면을 적용합니다. 기본적으로 이 시스템 기본값 스플래시 화면은 앱의 런처 아이콘 요소 및 테마의 windowBackground(단일 색상인 경우)를 사용하여 구성됩니다.

자세한 내용은 스플래시 화면 개발자 가이드를 참고하세요.

웹 인텐트 확인

Android 12(API 수준 31)부터 일반 웹 인텐트는 앱이 웹 인텐트에 포함된 특정 도메인에 관해 승인된 경우에만 앱의 활동으로 확인됩니다. 앱이 도메인에 관해 승인되지 않으면 웹 인텐트는 대신 사용자의 기본 브라우저 앱으로 확인됩니다.

앱은 다음 중 하나를 실행하여 이 승인을 받을 수 있습니다.

Android App Links를 사용하여 도메인을 확인합니다.

Android 12 이상을 타겟팅하는 앱에서 시스템은 앱의 Android App Links를 자동으로 확인하는 방법을 변경합니다. 앱의 인텐트 필터에서 BROWSABLE 카테고리를 포함하고 https 체계를 지원하는지 확인합니다.

Android 12 이상에서는 앱의 Android App Links를 수동으로 확인하여 이 업데이트된 로직이 앱에 미치는 영향을 테스트할 수 있습니다.
시스템 설정에서 앱을 도메인과 연결하라고 사용자에게 요청합니다.

앱에서 웹 인텐트를 호출하면 사용자에게 작업 확인을 요청하는 메시지나 대화상자를 추가하는 것이 좋습니다.

동작 탐색을 위한 몰입형 모드 개선사항

Android 12에서는 사용자가 몰입형 모드에서 동작 탐색 명령어를 더 쉽게 실행하도록 기존 동작을 통합합니다. 또한 Android 12는 고정 몰입형 모드를 위한 이전 버전과의 호환성 동작을 제공합니다.

Display#getRealSize 및 getRealMetrics: 지원 중단 및 제약 조건

Android 기기는 큰 화면, 태블릿, 폴더블과 같은 매우 다양한 폼 팩터로 제공됩니다. 콘텐츠를 각 기기에 맞게 렌더링하려면 앱은 화면이나 디스플레이 크기를 결정해야 합니다. 오랜 시간 동안 Android는 이 정보를 검색하는 다양한 API를 제공했습니다. Android 11에서는 WindowMetrics API를 도입하고 다음 메서드를 지원 중단했습니다.

Android 12에서는 WindowMetrics 사용을 계속 권장하면서 다음 메서드를 지원 중단합니다.

Display API를 사용하여 애플리케이션의 경계를 검색하는 애플리케이션의 동작을 완화하기 위해 Android 12에서는 완전히 크기를 조절할 수 없는 앱의 API에서 반환된 값을 제한합니다. 이는 MediaProjection과 함께 이 정보를 사용하는 앱에 영향을 미칠 수 있습니다.

앱은 WindowMetrics API를 사용하여 창 경계를 쿼리하고 Configuration.densityDpi를 사용하여 현재 밀도를 쿼리해야 합니다.

Android 이전 버전과의 호환성을 높이려면 Android 4.0(API 수준 14) 이상을 지원하는 WindowMetrics 클래스가 포함된 Jetpack WindowManager 라이브러리를 사용하면 됩니다.

WindowMetrics 사용 방법 예

먼저 앱 활동의 크기를 완전히 조절할 수 있는지 확인합니다.

활동은 모든 UI 관련 작업, 특히 WindowManager.getCurrentWindowMetrics() 또는 Jetpack의 WindowMetricsCalculator.computeCurrentWindowMetrics()의 경우 활동 컨텍스트의 WindowMetrics를 사용해야 합니다.

앱에서 MediaProjection을 만든다면 프로젝터 앱이 실행되는 디스플레이 파티션을 프로젝션이 캡처하므로 경계의 크기가 올바르게 지정되어야 합니다.

앱의 크기를 완전히 조절할 수 있으면 활동 컨텍스트는 다음과 같이 올바른 경계를 반환합니다.

Kotlin

val projectionMetrics: WindowMetrics = activityContext
      .getSystemService(WindowManager::class.java).maximumWindowMetrics

자바

WindowMetrics projectionMetrics = activityContext
      .getSystemService(WindowManager.class).getMaximumWindowMetrics();

앱의 크기를 완전히 조절할 수 없으면 WindowContext 인스턴스에서 쿼리하고 WindowManager.getMaximumWindowMetrics() 또는 Jetpack 메서드 WindowMetricsCalculator.computeMaximumWindowMetrics()를 사용하여 활동 경계의 WindowMetrics를 검색해야 합니다.

Kotlin

val windowContext = context.createWindowContext(mContext.display!!,
      WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
      .maximumWindowMetrics

자바

Context windowContext = context.createWindowContext(mContext.getDisplay(),
      WindowManager.LayoutParams.TYPE_APPLICATION, null);
WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class)
      .getMaximumWindowMetrics();

멀티 윈도우 모드의 모든 앱

Android 12는 멀티 윈도우 모드를 표준 동작으로 설정합니다.

큰 화면(sw 600dp 이상)에서 플랫폼은 앱 구성과 관계없이 멀티 윈도우 모드의 모든 앱을 지원합니다. resizeableActivity="false"인 경우 디스플레이 크기를 수용하기 위해 필요한 경우 앱이 호환성 모드로 전환됩니다.

작은 화면(sw 600dp 미만)에서 시스템은 활동의 minWidth 및 minHeight를 확인하여 활동이 멀티 윈도우 모드에서 실행될 수 있는지 판단합니다. resizeableActivity="false"인 경우 앱은 최소 너비 및 높이와 상관없이 멀티 윈도우 모드에서 실행되지 않습니다.

자세한 내용은 멀티 윈도우 지원을 참고하세요.

대형 화면에서 카메라 미리보기

카메라 앱은 일반적으로 기기의 방향과 카메라 미리보기의 가로세로 비율 사이에 고정된 관계를 가정합니다. 그러나 폴더블 기기와 같은 대형 화면 폼 팩터와 멀티 윈도우 및 다중 디스플레이와 같은 디스플레이 모드는 이러한 가정을 어렵게 합니다.

Android 12에서는 특정 화면 방향을 요청하고 크기를 조절할 수 없는(resizeableActivity="false") 카메라 앱이 인셋 세로 모드로 자동 전환됩니다. 따라서 카메라 미리보기의 적절한 방향과 가로세로 비율을 보장합니다. 카메라 하드웨어 추상화 계층(HAL)이 있는 폴더블 및 기타 기기에서는 추가 회전이 카메라 출력에 적용되어 카메라 센서 방향을 보정하고 카메라 출력은 앱의 카메라 미리보기 가로세로 비율에 맞게 잘립니다. 자르기와 추가 회전을 통해 기기의 방향과 기기의 접힌 상태나 펼쳐진 상태와 관계없이 카메라 미리보기를 적절하게 표시할 수 있습니다.

포그라운드 서비스 알림의 UX 지연

단기 실행 포그라운드 서비스에 간소화된 환경을 제공하기 위해 Android 12 이상을 실행하는 기기에서는 예외 몇 가지를 제외하고 포그라운드 서비스 알림 표시를 10초 지연시킬 수 있습니다. 이 변경사항으로 알림이 표시되기 전에 단기 실행 작업이 완료될 수 있습니다.

성능

제한된 앱 대기 버킷

Android 11(API 수준 30)에서는 제한됨 버킷을 앱 대기 버킷으로 도입했습니다. Android 12부터 이 버킷은 기본적으로 활성화되어 있습니다. 제한됨 버킷은 모든 버킷 중에서 우선순위가 가장 낮습니다(제한사항은 가장 많음). 높은 우선순위에서 낮은 우선순위 순으로 나열된 버킷은 다음과 같습니다.

활성: 앱이 현재 사용 중이거나 매우 최근에 사용되었습니다.
작업 세트: 앱이 정기적으로 사용됩니다.
자주 사용: 앱이 매일은 아니지만 자주 사용됩니다.
드물게 사용: 앱이 자주 사용되지 않습니다.
제한됨: 앱이 시스템 리소스를 많이 소비하거나 원하지 않는 동작을 보일 수 있습니다.

시스템은 사용 패턴 외에도 앱의 동작을 고려하여 앱을 제한됨 버킷에 배치할지 결정합니다.

앱이 시스템 리소스를 더 책임감 있게 사용하면 제한됨 버킷에 배치될 가능성은 낮습니다. 사용자가 앱과 직접 상호작용한다면 시스템은 앱을 덜 제한적인 버킷에 배치합니다.

앱이 제한됨 버킷에 있는지 확인

시스템이 앱을 제한됨 버킷에 배치했는지 확인하려면 getAppStandbyBucket()을 호출합니다. 이 메서드의 반환 값이 STANDBY_BUCKET_RESTRICTED이면 앱은 제한됨 버킷에 있는 것입니다.

제한됨 버킷 동작 테스트

시스템이 앱을 제한됨 버킷에 배치할 때 앱이 어떻게 동작하는지 테스트하려면 수동으로 앱을 제한됨 버킷으로 이동하면 됩니다. 이렇게 하려면 터미널 창에서 다음 명령어를 실행하세요.

adb shell am set-standby-bucket PACKAGE_NAME restricted

보안 및 개인 정보 보호

대략적인 위치

두 가지 옵션 세트가 세로로 배치된 대화상자 — **그림 1.** 사용자가 대략적인 위치 정보를 알려줄 수 있는 시스템 권한 대화상자

Android 12 이상을 실행하는 기기에서는 앱이 대략적인 위치 정보에만 액세스하도록 사용자가 요청할 수 있습니다.

앱이 ACCESS_FINE_LOCATION 런타임 권한을 요청하는 경우 ACCESS_COARSE_LOCATION 권한도 요청하여 사용자가 앱에 대략적인 위치 액세스 권한을 부여하는 사례도 처리해야 합니다. 이 두 권한은 모두 하나의 런타임 요청에 포함되어야 합니다.

그림 1과 같이 시스템 권한 대화상자에는 사용자를 위한 다음 옵션이 포함되어 있습니다.

정확한 위치: 정확한 위치 정보에 액세스할 수 있습니다.
대략적인 위치: 대략적인 위치 정보에만 액세스할 수 있습니다.

마이크 및 카메라 전환

Android 12 이상을 실행하는 지원 기기에서 사용자는 단일 전환 옵션을 눌러 기기의 모든 앱에 카메라 및 마이크 액세스를 사용 설정하거나 사용 중지할 수 있습니다. 사용자는 그림 1과 같이 빠른 설정에서 또는 시스템 설정의 개인 정보 보호 화면에서 전환 가능한 옵션에 액세스할 수 있습니다.

이러한 전환과 앱이 CAMERA 및 RECORD_AUDIO 권한과 관련하여 권장사항을 따르는지 확인하는 방법을 자세히 알아보세요.

마이크 및 카메라 표시기

Android 12 이상을 실행하는 기기에서는 앱이 마이크나 카메라에 액세스할 때 상태 표시줄에 아이콘이 표시됩니다.

이러한 표시기와 앱이 CAMERA 및 RECORD_AUDIO 권한과 관련하여 권장사항을 따르는지 확인하는 방법을 자세히 알아보세요.

빠른 설정 타일은 '카메라 액세스'와 '마이크 액세스'로 라벨이 지정됨 — **그림 2.** 빠른 설정에서 마이크 및 카메라 전환

카메라 아이콘과 마이크 아이콘이 포함된 오른쪽 상단의 모서리가 둥근 직사각형 — **그림 3.** 최근 데이터 액세스를 보여주는 마이크 및 카메라 표시기

권한 패키지 공개 상태

Android 12 이상을 실행하는 기기에서 Android 11(API 수준 30) 이상을 타겟팅하고 다음 메서드 중 하나를 호출하는 앱은 다른 앱에 관한 앱의 패키지 공개 상태에 기반하여 필터링된 결과 세트를 수신합니다.

BouncyCastle 구현이 삭제됨

Android 12에서는 모든 AES 알고리즘을 비롯하여 이전에 지원 중단된 암호화 알고리즘의 여러 BouncyCastle 구현을 삭제합니다. 시스템은 대신 이러한 알고리즘의 Conscrypt 구현을 사용합니다.

이러한 변경사항은 다음 항목 중 하나라도 맞다면 앱에 영향을 미칩니다.

앱이 512비트 키 크기를 사용합니다. Conscrypt는 이 키 크기를 지원하지 않습니다. 필요하다면 다른 키 크기를 사용하도록 앱의 암호화 로직을 업데이트하세요.
앱이 KeyGenerator에 잘못된 키 크기를 사용합니다. Conscrypt의 KeyGenerator 구현은 BouncyCastle과 비교하여 키 매개변수에서 추가 검증을 실행합니다. 예를 들어 Conscrypt는 앱이 64비트 AES 키를 생성하도록 허용하지 않습니다. AES가 128비트, 192비트, 256비트 키만 지원하기 때문입니다.

BouncyCastle을 사용하면 잘못된 크기의 키를 생성할 수 있지만 이러한 키를 Cipher와 함께 사용하면 나중에 실패합니다. Conscrypt가 더 일찍 실패합니다.
12바이트 이외의 크기를 사용하여 Galois/Counter Mode(GCM) 암호화를 초기화합니다. Conscrypt의 GcmParameterSpec 구현에는 NIST에서 권장하는 12바이트 초기화가 필요합니다.

클립보드 액세스 알림

Android 12 이상에서는 앱이 getPrimaryClip()을 호출하여 처음으로 다른 앱의 클립 데이터에 액세스할 때 토스트 메시지가 사용자에게 이 클립보드 액세스를 알립니다.

토스트 메시지 안의 텍스트에는 다음 형식이 포함되어 있습니다. APP pasted from your clipboard.

클립 설명의 텍스트 정보

Android 12 이상에서는 getPrimaryClipDescription()이 다음 세부정보를 감지할 수 있습니다.

스타일이 지정된 텍스트(isStyledText() 사용)
URL과 같은 다양한 텍스트 분류(getConfidenceScore() 사용)

앱이 시스템 대화상자를 닫을 수 없음

앱 및 시스템과 상호작용할 때 사용자 제어를 개선하기 위해 Android 12부터 ACTION_CLOSE_SYSTEM_DIALOGS 인텐트 작업이 지원 중단됩니다. 특수한 사례를 제외하고 앱이 이 작업이 포함된 인텐트를 호출하려고 하면 시스템은 앱의 타겟 SDK 버전에 따라 다음 중 하나를 실행합니다.

앱에서 Android 12 이상을 타겟팅하면 SecurityException이 발생합니다.

앱이 Android 11(API 수준 30) 이하를 타겟팅하면 인텐트가 실행되지 않고 다음 메시지가 Logcat에 표시됩니다.

E ActivityTaskManager Permission Denial: \
android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \
com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \
dropping broadcast.

예외

다음과 같은 경우 앱은 여전히 Android 12 이상에서 시스템 대화상자를 닫을 수 있습니다.

앱이 계측 테스트를 실행 중입니다.
앱이 Android 11 이하를 타겟팅하고 알림 창 위에 있는 창을 표시합니다.

참고: 앱이 Android 12를 타겟팅하는 경우 이 상황에서 ACTION_CLOSE_SYSTEM_DIALOGS를 사용하지 않아도 됩니다. 이유는 창이 알림 창 위에 있는 동안 앱에서 startActivity()를 호출하면 시스템에서 자동으로 알림 창을 닫기 때문입니다.
앱이 Android 11 이하를 타겟팅합니다. 또한 사용자가 알림의 작업 버튼을 사용하여 알림과 상호작용했으며 앱은 사용자 작업에 응답하여 서비스나 broadcast receiver를 처리하고 있습니다.
앱이 Android 11 이하를 타겟팅하고 활성 접근성 서비스를 보유합니다. 앱이 Android 12를 타겟팅하고 알림바를 닫으려는 경우 대신 GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE 접근성 작업을 사용하세요.

신뢰할 수 없는 터치 이벤트가 차단됨

시스템 보안 및 우수한 사용자 환경을 유지하기 위해 Android 12에서는 오버레이가 안전하지 않은 방식으로 앱을 가리는 터치 이벤트를 앱에서 사용하지 못하도록 합니다. 즉, 시스템은 몇 가지 예외를 제외하고 특정 창을 통과하는 터치를 차단합니다.

영향을 받은 앱

이 변경사항은 FLAG_NOT_TOUCHABLE 플래그 등을 사용하여 터치가 창을 통과할 수 있도록 하는 앱에 영향을 줍니다. 이러한 예에는 다음이 포함되나 이에 국한되지 않습니다.

TYPE_APPLICATION_OVERLAY를 사용하고 FLAG_NOT_TOUCHABLE 플래그를 사용하는 창과 같은 SYSTEM_ALERT_WINDOW 권한이 필요한 오버레이
FLAG_NOT_TOUCHABLE 플래그를 사용하는 활동 창

예외

다음과 같은 경우에는 '패스 스루' 터치가 허용됩니다.

앱 내 상호작용. 앱에서 오버레이를 표시하면 오버레이는 사용자가 앱과 상호작용할 때만 표시됩니다.
신뢰할 수 있는 창. 이러한 창에는 다음이 포함되지만 이에 국한되지 않습니다.
참고: TYPE_APPLICATION_OVERLAY 유형의 창은 신뢰할 수 없습니다.
표시되지 않는 창. 창의 루트 뷰가 GONE 또는 INVISIBLE입니다.
완전히 투명한 창. 창의 alpha 속성이 0.0입니다.
충분한 반투명 시스템 알림 창. 시스템은 결합된 불투명도가 시스템의 최대 터치 불투명도보다 작거나 같을 때 일련의 시스템 알림 창이 충분히 반투명하다고 간주합니다. Android 12에서 이 최대 불투명도는 기본적으로 0.8입니다.

신뢰할 수 없는 터치가 차단된 경우 감지

터치 작업을 시스템에서 차단하면 Logcat에서는 다음 메시지를 기록합니다.

Untrusted touch due to occlusion by PACKAGE_NAME

변경사항 테스트

신뢰할 수 없는 터치는 Android 12 이상을 실행하는 기기에서 기본적으로 차단됩니다. 신뢰할 수 없는 터치를 허용하려면 터미널 창에서 다음 ADB 명령어를 실행합니다.

# A specific app
adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
# If you'd still like to see a Logcat message warning when a touch would be
# blocked, use 1 instead of 0.
adb shell settings put global block_untrusted_touches 0

이 동작을 기본값(신뢰할 수 없는 터치가 차단됨)으로 되돌리려면 다음 명령어를 실행합니다.

# A specific app
adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
adb shell settings put global block_untrusted_touches 2

활동 수명 주기

루트 런처 활동이 뒤로 누르기에서 더 이상 완료되지 않음

Android 12에서는 작업의 루트에 있는 런처 활동에서 시스템 뒤로 누르기의 기본 처리를 변경합니다. 이전 버전에서는 시스템이 뒤로 누르기에서 이러한 활동을 완료했습니다. Android 12에서는 이제 시스템이 활동을 완료하는 대신 활동과 그 작업을 백그라운드로 이동합니다. 새로운 동작은 홈 버튼이나 동작을 사용하여 앱 외부로 이동할 때 현재 동작과 일치합니다.

대부분의 앱에서 이 변경사항으로 인해 뒤로를 사용하여 앱 외부로 이동하는 사용자는 콜드 상태에서 앱을 완전히 다시 시작할 필요 없이 웜 상태에서 더 빠르게 앱을 다시 시작할 수 있습니다.

이 변경사항으로 앱을 테스트하는 것이 좋습니다. 앱이 현재 onBackPressed()를 재정의하여 뒤로 탐색을 처리하고 Activity를 완료한다면 완료하는 대신 super.onBackPressed()를 호출하도록 구현을 업데이트합니다. super.onBackPressed()를 호출하면 적절한 경우 활동과 그 작업을 백그라운드로 이동하고 앱 전체에서 사용자에게 더 일관된 탐색 환경을 제공합니다.

또한 일반적으로 onBackPressed()를 재정의하는 대신 맞춤 뒤로 탐색을 제공하는 AndroidX Activity API를 사용하는 것이 좋습니다. AndroidX Activity API는 시스템 뒤로 누르기를 가로채는 구성요소가 없으면 자동으로 적절한 시스템 동작을 따릅니다.

그래픽과 이미지

새로고침 빈도 전환 개선

Android 12에서는 디스플레이에서 새로운 새로고침 빈도로의 원활한 전환을 지원하는지와 상관없이 setFrameRate()를 사용하여 새로고침 빈도가 변경될 수 있습니다. 원활한 전환은 1~2초 동안 검은색 화면이표시되는 것과 같은 시각적인 방해가 없는 전환입니다. 이전에는 디스플레이에서 원활한 전환을 지원하지 않으면 일반적으로 setFrameRate()가 호출된 후 같은 새로고침 빈도를 계속 사용했습니다. getAlternativeRefreshRates()를 호출하여 새로운 새로고침으로의 전환이 원활할지 미리 판단할 수 있습니다. 일반적으로 onDisplayChanged() 콜백은 새로고침 빈도 전환이 완료된 후 호출되지만 외부에 연결된 일부 디스플레이의 경우 원활하지 않은 전환 중에 호출됩니다.

다음은 이를 구현할 수 있는 방법을 보여주는 예입니다.

Kotlin

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
val refreshRates = this.display?.mode?.alternativeRefreshRates
val willBeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate)

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)

자바

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
Display display = context.getDisplay(); // API 30+
Display.Mode mode = display.getMode();
float[] refreshRates = mode.getAlternativeRefreshRates();
boolean willBeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate);

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);

연결성

Passpoint 업데이트

다음 API가 Android 12에 추가됩니다.

isPasspointTermsAndConditionsSupported(): 이용약관은 네트워크 배포에서 개방형 네트워크를 사용하는 안전하지 않은 종속 포털을 안전한 Passpoint 네트워크로 대체할 수 있는 Passpoint 기능입니다. 이용약관에 동의해야 하는 경우 사용자에게 알림이 표시됩니다. 이용약관으로 관리되는 Passpoint 네트워크를 제안하는 앱은 먼저 이 API를 호출하여 기기에서 이 기능을 지원하는지 확인해야 합니다. 기기에서 이 기능을 지원하지 않으면 이 네트워크에 연결할 수 없고 대체 네트워크나 기존 네트워크를 제안해야 합니다.
isDecoratedIdentitySupported(): 접두사 장식이 있는 네트워크에 인증할 때 장식된 ID 접두사를 사용하면 네트워크 운영자가 네트워크 액세스 식별자(NAI)를 업데이트하여 AAA 네트워크 내부의 여러 프록시를 통해 명시적 라우팅을 실행할 수 있습니다(자세한 내용은 RFC 7542 참고).

Android 12는 이 기능을 구현하여 PPS-MO 확장을 위한 WBA 사양을 준수합니다. 장식된 ID가 필요한 Passpoint 네트워크를 제안하는 앱은 먼저 이 API를 호출하여 기기에서 이 기능을 지원하는지 확인해야 합니다. 기기에서 이 기능을 지원하지 않으면 ID가 장식되지 않고 네트워크 인증이 실패할 수 있습니다.

Passpoint 제안을 만들려면 앱에서 PasspointConfiguration, Credential, HomeSp 클래스를 사용해야 합니다. 이러한 클래스는 Wi-Fi Alliance Passpoint 사양에 정의된 Passpoint 프로필을 설명합니다.

자세한 내용은 인터넷 연결을 위한 Wi-Fi 추천 API를 참고하세요.

비 SDK 인터페이스 제한사항 업데이트

Android 12에는 Android 개발자와의 공동작업 및 최신 내부 테스트를 기반으로 제한된 비 SDK 인터페이스의 업데이트된 목록이 포함되어 있습니다. 가능하면 Google은 비 SDK 인터페이스를 제한하기 전에 공개 대안을 사용할 수 있게 합니다.

Android 12를 타겟팅하지 않는 앱의 경우 이러한 변경사항 중 일부는 개발자에게 곧바로 영향을 주지 않을 수도 있습니다. 그러나 앱의 대상 API 수준에 따라 현재 일부 비 SDK 인터페이스를 사용할 수 있지만 비 SDK 메서드 또는 필드를 사용하면 언제든지 앱이 중단될 위험이 있습니다.

앱에서 비 SDK 인터페이스를 사용하는지 확실히 알 수 없는 경우 앱을 테스트하여 확인할 수 있습니다. 앱에서 비 SDK 인터페이스를 사용하는 경우 대체 SDK로의 이전을 계획해야 합니다. 일부 앱의 경우 비 SDK 인터페이스 사용에 관한 유효한 사용 사례가 있음을 알고 있습니다. 앱 기능을 구현하기 위해 비 SDK 인터페이스 대신 무엇을 사용해야 할지 알 수 없다면 새 공개 API를 요청해야 합니다.

이 Android 버전의 변경사항을 자세히 알아보려면 Android 12의 비 SDK 인터페이스 제한사항 업데이트를 참고하세요. 비 SDK 인터페이스에 관해 전반적으로 알아보려면 비 SDK 인터페이스 제한사항을 참고하세요.