Android 5.0 동작 변경 사항

API 수준: 21

Android 5.0에는 새로운 기능과 기능 외에도 다양한 시스템 변경사항과 API 동작 변경사항이 포함되어 있습니다. 이 문서에서는 앱에서 이해하고 고려해야 하는 몇 가지 주요 변경사항을 강조 표시합니다.

이전에 Android용 앱을 게시한 경우 Android 5.0의 이러한 변경사항으로 인해 앱이 영향을 받을 수 있습니다.

새 플랫폼 기능을 간략히 살펴보려면 Android Lollipop 주요 내용을 참고하세요.

동영상

개발자 바이트: Android 5.0의 새로운 기능

개발자 바이트: 알림

Android 런타임(ART)

Android 5.0에서는 ART 런타임이 플랫폼 기본값으로 Dalvik을 대체합니다. ART 런타임은 Android 4.4에서 실험적으로 도입되었습니다.

ART의 새로운 기능에 관한 개요는 ART 소개를 참고하세요. 주요 기능은 다음과 같습니다.

  • AOT(Ahead-of-time) 컴파일
  • 가비지 컬렉션(GC) 개선
  • 디버그 지원 개선

대부분의 Android 앱은 ART에 따른 변경 없이 작동합니다. 그러나 Dalvik에서 작동하는 기술 중 일부는 ART에서 작동하지 않습니다. 가장 중요한 문제에 관한 자세한 내용은 Android 런타임 (ART)에서 앱 동작 확인을 참고하세요. 다음의 경우에 특히 주의하세요.

  • 앱에서 JNI(Java Native Interface)를 사용하여 C/C++ 코드를 실행합니다.
  • 비표준 코드를 생성하는 개발 도구 (예: 일부 난독화 도구)를 사용합니다.
  • 압축 가비지 컬렉션과 호환되지 않는 기법을 사용합니다.

알림

알림이 이 Android 5.0 변경 사항을 고려하는지 확인하세요. Android 5.0 이상용 알림 디자인에 관한 자세한 내용은 알림 디자인 가이드를 참고하세요.

머티리얼 디자인 스타일

알림은 새로운 Material Design 위젯에 맞게 흰색 (또는 매우 밝은 색) 배경 위에 어두운 텍스트로 표시됩니다. 새 색 구성표로 모든 알림이 제대로 표시되는지 확인합니다. 알림이 잘못 표시되면 다음과 같이 수정하세요.

  • setColor()를 사용하여 아이콘 이미지 뒤의 원 안에 강조 색상을 설정합니다.
  • 색상을 포함하는 자산을 업데이트 또는 제거합니다. 시스템은 작업 아이콘과 기본 알림 아이콘에서 알파 채널이 아닌 모든 채널을 무시합니다. 이러한 아이콘은 알파 전용이라고 가정해야 합니다. 시스템은 알림 아이콘을 흰색으로, 작업 아이콘을 어두운 회색으로 그립니다.

소리 및 진동

현재 Ringtone, MediaPlayer 또는 Vibrator 클래스를 사용하여 알림에 소리와 진동을 추가하는 경우 시스템이 우선순위 모드에서 알림을 올바르게 표시할 수 있도록 이 코드를 삭제합니다. 대신 Notification.Builder 메서드를 사용하여 소리와 진동을 추가하세요.

기기를 RINGER_MODE_SILENT로 설정하면 기기가 새 우선순위 모드로 전환됩니다. RINGER_MODE_NORMAL 또는 RINGER_MODE_VIBRATE로 설정하면 기기가 우선순위 모드를 종료합니다.

이전에는 Android에서 STREAM_MUSIC를 마스터 스트림으로 사용하여 태블릿 기기의 볼륨을 제어했습니다. Android 5.0에서는 휴대전화와 태블릿 기기 모두의 마스터 볼륨 스트림이 통합되고 STREAM_RING 또는 STREAM_NOTIFICATION로 제어됩니다.

잠금 화면 가시성

