이전 버전과 마찬가지로 Android 12에는 앱에 영향을 미칠 수 있는 동작 변경사항이 포함되어 있습니다. 다음 동작 변경사항은 Android 12 이상을 타겟팅하는 앱에만 적용됩니다. 앱이 Android 12를 타겟팅하는 경우 이러한 동작을 올바르게 지원하도록 앱을 수정해야 합니다(적용되는 경우).
Android 12에서 실행되는 모든 앱에 영향을 주는 동작 변경사항의 목록도 검토하시기 바랍니다.
사용자 환경
맞춤 알림
Android 12에서는 완전한 맞춤 알림의 모양과 동작을 변경합니다. 이전에는 맞춤 알림이 전체 알림 영역을 사용하여 자체 레이아웃과 스타일을 제공했습니다. 이로 인해 사용자에게 혼동을 주거나 다양한 기기에서 레이아웃 호환성 문제를 일으킬 수 있는 안티패턴이 생겼습니다.
Android 12를 타겟팅하는 앱의 경우 맞춤 콘텐츠 뷰가 포함된 알림은 더 이상 전체 알림 영역을 사용하지 않습니다. 대신 시스템에서 표준 템플릿을 적용합니다. 이 템플릿은 맞춤 알림이 알림의 아이콘 및 확장 어포던스(접힌 상태)와 알림의 아이콘, 앱 이름, 축소 어포던스(펼친 상태) 등 모든 상태에서 다른 알림과 동일한 장식을 보유하도록 합니다. 이 동작은 Notification.DecoratedCustomViewStyle의 동작과 거의 동일합니다.
이러한 방식을 통해 Android 12는 모든 알림이 시각적으로 일관되고 쉽게 검색되도록 하며 사용자에게 검색 가능하고 친숙한 알림 확장 기능을 제공합니다.
다음 그림은 표준 템플릿의 맞춤 알림을 보여 줍니다.
다음 예는 맞춤 알림이 접힌 상태와 펼친 상태로 렌더링되는 방식을 보여 줍니다.
Android 12의 변경사항은 Notification.Style의 맞춤 서브클래스를 정의하거나 Notification.Builder의 메서드 setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews), setCustomHeadsUpContentView(RemoteViews)를 사용하는 앱에 영향을 줍니다.
앱이 완전한 맞춤 알림을 사용하면 가능한 한 빨리 새 템플릿으로 테스트하는 것이 좋습니다.
맞춤 알림 변경 사용 설정
- 앱의
targetSdkVersion을S로 변경하여 새 동작을 사용 설정합니다. - 다시 컴파일합니다.
- Android 12를 실행하는 기기나 에뮬레이터에 앱을 설치합니다.
- 앱의
맞춤 뷰를 사용하는 알림을 모두 테스트하여 예상대로 알림 창에 표시되는지 확인합니다. 테스트하는 동안 다음 사항을 고려하여 필요에 따라 조정합니다.
맞춤 뷰의 크기가 변경되었습니다. 일반적으로 맞춤 알림에 제공되는 높이가 이전보다 낮습니다. 접힌 상태에서 맞춤 콘텐츠의 최대 높이가 106dp에서 48dp로 줄었습니다. 가로 공간도 더 적습니다.
Android 12를 타겟팅하는 앱의 경우 모든 알림이 확장 가능합니다. 일반적으로 이는
setCustomContentView를 사용하는 경우setBigCustomContentView도 사용하여 접힌 상태와 펼쳐진 상태가 일관되도록 하는 것이 좋다는 의미입니다.'보행 중 주의 알림' 상태가 예상대로 표시되도록 하려면 알림 채널의 중요도를 'HIGH'(화면에 표시)로 올려야 합니다.
Android App Links 확인 변경사항
Android 12 이상을 타겟팅하는 앱에서 시스템은 Android App Links를 확인하는 방법을 몇 가지 변경합니다. 이러한 변경사항은 앱 연결 환경의 안정성을 개선하고 앱 개발자와 최종 사용자에게 더 많은 제어권을 제공합니다.
Android App Links 확인을 사용하여 앱에서 웹 링크를 연다면 Android App Links 확인을 위해 인텐트 필터를 추가할 때 올바른 형식을 사용하는지 확인합니다. 특히 이러한 인텐트 필터가 BROWSABLE 카테고리를 포함하고 https 체계를 지원하는지 확인하세요.
앱의 링크를 수동으로 확인하여 선언의 안정성을 테스트할 수도 있습니다.
PIP 모드 동작 개선사항
Android 12에서는 PIP 모드의 동작을 개선하고 동작 탐색과 요소 기반 탐색 모두의 전환 애니메이션에 권장되는 미적 개선사항을 도입합니다.
자세한 내용은 PIP 모드 개선사항을 참고하세요.
토스트 디자인 변경
Android 12의 토스트 메시지 뷰 디자인이 변경되었습니다. 이제 토스트 메시지는 텍스트 두 줄로 제한되며 텍스트 옆에 애플리케이션 아이콘이 표시됩니다.
자세한 내용은 토스트 개요를 참고하세요.
보안 및 개인 정보 보호
대략적인 위치
Android 12 이상을 실행하는 기기에서는 사용자가 앱의 대략적인 위치 정확도를 요청할 수 있습니다.
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를 참고하세요.
앱에서 SameSite 동작 테스트
앱에서 WebView를 사용하는 경우 또는 쿠키를 사용하는 웹사이트나 서비스를 개발자가 관리하는 경우 Android 12 WebView에서 흐름을 테스트하는 것이 좋습니다. 문제가 발견되면 새로운 SameSite 동작을 지원하도록 쿠키를 업데이트해야 할 수 있습니다.
사용자가 안전하지 않은 페이지에서 시작하여 안전한 페이지로 전환하는 로그인 흐름, 구매, 기타 인증 흐름뿐 아니라 로그인 및 삽입된 콘텐츠에 문제가 있는지 확인합니다.
WebView로 앱을 테스트하려면 다음 단계 중 하나를 완료하여 테스트하려는 앱에 새로운 SameSite 동작을 사용 설정해야 합니다.
WebView devtools에서 UI 플래그 webview-enable-modern-cookie-same-site를 전환하여 테스트 기기에서 SameSite 동작을 수동으로 사용 설정합니다.
이 접근 방식을 사용하면 Android 12를 포함하여 Android 5.0(API 수준 21) 이상을 실행하고 WebView 버전 89.0.4385.0 이상을 실행하는 기기에서 테스트할 수 있습니다.
targetSdkVersion으로 Android 12(API 수준 31)를 타겟팅하도록 앱을 컴파일합니다.이 접근 방식을 사용한다면 Android 12를 실행하는 기기를 사용해야 합니다.
Android에서의 WebView 원격 디버깅에 관한 자세한 내용은 Android 기기 원격 디버깅 시작하기를 참고하세요.
기타 자료
SameSite 최신 동작과 Chrome 및 WebView 출시에 관한 자세한 내용은 Chromium SameSite 업데이트 페이지를 참고하세요. WebView 또는 Chromium에서 버그를 발견하면 공개 Chromium Issue Tracker에 신고할 수 있습니다.
움직임 감지 센서의 속도가 제한됨
잠재적으로 민감한 사용자 정보를 보호하기 위해 앱이 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 12 이상을 타겟팅하고 인텐트 필터를 사용하는 활동이나 서비스, broadcast receiver를 포함하면 이러한 앱 구성요소의 android:exported 속성을 명시적으로 선언해야 합니다.
앱 구성요소에 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>
Android 스튜디오의 메시지
앱에 인텐트 필터를 사용하지만 android:exported를 선언하지 않는 활동이나 서비스, broadcast receiver가 포함되어 있다면 사용하는 Android 스튜디오 버전에 따라 다음과 같은 경고 메시지가 표시됩니다.
Android 스튜디오 2020.3.1 Canary 11 이상
다음 메시지가 표시됩니다.
다음 린트 경고가 매니페스트 파일에 표시됩니다.
When using intent filters, please specify android:exported as well앱을 컴파일하려고 하면 다음과 같은 빌드 오류 메시지가 표시됩니다.
Manifest merger failed : Apps targeting Android 12 and higher are required \ to specify an explicit value for android:exported when the corresponding \ component has an intent filter defined.
이전 버전의 Android 스튜디오
앱을 설치하려고 하면 Logcat에 다음 오류 메시지가 표시됩니다.
Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'
대기 중인 인텐트 변경 가능 여부
앱이 Android 12를 타겟팅하는 경우 앱에서 만드는 각 PendingIntent 객체의 변경 가능 여부를 지정해야 합니다. 이 추가 요구사항은 앱의 보안을 강화합니다.
대기 중인 인텐트 변경 가능 여부 테스트
앱에서 변경 가능 여부 선언이 누락되었는지 확인하려면 Android 스튜디오에서 다음과 같은 린트 경고를 찾습니다.
Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]
안전하지 않은 인텐트 실행
플랫폼 보안을 개선하기 위해 Android 12 이상에서는 안전하지 않은 인텐트 실행을 감지하는 디버깅 기능을 제공합니다. 시스템에서 이러한 안전하지 않은 실행을 감지하면 StrictMode 위반이 발생합니다.
성능
포그라운드 서비스 실행 제한
Android 12 이상을 타겟팅하는 앱은 특별한 사례 몇 가지를 제외하고 백그라운드에서 실행되는 동안 포그라운드 서비스를 시작할 수 없습니다. 앱이 백그라운드에서 실행되는 동안 포그라운드 서비스를 시작하려고 하면 예외가 발생합니다(특별한 사례 제외).
앱이 백그라운드에서 실행되는 동안 WorkManager를 사용하여 신속 처리 작업을 예약하고 시작해 보세요. 신속히 처리해야 하는 사용자 요청 작업을 완료하려면 정확한 알람 내에서 포그라운드 서비스를 시작하세요.
정확한 알람 권한
앱의 시스템 리소스 절약을 유도하기 위해 Android 12 이상을 타겟팅하고 정확한 알람을 설정하는 앱은 시스템 설정의 특수 앱 액세스 화면 내에 표시되는 '알람 및 리마인더' 기능에 액세스할 수 있어야 합니다.
이 특수 앱 액세스 권한을 가져오려면 매니페스트에서 SCHEDULE_EXACT_ALARM 권한을 요청하세요.
정확한 알람은 사용자에게 표시되는 기능에만 사용해야 합니다. 정확한 알람을 설정하기 위해 허용되는 사용 사례를 자세히 알아보세요.
동작 변경 사용 중지
Android 12를 타겟팅하도록 앱을 준비할 때 테스트 목적으로 디버그 가능한 빌드 변형에서 동작 변경사항을 일시적으로 사용 중지할 수 있습니다. 이렇게 하려면 다음 작업 중 하나를 완료하세요.
- 개발자 옵션 설정 화면에서 앱 호환성 변경사항을 선택합니다. 표시되는 화면에서 앱 이름을 탭하고 REQUIRE_EXACT_ALARM_PERMISSION을 사용 중지합니다.
개발 머신의 터미널 창에서 다음 명령어를 실행합니다.
adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
알림 트램펄린 제한사항
사용자가 알림과 상호작용할 때 일부 앱은 사용자가 최종적으로 보고 상호작용하는 활동을 결국 시작하는 앱 구성요소를 실행하여 알림 탭에 응답합니다. 이 앱 구성요소를 알림 트램펄린이라고 합니다.
앱 성능과 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.
알림 트램펄린 역할을 하는 앱 구성요소 식별
앱을 테스트할 때 알림을 탭하면 앱에서 알림 트램펄린 역할을 하는 서비스나 broadcast receiver를 식별할 수 있습니다. 다음 터미널 명령어의 출력을 확인하면 됩니다.
adb shell dumpsys activity service \ com.android.systemui/.dump.SystemUIAuxiliaryDumpService
출력의 섹션에 'NotifInteractionLog'라는 텍스트가 포함되어 있습니다. 이 섹션에는 알림 탭으로 인해 시작되는 구성요소를 식별하는 데 필요한 정보가 포함되어 있습니다.
앱 업데이트
앱이 알림 트램펄린 역할을 하는 서비스나 broadcast receiver에서 활동을 시작하는 경우 다음 이전 단계를 완료하세요.
- 사용자가 알림을 탭한 후 표시되는 활동과 연결된
PendingIntent객체를 만듭니다. - 알림 빌드의 일부로 이전 단계에서 만든
PendingIntent객체를 사용합니다.
활동의 출처를 식별하려면(예: 로깅을 실행하기 위해) 알림을 게시할 때 추가 항목을 사용합니다. 중앙 집중식 로깅의 경우 ActivityLifecycleCallbacks 또는 Jetpack 수명 주기 관찰자를 사용하세요.
동작 전환
디버그 가능한 버전의 앱을 테스트할 때 NOTIFICATION_TRAMPOLINE_BLOCK 앱 호환성 플래그를 사용하여 이 제한사항을 사용 설정하거나 사용 중지할 수 있습니다.
백업 및 복원
Android 12(API 수준 31)에서 실행되거나 이를 타겟팅하는 앱에서 백업 및 복원이 작동하는 방식이 변경되었습니다. Android 백업 및 복원에는 두 가지 형식이 있습니다.
- 클라우드 백업: 사용자 데이터가 사용자의 Google Drive에 저장되므로 나중에 기존 기기나 새 기기에서 복원할 수 있습니다.
- 기기 간(D2D) 전송: 사용자 데이터가 기존 기기에서 사용자의 새 기기로 직접 전송(예: 케이블 사용)됩니다.
데이터 백업 및 복원 방법에 관한 자세한 내용은 자동 백업으로 사용자 데이터 백업 및 Android Backup Service로 키-값 쌍 백업을 참고하세요.
D2D 전송 기능 변경사항
Android 12 이상에서 실행되거나 Android 12 이상을 타겟팅하는 앱
XML 구성 메커니즘으로 포함 및 제외 규칙을 지정하면 D2D 전송에는 영향을 미치지 않지만 클라우드 기반 백업 및 복원 (예: Google Drive 백업)에는 여전히 영향을 미칩니다. D2D 전송 규칙을 지정하려면 다음 섹션에서 다루는 새 구성을 사용해야 합니다.
일부 기기 제조업체의 기기에서는
android:allowBackup="false"를 지정하면 Google Drive 백업이 사용 중지되지만 앱의 D2D 전송은 사용 중지되지 않습니다.
새로운 포함 및 제외 형식
Android 12 이상에서 실행되거나 Android 12 이상을 타겟팅하는 앱은 XML 구성에 다른 형식을 사용합니다. 이 형식은 클라우드 백업과 D2D 전송에 포함 및 제외 규칙을 별도로 지정하도록 하여 Google Drive 백업과 D2D 전송 간의 차이를 명확히 합니다.
원한다면 백업 규칙을 지정하는 데 사용할 수도 있습니다. 이 경우 이전에 사용한 구성이 Android 12 이상을 실행하는 기기에서 무시됩니다. 이전 구성은 Android 11 이하를 실행하는 기기에는 여전히 필요합니다.
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>
다음은 형식의 변경사항을 굵게 표시하여 보여줍니다.
<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>
자세한 내용은 자동 백업으로 사용자 데이터 백업 가이드의 관련 섹션을 참고하세요.
앱의 매니페스트 플래그
매니페스트 파일에서 android:dataExtractionRules 속성을 사용하여 앱이 새 XML 구성을 가리키도록 합니다. 새 XML 구성을 가리키면 이전 구성을 가리키는 android:fullBackupContent 속성이 Android 12 이상을 실행하는 기기에서 무시됩니다. 다음 코드 샘플은 새 매니페스트 파일 항목을 보여줍니다.
<application ... <!-- The below attribute is ignored. --> android:fullBackupContent="old_config.xml" <!-- You can point to your new configuration using the new dataExtractionRules attribute . --> android:dataExtractionRules="new_config.xml" ...> </application>
연결
블루투스 권한
Android 12에서는 BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE, BLUETOOTH_CONNECT 권한을 도입합니다. 이러한 권한을 사용하면 Android 12를 타겟팅하는 앱, 특히 기기 위치 액세스가 필요하지 않은 앱이 블루투스 기기와 더 쉽게 상호작용할 수 있습니다.
Android 12 이상을 타겟팅하도록 기기를 준비하려면 앱의 로직을 업데이트하세요. 기존 블루투스 권한 세트를 선언하는 대신 최신 블루투스 권한 세트를 선언합니다.
동시 P2P + 인터넷 연결
Android 12(API 수준 31) 이상을 타겟팅하는 앱의 경우 동시 P2P 및 인터넷 연결을 지원하는 기기가 피어 기기 및 기본 인터넷 제공 네트워크 모두에 대한 동시 Wi-Fi 연결을 유지할 수 있어 사용자 환경이 더 원활해집니다. Android 11(API 수준 30) 이하를 타겟팅하는 앱에서는 피어 기기에 연결하기 전에 기본 Wi-Fi 네트워크가 연결 해제되는 기존 동작이 계속 발생합니다.
호환성
WifiManager.getConnectionInfo()는 단일 네트워크의 경우에만 WifiInfo를 반환할 수 있습니다. 따라서 Android 12 이상에서는 API 동작이 다음과 같이 변경되었습니다.
- 단일 Wi-Fi 네트워크만 사용할 수 있는 경우
WifiInfo가 반환됩니다. - Wi-Fi 네트워크를 두 개 이상 사용할 수 있고 통화 앱이 P2P 연결을 트리거한 경우 피어 기기에 상응하는
WifiInfo가 반환됩니다. - Wi-Fi 네트워크를 두 개 이상 사용할 수 있고 통화 앱이 P2P 연결을 트리거하지 않은 경우 기본 인터넷 제공 연결의
WifiInfo가 반환됩니다.
듀얼 동시 Wi-Fi 네트워크를 지원하는 기기에서 더 나은 사용자 환경을 제공하려면 모든 앱(특히 P2P 연결을 트리거하는 앱)이 WifiManager.getConnectionInfo() 호출에서 이전하고 대신 NetworkCallback.onCapabilitiesChanged()를 사용하여 NetworkCallback을 등록하는 데 사용되는 NetworkRequest와 일치하는 모든 WifiInfo 객체를 가져오는 것이 좋습니다. getConnectionInfo()는 Android 12부터 지원 중단됩니다.
다음 코드 샘플은 NetworkCallback에서 WifiInfo를 가져오는 방법을 보여줍니다.
Kotlin
val networkCallback = object : ConnectivityManager.NetworkCallback() { ... override fun onCapabilitiesChanged( network : Network, networkCapabilities : NetworkCapabilities) { val transportInfo = networkCapabilities.getTransportInfo() if (transportInfo !is WifiInfo) return val wifiInfo : WifiInfo = transportInfo ... } }
자바
final NetworkCallback networkCallback = new NetworkCallback() { ... @Override public void onCapabilitiesChanged( Network network, NetworkCapabilities networkCapabilities) { final TransportInfo transportInfo = networkCapabilities.getTransportInfo(); if (!(transportInfo instanceof WifiInfo)) return; final WifiInfo wifiInfo = (WifiInfo) transportInfo; ... } ... };
mDNSResponder 네이티브 API
Android 12에서는 앱이 mDNSResponder 네이티브 API를 사용하여 mDNSResponder 데몬과 상호작용할 수 있는 시점을 변경합니다.
이전에는 앱이 네트워크에 서비스를 등록하고 getSystemService() 메서드를 호출할 때 앱이 아직 NsdManager 메서드를 호출하지 않았더라도 시스템의 NSD 서비스에서 mDNSResponder 데몬을 시작했습니다. 그러면 데몬은 기기를 모든 노드 멀티캐스트 그룹에 썼으므로 시스템이 더 자주 절전 모드를 해제하고 추가 전력을 사용했습니다. 배터리 사용량을 최소화하기 위해 Android 12 이상에서는 이제 시스템이 NSD 이벤트에 필요할 때만 mDNSResponder 데몬을 시작하고 그 후에는 중지합니다.
이 변경사항은 mDNSResponder 데몬을 사용할 수 있는 시점에 영향을 미치므로 getSystemService() 메서드 호출 후 mDNSResponder 데몬이 시작된다고 가정하는 앱은 mDNSResponder 데몬을 사용할 수 없다고 알리는 메시지를 시스템에서 수신할 수 있습니다. NsdManager를 사용하고 mDNSResponder 네이티브 API를 사용하지 않는 앱은 이 변경사항으로 영향을 받지 않습니다.
공급업체 라이브러리
공급업체 제공 네이티브 공유 라이브러리
실리콘 공급업체나 기기 제조업체에서 제공한 비 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 인터페이스 제한사항을 참고하세요.