android 12 변경 사항 정리

이 글은 아래 사이트를 학습하며 작성한 글입니다.

https://developer.android.com/about/versions/12/behavior-changes-all?hl=ko 

 

모든 앱 동작 변경 사항

모든앱 동작 변경 사항이란? targetSdkVersion과 관계없이 Android 12에서 실행되는 모든 앱에 적용되는 동작 변경 사항으로

앱은 관련 동작 변경 사항을 반드시 파악하여 android 12 단말 출시(or 업데이트)에 문제 없도록 대응해야 합니다.

 

** 사용자 환경 **

스트레치 오버스크롤 효과

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

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

 

앱 스플래시 화면

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

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

https://als2019.tistory.com/93

 

웹 인텐트 확인

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를 도입하고 다음 메서드를 지원 중단했습니다.

• Display.getSize()
• Display.getMetrics()

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

• Display.getRealSize()
• Display.getRealMetrics()

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

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

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

 

멀티 윈도우 모드의 모든 앱

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

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

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

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

 

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

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

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

 

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

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

 

 

** 성능 **

Restricted App Standby Bucket(제한된 앱 대기 버킷)

Android 11(API 수준 30)에서는 Restricted bucket을 앱 대기 버킷으로 도입했습니다. 

Android 12부터 이 버킷은 기본적으로 활성화되어 있습니다. 제한됨 버킷은 모든 버킷 중에서 우선순위가 가장 낮습니다(제한사항은 가장 많음). 

높은 우선순위에서 낮은 우선순위 순으로 나열된 버킷은 다음과 같습니다.

1. Active: 앱이 현재 사용 중이거나 매우 최근에 사용되었습니다.
2. Working set: 앱이 정기적으로 사용됩니다.
3. Frequent: 앱이 매일은 아니지만 자주 사용됩니다.
4. Rare: 앱이 자주 사용되지 않습니다.
5. Restricted: 앱이 시스템 리소스를 많이 소비하거나 원하지 않는 동작을 보일 수 있습니다.

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

앱이 시스템 리소스를 더 책임감 있게 사용하면 제한됨 버킷에 배치될 가능성은 낮습니다. 

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

 

앱이 Restricted bucket에 있는지 확인하는 방법

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

제한됨 버킷 동작 테스트

 

 

** 보안 및 개인 정보 보호 **

마이크 및 카메라 전환

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

사용 시 CAMERA 및 RECORD_AUDIO permission을 따라야 합니다.

 

마이크 및 카메라 표시기

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

사용 시 CAMERA 및 RECORD_AUDIO permission을 따라야 합니다.

 

권한 패키지 공개 상태

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

  - getAllPermissionGroups()

  - getPermissionGroupInfo()

  - getPermissionInfo()

  - queryPermissionsByGroup()

 

BouncyCastle  Removed

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

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

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

 

클립 설명의 텍스트 정보

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 이상에서 시스템 대화상자를 닫을 수 있습니다.

  - 앱이 Test를 실행 중인 경우

  - 앱이 Android 11 이하를 타겟팅하고 알림 창 위에 있는 창을 표시하는 경우

  - 앱이 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 플래그를 사용하는 Activity Window

단, 다음과 같은 경우에는 "pass-through" 터치가 허용됩니다.

  - 앱 내 상호작용. 

     앱에서 오버레이를 표시하면 오버레이는 사용자가 앱과 상호작용할 때만 표시됩니다.

  - 신뢰할 수 있는 창. 이러한 창에는 다음이 포함되지만 이에 국한되지 않습니다.

     * Accessibility windows

     * Input method editor (IME) windows

     * Assistant windows

     * Invisible windows

     * Completely transparent windows

     * Sufficiently translucent system alert windows      

 

 

** 활동 수명 주기 **

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

Android 12에서는 작업의 루트에 있는 런처 Activity에서 시스템 뒤로 누르기의 기본 처리를 변경합니다. 이전 버전에서는 시스템이 뒤로 누르기에서 이러한 Activity를 종료했습니다.

Android 12에서는 이제 시스템이 Activity를 종료하는 대신 Activity와 그 task들을 백그라운드로 이동시킵니다. 새로운 동작은 홈 버튼이나 동작을 사용하여 앱 외부로 이동할 때 현재 동작과 일치합니다.

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

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

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

 

 