이제 Android 5.0에서 기본적으로 알림이 사용자의 잠금 화면에 표시됩니다. 사용자는 민감한 정보가 노출되지 않도록 보호하도록 선택할 수 있으며, 이 경우 시스템에서 알림에 표시된 텍스트를 자동으로 삭제합니다. 수정된 이 알림을 맞춤설정하려면 setPublicVersion()를 사용하세요.

알림에 개인 정보가 포함되어 있지 않거나 알림에서 미디어 재생 제어를 허용하려면 setVisibility() 메서드를 호출하고 알림의 공개 상태 수준을 VISIBILITY_PUBLIC로 설정합니다.

미디어 재생

미디어 재생 상태 또는 전송 컨트롤을 표시하는 알림을 구현하는 경우 맞춤 RemoteViews.RemoteView 객체 대신 새 Notification.MediaStyle 템플릿을 사용하는 것이 좋습니다. 어떤 접근 방식을 선택하든 잠금 화면에서 컨트롤에 액세스할 수 있도록 알림의 공개 상태를 VISIBILITY_PUBLIC로 설정해야 합니다. Android 5.0부터 시스템은 더 이상 잠금 화면에 RemoteControlClient 객체를 표시하지 않습니다. 자세한 내용은 앱에서 RemoteControlClient를 사용하는 경우를 참고하세요.

헤드업 알림

이제 기기가 활성 상태 (즉, 기기가 잠금 해제되어 있고 화면이 켜져 있는 상태)일 때 알림이 작은 플로팅 창 (헤드업 알림이라고도 함)에 표시될 수 있습니다. 이러한 알림은 좁게 표시된 알림과 유사하게 표시되지만 헤드업 알림에는 작업 버튼도 표시됩니다. 사용자는 현재 앱을 나가지 않고도 헤드업 알림에 작업하거나 닫을 수 있습니다.

헤드업 알림을 트리거할 수 있는 조건을 예로 들면 다음과 같습니다.

  • 사용자의 활동이 전체 화면 모드인 경우 (앱이 fullScreenIntent를 사용하는 경우)
  • 알림의 우선 순위가 높고 벨소리나 진동을 사용할 경우

앱이 이러한 시나리오에서 알림을 구현하는 경우 헤드업 알림이 올바르게 표시되는지 확인합니다.

미디어 컨트롤 및 RemoteControlClient

RemoteControlClient 클래스는 이제 지원 중단되었습니다. 최대한 빨리 새 MediaSession API로 전환하세요.

Android 5.0의 잠금 화면에 MediaSession 또는 RemoteControlClient의 전송 컨트롤이 표시되지 않습니다. 대신 앱은 알림을 통해 잠금 화면에서 미디어 재생 컨트롤을 제공할 수 있습니다. 이렇게 하면 앱에서 미디어 버튼의 표시를 더 효과적으로 제어할 수 있으며 잠긴 기기와 잠금 해제된 기기에서 사용자에게 일관된 환경을 제공할 수 있습니다.

Android 5.0에서는 이 목적을 위한 새로운 Notification.MediaStyle 템플릿을 도입했습니다. Notification.MediaStyle는 Notification.Builder.addAction()로 추가한 알림 작업을 앱의 미디어 재생 알림에 삽입된 소형 버튼으로 변환합니다. 세션 토큰을 setSession() 메서드에 전달하여 이 알림이 진행 중인 미디어 세션을 제어한다고 시스템에 알립니다.

알림의 공개 상태를 VISIBILITY_PUBLIC로 설정하여 알림을 모든 잠금 화면에 표시할 수 있는 안전한 알림으로 표시해야 합니다 (보안 여부와 관계없음). 자세한 내용은 잠금 화면 알림을 참고하세요.

앱이 Android TV 또는 Wear 플랫폼에서 실행 중일 때 미디어 재생 컨트롤을 표시하려면 MediaSession 클래스를 구현합니다. 앱에서 Android 기기에서 미디어 버튼 이벤트를 수신해야 하는 경우에도 MediaSession를 구현해야 합니다.

