동작 변경사항: 모든 앱

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

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

사용자 환경

오버스크롤 효과

오버스크롤 이벤트 동작이 Android 12에서 변경됩니다. 자세한 내용은 오버스크롤 효과를 참고하세요.

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

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

포그라운드 서비스에 다음 특성 중 하나 이상이 있으면 시스템에서는 서비스가 시작된 직후 연결된 알림을 표시합니다.

  • 서비스가 작업 버튼이 포함된 알림과 연결됩니다.
  • 서비스에 mediaPlayback이나 mediaProjection, phoneCallforegroundServiceType이 있습니다.
  • 서비스는 알림의 카테고리 속성에 정의된 전화 통화, 탐색 또는 미디어 재생과 관련된 사용 사례를 제공합니다.
  • 이 서비스는 알림을 설정할 때 FOREGROUND_SERVICE_IMMEDIATEsetForegroundServiceBehavior()로 전달하여 동작 변경사항을 선택 해제했습니다.

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

Android 12에서는 몰입형 모드를 간소화하여 동작 탐색이 더 쉬워지고 동영상 보기 및 책 읽기와 같은 나머지 활동 환경과의 일관성이 높아집니다. 자세한 내용은 기능 페이지에서 상응하는 항목을 참고하세요.

웹 인텐트 확인

사용자가 웹 링크를 선택할 때 더 간소화된 환경을 제공하기 위해 Android 12에서는 주어진 웹 인텐트에 승인되지 않은 도메인이 포함되어 있는 경우 사용자의 기본 브라우저에서 이 인텐트를 엽니다. 앱은 다음 방법 중 하나를 사용하여 도메인용으로 승인받을 수 있습니다.

  • Android App Links를 사용하여 도메인을 확인합니다.
  • 사용자에게 앱을 도메인과 연결하라고 요청합니다.

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

웹 인텐트 확인 변경사항 자세히 알아보기

제한된 앱 대기 버킷

앱 대기 버킷을 통해 시스템은 앱이 얼마나 최근에 얼마나 자주 사용되었는지에 따라 앱의 리소스 요청 우선순위를 지정할 수 있습니다.

각 버킷은 우선순위를 나타냅니다. 우선순위가 낮으면 시스템에서 앱 실행에 더 많은 제한을 적용합니다.

Android 12부터는 제한됨이라는 새 버킷이 있습니다. 제한됨 버킷은 모든 버킷 중에서 우선순위가 가장 낮습니다(제한사항은 가장 많음). 높은 우선순위에서 낮은 우선순위 순으로 나열된 버킷은 다음과 같습니다.

  1. 활성: 앱이 현재 사용중이거나 매우 최근에 사용되었습니다.
  2. 작업 세트: 앱이 정기적으로 사용됩니다.
  3. 자주 사용: 앱이 매일은 아니지만 자주 사용됩니다.
  4. 드물게 사용: 앱이 자주 사용되지 않습니다.
  5. 제한됨

시스템은 사용 패턴 외에도 앱의 동작을 고려하여 앱을 제한됨 버킷에 배치할지 결정합니다. 앱이 시스템 리소스를 더 책임감 있게 사용하면 제한됨 버킷에 배치될 가능성은 낮습니다.

사용자가 앱과 직접 상호작용한다면 시스템은 앱을 덜 제한적인 버킷에 배치합니다.

전력 관리 제한사항

시스템이 앱을 제한됨 버킷에 배치하면 다음 제한사항이 적용됩니다.

  • 하루에 한 번 10분 일괄 세션으로 작업을 실행할 수 있습니다. 이 세션 동안 시스템은 앱의 작업을 다른 앱의 작업과 그룹화합니다.
  • 앱은 시스템이 앱을 덜 제한적인 버킷에 배치할 때와 비교하여 신속 처리 작업을 더 적게 실행할 수 있습니다.
  • 앱의 부정확한 알람은 하루에 한 번 전송됩니다. set()setInexactRepeating(), setAndAllowWhileIdle(), setWindow() 메서드를 호출할 때 부정확한 알람을 만듭니다.
  • 앱은 시의적절한 방식으로 우선순위가 높은 Firebase 클라우드 메시징(FCM) 메시지를 하루에 5개 수신할 수 있습니다. 모든 후속 FCM 메시지는 보통 우선순위로 전송되므로 기기가 절전 모드일 경우 메시지가 지연될 수 있습니다.