** 그래픽과 이미지 **

새로고침 빈도 전환 개선

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

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

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

 

** 연결성 **

Passpoint 업데이트

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

- isPasspointTermsAndConditionsSupported()

이용약관은 네트워크 배포에서 개방형 네트워크를 사용하는 안전하지 않은 종속 포털을 안전한 Passpoint 네트워크로 대체할 수 있는 Passpoint 기능입니다. 이용약관에 동의해야 하는 경우 사용자에게 알림이 표시됩니다. 이용약관으로 관리되는 Passpoint 네트워크를 제안하는 앱은 먼저 이 API를 호출하여 기기에서 이 기능을 지원하는지 확인해야 합니다. 기기에서 이 기능을 지원하지 않으면 이 네트워크에 연결할 수 없고 대체 네트워크나 기존 네트워크를 제안해야 합니다.

- isDecorateddentitySupported()

접두사 장식이 있는 네트워크에 인증할 때 장식된 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 인터페이스제한사항을 참고하세요.

 

 

---

 

동작 변경 사항: Android 12를 타겟팅하는 앱

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

 

 

** 사용자 환경 **

맞춤 알림

Android 12에서는 완전한 custom notifications의 모양과 동작을 변경합니다. 이전에는 custom notifications이 전체 알림 영역을 사용하여 자체 레이아웃과 스타일을 제공했습니다. 이로 인해 사용자에게 혼동을 주거나 다양한 기기에서 레이아웃 호환성 문제를 일으킬 수 있는 안티패턴이 생겼습니다.

Android 12를 타겟팅하는 앱의 경우 맞춤 콘텐츠 뷰가 포함된 알림은 더 이상 전체 알림 영역을 사용하지 않습니다. 대신 시스템에서 표준 템플릿을 적용합니다. 이 템플릿은 맞춤 알림이 알림의 아이콘 및 확장 어포던스(접힌 상태)와 알림의 아이콘, 앱 이름, collapse, affordance(펼친 상태) 등 모든 상태에서 다른 알림과 동일한 장식을 보유하도록 합니다. 이 동작은 Notification.DecoratedCustomViewStyle의 동작과 거의 동일합니다.

이러한 방식을 통해 Android 12는 모든 알림이 시각적으로 일관되고 쉽게 검색되도록 하며 사용자에게 검색 가능하고 친숙한 알림 확장 기능을 제공합니다.

다음 그림은 표준 템플릿의 맞춤 알림을 보여 줍니다.

다음 예는 맞춤 알림이 접힌 상태와 펼친 상태로 렌더링되는 방식을 보여 줍니다.

Android 12의 변경사항은 Notification.Style의 맞춤 서브클래스를 정의하거나 Notification.Builder의 메서드 setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews), setCustomHeadsUpContentView(RemoteViews)를 사용하는 앱에 영향을 줍니다.

앱이 완전한 custom notifications을 사용하면 가능한 한 빨리 새 템플릿으로 테스트하는 것이 좋습니다.

 

Android App Links 확인 변경 사항

Android 12 이상을 타겟팅하는 앱에서 시스템은 Android App Links를 확인하는 방법을 몇 가지 변경합니다. 이러한 변경사항은 앱 연결 환경의 안정성을 개선하고 앱 개발자와 최종 사용자에게 더 많은 제어권을 제공합니다.

Android App Links 확인을 사용하여 앱에서 웹 링크를 연다면 Android App Links 확인을 위해 인텐트 필터를 추가할 때 올바른 형식을 사용하는지 확인합니다. 특히 이러한 인텐트 필터가 BROWSABLE 카테고리를 포함하고 https 체계를 지원하는지 확인하세요.

앱의 링크를 수동으로 확인하여 선언의 안정성을 테스트할 수도 있습니다.

 

PIP 동작 개선 사항

Android 12에서는 PIP 모드의 동작을 개선합니다. 자세한 내용은 PIP 모드 개선사항을 참고하세요.

 

 

** 보안 및 개인 정보 보호 **

대략적인 위치

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