getRecentTasks()

Android 5.0에서 새로운 동시 실행되는 문서 및 활동 작업 기능 (아래의 최근 화면의 동시 실행되는 문서 및 활동 참고)이 도입됨에 따라 사용자 개인 정보 보호를 개선하기 위해 ActivityManager.getRecentTasks() 메서드가 지원 중단되었습니다. 이전 버전과의 호환성을 위해 이 메서드는 호출 애플리케이션 자체 작업과 기타 민감하지 않은 작업 (예: Home)을 포함하여 데이터의 작은 하위 집합을 계속 반환합니다. 앱에서 이 메서드를 사용하여 자체 작업을 검색하는 경우 대신 getAppTasks()를 사용하여 해당 정보를 검색하세요.

Android NDK의 64비트 지원

Android 5.0에서는 64비트 시스템에 대한 지원 기능이 추가되었습니다. 64비트 개선사항은 주소 공간을 늘리고 성능을 개선하면서 기존 32비트 앱을 완전히 지원합니다. 64비트 지원은 암호화를 위한 OpenSSL의 성능도 개선합니다. 또한 이 버전에서는 새로운 네이티브 미디어 NDK API와 네이티브 OpenGL ES (GLES) 3.1 지원을 도입합니다.

Android 5.0에 제공된 64비트 지원을 사용하려면 Android NDK 페이지에서 NDK 버전 10c를 다운로드하여 설치합니다. NDK의 중요한 변경사항 및 버그 수정에 관한 자세한 내용은 버전 10c 출시 노트를 참고하세요.

서비스에 바인딩

이제 Context.bindService() 메서드에는 명시적 Intent가 필요하며 암시적 인텐트가 주어지면 예외가 발생합니다. 앱을 안전하게 유지하려면 Service를 시작하거나 바인딩할 때 명시적 인텐트를 사용하고 서비스에 인텐트 필터를 선언하지 마세요.

WebView

Android 5.0은 앱의 기본 동작을 변경합니다.

  • 앱이 API 수준 21 이상을 타겟팅하는 경우:
    • 시스템은 기본적으로 혼합 콘텐츠 및 서드 파티 쿠키를 차단합니다. 혼합 콘텐츠와 서드 파티 쿠키를 허용하려면 각각 setMixedContentMode() 및 setAcceptThirdPartyCookies() 메서드를 사용하세요.
    • 이제 시스템은 그릴 HTML 문서의 일부를 지능적으로 선택합니다. 이 새로운 기본 동작은 메모리 사용량을 줄이고 성능을 높이는 데 도움이 됩니다. 전체 문서를 한 번에 렌더링하려면 enableSlowWholeDocumentDraw()를 호출하여 이 최적화를 사용 중지합니다.
  • 앱이 21보다 낮은 API 수준을 타겟팅하는 경우: 시스템은 혼합 콘텐츠와 서드 파티 쿠키를 허용하며 항상 전체 문서를 한 번에 렌더링합니다.

사용자 지정 권한에 대한 고유성 요구사항

권한 개요에 설명된 대로 Android 앱은 플랫폼의 사전 정의된 시스템 권한을 사용하지 않고도 독점적인 방식으로 구성요소에 대한 액세스를 관리하는 수단으로 맞춤 권한을 정의할 수 있습니다. 앱은 매니페스트 파일에 선언된 <permission> 요소에서 맞춤 권한을 정의합니다.

맞춤 권한을 정의하는 것이 적법하고 안전한 접근 방식인 시나리오는 소수에 불과합니다. 하지만 맞춤 권한을 만드는 것이 불필요할 때도 있으며 권한에 할당된 보호 수준에 따라 앱에 잠재적인 위험을 초래할 수도 있습니다.

Android 5.0에는 권한을 정의하는 다른 앱과 동일한 키로 서명되지 않는 한 하나의 앱만 지정된 맞춤 권한을 정의할 수 있도록 하는 동작 변경사항이 포함되어 있습니다.

중복 사용자 지정 권한을 사용하는 앱

