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

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

Android 13에서 실행되는 모든 앱에 영향을 주는 동작 변경사항의 목록도 검토하시기 바랍니다.

개인 정보 보호

알림 권한이 포그라운드 서비스 모양에 영향을 줌

사용자가 알림 권한을 거부하면 알림 창에서 포그라운드 서비스와 관련된 알림을 볼 수 없습니다. 그러나 알림 권한 부여 여부와 관계없이 작업 관리자에서 포그라운드 서비스와 관련된 알림이 계속 표시됩니다.

근처 Wi-Fi 기기의 새 런타임 권한

이전 버전의 Android에서는 사용자가 앱에 여러 일반적인 Wi-Fi 사용 사례를 완료할 수 있는 ACCESS_FINE_LOCATION 권한을 부여해야 합니다.

사용자가 위치 정보 액세스 권한을 Wi-Fi 기능과 연결하기는 어려우므로 Android 13(API 수준 33)에서는 Wi-Fi를 통해 근처 액세스 포인트에 대한 기기의 연결을 관리하는 앱을 위해 NEARBY_DEVICES 권한 그룹의 런타임 권한을 도입했습니다. 이 권한 NEARBY_WIFI_DEVICES는 다음과 같은 Wi-Fi 사용 사례를 처리합니다.

• 프린터나 미디어 전송 기기와 같은 근처 기기를 찾거나 기기에 연결합니다. 이 워크플로를 통해 앱은 다음과 같은 작업을 할 수 있습니다.
  • BLE 등을 통해 대역 외 AP 정보를 수신합니다.
  • 로컬 전용 핫스팟을 사용하는 Wi-Fi Aware 및 Connect를 통해 기기를 검색하여 연결합니다.
  • Wi-Fi Direct를 통해 기기를 검색하여 연결합니다.
• 자동차나 스마트 홈 기기와 같이 알려진 SSID에 연결을 시작합니다.
• 로컬 전용 핫스팟을 시작합니다.
• 근처 Wi-Fi Aware 기기까지 다양한 기기를 지원합니다.

Android 13 이상을 타겟팅하고 Wi-Fi API를 사용하는 경우에는 ACCESS_FINE_LOCATION 대신 NEARBY_WIFI_DEVICES를 요청하세요(앱이 Wi-Fi API에서 물리적 위치 정보를 얻는 것이 아니어야 함). NEARBY_WIFI_DEVICES 권한을 선언할 때 앱이 Wi-Fi API에서 물리적 위치 정보를 얻지 않는다고 강력하게 어설션합니다. 이렇게 하려면 android:usesPermissionFlags 속성을 neverForLocation으로 설정합니다. 이 프로세스는 Android 12(API 수준 31)에서 블루투스 기기 정보가 위치에 사용되지 않는다고 어설션할 때 실행하는 프로세스와 유사합니다.

근처 Wi-Fi 기기에 대한 액세스 권한을 요청하는 방법을 자세히 알아보세요.

세분화된 미디어 권한

앱이 Android 13 이상을 타겟팅하고 다른 앱에서 만든 미디어 파일에 액세스해야 하는 경우 READ_EXTERNAL_STORAGE 권한 대신 다음과 같은 세분화된 미디어 권한을 하나 이상 요청해야 합니다.

다른 앱의 미디어 파일에 액세스하기 전에 사용자가 앱에 적절한 세분화된 미디어 권한을 부여했는지 확인합니다.

그림 1은 READ_MEDIA_AUDIO 권한을 요청하는 앱을 보여줍니다.

READ_MEDIA_IMAGES 권한과 READ_MEDIA_VIDEO 권한을 동시에 모두 요청하면 시스템 권한 대화상자가 하나만 표시됩니다.

이전에 앱에 READ_EXTERNAL_STORAGE 권한이 부여되었다면 업그레이드 시 요청된 READ_MEDIA_* 권한이 자동으로 부여됩니다. 다음 ADB 명령어를 사용하여 업그레이드된 권한을 검토할 수 있습니다.

adb shell cmd appops get --uid PACKAGE_NAME

백그라운드에서 생체 신호 센서를 사용하려면 새로운 권한이 필요함

Android 13에서는 심박수, 체온, 혈중 산소 농도와 같은 생체 신호 센서에 '사용 중인 동안' 액세스라는 개념이 도입되었습니다. 이 액세스 모델은 Android 10 (API 수준 29)의 위치에 도입되었던 액세스 모델과 매우 유사합니다.

앱이 Android 13을 타겟팅하며 백그라운드에서 실행되는 동안 생체 신호 센서 정보에 액세스해야 하는 경우, 기존 BODY_SENSORS 권한에 더해 새로운 BODY_SENSORS_BACKGROUND 권한을 선언해야 합니다.

성능 및 배터리

배터리 리소스 사용률

앱이 Android 13을 타겟팅하는 동안 앱을 백그라운드 배터리 사용량에 관해 '제한됨' 상태로 설정하면 시스템은 다른 이유로 앱이 시작되기 전까지는 BOOT_COMPLETED 브로드캐스트 또는 LOCKED_BOOT_COMPLETED 브로드캐스트를 전달하지 않습니다.