참고: 앱이 ACCESS_COARSE_LOCATION은 요청하지만 ACCESS_FINE_LOCATION은 요청하지 않는다면 이 변경사항은 앱에 영향을 미치지 않습니다.

앱이 Android 12 이상을 타겟팅하고 ACCESS_FINE_LOCATION 런타임 권한을 요청하면 ACCESS_COARSE_LOCATION 권한도 요청해야 합니다. 단일 런타임 요청에 두 권한을 모두 포함해야 합니다.

앱이 ACCESS_FINE_LOCATION과 ACCESS_COARSE_LOCATION을 모두 요청하면 시스템 권한 대화상자에는 그림 1과 같이 새로운 사용자 옵션이 포함됩니다.

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

 

WebView의 최신 SameSite 쿠키

Android의 WebView 구성요소는 Google의 Chrome 브라우저를 지원하는 오픈소스 프로젝트인 Chromium에 기반합니다. Chromium은 타사 쿠키 처리에 변경사항을 도입하여 보안과 개인 정보 보호를 강화하고 사용자에게는 더 높은 투명성과 더 많은 제어 기능을 제공했습니다. Android 12부터 이러한 변경사항은 앱에서 Android 12(API 수준 31) 이상을 타겟팅할 때 WebView에도 포함됩니다.

쿠키의 SameSite 속성은 쿠키가 모든 요청과 함께 전송될 수 있는지 아니면 동일한 사이트 요청으로만 전송될 수 있는지를 제어합니다. 다음과 같은 개인 정보 보호 변경사항은 타사 쿠키의 기본 처리를 개선하고 의도하지 않은 교차 사이트 공유를 방지할 수 있습니다.

• SameSite 속성이 없는 쿠키는 SameSite=Lax로 간주됩니다.
• SameSite=None이 있는 쿠키는 Secure 속성도 지정해야 합니다. 즉, 보안 컨텍스트가 필요하고 HTTPS를 통해 전송되어야 합니다.
• 사이트의 HTTP 버전과 HTTPS 버전 간의 링크는 이제 교차 사이트 요청으로 간주되므로 쿠키가 SameSite=None; Secure로 적절하게 표시되지 않는 한 전송되지 않습니다.

개발자의 경우 일반적으로, 중요한 사용자 흐름에서 교차 사이트 쿠키 종속 항목을 식별하고 SameSite 속성이 필요에 따라 적절한 값과 함께 명시적으로 설정되어 있는지 확인하는 것이 좋습니다. 웹사이트 또는 HTTP에서 HTTPS로 이동하는 동일한 사이트 탐색에서 작동하도록 허용된 쿠키를 명시적으로 지정해야 합니다.

웹 개발자를 위한 이러한 변경사항에 관한 자세한 안내는 SameSite 쿠키 설명과 Schemeful SameSite를 참고하세요.

 

움직임 감지 센서의 속도 제한

잠재적으로 민감한 사용자 정보를 보호하기 위해 앱이 Android 12 이상을 타겟팅하는 경우 시스템은 특정 움직임 감지 센서와 위치 센서의 데이터 새로고침 빈도를 제한합니다.

센서 비율 제한을 자세히 알아보세요.

 

앱 최대 절전 모드

Android 12에서는 Android 11(API 수준 30)에서 도입된 권한 자동 초기화 동작을 확장합니다. 앱이 Android 12를 타겟팅하고 사용자가 몇 달 동안 앱과 상호작용하지 않는다면 시스템은 부여된 모든 권한을 자동 초기화하고 앱을 최대 절전 모드 상태로 전환합니다.

자세한 내용은 앱 최대 절전 모드 가이드를 참고하세요.

 

데이터 액세스 분석의 저작자 표시

Android 11(API 수준 30)에서 도입된 데이터 액세스 분석 API를 사용하면 앱의 사용 사례에 기반하여 저작자 표시 태그를 생성할 수 있습니다. 이러한 태그를 통해 앱에서 특정 유형의 데이터 액세스를 실행하는 부분을 더 쉽게 확인할 수 있습니다.

앱이 Android 12 이상을 타겟팅한다면 앱의 매니페스트 파일에서 이러한 저작자 표시 태그를 선언해야 합니다.

 

ADB 백업 제한