모든 앱은 원하는 맞춤 권한을 정의할 수 있으므로 여러 앱에서 동일한 맞춤 권한을 정의할 수 있습니다. 예를 들어 두 앱이 유사한 기능을 제공하는 경우 맞춤 권한에 동일한 로직 이름을 가져올 수 있습니다. 앱이 동일한 맞춤 권한 정의를 포함하는 공통 공개 라이브러리 또는 코드 예시를 통합할 수도 있습니다.

Android 4.4 이하에서는 시스템이 처음 설치된 앱에서 지정한 보호 수준을 할당했지만 사용자가 특정 기기에 이러한 앱을 여러 개 설치할 수 있었습니다.

Android 5.0부터 시스템은 서로 다른 키로 서명된 앱에 새로운 맞춤 권한 고유성 제한을 적용합니다. 이제 권한을 정의하는 다른 앱이 동일한 키로 서명되지 않는 한 기기의 앱 하나만 이름으로 지정된 특정 맞춤 권한을 정의할 수 있습니다. 사용자가 중복 맞춤 권한이 있는 앱을 설치하려고 하며 이 앱이 권한을 정의하는 상주 앱과 동일한 키로 서명되지 않은 경우 시스템은 설치를 차단합니다.

앱에 대한 고려 사항

Android 5.0 이상에서는 앱이 이전과 마찬가지로 자체 맞춤 권한을 계속 정의하고 <uses-permission> 메커니즘을 통해 다른 앱의 맞춤 권한을 요청할 수 있습니다. 하지만 Android 5.0에 도입된 새로운 요구사항으로 인해 앱에 미칠 수 있는 영향을 신중하게 평가해야 합니다.

다음은 몇 가지 고려할 사항입니다.

  • 앱이 매니페스트에서 <permission> 요소를 선언하나요? 그렇다면 앱 또는 서비스의 올바른 작동에 실제로 필요한 권한인가요? 또는 시스템 기본 권한을 대신 사용할 수 있나요?
  • 앱에 <permission> 요소가 있는 경우 요소의 출처를 알고 있나요?
  • 다른 앱이 <uses-permission>를 통해 맞춤 권한을 요청하도록 의도하시나요?
  • 앱에서 <permission> 요소가 포함된 템플릿 또는 예시 코드를 사용하고 있나요? 이러한 권한 요소가 실제로 필요한가요?
  • 맞춤 권한의 이름이 간단하거나 다른 앱에서 공유할 수 있는 일반적인 용어를 기반으로 하나요?

새로운 설치 및 업데이트

위에서 언급한 대로 Android 4.4 이하를 실행하는 기기에서 앱을 새로 설치하거나 업데이트하는 경우 영향을 받지 않으며 동작에 변화가 없습니다. Android 5.0 이상을 실행하는 기기에서 새로 설치하거나 업데이트할 때 기존 상주 앱에서 이미 정의한 맞춤 권한을 정의하면 시스템은 앱 설치를 차단합니다.

Android 5.0 시스템 업데이트를 이용한 기존 설치

앱이 맞춤 권한을 사용하고 널리 배포 및 설치된 경우 사용자가 기기를 Android 5.0으로 업데이트할 때 영향을 받을 수 있습니다. 시스템 업데이트가 설치되면 시스템은 맞춤 권한 확인을 포함하여 설치된 앱의 유효성을 다시 검사합니다. 앱이 이미 유효성 검사를 마친 다른 앱에서 이미 정의한 맞춤 권한을 정의하고 앱이 다른 앱과 동일한 키로 서명되지 않은 경우 시스템은 앱을 다시 설치하지 않습니다.

권장사항