포그라운드 서비스 허용

시스템이 앱을 제한됨 버킷에 배치해도 앱은 포그라운드 서비스를 계속 실행할 수 있습니다. 그러나 앱이 Android 12를 타겟팅하는 경우 여전히 포그라운드 서비스 실행 제한의 영향을 받습니다.

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

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

제한됨 버킷 동작 테스트

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

adb shell am set-standby-bucket PACKAGE_NAME restricted

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()의 경우 활동 컨텍스트의 WindowMetrics를 사용해야 합니다.

앱에서 MediaProjection을 만든다면 프로젝션이 디스플레이를 캡처하므로 경계의 크기가 올바르게 지정되어야 합니다. 앱의 크기를 완전히 조절할 수 있으면 활동 컨텍스트는 다음과 같이 올바른 경계를 반환합니다.

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

앱의 크기를 완전히 조절할 수 없으면 WindowContext 인스턴스에서 경계를 쿼리하고 WindowManager.getMaximumWindowMetrics()를 사용하여 애플리케이션에서 사용할 수 있는 최대 디스플레이 영역의 WindowMetrics를 검색해야 합니다.

Context windowContext = mContext.createWindowContext(mContext.getDisplay(),
        TYPE_APPLICATION, null /* options */);
WindowMetrics projectionMetrics = windowContext.getWindowManager()
        .getMaximumWindowMetrics();

그래픽과 이미지

새로고침 빈도 전환 개선

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);

보안 및 개인 정보 보호

마이크 및 카메라 전환

빠른 설정 타일은 &#39;카메라 액세스&#39;와 &#39;마이크 액세스&#39;로 라벨이 지정됨
그림 1. 빠른 설정에서 마이크 및 카메라 전환

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

카메라 및 마이크 전환은 기기의 모든 앱에 영향을 미칩니다.

  • 사용자가 카메라 액세스를 사용 중지하면 앱은 빈 카메라 피드를 수신합니다.
  • 사용자가 마이크 액세스를 사용 중지하면 앱은 무음 오디오를 수신합니다. 또한 HIGH_SAMPLING_RATE_SENSORS 권한 선언 여부와 관계없이 움직임 감지 센서는 속도가 제한됩니다.

사용자가 카메라나 마이크 액세스를 사용 중지한 후 카메라나 마이크 정보에 액세스해야 하는 앱을 실행하면 시스템에서는 사용자에게 기기 전체 전환 버튼이 사용 중지되었다고 알립니다.

주어진 기기에서 마이크 및 카메라 전환을 지원하는지 확인

기기에서 마이크 및 카메라 전환을 지원하는지 확인하려면 다음 코드 스니펫에 표시되는 로직을 추가하세요.

Kotlin

val sensorPrivacyManager = applicationContext
        .getSystemService(SensorPrivacyManager::class.java)
        as SensorPrivacyManager
val supportsMicrophoneToggle = sensorPrivacyManager
        .supportsSensorToggle(Sensors.MICROPHONE)
val supportsCameraToggle = sensorPrivacyManager
        .supportsSensorToggle(Sensors.CAMERA)

자바

SensorPrivacyManager sensorPrivacyManager = getApplicationContext()
        .getSystemService(SensorPrivacyManager.class);
boolean supportsMicrophoneToggle = sensorPrivacyManager
        .supportsSensorToggle(Sensors.MICROPHONE);
boolean supportsCameraToggle = sensorPrivacyManager
        .supportsSensorToggle(Sensors.CAMERA);

마이크 및 카메라 전환에 대응하는 앱 동작 확인