비공개 앱 데이터를 보호할 수 있도록 Android 12에서는 adb backup 명령어의 기본 동작을 변경합니다. Android 12(API 수준 31) 이상을 타겟팅하는 앱의 경우 사용자가 adb backup 명령어를 실행하면 앱 데이터는 기기에서 내보내는 다른 시스템 데이터에서 제외됩니다.

테스트 또는 개발 워크플로가 adb backup을 사용하는 앱 데이터에 의존하는 경우 이제 android:debuggable을 앱의 매니페스트 파일에서 true로 설정하여 앱 데이터 내보내기를 선택할 수 있습니다.

주의: 앱 데이터를 보호하려면 앱을 출시하기 전에 android:debuggable을 false로 설정해야 합니다.

 

더 안전한 구성요소 내보내기

앱이 Android 12 이상을 타겟팅하고 인텐트 필터를 사용하는 활동이나 서비스, broadcast receiver를 포함하면 이러한 앱 구성요소의 android:exported 속성을 명시적으로 선언해야 합니다.

 

경고: 활동이나 서비스, broadcast receiver에서 인텐트 필터를 사용하지만 명시적으로 선언된 android:exported 값이 없으면 Android 12 이상을 실행하는 기기에 앱을 설치할 수 없습니다.

 

앱 구성요소에 LAUNCHER 카테고리가 포함된 경우 android:exported를 true로 설정합니다. 다른 대부분의 경우에는 android:exported를 false로 설정합니다.

다음 코드 스니펫은 android:exported 속성이 false로 설정된 인텐트 필터가 포함된 서비스의 예를 보여줍니다.

<service android:name="com.example.app.backgroundService"          android:exported="false">     <intent-filter>         <action android:name="com.example.app.START_BACKGROUND" />     </intent-filter> </service>

 

PendingIntent mutability

앱이 Android 12를 타겟팅하는 경우 앱에서 만드는 각 PendingIntent 객체의 변경 가능 여부를 지정해야 합니다. 이 추가 요구사항은 앱의 보안을 강화합니다.

앱에서 변경 가능 여부 선언이 누락되었는지 확인하려면 Android 스튜디오에서 다음과 같은 린트 경고를 찾습니다.

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

 

안전하지 않은 인텐트 실행

플랫폼 보안을 개선하기 위해 Android 12 이상에서는 안전하지 않은 인텐트 실행을 감지하는 디버깅 기능을 제공합니다. 시스템에서 이러한 안전하지 않은 실행을 감지하면 StrictMode 위반이 발생합니다.

 

 

** 성능 **

포그라운드 서비스 실행 제한

Android 12 이상을 타겟팅하는 앱은 특별한 사례 몇 가지를 제외하고 백그라운드에서 실행되는 동안 포그라운드 서비스를 시작할 수 없습니다. 앱이 백그라운드에서 실행되는 동안 포그라운드 서비스를 시작하려고 하면 예외가 발생합니다(특별한 사례 제외).

앱이 백그라운드에서 실행되는 동안 WorkManager를 사용하여 신속 처리 작업을 예약하고 시작해 보세요. 신속히 처리해야 하는 사용자 요청 작업을 완료하려면 정확한 알람 내에서 포그라운드 서비스를 시작하세요.

 

정확한 알람 권한

앱의 시스템 리소스 절약을 유도하기 위해 Android 12 이상을 타겟팅하고 정확한 알람을 설정하는 앱은 시스템 설정의 특수 앱 액세스 화면 내에 표시되는 '알람 및 리마인더' 기능에 액세스할 수 있어야 합니다.

이 특수 앱 액세스 권한을 가져오려면 매니페스트에서 SCHEDULE_EXACT_ALARM 권한을 요청하세요.

정확한 알람은 사용자에게 표시되는 기능에만 사용해야 합니다. 정확한 알람을 설정하기 위해 허용되는 사용 사례를 자세히 알아보세요.

 

알림 트램펄린 제한 사항

사용자가 알림과 상호작용할 때 일부 앱은 사용자가 최종적으로 보고 상호작용하는 활동을 결국 시작하는 앱 구성요소를 실행하여 알림 탭에 응답합니다. 이 앱 구성요소를 알림 트램펄린이라고 합니다.