Android 5.0 이상을 실행하는 기기에서는 앱을 즉시 검토하고 필요한 조정을 한 후 업데이트된 버전을 최대한 빨리 사용자에게 게시하는 것이 좋습니다.

  • 앱에서 맞춤 권한을 사용하는 경우 권한의 출처와 실제로 필요한지 여부를 고려하세요. 앱의 올바른 작동에 필요한 것이 아니라고 확신할 수 없는 한 앱에서 모든 <permission> 요소를 삭제합니다.
  • 가능하면 맞춤 권한을 시스템 기본 권한으로 대체하는 것이 좋습니다.
  • 앱에 맞춤 권한이 필요한 경우 앱의 전체 패키지 이름에 추가하는 등 앱에 고유하도록 맞춤 권한의 이름을 바꿉니다.
  • 다른 키로 서명된 앱 모음이 있고 앱이 맞춤 권한을 통해 공유 구성요소에 액세스하는 경우 맞춤 권한이 공유 구성요소에서 한 번만 정의되어 있는지 확인합니다. 공유 구성요소를 사용하는 앱은 맞춤 권한을 직접 정의하지 말고 대신 <uses-permission> 메커니즘을 통해 액세스를 요청해야 합니다.
  • 동일한 키로 서명된 앱 모음을 사용하는 경우 각 앱은 필요에 따라 동일한 맞춤 권한을 정의할 수 있습니다. 시스템은 앱을 일반적인 방식으로 설치할 수 있도록 허용합니다.

TLS/SSL 기본 구성 변경

Android 5.0에서는 앱에서 HTTPS 및 기타 TLS/SSL 트래픽에 사용하는 기본 TLS/SSL 구성을 변경합니다.

  • 이제 TLSv1.2 및 TLSv1.1 프로토콜이 활성화됩니다.
  • 이제 AES-GCM (AEAD) 암호화 제품군이 활성화됩니다.
  • 이제 MD5, 3DES, 내보내기 및 정적 키 ECDH 암호화 제품군이 비활성화됩니다.
  • Forward Secrecy 암호화 제품군(ECDHE 및 DHE)을 권장합니다.

이러한 변경으로 인해 아래에 나열된 소수의 경우에 HTTPS 또는 TLS/SSL 연결이 끊어질 수 있습니다.

Google Play 서비스의 보안 ProviderInstaller는 이미 Android 2.3까지 Android 플랫폼 버전 전반에서 이러한 변경사항을 제공하고 있습니다.

서버가 활성화된 암호화 제품군을 지원하지 않음

예를 들어 서버는 3DES 또는 MD5 암호화 제품군만 지원할 수 있습니다. 서버 구성을 개선하여 더 강력하고 최신 암호화 스위트와 프로토콜을 사용 설정하는 것이 좋습니다. TLSv1.2 및 AES-GCM을 사용 설정하고 Forward Secrecy 암호화 스위트 (ECDHE, DHE)를 사용 설정하고 선호하는 것이 좋습니다.

또는 맞춤 SSLSocketFactory를 사용하여 서버와 통신하도록 앱을 수정할 수 있습니다. 팩토리는 기본 암호화 모음 외에도 서버에 필요한 일부 암호화 모음이 사용 설정된 SSLSocket 인스턴스를 만들도록 설계되어야 합니다.

앱이 서버에 연결하는 데 사용되는 암호화 제품군에 대해 잘못 가정함

예를 들어 일부 앱에는 authType 매개변수가 RSA일 것으로 예상하지만 ECDHE_RSA 또는 DHE_RSA가 발생하여 중단되는 맞춤 X509TrustManager가 포함되어 있습니다.

서버가 TLSv1.1, TLSv1.2 또는 새로운 TLS 확장 기능을 수용하지 못함

예를 들어 서버와의 TLS/SSL 핸드셰이크가 잘못 거부되거나 중단됩니다. TLS/SSL 프로토콜을 준수하도록 서버를 업그레이드하는 것이 좋습니다. 이렇게 하면 서버가 이러한 최신 프로토콜을 성공적으로 협상하거나 TLSv1 또는 이전 프로토콜을 협상하고 이해하지 못하는 TLS 확장 프로그램을 무시합니다. 경우에 따라 서버에서 TLSv1.1 및 TLSv1.2를 사용 중지하면 서버 소프트웨어가 업그레이드될 때까지 임시 조치로 작동할 수 있습니다.