마이크 및 카메라 전환은 개발자가 Android 권한 권장사항을 준수하는 한 앱이 CAMERARECORD_AUDIO 권한을 처리하는 방식에 영향을 미쳐서는 안 됩니다.

특히 앱은 다음 작업을 실행해야 합니다.

  • 사용자가 앱에 CAMERA 권한을 부여할 때까지 기기의 카메라에 액세스하는 것을 기다립니다.
  • 사용자가 앱에 RECORD_AUDIO 권한을 부여할 때까지 기기의 마이크에 액세스하는 것을 기다립니다.

마이크 및 카메라 표시기

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

Android 12를 실행하는 기기에서는 앱이 마이크나 카메라에 액세스할 때 상태 표시줄에 아이콘이 표시됩니다. 앱이 몰입형 모드이면 아이콘은 화면 오른쪽 상단에 표시됩니다. 사용자는 빠른 설정을 열고 아이콘을 선택하여 현재 마이크나 카메라를 사용하는 앱을 확인할 수 있습니다. 그림 2는 아이콘이 포함된 스크린샷을 보여주는 예입니다.

더 나은 사용자 환경을 제공하려면 사용자가 앱에 명시적으로 권한을 부여할 때까지 마이크나 카메라에 액세스하지 마세요.

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

앱 및 시스템과 상호작용할 때 사용자 제어를 개선하기 위해 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 11 이하를 타겟팅합니다. 또한 사용자가 알림의 작업 버튼을 사용하여 알림과 상호작용했으며 앱은 사용자 작업에 응답하여 서비스broadcast receiver를 처리하고 있습니다.

  • 앱이 Android 11 이하를 타겟팅하고 활성 접근성 서비스를 보유합니다. 앱이 Android 12를 타겟팅하고 알림바를 닫으려는 경우 대신 GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE 접근성 작업을 사용하세요.

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

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

영향을 받은 앱

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

예외

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

  • 앱 내 상호작용. 앱에서 오버레이를 표시하면 오버레이는 사용자가 앱과 상호작용할 때만 표시됩니다.
  • 신뢰할 수 있는 창. 이러한 창에는 다음이 포함되지만 이에 국한되지 않습니다.

  • 표시되지 않는 창. 창의 루트 뷰가 GONE 또는 INVISIBLE입니다.

  • 완전히 투명한 창. 창의 alpha 속성이 0.0입니다.

  • 충분한 반투명 시스템 알림 창. 시스템은 결합된 불투명도가 시스템의 최대 터치 불투명도보다 작거나 같을 때 일련의 시스템 알림 창이 충분히 반투명하다고 간주합니다. Android 12 베타에서는 이 최대 불투명도가 0.8입니다. 이 값은 향후 베타 출시에서 변경될 수 있습니다.

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

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

Untrusted touch due to occlusion by PACKAGE_NAME

변경사항 테스트

신뢰할 수 없는 터치는 Android 12 개발자 프리뷰 3을 실행하는 기기에서 기본적으로 차단됩니다. 신뢰할 수 없는 터치를 허용하려면 터미널 창에서 다음 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 11(API 수준 30) 이상을 타겟팅하고 다음 메서드 중 하나를 호출하는 앱은 다른 앱에 관한 앱의 패키지 공개 상태에 기반하여 필터링된 결과 세트를 수신합니다.

Bouncy Castle 구현이 삭제됨

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()을 호출하여 다른 앱의 ClipData에 처음 액세스할 때 토스트 메시지가 사용자에게 이 클립보드 액세스를 알립니다.

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

클립 설명을 검색할 때 메시지가 표시되지 않음

앱은 getPrimaryClipDescription()을 호출하여 클립보드에 있는 현재 데이터에 관한 정보를 수신할 수도 있습니다. 앱에서 이 메서드를 호출할 때 시스템에서는 토스트 메시지를 표시하지 않습니다.

Android 12는 이 메서드를 개선하여 다음 추가 세부정보를 감지합니다.

연결성

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 프로필을 설명합니다.

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

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

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

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

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