앱 성능과 UX를 개선하기 위해 Android 12 이상을 타겟팅하는 앱은 알림 트램펄린으로 사용되는 서비스나 broadcast receiver에서 활동을 시작할 수 없습니다. 즉, 사용자가 알림을 탭하거나 알림 내에서 작업 버튼을 탭한 후, 앱은 서비스나 broadcast receiver 내부에서 startActivity()를 호출할 수 없습니다.

앱이 알림 트램펄린 역할을 하는 서비스나 broadcast receiver에서 활동을 시작하려고 하면 시스템에서는 활동이 시작되지 못하게 하고 다음 메시지가 Logcat에 표시됩니다.

Indirect notification activity start (trampoline) from PACKAGE_NAME, \ this should be avoided for performance reasons.

 

 

** 백업 및 복원 **

Android 12(API 수준 31)에서 실행되거나 이를 타겟팅하는 앱에서 백업 및 복원이 작동하는 방식이 변경되었습니다. Android 백업 및 복원에는 두 가지 형식이 있습니다.

• 클라우드 백업: 사용자 데이터가 사용자의 Google Drive에 저장되므로 나중에 기존 기기나 새 기기에서 복원할 수 있습니다.
• 기기 간(D2D) 전송: 사용자 데이터가 기존 기기에서 사용자의 새 기기로 직접 전송(예: 케이블 사용)됩니다.

데이터 백업 및 복원 방법에 관한 자세한 내용은 자동 백업으로 사용자 데이터 백업과 Android Backup Service로 키-값 쌍 백업을 참고하세요.

 

D2D 전송 기능 변경 사항

Android 12 이상에서 실행되거나 Android 12 이상을 타겟팅하는 앱

• android:allowBackup="false"를 지정하면 Google Drive 백업이 사용 중지되지만 앱의 D2D 전송은 사용 중지되지 않습니다.
• XML 구성 메커니즘으로 포함 및 제외 규칙을 지정하면 더 이상 D2D 전송에 영향을 미치지 않지만 Google Drive 백업에는 여전히 영향을 미칩니다. D2D 전송 규칙을 지정하려면 다음 섹션에서 다루는 새 구성을 사용해야 합니다.
  
  

새로운 포함 및 제외 형식

Android 12 이상에서 실행되거나 Android 12 이상을 타겟팅하는 앱은 XML 구성에 다른 형식을 사용합니다. 이 형식은 클라우드 백업과 D2D 전송에 포함 및 제외 규칙을 별도로 지정하도록 하여 Google Drive 백업과 D2D 전송 간의 차이를 명확히 합니다.

원한다면 백업 규칙을 지정하는 데 사용할 수도 있습니다. 이 경우 이전 구성이 Android 12 이상을 실행하는 기기에서 무시됩니다. 이전 구성은 Android 11 이하를 실행하는 기기에는 여전히 필요합니다.

참고: 새 구성 형식을 사용하면 아직 Android 12를 타겟팅하지 않더라도 앱이 Android 12 이상이 설치된 기기에서 실행될 때 새로운 동작을 사용합니다.

 

XML 형식 변경사항

다음은 Android 11 이하에서 백업 및 복원 구성에 사용되는 형식입니다.

<full-backup-content>     <include domain=["file" | "database" | "sharedpref" | "external" |                      "root"] path="string"     requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />     <exclude domain=["file" | "database" | "sharedpref" | "external" |                      "root"] path="string" /> </full-backup-content>

 

다음은 형식의 변경사항을 굵게 표시하여 보여줍니다.

<full-backup-content>     <include domain=["file" | "database" | "sharedpref" | "external" |                      "root"] path="string"     requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />     <exclude domain=["file" | "database" | "sharedpref" | "external" |                      "root"] path="string" /> </full-backup-content>

 

 

자세한 내용은 자동 백업으로 사용자 데이터 백업 가이드의 관련 섹션을 참고하세요.

 

매니페스트 파일에서 android:dataExtractionRules 속성을 사용하여 앱이 새 XML 구성을 가리키도록 합니다. 새 XML 구성을 가리키면 이전 구성을 가리키는 android:fullBackupContent 속성이 Android 12 이상을 실행하는 기기에서 무시됩니다. 다음 코드 샘플은 새 매니페스트 파일 항목을 보여줍니다.