사용자 환경

PlaybackState에서 파생된 미디어 컨트롤

Android 13(API 수준 33) 이상을 타겟팅하는 앱의 경우 시스템은 PlaybackState 작업에서 미디어 컨트롤을 가져옵니다. 이를 통해 시스템은 스마트폰과 태블릿 기기 사이에 기술적으로 일관된 더 풍부한 컨트롤 세트를 표시할 수 있고, Android Auto 및 Android TV와 같은 다른 Android 플랫폼에서 미디어 컨트롤이 렌더링되는 방식과도 일치시킬 수 있게 됩니다.

그림 2는 스마트폰과 태블릿 기기에서 각각 어떻게 표시되는지 보여줍니다.

Android 13 전에는 시스템이 MediaStyle 알림에서 작업이 추가된 순서대로 최대 5개의 작업을 표시했습니다. 압축 모드(예: 축소된 빠른 설정)에서는 setShowActionsInCompactView()로 지정된 작업이 최대 3개까지 표시되었습니다.

Android 13부터 시스템은 다음 표에 설명된 대로 PlaybackState를 기반으로 작업 버튼을 최대 5개 표시합니다. 압축 모드에서는 처음 3개의 작업 슬롯만 표시됩니다. Android 13을 타겟팅하지 않거나 PlaybackState를 포함하지 않는 앱의 경우 시스템은 MediaStyle 알림에 추가된 Action 목록에 기반하여 컨트롤을 표시합니다(이전 단락에서 설명).

맞춤 작업은 PlaybackState에 추가된 순서대로 배치됩니다.

앱 색상 테마가 WebView 콘텐츠에 자동으로 적용됨

Android 13(API 수준 33) 이상을 타겟팅하는 앱의 경우 setForceDark() 메서드가 지원 중단되므로 이 메서드가 호출되면 작동하지 않습니다.

대신 이제 WebView가 앱의 테마 속성 isLightTheme에 따라 미디어 쿼리 prefers-color-scheme을 항상 설정합니다. 즉, isLightTheme이 true이거나 지정되지 않은 경우 prefers-color-scheme은 light입니다. 그 외의 경우에는 dark입니다. 이 동작은 콘텐츠에서 지원하면 웹 콘텐츠의 밝은 스타일이나 어두운 스타일이 앱 테마에 맞게 자동으로 적용된다는 것을 의미합니다.

대부분의 앱에서 새 동작은 적절한 앱 스타일을 자동으로 적용해야 합니다. 하지만 앱을 테스트하여 어두운 모드 설정을 수동으로 제어했을 수 있는 사례를 확인해야 합니다.

그래도 앱의 색상 테마 동작을 맞춤설정해야 한다면 setAlgorithmicDarkeningAllowed() 메서드를 대신 사용하세요. 이전 Android 버전과의 호환성을 위해 AndroidX에서 동등한 setAlgorithmicDarkeningAllowed() 메서드를 사용하는 것이 좋습니다.

앱의 targetSdkVersion 및 테마 설정에 따라 앱에서 발생할 수 있는 동작을 자세히 알아보려면 이 메서드에 관한 문서를 참고하세요.

연결

BluetoothAdapter#enable() 및 BluetoothAdapter#disable() 지원 중단됨

Android 13 (API 수준 33) 이상을 타겟팅하는 앱의 경우 BluetoothAdapter#enable() 및 BluetoothAdapter#disable() 메서드가 지원 중단되며 항상 false을 반환합니다.

다음 유형의 앱은 이러한 변경사항에서 제외됩니다.

• 기기 소유자 앱
• 프로필 소유자 앱
• 시스템 앱

Google Play 서비스

광고 ID에 필요한 권한

Google Play 서비스 광고 ID를 사용하고 Android 13(API 수준 33) 이상을 타겟팅하는 앱은 다음과 같이 앱의 매니페스트 파일에서 AD_ID 일반 권한을 선언해야 합니다.

<manifest ...>
    <!-- Required only if your app targets Android 13 or higher. -->
    <uses-permission android:name="com.google.android.gms.permission.AD_ID"/>

    <application ...>
        ...
    </application>
</manifest>

앱이 Android 13 이상을 타겟팅할 때 이 권한을 선언하지 않으면 광고 ID가 자동으로 삭제되고 0으로 이루어진 문자열로 대체됩니다.

앱이 라이브러리의 매니페스트에서 AD_ID 권한을 선언하는 SDK를 사용하는 경우 이 권한은 앱의 매니페스트 파일과 기본적으로 병합됩니다. 이 경우 앱의 매니페스트 파일에서 권한을 선언할 필요가 없습니다.

자세한 내용은 Play Console 도움말의 광고 ID를 참고하세요.

업데이트된 비 SDK 제한사항

Android 13에는 Android 개발자와의 공동작업 및 최신 내부 테스트를 기반으로 제한된 비 SDK 인터페이스의 업데이트된 목록이 포함되어 있습니다. 비 SDK 인터페이스를 제한하는 경우, 가능하면 해당 인터페이스에 대한 공개된 대안이 사용 가능한지 여부를 확인합니다.

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

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

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