안드로이드-KR

(원문: http://developer.android.com/guide/components/intents-filters.html)

(위치: Develop > API Guides > Intents and Intent Filters)

(전체 번역 글 목록으로 이동하기)

인텐트와 인텐트 필터

인텐트는 앱의 컴포넌트들 간에 요청 및 메시지를 전달해 주는 객체입니다. 인텐트를 사용하는 방법에는 여러가지가 있지만 대표적인 세가지는 아래와 같습니다.

• 액티비티 시작하기:
  하나의 액티비티는 내 앱에서 보통 하나의 화면을 구성합니다. 현재 컴포넌트에서 새로운 액티비티를 실행하기 위해서는, 인텐트에 실행할 액티비티 정보와 (필요하다면) 액티비티에 넘겨줄 데이터를 담아서 startActivity() 호출시 인자로 넘겨주면 됩니다.
  현재 액티비티에서 새로운 액티비티를 실행하고 그로부터 결과값을 받아오고 싶다면, startActivityForResult()를 호출합니다. 새로운 액티비티가 결과값을 설정하고 종료되면, 현재 액티비티의 onActivityResult() 콜백 메소드에서 결과값을 인텐트로 받을 수 있습니다. 자세한 내용은 Activity에 대하여에서 학습하실 수 있습니다.
  
  
• 서비스 시작하기:
  서비스는 사용자에게 UI를 제공하지 않고 백그라운드에서 실행되는 컴포넌트입니다. 파일을 다운로드 하는 경우와 같이 백그라운드에서 한가지 일만 하고 종료되게 하려면, 인텐트에 실행할 서비스 정보와 (필요하다면) 넘겨줄 데이터를 담아서 startService() 호출시 인자로 넘겨주면 됩니다.
  만약, 액티비티와 서비스가 클라이언트-서버 구조로 동작하길 원한다면, bindService() 호출시 서비스 및 필요 데이터를 담은 인텐트를 넘겨서, 액티비티에 서비스를 바인드 합니다. 자세한 내용은 Service에 대하여에서 학습하실 수 있습니다.
  
  
• 알림(broadcast) 발송하기:
  알림은 어떤 앱이건 (퍼미션만 가지고 있다면) 받을 수 있는 메시지입니다. 시스템이 부팅되었을 때나 디바이스가 충전되기 시작할 때 등의 상황에, 시스템은 알림 발송을 위해 이벤트를 발생시킵니다. sendBroadcast(), sendOrderedBroadcast(), sendStickyBroadcast() 호출시 필요한 데이터를 담은 인텐트를 인자로 넘기면 됩니다.

인텐트의 타입

인텐트는 아래와 같이 두가지 타입이 있습니다:

• 명시적 인텐트는 실행할 컴포넌트의 클래스 정보를 명시적으로 가지고 있는 인텐트입니다. 내 앱 안에서 컴포넌트들을 실행할 때는, 컴포넌트들을 다 알고 있기 때문에, 보통 명시적 인텐트를 사용합니다. 
  
  
• 암묵적 인텐트는 실행할 컴포넌트의 클래스 정보 대신 액션값을 선언한 인텐트이며, 다른 앱의 컴포넌트를 실행할 때에도 사용할 수 있습니다. 예를 들어, 내 앱에서 가지고 있는 위치값을 지도 위에서 보고 싶다면, 암묵적 인텐트를 이용하여 지도 기능을 가진 다른 앱의 컴포넌트를 실행할 수 있는 것입니다.

명시적 인텐트를 사용하여 액티비티나 서비스 실행 메소드를 호출하면, 시스템은 즉시 그 인텐트에 지정된 컴포넌트를 실행합니다.

암묵적 인텐트를 사용하면, 시스템은 우선 인텐트에 설정된 액션값 등의 정보와, 다른 앱들의 매니페스트 파일에 선언된 인텐트 필터들을 비교하여 조건에 맞는 컴포넌트를 찾습니다. 그래서 만약 한개의 컴포넌트를 찾았다면 인텐트를 넘겨주며 실행시키고, 두개 이상이라면 사용자가 선택할 수 있도록 화면에 선택 다이얼로그를 보여줍니다.

인텐트 필터는 매니페스트 파일의 컴포넌트 요소 안에 추가되는 요소로서, 컴포넌트가 받고자 하는 인텐트의 액션값 및 데이터 타입 등을 지정합니다. 예를 들면, 액티비티에 인텐트 필터를 선언함으로써, 다른 앱에서 그에 맞는 암묵적 인텐트로 그 액티비티를 실행할 수 있습니다. 반대로 액티비티에 인텐트 필터를 선언하지 않으면, 그 액티비티를 실행할 수 있는 액션값이 없는 것이므로 명시적 인텐트로만 실행할 수 있습니다.

주의사항: 앱의 보안을 위해서, 서비스에는 인텐트 필터를 선언하지 말고 명시적 인텐트로만 실행하도록 합니다. 암묵적 인텐트로 서비스를 실행하는 것은, 그 인텐트에 어떤 서비스가 응답할 것인지를 확신할 수 없고, 어떤 서비스가 실행되는지 사용자가 확인할 수도 없기 때문에 보안적으로 위험합니다.

그림1. 암묵적 인텐트가 어떻게 액티비티를 시작하는지를 표현합니다. 

[1] Activity A에서 인텐트에 액션값을 담아 startActivity() 호출시 인자로 넘깁니다.

[2] Android System이 모든 앱의 인텐트 필터에 대하여, 인텐트의 액션값에 해당하는 것이 있는지 검색합니다.

[3] 검색결과 Activity B를 찾았다면, 시스템은 액티비티 실행을 위해 onCreate() 메소드 호출시 해당 인텐트를 넘겨줍니다.

인텐트 만들기 (Building an Intent)

인텐트 객체는 실행하고자 하는 컴포넌트의 이름이나 카테고리 정보를 전달하는 역할을 하며, 응답하는 컴포넌트에게 액션값과 필요한 데이터들을 전달하기도 합니다.

인텐트가 담고 있는 주요한 정보들은 아래와 같습니다.

컴포넌트 이름 (Component name)

실행할 컴포넌트의 이름입니다.

이것은 명시적 인텐트에 필요한 것으로서, 그 이름에 해당하는 컴포넌트를 실행합니다. 암묵적 인텐트에서는 컴포넌트 이름 대신에 액션(action), 데이터(data), 카테고리(category) 정보를 담고 있습니다(액션은 필수, 데이터와 카테고리는 선택). 보통 앱 내의 컴포넌트를 실행할 때는 컴포넌트 이름을 이용한 명시적 인텐트를 사용합니다. 

주의사항: 서비스는 항상 명시적 인텐트를 사용해야 합니다. 만약 암묵적 인텐트를 사용한다면, 인텐트에 응답하는 서비스가 무엇인지 확신할 수 없고, 사용자들도 어떤 서비스가 실행되는지 볼 수 없기 때문입니다.

컴포넌트 이름은, 패키지명과 클래스명(예를 들면, com.example.ExampleActivity)을 담고 있는 ComponentName 객체로 인텐트에 추가할 수 있으며, setComponent() 메소드를 사용합니다. 그 외에도 인텐트의 setClass(), setClassName() 메소드나 생성자에 클래스 정보를 인자로 넘겨서 실행할 컴포넌트를 명시할 수 있습니다.

액션 (Action)

실행하고자 하는 액션을 나타내는 문자열입니다. (예를 들면, view나 pick)

알림(broadcast) 인텐트의 경우, 액션은 리시버가 어떤 일을 할 것인지를 나타냅니다. 액션은 암묵적 인텐트의 주요한 값이 되며, 인텐트는 그 액션에 따라 필요한 데이터 등을 담을 수 있습니다.

내 앱에서 임의로 액션을 추가하여 사용할 수도 있지만, 보통은 Intent 클래스나 다른 프레임웍에 이미 정의되어 있는 값들을 사용하는 것이 좋습니다.

Intent.ACTION_VIEW

실제값은 "android.intent.action.VIEW" 입니다. 사진을 갤러리 앱에서 보거나 어떤 주소에 대한 위치를 지도 앱에서 볼 때와 같이, 어떤 정보를 가지고 있고 그것을 사용자에게 보여주고자 할 때 사용하기 위해 정의된 값입니다.

Intent.ACTION_SEND

실제값은 "android.intent.action.SEND" 입니다. "공유하기" 기능을 구현할 때 사용하는 이 액션값은, 이메일 앱이나 소셜 공유 앱과 같은 다른 앱을 통해 데이터를 공유하고자 할 때 사용하기 위해 정의된 값입니다.

미리 정의된 일반적인 액션값들은 Intent 클래스의 레퍼런스 정보에서 확인할 수 있으며, 그 외에 안드로이드 프레임웍의 다른 부분에서 정의된 액션값들은 그와 관련된 클래스 정보에서 확인할 수 있습니다. 예를 들어, 설정 앱과 관련된 액션값들은 Settings 클래스에서 확인할 수 있습니다.

액션값은 인텐트의 setAction() 메소드 또는 생성자에 인자로 넘겨 설정할 수 있습니다.

만약 내 앱의 자체적인 액션값을 만든다면, 아래와 같이 앞부분에 패키지명을 넣어 주시기 바랍니다.

static final String ACTION_TIMETRAVEL = "com.example.action.TIMETRAVEL";

데이터 (Data)

액션에 관련된 데이터의 URI(Uri 클래스의 객체)와 그 데이터에 대한 MIME 타입을 말합니다. 데이터는 보통 액션값과 관련되어 있습니다. 예를 들어, 액션값이 ACTION_EDIT이라면, 데이터는 수정할 문서의 URI를 포함하고 있어야 합니다. 

인텐트를 만들 때, 데이터의 URI와 함께 MIME 타입을 지정해야 하는 경우도 있습니다. 예를 들어 이미지 뷰어 액티비티는 동영상 파일을 재생할 필요가 없는데, 이미지나 동영상의 URI가 비슷하여 구분하기 어려운 경우가 있을 수 있습니다. 그래서 안드로이드는 MIME 타입을 이용하여 더 적합한 컴포넌트를 찾습니다. 반면에 MIME 타입을 URI로부터 추론할 수 있는 경우도 있습니다. URI가 content: 로 시작하면, 디바이스의 로컬 저장소에 저장된 데이터이고 컨텐트 프로바이더를 통해 제공된 데이터라는 의미이며, 이때는 프로바이더가 시스템에게 MIME 타입을 알려줍니다.

인텐트 객체에 URI를 담기 위해서는 setData() 메소드를 호출하고, MIME 타입을 담기 위해서는 setType()을 호출하며, 둘다 담기 위해서는 setDataAndType()을 호출합니다.

주의사항: URI와 MIME 타입 모두 셋팅하는 경우에는, setData()와 setType()을 사용하면 안됩니다. setData()는 MIME 타입을 null로 만들고, setType()은 URI를 null로 만들기 때문입니다. 따라서 둘 모두 셋팅하는 경우에는 setDataAndType()을 사용해야만 합니다.

카테고리 (Category)

암묵적 인텐트로 찾고 있는 컴포넌트에 대한 추가적인 정보입니다. 인텐트는 카테고리를 1개 이상 담고 있을 수 있지만, 대부분의 경우 카테고리를 필요로 하지는 않습니다.

일반적으로 접하게 되는 카테고리 두 가지는 아래와 같습니다.

Intent.CATEGORY_BROWSABLE

실행될 액티비티가, 링크로 연결된 컨텐츠(웹문서, 이미지, 이메일 메시지)를 보여줄 수 있는 웹 브라우저 기능을 포함하고 있다는 것을 의미합니다.

Intent.CATEGORY_LAUNCHER

실행될 액티비티가 태스크의 첫 액티비티이며, 런처 화면의 앱 목록에 보여진다는 것을 의미합니다.

카테고리 전체 목록은 Intent 클래스의 레퍼런스 문서에서 확인하실 수 있습니다.

인텐트에 카테고리 정보를 담기 위해서는 addCategory() 메소드를 사용합니다.

위에서 설명한 속성들(컴포넌트 이름, 액션, 데이터, 카테고리)은 인텐트의 성격을 대표하는 값으로서, 시스템이 컴포넌트를 찾을 때 사용됩니다.

하지만 인텐트는, 컴포넌트 찾는 일과 상관 없이 부가적인 정보를 전달할 수 있으며, 아래 두 가지 속성을 지원합니다.

엑스트라 정보 (Extras)

요청된 액션을 수행하는데 필요한 부가적인 정보이며, 키와 값의 조합으로 구성되어 있습니다(key-value pairs). 일부 액션이 특정 종류의 URI를 필요로 하는 것과 마찬가지로, 일부 액션은 특정 엑스트라 정보를 필요로 합니다. 

엑스트라 정보는 인텐트의 다양하게 오버로딩된 putExtra() 메소드에 키와 값을 인자로 넘겨서 셋팅할 수 있습니다. 또한 Bundle 객체를 만들어서 putExtras() 메소드에 넘길 수도 있습니다.

예를 들어 "새 이메일 쓰기" 액티비티를 실행하기 위해서, 인텐트의 액션값은 ACTION_SEND이고, 수신자가 미리 채워져 있도록 하기 위해 putExtra(Intent.EXTRA_EMAIL, "수신자 이메일")을 호출하며, 제목이 미리 채워져 있도록 하기 위해 putExtra(Intent.EXTRA_SUBJECT, "이메일 제목")을 호출합니다.

엑스트라 정보의 키 값을 표준화하기 위해, Intent 클래스에는 상당히 많은 EXTRA_* 상수가 정의되어 있습니다. 만약 내 앱 자체적으로 엑스트라 키를 정의해서 사용해야 한다면, 아래와 같이 앞부분에 패키지명을 넣어야 미리 정의된 값들과 충돌되는 일이 없을 것입니다.

static final String EXTRA_GIGAWATTS = "com.example.EXTRA_GIGAWATTS";

플래그 (Flags)

플래그는 인텐트의 메타데이터 역할을 합니다. 플래그는 액티비티를 어떻게 실행할 것인지(예를 들어, 어떤 태스크(task)에 포함될 것인지)와 실행된 후에 어떻게 처리할 것인지(예를 들어, 최근 액티비티 목록에 포함을 시킬지 말지 여부)를 지시합니다. 

자세한 내용은 Intent 클래스 문서의 setFlags() 메소드 부분에서 학습할 수 있습니다.

명시적 인텐트의 예제

명시적 인텐트는 내 앱의 액티비티나 서비스와 같은 컴포넌트를 실행하기 위한 수단 중 하나로, 인텐트 객체에 컴포넌트 이름을 명시적으로 지정하여 만듭니다. 컴포넌트 이름 이외의 다른 속성들은 없어도 됩니다.

예를 들어, 내 앱에서 웹으로부터 파일을 다운로드 받는 DownloadService 를 만들었다면, 아래 코드와 같이 서비스를 실행할 수 있습니다.

// Executed in an Activity, so 'this' is the Context
// The fileUrl is a string URL, such as "http://www.example.com/image.png"
Intent downloadIntent = new Intent(this, DownloadService.class);
downloadIntent.setData(Uri.parse(fileUrl));
startService(downloadIntent);

Intent(Context, Class) 생성자는 앱의 Context와 실행할 컴포넌트의 Class 객체를 받습니다. 따라서 해당 생성자로 만들어진 인텐트는 명시적으로 DownloadService를 실행할 수 있습니다.

서비스를 만들고 실행하는 것에 대한 자세한 내용은 서비스에 대하여에서 학습하실 수 있습니다.

암묵적 인텐트의 예제

암묵적 인텐트에는, 디바이스의 모든 앱 중에서 원하는 앱을 실행하기 위해 액션값을 지정합니다. 어떤 기능에 대하여 내 앱 안에는 그 기능을 수행할 수 있는 컴포넌트가 없고 다른 앱에는 있을 때 암묵적 인텐트를 사용하여 다른 앱의 컴포넌트를 실행할 수 있습니다. 해당 기능을 수행할 수 있는 컴포넌트가 두 개 이상이라면 사용자가 선택 다이얼로그를 통해 선택할 수 있습니다.

예를 들어, 다른 사람에게 컨텐츠를 공유하고 싶다면, 인텐트에 ACTION_SEND를 설정하고 엑스트라 정보로 공유할 컨텐츠를 추가한 후 startActivity() 호출시 인자로 넘겨주면, 컨텐츠 공유가 가능한 앱들이 선택 다이얼로그로 보여지며 사용자가 그 중 하나를 선택할 수 있습니다.

주의사항: 암묵적 인텐트로 startActivity()를 호출했을 때, 그 인텐트로 찾고자 하는 컴포넌트가 하나도 없을 수도 있습니다. 이 경우, 호출은 실패하고 앱은 종료될 것입니다. 그래서 이러한 경우를 예방하기 위해서는 인텐트 객체의 resolveActivity() 메소드를 이용할 수 있습니다. resolveActivity()의 호출결과가 null이 아니라면 실행될 수 있는 컴포넌트가 있다는 의미이므로 startActivity()가 정상적으로 수행될 것이고, 반대로 null이라면 실행될 컴포넌트가 없으므로 startActivity()를 호출하지 않도록 해당 UI를 비활성 처리해야 할 것입니다.

// Create the text message with a string
Intent sendIntent = new Intent();
sendIntent.setAction(Intent.ACTION_SEND);
sendIntent.putExtra(Intent.EXTRA_TEXT, textMessage);
sendIntent.setType(HTTP.PLAIN_TEXT_TYPE); // "text/plain" MIME type

// Verify that the intent will resolve to an activity
if (sendIntent.resolveActivity(getPackageManager()) != null) {
    startActivity(sendIntent);
}

메모: 위 예제의 경우, URI는 사용되지 않지만 엑스트라 정보의 타입을 지정하기 위해 setType()을 호출합니다.

startActivity()가 호출되면, 시스템은 설치된 모든 앱 중에서 인텐트에 부합하는 앱들을 찾습니다 (위의 예제에서 인텐트의 액션값은 ACTION_SEND이고, 데이터 타입은 text/plain입니다). 만약 인텐트에 부합하는 앱이 한 개라면 그 앱을 바로 실행하고, 두 개 이상이라면 사용자에게 선택 다이얼로그를 보여줍니다. 여기서는 앱을 찾는다고 표현했으나 실제로는 컴포넌트를 찾는 것이며, 선택 다이얼로그에서는 해당 컴포넌트를 포함하고 있는 앱을 보여줍니다. 

앱 선택 다이얼로그 띄우기

암묵적 인텐트에 부합하는 앱이 두 개 이상인 경우, 사용자는 어떤 앱을 실행할 지 선택할 수 있고, 선택한 앱을 기본값으로 사용할 수도 있습니다. 이것은 사용자가 어떤 액션에 대해서는 항상 같은 앱이 실행되기를 바랄 때 유용합니다. 예를 들면, 만약 브라우저 앱이 여러개 있다면 웹페이지 링크를 클릭했을 때 선택 다이얼로그가 뜰 것입니다. 이때 하단에 체크박스(이 작업에 대해 기본값으로 사용)를 체크하고 크롬을 선택하면, 다음부터는 바로 크롬이 실행됩니다.

하지만 사용자가 상황에 따라 다른 앱을 선택할 수 있어야 하는 경우라면, 항상 사용자가 선택 다이얼로그를 볼 수 있도록 명시적으로 다이얼로그를 출력해 줘야 합니다. 예를 들어, 아래 코드 예제에서와 같이 createChooser()로 인텐트를 만들어서 startActivity() 하면 [그림2]와 같이 선택 다이얼로그가 뜨는데, 여기에는 하단의 기본값 설정 관련 체크박스가 없습니다.

Intent intent = new Intent(Intent.ACTION_SEND);
...

// Always use string resources for UI text.
// This says something like "Share this photo with"
String title = getResources().getString(R.string.chooser_title);
// Create intent to show chooser
Intent sendIntent = Intent.createChooser(intent, title);

// Verify the intent will resolve to at least one activity
if (sendIntent.resolveActivity(getPackageManager()) != null) {
    startActivity(sendIntent);
}

createChooser() 호출시 인자로 넘겨주는 title은 선택 다이얼로그의 상단에 출력되는 제목입니다.

그림2. 선택 다이얼로그

암묵적 인텐트 받기 

암묵적 인텐트를 받을 수 있는 컴포넌트가 되려면, 매니페스트 파일의 컴포넌트 요소 안에 하나 이상의 인텐트 필터 요소(<intent-filter>)를 선언해야 합니다. 각 인텐트 필터는 인텐트의 액션, 데이터, 카테고리에 대응되는 요소들을 포함합니다. 시스템은 컴포넌트의 인텐트 필터들을 확인하여 인텐트에 부합하는 인텐트 필터가 있을 경우에만 그 인텐트를 컴포넌트에게 전달합니다. 

메모: 명시적 인텐트는 인텐트 필터와 상관 없이 대상 컴포넌트에게 전달됩니다.

앱의 컴포넌트는 어떤 일을 할 것인가에 따라 구분된 인텐트 필터를 선언해야 합니다. 예를 들어, 갤러리 앱의 액티비티는 아마도 두 개의 인텐트 필터를 가질 것인데, 하나는 이미지를 보는 것에 대한 필터일 것이고 다른 하나는 이미지를 편집하는 것에 대한 필터일 것입니다. 액티비티가 시작되면, 그 액티비티는 넘겨받은 인텐트의 액션값 등을 확인하여, 이미지를 그냥 보여줄 것인지 아니면 편집화면을 보여줄 것인지를 결정합니다.

인텐트 필터는 매니페스트 파일에서 <activity>와 같은 컴포넌트 요소의 자식 요소인 <intent-filter>로 선언되고, <intent-filter> 요소에는 다시 자식 요소로 아래 세가지 요소들이 선언됩니다. 

<action>
받아들일 인텐트의 액션값을 name 속성에 선언합니다. 이때 주의할 점은, 자바코드의 Intent.ACTION_SEND와 같은 변수명이 아니라 "android.intent.action.SEND"와 같은 실제 문자열을 넣어야 한다는 것입니다.

<data>
받아들일 인텐트의 데이터 타입을 한 개 이상 선언할 수 있습니다. 여기에는 URI를 구성하는 부분들(scheme, host, port, path 등)과 MIME 타입이 선언됩니다.

<category>
받아들일 인텐트의 카테고리를 name 속성에 선업합니다. 이때 주의할 점은 변수명이 아니라 실제 문자열을 넣어야 한다는 것입니다.

메모: 암묵적 인텐트를 받기 위해서는 인텐트 필터에 "android.intent.category.DEFAULT" 가 반드시 포함되어 있어야 합니다. startActivity()와 startActivityForResult() 메소드는 모든 인텐트에 Intent.CATEGORY_DEFAULT가 선언되어 있다고 전제하고 동작하기 때문에, 인텐트 필터에 CATEGORY_DEFAULT가 선언되어 있지 않으면, 인텐트에 부합하는 컴포넌트가 되지 못합니다.

아래 예제는, 액션이 ACTION_SEND이고 데이터 타입이 텍스트인 인텐트를 받을 수 있는 액티비티의 선언입니다.

<activity android:name="ShareActivity">
    <intent-filter>
        <action android:name="android.intent.action.SEND"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <data android:mimeType="text/plain"/>
    </intent-filter>
</activity>

하나의 인텐트 필터가 <action>, <data>, <category>를 각각 두 개 이상씩 포함할 수도 있습니다. 이러한 경우에는 모든 조합에 대하여 한 가지만 조건에 맞아도 인텐트가 필터를 통과할 수 있습니다.

만약 여러 종류의 인텐트를 받고 싶으나 특정 조합들에 대해서만 제한하고 싶다면, 각 조합들에 해당하는 인텐트 필터들을 추가하면 됩니다.

암묵적 인텐트는 액션, 데이터, 카테고리에 대하여 인텐트 필터의 그것들과 각각 테스트를 하며, 모든 테스트가 통과되어야만 컴포넌트에게 인텐트가 전달되며, 하나라도 통과하지 못하면 인텐트가 전달되지 않습니다. 하지만 인텐트 필터가 여러개일 경우, 어떤 인텐트 필터에 대하여 테스트가 실패하면 다음 인텐트 필터에 대하여 테스트하게 되고, 테스트가 통과되는 인텐트 필터를 찾을 때까지 모두 확인합니다. 시스템이 인텐트를 처리하는 방법에 대한 자세한 내용은 아래의 인텐트 처리하기에서 학습할 수 있습니다.

주의사항: 우연히 다른 앱의 서비스가 실행되는 일이 없도록 하기 위해, 내 앱의 서비스를 실행할 때는 명시적 인텐트를 사용하고, 서비스에는 인텐트 필터를 선언하지 않도록 합니다.

메모: 액티비티를 선언하거나 액티비티에 인텐트 필터를 선언하는 것은 매니페스트 파일에서만 가능합니다. 하지만 브로드캐스트 리시버는 소스코드에서 registerReceiver()로 등록할 수 있고(이때 인텐트 필터를 설정합니다), unregisterReceiver()로 해제할 수 있습니다. 매니페스트에 선언된 리시버는 시스템이 정해놓은 시점에 등록 및 해제가 되지만, 소스코드에서는 개발자가 원하는 시점에 리시버를 등록 및 해제할 수 있습니다.

컴포넌트로의 접근 제한 방법: 컴포넌트에 인텐트 필터를 선언하는 것은 암묵적 인텐트의 종류를 제한하기는 하지만 다른 앱에 의해 실행될 수 있기 때문에 보안적으로 안전한 방법은 아닙니다. 또한 다른 앱에서 내 앱의 컴포넌트 이름을 알고 있다면 명시적 인텐트를 통해 해당 컴포넌트를 실행할 수도 있습니다. 그래서 다른 앱으로부터 내 앱의 컴포넌트를 안전하게 지키기 위해서는 exported 속성을 "false"로 설정해야 합니다. 

인텐트 필터의 예제

아래 예제는 인텐트 필터의 동작에 대한 이해를 돕기 위해 준비한 어떤 소셜 공유 앱의 매니페스트 파일 일부입니다.

<activity android:name="MainActivity">
    <!-- This activity is the main entry, should appear in app launcher -->
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

<activity android:name="ShareActivity">
    <!-- This activity handles "SEND" actions with text data -->
    <intent-filter>
        <action android:name="android.intent.action.SEND"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <data android:mimeType="text/plain"/>
    </intent-filter>
    <!-- This activity also handles "SEND" and "SEND_MULTIPLE" with media data -->
    <intent-filter>
        <action android:name="android.intent.action.SEND"/>
        <action android:name="android.intent.action.SEND_MULTIPLE"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <data android:mimeType="application/vnd.google.panorama360+jpg"/>
        <data android:mimeType="image/*"/>
        <data android:mimeType="video/*"/>
    </intent-filter>
</activity>

첫번째 액티비티인 MainActivity는 앱의 진입점으로서 시작화면이고, 사용자가 런처화면에서 아이콘을 눌러 들어오게 되는 액티비티입니다.

• "android.intent.action.MAIN"(Intent.ACTION_MAIN)은 이 액티비티가 시작화면이고, 부가적인 데이터는 필요로 하지 않는다는 것을 의미합니다.
• "android.intent.category.LAUNCHER" (Intent.CATEGORY_LAUNCHER)는 이 액티비티의 아이콘이 안드로이드 런처화면에 보여진다는 것을 의미합니다. 만약 <activity> 요소에 icon 속성이 정의되어 있지 않다면, <application> 요소의 icon 속성이 사용됩니다.

런처화면에 아이콘이 보여지기 위해서는 인텐트 필터에 위의 두가지가 모두 있어야 합니다.

두번째 액티비티인 ShareActivity는 텍스트나 미디어 컨텐츠를 공유하기 위한 액티비티입니다. 이것은 MainActivity로부터 실행될 수도 있고, 다른 앱으로부터 (두 필터 중 하나와 부합하는) 암묵적 인텐트를 통해 실행될 수도 있습니다.

메모: MIME 타입 중에 application/vnd.google.panorama360+jpg는 파노라마 사진(360도 촬영 사진)을 나타내는 특별한 데이터 타입이며, 파노라마 사진은 구글 파노라마 API (Google panorama APIs)를 사용하여 만들 수 있습니다.

펜딩 인텐트 사용하기

펜딩 인텐트(PendingIntent) 객체는 인텐트 객체를 포함하는 객체이며, 주요 목적은 다른 앱이 펜딩 인텐트에 포함된 인텐트를 마치 자신의 인텐트인양 권한을 부여하는 것입니다. 

펜딩 인텐트는 주로 아래와 같은 상황에서 사용됩니다.

• 노티(Notification)를 노티피케이션바에 올린 경우, 노티를 눌렀을 때 시스템의 NotificationManager가 펜딩 인텐트에 포함된 인텐트를 사용하여 컴포넌트를 실행합니다.
• 앱 위젯(App Widget)을 이용하는 경우, 위젯의 버튼 등을 눌렀을 때, 런처의 홈스크린앱이 펜딩 인텐트에 포함된 인텐트를 사용하여 컴포넌트를 실행합니다.
• 시스템 알람 기능을 이용하는 경우, 미래의 특정 시점이 되었을 때 AlarmManager가 펜딩 인텐트에 포함된 인텐트를 사용하여 컴포넌트를 실행합니다.

각 인텐트는 액티비티, 서비스, 브로드캐스트 리시버 중 하나를 실행하도록 설계되어 있기 때문에, 펜딩 인텐트도 마찬가지로 한가지 목적을 가지고 만들어져야 합니다. 펜딩 인텐트를 사용하는 경우에는 startActivity()와 같은 메소드를 사용할 수 없습니다. 대신에, 아래 소개되는 펜딩 인텐트의 생성 메소드들 중 하나를 사용함으로써 실행할 컴포넌트를 지정해야 합니다.

• PendingIntent.getActivity()는, 인텐트가 실행할 컴포넌트가 액티비티인 경우에 사용하며, 펜딩 인텐트 객체를 반환해 줍니다.
• PendingIntent.getService()는, 인텐트가 실행할 컴포넌트가 서비스인 경우에 사용합니다.
• PendingIntent.getBroadcast()는, 인텐트가 실행할 컴포넌트가 브로드캐스트 리시버인 경우에 사용합니다.

다른 앱으로부터 펜딩 인텐트를 받기만 하는 것이 아니라 만들기도 해야한다면 위의 세가지 메소드가 필요할 것입니다.

각 메소드의 인자로는, 앱의 Context와 펜딩 인텐트 안에 포함할 인텐트, 그리고 인텐트가 어떤 방식으로 사용될 지를 지정하는 플래그를 받습니다. 

펜딩 인텐트를 사용하는 방법에 대한 더 자세한 내용은 노티피케이션(Notifications)과 앱 위젯(App Widget)에서 학습하실 수 있습니다.

인텐트 처리하기

시스템은, 암묵적 인텐트를 받아 액티비티를 실행하려고 할때, 그 인텐트와 설치된 앱들의 인텐트 필터들을 아래 나열된 세가지 측면에서 비교하여 조건에 맞는 액티비티를 찾습니다.

• 인텐트의 액션값
• 인텐트의 데이터 (URI와 데이터 타입)
• 인텐트의 카테고리

아래 내용에서는 원하는 인텐트를 받기 위해 매니페스트 파일에 인텐트 필터를 어떻게 선언할지에 대하여 학습합니다.

액션 테스트 (Action test)

어떤 액션값을 받을지 지정하기 위해, 인텐트 필터는 아래와 같이 0개 이상의 <action> 요소를 선언할 수 있습니다.

<intent-filter>
    <action android:name="android.intent.action.EDIT" />
    <action android:name="android.intent.action.VIEW" />
    ...
</intent-filter>

위의 필터를 통과하기 위해서는 인텐트가 필터에 선언된 두 액션 중 하나를 가지고 있어야 합니다.

만약 필터에 액션이 하나도 선언되지 않았다면, 그 필터를 통과할 수 있는 인텐트는 없을 것입니다.

카테고리 테스트 (Category test)

어떤 카테고리를 받을지 지정하기 위해, 인텐트 필터는 아래와 같이 0개 이상의 <category> 요소를 선언할 수 있습니다.

<intent-filter>
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    ...
</intent-filter>

인텐트가 카테고리 테스트를 통과하기 위해서는, 인텐트가 가지고 있는 카테고리가 모두 필터에 선언된 카테고리들 안에 포함되어야 합니다. 그래서 필터 안에 카테고리들을 더 선언하더라도 기존에 통과하던 인텐트는 여전히 통과할 수 있습니다. 따라서, 카테고리를 가지고 있지 않은 인텐트는 필터에 어떤 카테고리가 선언되었느냐에 상관없이 무조건 통과할 수 있습니다.

메모: 안드로이드는 startActivity()나 startActivityForResult()를 할때 자동적으로 인텐트에 기본 카테고리(Intent.CATEGORY_DEFAULT, "android.intent.category.DEFAULT")를 적용합니다. 따라서 암묵적 인텐트로 액티비티를 실행하려고 한다면, 그 액티비티의 인텐트 필터에 기본 카테고리가 선언되어 있어야 합니다. 

데이터 테스트 (Data test)

어떤 종류의 데이터를 받을지 지정하기 위해, 인텐트 필터는 아래와 같이 0개 이상의 <data> 요소를 선언할 수 있습니다.

<intent-filter>
    <data android:mimeType="video/mpeg" android:scheme="http" ... />
    <data android:mimeType="audio/mpeg" android:scheme="http" ... />
    ...
</intent-filter>

<data>에는 URI를 구성하는 부분들(scheme, host, port, path)과 MIME 타입이 선언됩니다.

<scheme>://<host>:<port>/<path>

와 같은 형태가 되며 예를 들면 아래와 같습니다.

content://com.example.project:200/folder/subfolder/etc

이 URI에서 scheme은 content, host는 com.example.project, port는 200, path는 folder/subfolder/etc 입니다.

<data>의 각 속성들은 옵셔널(optional)하지만, 서로간에 의존성이 있습니다.

• scheme이 없으면, host는 무시됩니다.
• host가 없으면, port는 무시됩니다.
• scheme과 host가 둘다 없으면, path는 무시됩니다.

인텐트가 가지고 있는 URI를 인텐트 필터와 비교할 때는, <data>에 선언된 속성들만을 비교합니다. 예를 들면,

• <data>에 scheme만 선언되어 있다면, 선언된 scheme으로 시작하는 URI들은 모두 테스트를 통과합니다.
• <data>에 scheme과 authority(host+port부분, 실제로 port는 선언되는 경우가 별로 없습니다)가 선언되어 있다면, 선언된 값들로 구성된 URI들은 path와 상관없이 테스트를 통과합니다.
• <data>에 scheme, authority, path가 선언되어 있다면, 선언된 값들로 구성된 URI만이 테스트를 통과합니다.

메모: path 선언시에는 와일드카드 문자 *를 포함하여 융통성 있게 선언할 수 있습니다.

데이터 테스트는 인텐트의 URI와 MIME 타입을, 인텐트 필터에 선언된 URI와 MIME 타입과 비교합니다. 그 규칙은 아래와 같습니다.

1. URI와 MIME 타입이 모두 없는 인텐트는, URI와 MIME 타입이 모두 선언되지 않은 인텐트 필터에서 테스트를 통과합니다.
2. URI는 있으나 MIME 타입이 없는 인텐트는, 마찬가지로 URI는 선언되어 있고 MIME 타입이 선언되지 않은 필터에서 테스트를 통과할 수 있습니다.
3. MIME 타입은 있으나 URI가 없는 인텐트는, MIME 타입이 선언되어 있고 URI가 선언되지 않은 필터에서 테스트를 통과할 수 있습니다.
4. URI와 MIME 타입이 모두 있는 인텐트는, 일단 필터에 일치하는 MIME 타입이 선언되어 있어야 하고 다음 조건을 만족해야 테스트를 통과할 수 있습니다. 인텐트 필터에 URI가 선언되어 있다면 인텐트의 그것과 일치해야 하며, 필터에 URI가 선언되어 있지 않다면 URI가 content: 나 file: 로 시작하는 값이어야 합니다. 바꿔 말하면, 인텐트 필터의 <data>에 MIME 타입만 선언하는 것은, content: 나 file: 로 시작하는 URI만 받겠다는 것을 의미합니다.

위의 마지막 규칙 D는, MIME 타입만 선언된 필터를 가지고 있는 컴포넌트가 파일 시스템이나 컨텐트 프로바이더를 통해 로컬 파일을 처리할 수 있다는 것을 알려줍니다. 따라서 이러한 경우는 데이터 타입들만 선언하고, 명시적으로 scheme에 content나 file을 선언할 필요는 없습니다. 이것은 전형적인 사용 방식으로서, 아래 예제는 시스템에게, 이 필터를 포함한 컴포넌트는 컨텐트 프로바이더로부터 이미지를 얻어와 보여주는 역할을 한다라고 말해줍니다.

<intent-filter>
    <data android:mimeType="image/*" />
    ...
</intent-filter>

많은 경우의 데이터들이 컨텐트 프로바이더로부터 오기 때문에, 인텐트 필터의 <data> 요소에 URI 관련 선언이 없는 경우가 일반적입니다.

위와 다르게, <data>에 scheme과 mimeType이 선언된 경우가 있습니다. 아래 예제는 시스템에게, 이 필터를 포함한 컴포넌트가 네트웍을 통해 동영상 데이터를 받아오는 역할을 한다라고 말해줍니다.

<intent-filter>
    <data android:scheme="http" android:mimeType="video/*" />
    ...
</intent-filter>

인텐트 매칭 (Intent matching)

인텐트는 두 가지 목적에서 인텐트 필터와 비교합니다. 실행할 컴포넌트를 찾기 위해서이기도 하고, 어떤 조건에 맞는 컴포넌트 목록을 얻어오기 위해서이기도 합니다. 예를 들어 홈스크린앱은, 설치된 모든 앱에서 인텐트 필터에 ACTION_MAIN과 CATEGORY_LAUNCHER가 선언된 액티비티들을 찾아와 화면에 그 목록을 보여주는 것이 주된 역할입니다.

내 앱에서도 비슷한 방식으로 인텐트 매칭을 사용할 수 있습니다. PackageManager는 query...() 형태의 메소드들과 resolve...() 형태의 메소드들을 지원합니다. query...()은 인텐트를 받을 수 있는 모든 컴포넌트의 목록을 리턴해주고, resolve...()은 가장 적절한 컴포넌트를 리턴해 줍니다. 예를 들어, queryIntentActivities()는 인텐트를 받을 수 있는 모든 액티비티들을 리턴해주고, queryIntentServices()는 서비스들을 리턴해주며, queryBroadcastReceivers()는 브로드캐스트 리시버들을 리턴해줍니다. 위의 세 메소드는 실제로 컴포넌트를 실행하거나 하지는 않고, 단지 목록을 리턴해주기만 합니다.

(원문: http://developer.android.com/guide/components/index.html)

(위치: Develop > API Guides > App Components)

(전체 번역 글 목록으로 이동하기)

앱 컴포넌트

안드로이드의 앱 개발 프레임웍은 재사용 가능한 컴포넌트들을 사용함으로써 혁신적인 앱을 만들 수 있도록 해줍니다. 이어지는 섹션들에서는 컴포넌트들을 만드는 방법과 인텐트로 서로 연결하는 방법을 학습합니다.

Intent와 Intnt Filter >

트레이닝 카테고리의 관련 글:

액티비티(Activity)의 생명주기 관리하기

액티비티 생명주기에 따른 콜백 메소드들의 구현 방법에 대하여 학습합니다. 액티비티는 사용자들에게 익숙한 UI를 제공해야 하고, 쓸데없이 시스템 리소스를 낭비하지 않아야 합니다.

프레그먼트(Fragment)를 이용한 동적 UI 개발하기

프레그먼트를 이용하여 스마트폰 및 태블릿에 모두 대응할 수 있는 동적 UI를 개발하는 방법을 학습합니다. 다만, 프레그먼트는 안드로이드 버전 1.6부터 사용 가능합니다.

컨텐츠 공유하기

인텐트와 액션 프로바이더(ActionProvider)를 사용하는 앱들간에 컨텐츠를 주고 받는 일반적인 방법들에 대하여 학습합니다.

(원문: 

http://developer.android.com/guide/topics/security/permissions.html)

(위치: Develop > API Guides > Introduction > System Permissions)

(전체 번역 글 목록으로 이동하기)

시스템 퍼미션

안드로이드는 유저 및 그룹별로 권한이 분리되어 있는 OS로서, 앱들은 각각의 시스템 ID(리눅스 유저 ID와 그룹 ID)를 가지고 실행됩니다. 시스템의 각 부분들도 각각의 ID를 갖고 분리되어 있습니다. 리눅스에서, 앱들은 서로 분리된 환경에서 구동되고, 또 시스템과도 분리되어 있는데, 안드로이드가 이러한 리눅스를 기반으로 하고 있는 것입니다.

추가로 도입된 보안적 특징은 퍼미션(permission) 메커니즘을 통해 실행을 제한한다는 점입니다. 특정 프로세스의 실행을 제한할 수 있고, 특정 데이터에 접근을 허용하는 URI들에 대해서도 실행을 제한할 수 있습니다.

여기서는 개발자들이 안드로이드의 보안 특징들을 어떻게 이용할 수 있는지 설명하겠습니다. 더 자세한 내용은 안드로이드 보안 훑어보기에서 학습하실 수 있습니다.

보안 아키텍쳐 (Security Architecture)

안드로이드 보안 아키텍쳐의 핵심은, 기본적으로 앱들이 다른 앱이나 OS, 또는 사용자에게 불리한 영향을 미칠 만한 퍼미션들을 갖고 있지 않습니다. 여기에는 주소록이나 이메일과 같은 사용자 개인 정보의 읽기/쓰기 권한과, 다른 앱의 파일에 대한 읽기/쓰기 권한, 그리고 네트워크 접속과 관련된 권한, 디바이스를 켜진 상태로 유지하는 권한 등이 포함됩니다.

안드로이드 앱은 각각의 프로세스 샌드박스에서 구동되기 때문에, 앱끼리 리소스나 데이터를 공유하려면 명시적으로 해야 합니다. 이것은, 기본적으로는 사용할 수 없지만 퍼미션을 선언함으로써 사용할 수 있다는 의미입니다. 앱들은 필요한 퍼미션들을 매니페스트 파일에 선언해야 하고, 안드로이드 시스템은 앱이 설치되기 직전에 사용자에게 퍼미션 목록을 보여줌으로써 동의를 구합니다. 안드로이드는 보안과 관련된 사용자 경험을 복잡하게 만들지 않기 위해서, 런타임에 동적으로 퍼미션을 관리하지는 않습니다. 다시 말해서, 앱을 설치할 때 한번 사용자에게 모든 동의를 받고, 앱을 실행하는 중에는 퍼미션과 관련된 절차를 거치지 않는다는 것입니다.

앱의 샌드박스는 앱을 빌드할 때 사용하는 개발언어 및 기술들에 의존적이지 않습니다. 좀더 구체적으로 말하면, 달빅 가상머신(Dalvik VM)은 보안 환경 안에 있지 않으며, 어떤 앱이던 C/C++과 같은 네이티브 코드(안드로이드 NDK 참고)를 실행할 수 있습니다. 즉, 자바로 개발된 앱이나, C/C++로 개발된 앱이나, 또는 둘을 혼용한 앱이나 모두 같은 방식의 샌드박스 안에서 실행되며, 서로간의 보안 환경도 같습니다.

앱에 사인하기 (Application Signing)

모든 APK 파일들(.apk)은 개발자의 개인키가 되는 증명서로 사인이 되어 있어야만 합니다. 이 증명서는 앱의 소유자를 확인하는 용도로 사용되는데, 인증 기관을 통해 발행되는 것이 아니라 개발자가 자체적으로 만드는 것이며(self-signed), 안드로이드에서 이러한 증명서들의 목적은 앱의 소유자를 구분하는 것입니다. 시스템이 시그니쳐 레벨의 퍼미션(signature-level permissions)을 승인하거나 거부할 때, 그리고 동일한 리눅스 ID로부터 요청받은 사항을 승인하거나 거부할 때 증명서를 사용합니다.

유저 ID와 파일 접근성(User IDs and File Access)

안드로이드는 앱을 설치할 때 해당 앱의 대표 패키지명에 대응되는 리눅스 유저 ID를 부여합니다. 이 ID는 해당 패키지가 디바이스에서 제거될 때까지 상수로 남습니다. 안드로이드 OS는 각 디바이스에 따로 있기 때문에, 같은 패키지에 대한 유저 ID가 디바이스마다 서로 다를 수는 있겠지만, 한 디바이스 안에서 서로 구분만 되면 되기 때문에 문제가 되지는 않습니다.

보안 실행은 프로세스 레벨에서 발생하기 때문에, 서로 다른 리눅스 유저 ID를 갖는 두 개의 패키지가 하나의 프로세스에서 실행될 수는 없습니다. 그러나 안드로이드 매니페스트 파일(AndroidManifest.xml)의 <manifest> 태그에 있는 sharedUserId 속성값을 똑같이 설정하면, 안드로이드는 이러한 두개의 패키지를 같은 앱으로서 관리하고 같은 유저 ID 및 같은 파일 접근 권한을 사용합니다. 그러나, 보안을 유지하기 위해 두 개의 앱이 같은 증명서로 사인되어야만 합니다.

앱에서 저장한 데이터는 해당 앱의 유저 ID에 할당되기 때문에, 기본적으로 다른 앱에서는 접근하지 못합니다. 그러나, 데이터를 저장하기 위해  getSharedPreferences(String, int), openFileOutput(String, int), openOrCreateDatabase(String, int, SQLiteDatabase.CursorFactory) 메소드들을 호출할 때, MODE_WORLD_RELEASE, MODE_WORLD_WRITEABLE 값을 인자로 넘기면 저장되는 파일의 접근 권한을 변경하여, 다른 앱에서도 읽기 또는 쓰기를 할 수가 있습니다.

퍼미션 사용하기 (Using Permissions)

아주 기본적인 안드로이드 앱은 아무런 퍼미션도 갖고 있지 않습니다. 사용자 경험이나 디바이스에 저장된 데이터와 관련하여, 사용자 동의를 구하지 않고 얻은 퍼미션으로 인해 좋지 않은 영향을 받을 수도 있기 때문입니다. 따라서 보호된 기능들을 사용하기 위해서는 매니페스트 파일(AndroidManifest.xml)에 해당 기능들에 대한 <uses-permission> 태그들을 추가해야 합니다. 

예를 들어, SMS 메시지가 수신될 때, 내 앱에서 이벤트를 받아 관련된 기능을 구현하고자 한다면 아래와 같이 선언해 줘야 합니다.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.app.myapp" >
    <uses-permission android:name="android.permission.RECEIVE_SMS" />
    ...
</manifest>

앱이 설치되기 직전에, 패키지 인스톨러(package installer)가 정상적으로 사인된 앱에 선언된 퍼미션들을 확인하여 사용자에게 보여주고 동의를 구합니다. 그리고 나서 앱이 실행될 때에는 퍼미션과 관련하여 사용자에게 동의를 구하지 않습니다. 만약 매니페스트 파일에 선언되지 않은 기능을 런타임에 사용하려고 하면, 사용자에게 동의를 구하고자 하지 않고 바로 실패 처리해 버립니다.

퍼미션이 선언되지 않아 관련 기능에 대한 호출이 실패한 경우, 대부분은 보안 예외(SecurityException)가 발생되지만 이것이 항상 보장되는 것은 아닙니다. 예를 들면, sendBroadcast(Intent) 메소드는 비동기적으로 동작하기 때문에, 데이터가 브로드캐스트 리시버들에게 제대로 전달되었는지를, 결과를 리턴해주고 나서야 확인합니다. 따라서 sendBroadcast(Intent)를 호출하는 시점에 보안 예외를 잡을 수는 없습니다(try-catch). 하지만 거의 모든 경우에, 퍼미션 실패가 발생되면 시스템 로그가 출력됩니다.

그러나, 구글플레이 스토어에서 앱을 설치할 때와 같이 일반적인 경우에, 사용자가 퍼미션들을 허용하는데에 동의하지 않는다면 그 앱은 설치되지 않기 때문에, 런타임때 보안 예외가 발생할 것에 대해 걱정할 필요는 없습니다. 바꿔 말하면, 앱이 설치가 되었다는 것은 그 앱이 요구하는 모든 퍼미션이 승인되었다는 것을 의미합니다. 이것은 필요한 퍼미션을 모두 매니페스트 파일에 선언했다는 것을 전제합니다.

안드로이드 시스템에 의해 제공되는 퍼미션들은 Manifest.permission 클래스에서 확인할 수 있습니다. 하지만, 내 앱에서 따로 퍼미션을 정의하고 요구할 수 있기 때문에, Manifest.permission 클래스의 퍼미션들이 전부라고 할 수는 없습니다.

내 앱이 실행되는 동안에 퍼미션이 필요한 몇가지 경우들을 요약하면 아래와 같습니다.

• 앱이 시스템에 속한 기능을 사용하려고 할 때
• 다른 앱의 액티비티(activity)를 실행하려고 할 때
• 알림(broadcasts)을 발송하거나 수신하는 경우, 발송자나 수신자를 제한해야 할 때
• 컨텐트 프로바이더(content provider)를 사용할 때
• 서비스(service)를 바인드하거나 시작할 때

주의사항: 

시간이 흘러 안드로이드가 계속 업데이트 되다 보면, 어떤 API를 호출하기 위해 이전에는 신경쓰지 않았던 퍼미션을 요청해야 하는 경우가 생길 수도 있습니다. 이러한 변화 때문에 기존에 출시되어 있던 앱이 영향을 받지 않도록 하기 위해, 안드로이드는 targetSdkVersion 속성값을 확인하여 그 값이 현재 플랫폼 버전보다 낮을 경우, 하위호환을 위해 앱이 퍼미션을 요청하지 않았더라도 승인해 줄 수 있습니다.

예를 들면, API 레벨 4에서 외부 저장소로의 접근을 제한하기 위해 WRITE_EXTERNAL_STORAGE 퍼미션이 추가되었는데, 만약 내 앱의 targetSdkVersion이 3이하로 되어 있다면, API 레벨 4 이상의 안드로이드에서는 해당 퍼미션을 내 앱에 추가해 줍니다.

만약 내 앱에 이러한 경우가 생긴다면, 실제로 내 앱에서 외부 저장소 관련 기능을 사용하지 않더라도 구글플레이에서는 사용자에게 보여주는 퍼미션 목록에 WRITE_EXTERNAL_STORAGE 퍼미션을 추가한다는 것을 기억해야 합니다.

이렇게 필요하지도 않은 퍼미션이 사용자에게 보여지는 것을 막기 위해서는 targetSdkVersion을 가능한 한 높게 설정해야 합니다. 안드로이드 버전에 따라 어떤 퍼미션들이 추가되었는지에 대해서는 Build.VERSION_CODE 클래스 문서에서 확인하실 수 있습니다.

새로운 퍼미션의 정의와 사용

(Declaring and Enforcing Permissions)

새로운 퍼미션을 정의하기 위해서는 AndroidManifest.xml에 <permission> 태그를 선언해야 합니다.

예를 들어, 다른 앱들이 아무런 제한 없이 내 앱의 액티비티를 실행하는 것을 방지하기 위해 아래와 같이 퍼미션을 선언할 수 있습니다.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.me.app.myapp" >
    <permission android:name="com.me.app.myapp.permission.DEADLY_ACTIVITY"
        android:label="@string/permlab_deadlyActivity"
        android:description="@string/permdesc_deadlyActivity"
        android:permissionGroup="android.permission-group.COST_MONEY"
        android:protectionLevel="dangerous" />
    ...
</manifest>

<protectionLevel> 속성은 필수 입력 사항이며, 앱이 해당 퍼미션을 필요로 한다는 것을 사용자에게 알려줄 때 어느 정도의 영향을 줄 수 있는 퍼미션인지를 나타냅니다. 링크된 문서에서 자세히 학습하실 수 있습니다.

<permissionGroup> 속성은 선택 입력 사항이며, 시스템이 퍼미션을 사용자에게 보여줄 때 추가적으로 보여지는 정보에 불과합니다. 보통은 표준 시스템 그룹(android.Manifest.permission_group 클래스 참조)에 정의된 값을 사용하는데, 때에 따라서는 내 앱에서 정의한 값을 사용해야할 경우도 있을 것입니다. 하지만 사용자에게 보여지는 UI를 단순화하기 위해서는 기존에 있는 값을 사용하는게 권장됩니다. 이런저런 앱들을 설치할 때 항상 보던 문구가 아닌 다른 것이 있다면 사용자 입장에서는 다소 혼란스러울 수도 있기 때문입니다.

android:label과 android:description은 사용자에게 보여지는 퍼미션 정보입니다. label은 퍼미션 목록에 보여지는 짧은 제목이고, description은 해당 퍼미션에 대한 자세한 정보로서 보통 2개의 문장으로 이루어져 있는데, 첫 문장에서 퍼미션에 대해 설명하고 두번째 문장에서는 해당 퍼미션을 승인했을 때 발생할 수도 있을 좋지 않은 영향에 대해 경고합니다.

아래의 예는 CALL_PHONE 퍼미션의 label과 description 입니다.

    <string name="permlab_callPhone">directly call phone numbers</string>
    <string name="permdesc_callPhone">Allows the application to call
        phone numbers without your intervention. Malicious applications may
        cause unexpected calls on your phone bill. Note that this does not
        allow the application to call emergency numbers.</string>

현재 시스템에 정의되어 있는 퍼미션들은 시스템 설정 앱이나 쉘 명령어를 통해 확인할 수 있습니다. 설정 앱을 사용할 경우, 설정 > 애플리케이션 에서 앱을 선택한 후 하단의 권한 정보를 확인하면 됩니다. 그리고 쉘 명령어를 이용하는 경우, 콘솔창에서 adb shell pm list permissions 를 입력하면 되는데 끝부분에 -s 옵션을 추가하면 사용자들이 보게 될 화면과 유사하게 콘솔창에 출력해 줍니다.

$ adb shell pm list permissions -s
All Permissions:

Network communication: view Wi-Fi state, create Bluetooth connections, full
Internet access, view network state

Your location: access extra location provider commands, fine (GPS) location,
mock location sources for testing, coarse (network-based) location

Services that cost you money: send SMS messages, directly call phone numbers

...

AndroidManifest.xml에서 퍼미션 적용하기

시스템이나 앱의 모든 컴포넌트에 대해 접근을 제한하는 고수준의 퍼미션들은 AndroidManifest.xml을 통해 요청됩니다. 요청시 필요한 것은 매니페스트의 컴포넌트 요소에 android:permission 속성을 추가하는게 전부입니다.

액티비티의 퍼미션은 누가 그 액티비티를 시작할 수 있는지를 제한합니다. Context.startActivity()와 Activity.startActivityForResult()가 호출되었을 때, 호출한 쪽에서 호출받는 액티비티의 퍼미션을 가지고 있지 않다면 SecurityException이 발생됩니다.

마찬가지로 서비스의 퍼미션은 누가 그 서비스를 시작하거나 바인드할 수 있는지를 제한합니다. Context.startService(), Context.stopService(), Context.bindService()가 호출되었을 때, 퍼미션을 가지고 있지 않다면 SecurityException이 발생됩니다.

브로드캐스트 리시버의 퍼미션은 누가 그 리시버에게 알림(broadcasts)을 발송할 수 있는지를 제한하지만, 액티비티나 서비스의 퍼미션과는 다르게 Context.sendBroadcast()가 반환값(void)을 리턴한 후에, 시스템이 알림을 리시버에게 전달하려고 할 때 퍼미션을 체크합니다. 따라서 퍼미션을 가지고 있지 않아 접근 제한을 받는 상황이라 하더라도 호출한 쪽에서는 SecurityException이 발생되지 않으며, 그저 리시버에게 알림이 가지 않을 뿐입니다. 리시버의 퍼미션은 매니페스트 파일 뿐만 아니라 소스코드 내에서 Context.registerReceiver()를 통해 동적으로 등록될 때에도 설정될 수 있습니다. 그리고 반대로, Context.sendBroadcast()를 호출할 때 퍼미션을 설정하여, 해당 퍼미션을 가지고 있지 않은 리시버는 받지 못하도록 제한할 수도 있습니다.

컨텐트 프로바이더의 퍼미션은 누가 데이터에 접근할 수 있는지를 제한합니다 (컨텐트 프로바이더는 URI 퍼미션이라 불리는 중요한 보안적 특징을 가지고 있습니다). 다른 컴포넌트들과는 다르게 퍼미션 속성이 둘로 나뉘어 있는데, android:readPermission은 읽기 관련 퍼미션이고 android:writePermission은 쓰기 관련 퍼미션입니다. 이 둘은 독립적이기 때문에 쓰기 관련 퍼미션을 가지고 있는 것이 읽기 관련 퍼미션도 가지고 있는 것을 의미하지는 않습니다. 컨텐트 프로바이더의 퍼미션은 프로바이더가 처음 불려져서 실행될 때 체크되며, 만약 호출하는 쪽에서 요구되는 퍼미션을 가지고 있지 않다면 SecurityException이 발생됩니다. ContentResolver.query()는 (만약 프로바이더가 요구한다면) 읽기 관련 퍼미션을 가지고 있어야 하고, ContentResolver.insert(), ContentResolver.update(), ContentResolver.delete()는 쓰기 관련 퍼미션을 가지고 있어야 하며, 이 모든 경우에 대하여 요구되는 퍼미션을 가지고 있지 않은 경우에는 SecurityException이 발생됩니다.

sendBroadcast()할 때 퍼미션 적용하기

위에서 설명한 바와 같이 브로드캐스트 리시버의 퍼미션은 누가 그 리시버에게 알림을 발송할 수 있는지를 제한할 수도 있지만, 반대로 어떤 리시버가 내 알림을 받을 수 있는지를 제한할 수도 있습니다. Context.sendBroadcast()를 호출할 때 퍼미션을 인자로 넘기면, 그 퍼미션을 가지고 있는 리시버만이 알림을 받을 수 있습니다. 

알림을 보내는 쪽(sendBroadcast() 호출)과 알림을 받는 쪽(브로드캐스트 리시버) 모두가 퍼미션을 요구하는 경우도 있을 수 있습니다. 이러한 경우에는 양쪽 모두 퍼미션들을 제대로 가지고 있어야 알림을 제대로 전달받을 수 있습니다.

다른 프로세스의 퍼미션 사용하기

원격 서비스 호출시에도 Context.checkCallingPermission()을 사용하여 퍼미션을 확인할 수 있습니다. 메소드 호출시 퍼미션을 인자로 넘기면, 현재 프로세스가 그 퍼미션을 가지고 있는지를 리턴해 줍니다. 단, 이 메소드는 서로 다른 프로세스간 통신(IPC)일 때에만 사용가능하며, 보통 IDL인터페이스를 통해 사용됩니다. 다시 말해서 Context.checkCallingPermission()은, 다른 앱의 서비스를 바인드하여 필요한 메소드를 호출할 때 먼저 내 앱이 퍼미션을 가지고 있는지를 확인하기 위하여 사용되는 것입니다.

퍼미션을 체크하는 방법 몇 가지를 더 알려드리겠습니다. 만약 다른 프로세스의 pid를 알고 있다면, 그 프로세스가 퍼미션을 가지고 있는지 확인하기 위해 Context.checkPermission(String, int, int)를 사용할 수 있습니다. 그리고 만약 다른 앱의 대표 패키지명을 알고 있다면, 그 앱이 퍼미션을 가지고 있는지 확인하기 위해 PackageManager.checkPermission(String, String)을 사용할 수 있습니다.

URI 퍼미션

지금까지 설명한 표준 퍼미션 시스템은 컨텐트 프로바이더를 사용할 때 다소 부족한 점이 있습니다. 컨텐트 프로바이더는 프로바이더 자체에 대해 읽기 및 쓰기 관련 퍼미션을 적용하고 있는데 반해, 프로바이더를 사용하고자 하는 클라이언트는 특정 URI들만 필요로 할 수 있기 때문입니다. 한가지 예로 이메일 앱에 이미지가 첨부되어 있고, 이것을 이미지 뷰어 앱으로 보는 경우를 들 수 있습니다. 이메일 앱은 민감한 사용자 정보를 다루기 때문에 퍼미션들에 의해 보호되어야 하며, 이미지 뷰어 앱은 이메일 내용에 대해서는 알 필요가 없기 때문에 이메일 관련 퍼미션은 가지고 있지 않습니다. 

이러한 경우의 해결책이 바로 URI당 퍼미션(per-URI permissions)입니다. 액티비티를 시작할 때나(startActivity()), 시작된 액티비티에서(startActivityForResult()) 돌려줄 결과값을 추가할 때, 인텐트에 Intent.FLAG_GRANT_READ_URI_PERMISSION과 Intent.FLAG_GRANT_WRITE_URI_PERMISSION을 설정할 수 있습니다. 이것은 컨텐트 프로바이더에 대한 퍼미션과 상관 없이 특정 URI에 대한 읽기 또는 쓰기 권한을 주는 것입니다.

이 메카니즘은 사용자와의 상호작용(첨부파일을 열거나, 주소록의 항목을 선택하는 등)을 통해 세분화된 퍼미션을 임시로 허용해 줍니다. 만약 이런 방법이 없고 이미지 뷰어 앱으로 첨부된 이미지를 봐야 한다면, 첨부된 이미지를 볼 수 있게 하는 퍼미션을 만들어야 할 것입니다. 이렇게 특정 앱들간의 직접적인 문제들로 인해 퍼미션들이 생성되는 것을 줄이는 것이 URI당 퍼미션의 중요한 목적 중 하나입니다.

하지만 이것은 컨텐트 프로바이더의 협조를 필요로 합니다. 컨텐트 프로바이더는 URI당 퍼미션을 허용하기 위해, 매니페스트 파일의 프로바이더 요소 안에 android:grantUriPermissions 속성을 추가하거나, <grant-uri-permissions> 태그를 추가해야 합니다.

더 자세한 내용은 Context.grantUriPermission(), Context.revokeUriPermission(), Context.checkUriPermission() 메소드에 대한 레퍼런스 정보에서 확인하시기 바랍니다. 

이어서 학습할 내용들:

암묵적으로 기능을 요구하는 퍼미션들

내 앱에서 요구되는 퍼미션이 디바이스에서 제공하는 하드웨어나 소프트웨어 기능을 암묵적으로 요구하는 경우에 대하여 학습합니다.

<uses-permission>

내 앱이 필요로 하는 퍼미션을 매니페스트 파일에 선언하는 방법을 학습합니다.

Manifest.permission

모든 시스템 퍼미션에 대한 API 레퍼런스를 학습합니다.

추가로 학습할 내용들:

기기 호환성 (Device Compativility)

다양한 종류의 디바이스들에서 안드로이드가 어떻게 동작하는지에 대해서와, 그러한 디바이스들의 제공 가능한 기능들과 관련하여 어떻게 최적화시킬 수 있는지에 대해 자세히 학습합니다.

안드로이드 보안 훑어보기 (Android Security Overview)

안드로이드의 보안 모델에 대하여 학습합니다.