<data-extraction-rules>   <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>     ...     <include domain=["file" | "database" | "sharedpref" | "external" |                         "root"] path="string"/>     ...     <exclude domain=["file" | "database" | "sharedpref" | "external" |                         "root"] path="string"/>     ...   </cloud-backup>   <device-transfer>     ...     <include domain=["file" | "database" | "sharedpref" | "external" |                         "root"] path="string"/>     ...     <exclude domain=["file" | "database" | "sharedpref" | "external" |                         "root"] path="string"/>     ...   </device-transfer> </data-extraction-rules>

 

** 연결성 **

동시 P2P + 인터넷 연결

Android 12(API 수준 31) 이상을 타겟팅하는 앱의 경우 동시 P2P 및 인터넷 연결을 지원하는 기기가 피어 기기 및 기본 인터넷 제공 네트워크 모두에 대한 동시 Wi-Fi 연결을 유지할 수 있어 사용자 환경이 더 원활해집니다. Android 11(API 수준 30) 이하를 타겟팅하는 앱에서는 피어 기기에 연결하기 전에 기본 Wi-Fi 네트워크가 연결 해제되는 기존 동작이 계속 발생합니다.

 

 

** 공급업체 라이브러리 **

공급업체 제공 네이티브 공유 라이브러리

실리콘 공급업체나 기기 제조업체에서 제공한 비 NDK 네이티브 공유 라이브러리에는 앱이 Android 12(API 수준 31) 이상을 타겟팅하면 기본적으로 액세스할 수 없습니다. <uses-native-library> 태그를 사용하여 명시적으로 요청된 때만 라이브러리에 액세스할 수 있습니다.

앱이 Android 11(API 수준 30) 이하를 타겟팅한다면 <uses-native-library> 태그가 필요하지 않습니다. 이 경우 NDK 라이브러리인지와 상관없이 모든 네이티브 공유 라이브러리에 액세스할 수 있습니다.

 

 

** 업데이트된 비 SDK 제한사항 **

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

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

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

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

 

 

---

 

 

지원 중단

각 출시에서 특정 Android API는 더 이상 사용되지 않거나 더 나은 개발자 환경 제공이나 새 플랫폼 기능 지원을 위해 리팩터링해야 할 수 있습니다. 이 경우 Android는 더 이상 사용되지 않는 API를 공식적으로 지원 중단하고 개발자에게 대신 사용할 새 API를 안내합니다.

지원 중단이란 API에 관한 공식 지원은 종료되나 개발자는 계속 사용할 수 있다는 의미입니다. 이 페이지에서는 이번 Android 출시에서 지원 중단된 사항을 중점적으로 다룹니다. 다른 지원 중단을 확인하려면 API 차이점 보고서를 참고하세요.

 

RenderScript

Android 12부터 RenderScript API는 지원 중단됩니다. 계속 작동하지만 기기 및 구성요소 제조업체는 시간이 지남에 따라 하드웨어 가속 지원을 더 이상 제공하지 않을 것으로 예상됩니다. GPU 가속을 최대한 활용하려면 RenderScript에서 이전하는 것이 좋습니다.

 

Android 재생목록

Android 재생목록이 지원 중단됩니다. 이 API는 더 이상 유지되지 않지만 현재 기능은 호환성을 위해 유지됩니다.

재생목록을 m3u 파일로 읽고 저장하는 것이 좋습니다.

 

Display API 지원 중단

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

• Display.getSize()
• Display.getMetrics()

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

• Display.getRealSize()
• Display.getRealMetrics()

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

Jetpack WindowManager 라이브러리에는 Android 4.0.1(API 수준 14) 이상을 지원하는 WindowMetrics 클래스가 포함되어 있습니다.

 

다음은 WindowMetrics 사용 방법을 보여주는 예입니다.

먼저 앱이 앱 활동을 완전히 크기 조절이 가능하도록 할 수 있는지 확인합니다.

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

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

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

참고: MediaProjection을 사용하는 라이브러리도 이 도움말을 따라 앱 창의 적절한 WindowMetrics를 쿼리해야 합니다.