Android 5.0 동작 변경 사항

동영상

Dev Byte: Android 5.0의 새로운 기능

동영상

Dev Byte: 알림

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에서는 작동하지 않습니다. 가장 중요한 문제에 대해 알아보려면, ART(Android Runtime)에서 앱 동작 확인을 참조하세요. 다음의 경우에 특히 주의하세요.

앱에서 JNI(Java Native Interface)를 사용하여 C/C++ 코드를 실행합니다.
비표준 코드를 생성하는 개발 도구를 사용합니다(일부 obfuscator 등).
간결한 가비지 컬렉션과 호환되지 않는 기법을 사용합니다.

알림

알림이 이 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() 메서드의 지원이 중단됩니다. 이전 버전과의 호환성을 위해, 이 메서드는 여전히 호출 애플리케이션의 자체 작업과 민감하지 않은 다른 작업(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 Revision 10c를 다운로드하고 설치합니다. NDK의 중요한 변경 사항 및 버그 수정에 대한 자세한 내용은 Revision 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 플랫폼 버전에서 거꾸로 Android 2.3까지 이러한 변경 사항을 제공하고 있습니다.

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

예를 들어 서버는 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은 잠금 화면 위젯에 대한 지원을 제거하며, 계속해서 홈 화면에서 위젯을 지원합니다.