또는 맞춤 SSLSocketFactory를 사용하여 서버와 통신하도록 앱을 수정할 수 있습니다. 팩토리는 서버에서 올바르게 지원되는 프로토콜만 사용 설정된 SSLSocket 인스턴스를 만들도록 설계되어야 합니다.

관리 프로필 지원

기기 관리자는 기기에 관리 프로필을 추가할 수 있습니다. 이 프로필은 관리자가 소유하므로 관리자는 관리 프로필을 제어할 수 있지만 사용자의 개인 프로필과 저장용량은 사용자의 제어하에 둡니다. 이 변경사항은 다음과 같은 방식으로 기존 앱의 동작에 영향을 줄 수 있습니다.

인텐트 처리

기기 관리자는 관리 프로필에서 시스템 애플리케이션에 대한 액세스를 제한할 수 있습니다. 이 경우 앱이 일반적으로 해당 애플리케이션에서 처리할 관리 프로필의 인텐트를 실행하고 관리 프로필에 인텐트에 적합한 핸들러가 없는 경우 인텐트로 인해 예외가 발생합니다. 예를 들어 기기 관리자는 관리 프로필의 앱이 시스템의 카메라 애플리케이션에 액세스하지 못하도록 제한할 수 있습니다. 앱이 관리 프로필에서 실행 중이고 MediaStore.ACTION_IMAGE_CAPTURE의 startActivityForResult()를 호출하지만 관리 프로필에 인텐트를 처리할 수 있는 앱이 없는 경우 ActivityNotFoundException이 발생합니다.

인텐트를 실행하기 전에 인텐트에 대한 핸들러가 하나 이상 있는지 확인하면 이를 방지할 수 있습니다. 유효한 핸들러를 확인하려면 Intent.resolveActivity()를 호출합니다. 간편하게 사진 찍기: 카메라 앱으로 사진 찍기에서 이에 관한 예시를 확인할 수 있습니다.

프로필에서 파일 공유

각 프로필에는 자체 파일 저장소가 있습니다. 파일 URI는 파일 저장소의 특정 위치를 참조하므로 한 프로필에서 유효한 파일 URI는 다른 프로필에서는 유효하지 않습니다. 이는 일반적으로 생성한 파일에만 액세스하는 앱에는 문제가 되지 않습니다. 그러나 앱이 인텐트에 파일을 연결하는 경우 파일 URI를 연결하는 것은 안전하지 않습니다. 경우에 따라 인텐트가 다른 프로필에서 처리될 수 있기 때문입니다. 예를 들어 기기 관리자는 이미지 캡처 이벤트를 개인 프로필의 카메라 앱에서 처리해야 한다고 지정할 수 있습니다. 관리 프로필의 앱에서 인텐트를 실행하는 경우 카메라는 관리 프로필의 앱에서 읽을 수 있는 위치에 이미지를 쓸 수 있어야 합니다.

한 프로필에서 다른 프로필로 넘어갈 수 있는 인텐트에 파일을 첨부해야 하는 경우 안전을 위해 파일의 콘텐츠 URI를 만들고 사용해야 합니다. 콘텐츠 URI로 파일을 공유하는 방법에 관한 자세한 내용은 파일 공유를 참고하세요. 예를 들어 기기 관리자는 개인 프로필의 카메라에서 ACTION_IMAGE_CAPTURE를 처리하도록 허용할 수 있습니다. 실행 인텐트의 EXTRA_OUTPUT에는 사진이 저장되어야 하는 위치를 지정하는 콘텐츠 URI가 포함되어야 합니다. 카메라 앱은 해당 URI로 지정된 위치에 이미지를 쓸 수 있으며 인텐트를 실행한 앱은 앱이 다른 프로필에 있더라도 해당 파일을 읽을 수 있습니다.

잠금 화면 위젯 지원 제거

Android 5.0에서는 잠금 화면 위젯 지원이 삭제됩니다. 홈 화면의 위젯은 계속 지원됩니다.