API 수준: 21
Android 5.0에는 새로운 기능 및 특징과 더불어 다양한 시스템 변경사항 및 API 동작 변경사항이 포함되어 있습니다. 이 문서에서는 개발자가 이해하고 앱에 고려해야 하는 몇 가지 주요 변경사항을 중점적으로 설명합니다.
이전에 Android용 앱을 게시한 적이 있는 경우 이러한 Android 5.0 변경사항으로 앱이 영향을 받을 수 있다는 점에 유의하세요.
새로운 플랫폼 기능을 개략적으로 알아보려면 Android Lollipop 하이라이트를 참고하세요.
동영상
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 이상에서 알림 디자인에 관한 자세한 내용은 알림 디자인 가이드를 참조하세요.
머티리얼 디자인 스타일
새 머티리얼 디자인 위젯과 일치하도록 흰색 (또는 매우 밝은 배경) 배경 위에 어두운 텍스트로 알림이 그려집니다. 모든 알림이 새로운 색 구성표로 올바르게 표시되는지 확인하세요. 알림이 잘못 표시되면 다음과 같이 수정합니다.
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() 메서드가 지원 중단됩니다. 이전 버전과의 호환성을 위해 이 메서드는 여전히 호출 애플리케이션의 자체 작업과 민감하지 않은 다른 작업 (예: 홈)을 포함하여 데이터의 작은 하위 집합을 반환합니다. 앱이 이 메서드를 사용하여 자체 작업을 검색하는 경우 대신 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은 잠금 화면 위젯 지원을 중단하고 홈 화면에서 위젯을 계속 지원합니다.