작업은 사용자가 특정 작업을 할 때 상호작용하는 활동의 컬렉션입니다. 활동은 스택(백 스택)에 각 활동이 열린 순서대로 정렬됩니다. 예를 들어 이메일 앱에는 새 메시지 목록을 표시하는 활동이 하나 있을 수 있습니다. 사용자가 메시지를 선택하면 메시지를 볼 수 있도록 새 활동이 열립니다. 새로운 활동은 백 스택에 추가됩니다. 사용자가 뒤로 버튼을 누르면 새로운 활동이 완료되고 스택에서 팝됩니다. 다음 동영상은 백 스택의 작동 방식과 관련된 유용한 개요를 제공합니다.
Android 7.0(API 레벨 24) 이상에서 지원되는 멀티 윈도우 환경에서 앱이 동시에 실행될 때 시스템은 각 창의 작업을 별도로 관리합니다. 각 창에는 여러 작업이 있을 수 있습니다. Chromebook에서 실행되고 있는 Android 앱에서도 마찬가지입니다. 시스템은 작업 또는 작업 그룹을 창 단위로 관리합니다.
기기의 홈 화면은 대부분의 작업이 시작되는 위치입니다. 사용자가 앱 런처의 아이콘(또는 홈 화면의 바로가기)을 터치하면 앱의 작업이 포그라운드로 나옵니다. 앱의 작업이 없으면(앱이 최근에 사용된 적이 없으면) 새 작업이 생성되고 이 앱의 '기본' 활동이 스택의 루트 활동으로 열립니다.
현재 활동이 또 다른 활동을 시작하면 새 활동이 스택의 맨 위에 푸시되고 포커스를 갖게 됩니다. 이전 활동은 스택에 남아있지만 중지됩니다. 활동이 중지되면 시스템은 활동의 사용자 인터페이스가 갖고 있는 현재 상태를 보존합니다. 사용자가 뒤로 버튼을 누르면 현재 활동이 스택의 맨 위에서 팝되고(활동이 제거되고) 이전 활동이 다시 시작됩니다(UI의 이전 상태가 복원됨). 스택의 활동은 다시 정렬되지 않으며 스택에 푸시되고 스택에서 팝될 뿐입니다. 현재 활동에 의해 시작될 때 스택으로 푸시되고 사용자가 뒤로 버튼을 사용하여 활동을 떠날 때 스택에서 팝됩니다. 따라서 백 스택은 'LIFO(후입선출)' 객체 구조로 작동합니다. 그림 1은 각 시점에서 현재 백 스택과 함께 활동 간 진행 상황을 보여주는 타임라인을 통해 이 동작을 시각화한 것입니다.
그림 1. 작업의 새로운 각 활동이 백 스택에 항목을 추가하는 방식을 나타냅니다. 사용자가 뒤로 버튼을 누르면 현재 활동이 제거되고 이전 활동이 다시 시작됩니다.
사용자가 계속 뒤로 버튼을 누르면 사용자가 홈 화면으로(또는 작업이 시작될 때 실행 중이었던 활동으로) 돌아갈 때까지 스택의 각 활동이 스택에서 팝되어 바로 이전 활동이 나타납니다. 모든 활동이 스택에서 삭제되면 작업이 더 이상 존재하지 않습니다.
그림 2. 두 작업: 작업 B가 포그라운드에서 사용자 상호작용을 수신하는 동안 작업 A는 백그라운드에서 다시 시작되기를 기다리고 있습니다.
사용자가 새 작업을 시작하거나 홈 버튼을 통해 홈 화면으로 이동할 때 작업은 '백그라운드'로 이동할 수 있는 응집 단위입니다. 작업의 모든 활동은 백그라운드에 있는 동안 중지되지만 작업의 백 스택은 온전하게 그대로 유지됩니다. 그림 2에서와 같이 작업은 또 다른 작업이 실행되는 동안 포커스를 잃을 뿐입니다. 이후에 작업이 '포그라운드'로 돌아갈 수 있으므로 사용자는 중단된 활동을 계속 이어나갈 수 있습니다. 예를 들어 현재 작업(작업 A)의 스택에 세 개의 활동이 있고 현재 활동으로 두 개가 있다고 가정합니다. 사용자가 홈 버튼을 누른 후 앱 런처에서 새 앱을 시작합니다. 홈 화면이 표시될 때 작업 A는 백그라운드로 전환됩니다. 새 앱이 시작될 때 시스템은 앱의 작업(작업 B)을 시작하며 작업에는 자체 활동 스택이 있습니다. 사용자가 앱과 상호작용한 후 다시 홈으로 돌아가서 원래 작업 A를 시작한 앱을 선택합니다. 이제 작업 A가 포그라운드로 나옵니다. 스택의 세 활동은 모두 그대로 유지되며 스택의 맨 위에 있는 활동이 다시 시작됩니다. 또한 이 시점에서 사용자는 작업 B로 다시 전환할 수도 있습니다. 즉, 홈으로 이동하여 이 작업을 시작한 앱 아이콘을 선택하여(또는 최근 화면에서 앱의 작업을 선택하여) 전환할 수 있습니다. 이렇게 Android에서 멀티태스킹의 예를 간단히 살펴보았습니다.
참고: 여러 작업을 동시에 백그라운드에 유지할 수 있습니다. 하지만 사용자가 여러 백그라운드 작업을 동시에 실행하면 시스템이 메모리를 복구하기 위해 백그라운드 활동의 제거를 시작할 수 있으며 이로 인해 활동 상태가 손실될 수 있습니다.
그림 3. 단일 활동이 여러 번 인스턴스화됩니다.
백 스택의 활동은 결코 다시 정렬되지 않으므로 앱에서 사용자에게 둘 이상의 활동으로부터 특정 활동을 시작하도록 허용하면 활동의 새 인스턴스가 생성되어 스택으로 푸시됩니다(활동의 이전 인스턴스가 맨 위로 오는 것이 아님). 따라서 그림 3에서와 같이 앱의 한 활동이 여러 번 인스턴스화될 수 있습니다(심지어 다른 작업으로부터도). 따라서 사용자가 뒤로 버튼을 사용하여 뒤로 이동하면 활동의 각 인스턴스는 열렸던 순서대로(그리고 각각 고유한 UI 상태로) 나타납니다. 그러나 활동을 두 번 이상 인스턴스화하지 않으려면 이 동작을 수정할 수 있습니다. 동작을 수정하는 방법은 작업 관리에 관한 이후 섹션에서 설명합니다.
활동 및 작업의 기본 동작 요약:
- 활동 A가 활동 B를 시작하면 활동 A는 중지되지만 시스템이 상태(예: 스크롤 위치 및 양식에 입력된 텍스트)를 보존합니다. 사용자가 활동 B에 있는 동안 뒤로 버튼을 누르면 활동 A가 다시 시작되며 상태도 복원됩니다.
- 사용자가 홈 버튼을 눌러 작업을 떠나면 현재 활동이 중지되고 작업이 백그라운드로 전환됩니다. 시스템은 작업의 모든 활동 상태를 보존합니다. 사용자가 나중에 작업을 시작했던 런처 아이콘을 선택하여 작업을 다시 시작하면 작업이 포그라운드로 나오고 스택의 맨 위에 있는 활동이 다시 시작됩니다.
- 사용자가 뒤로 버튼을 누르면 현재 활동이 스택에서 팝되고 제거됩니다. 스택의 이전 활동이 다시 시작됩니다. 활동이 제거되면 시스템은 활동 상태를 보존하지 않습니다.
- 활동은 여러 번 인스턴스화될 수 있으며 심지어 다른 작업으로부터도 인스턴스화될 수 있습니다.
탐색 디자인
Android에서 앱 탐색 작동 방식에 관한 자세한 내용은 Android 디자인의 탐색 가이드를 참조하세요.
작업 관리
위에서 설명한 대로 Android에서 작업 및 백 스택을 관리하는 방식(연속적으로 시작된 모든 활동을 동일한 작업에 그리고 'LIFO(후입선출)' 스택에 배치하는 방식)은 대부분의 앱에 매우 효과적입니다. 따라서 활동이 작업과 연결되는 방식 또는 백 스택에 존재하는 방식에 관해 걱정하지 않아도 됩니다. 그러나 정상적인 동작을 중단시켜야 할 수도 있습니다. 어쩌면 앱의 활동이 시작될 때 현재 작업 내에 배치되지 않고 새 작업이 시작되도록 할 수 있습니다. 또는 활동이 시작될 때 백 스택의 맨 위에 새 인스턴스가 생성되는 대신 활동의 기존 인스턴스가 앞으로 나오도록 할 수 있습니다. 또는 사용자가 작업을 떠날 때 루트 활동을 제외한 모든 활동이 백 스택에서 제거되도록 할 수 있습니다.
<activity> manifest 요소의 속성 및 startActivity()에 전달하는 인텐트의 플래그를 사용하여 이러한 모든 작업과 그 외의 여러 작업을 할 수 있습니다.
이와 관련하여 사용할 수 있는 주요 <activity> 속성은 다음과 같습니다.
-
taskAffinity -
launchMode -
allowTaskReparenting -
clearTaskOnLaunch -
alwaysRetainTaskState -
finishOnTaskLaunch
사용할 수 있는 주요 인텐트 플래그는 다음과 같습니다.
다음 섹션에서는 이러한 manifest 속성 및 인텐트 플래그를 사용하여 활동이 작업과 연결되는 방식 및 백 스택에서 동작하는 방식을 어떻게 정의할 수 있는지 살펴보겠습니다.
또한 최근 화면에서 작업 및 활동을 표시하고 관리하는 방식에 관한 고려사항도 별도로 설명합니다. 자세한 내용은 최근 화면을 참조하세요. 일반적으로 최근 화면에 작업 및 활동이 표시되는 방식을 시스템이 정의하도록 해야 하며 이 동작을 개발자가 수정할 필요는 없습니다.
주의: 대부분의 앱은 활동 및 작업의 기본 동작을 중단해서는 안 됩니다. 개발자는 활동에서 기본 동작을 수정할 필요가 있다고 판단하면 신중하게 생각하고 활동 실행 중에 그리고 뒤로 버튼을 통해 다른 활동 및 작업에서 이 활동으로 다시 이동할 때 활동의 사용성을 테스트해야 합니다. 사용자의 예상되는 동작과 충돌할 가능성이 있는 탐색 동작을 테스트해야 합니다.
실행 모드 정의
실행 모드를 통해 활동의 새 인스턴스가 현재 작업과 연결되는 방식을 정의할 수 있습니다. 다음 두 가지 방법으로 서로 다른 실행 모드를 정의할 수 있습니다.
- manifest 파일 사용
manifest 파일에서 활동을 선언하면 활동이 시작될 때 작업과 연결되어야 하는 방식을 지정할 수 있습니다.
- 인텐트 플래그 사용
startActivity()를 호출할 때 새 활동이 현재 작업과 연결되어야 하는 방식(또는 연결되어야 하는지 여부)을 선언하는 플래그를Intent에 포함할 수 있습니다.
따라서 활동 A가 활동 B를 시작하면 활동 B는 현재 작업과 연결되어야 하는 방식(연결되어야 한다면)을 manifest에 정의할 수 있으며 활동 A도 활동 B가 현재 작업과 연결되어야 하는 방식을 요청할 수 있습니다. 두 활동이 모두 활동 B가 작업과 연결되어야 하는 방식을 정의하면 활동 A의 요청(인텐트에 정의)이 활동 B의 요청(manifest에 정의)보다 우선합니다.
참고: manifest 파일에 사용할 수 있는 실행 모드 중에는 인텐트의 플래그로 사용할 수 없는 것도 있으며 인텐트의 플래그로 사용할 수 있는 실행 모드 중에는 manifest에서 정의할 수 없는 것도 있습니다.
manifest 파일 사용
manifest 파일에서 활동을 선언할 때 <activity> 요소의 launchMode 속성을 사용하여 활동이 작업과 연결되어야 하는 방식을 지정할 수 있습니다.
launchMode 속성은 활동을 작업으로 실행하는 방식에 관한 지침을 지정합니다. launchMode 속성에 할당할 수 있는 네 가지 실행 모드는 다음과 같습니다.
"standard"(기본 모드)- 기본값입니다. 시스템은 활동이 시작된 작업에 활동의 새 인스턴스를 생성하고 인텐트를 인스턴스로 라우팅합니다. 활동은 여러 번 인스턴스화될 수 있고 각 인스턴스는 서로 다른 작업에 속할 수 있으며 한 작업에는 여러 인스턴스가 있을 수 있습니다.
"singleTop"- 활동의 인스턴스가 이미 현재 작업의 맨 위에 있으면 시스템은 활동의 새 인스턴스를 생성하지 않고
onNewIntent()메서드를 호출하여 인텐트를 기존 인스턴스로 라우팅합니다. 활동은 여러 번 인스턴스화될 수 있고 각 인스턴스는 서로 다른 작업에 속할 수 있으며 한 작업에는 여러 인스턴스가 있을 수 있습니다(단, 백 스택의 맨 위에 있는 활동이 활동의 기존 인스턴스가 아닐 때에만).예를 들어 작업의 백 스택이 루트 활동 A와 활동 B 및 C 그리고 맨 위의 활동 D로 구성되어 있다고 가정합니다(스택은 A-B-C-D이며 D가 맨 위에 있음). D 유형 활동의 인텐트가 도착합니다. D에 기본
"standard"실행 모드가 있으면 클래스의 새 인스턴스가 실행되고 스택이 A-B-C-D-D가 됩니다. 하지만 D의 실행 모드가"singleTop"이면 D의 기존 인스턴스는onNewIntent()를 통해 도착한 인텐트를 받습니다. D의 기존 인스턴스가 스택의 맨 위에 있기 때문이며 스택은 계속 A-B-C-D로 유지됩니다. 그러나 B 유형 활동의 인텐트가 도착하면 B의 새 인스턴스가 스택에 추가되며 B의 실행 모드가"singleTop"이더라도 그렇습니다.참고: 활동의 새 인스턴스가 생성되면 사용자는 뒤로 버튼을 눌러 이전 활동으로 돌아갈 수 있습니다. 그러나 활동의 기존 인스턴스가 새 인텐트를 처리할 때 사용자는 뒤로 버튼을 눌러도 새 인텐트가
onNewIntent()에 도착하기 이전 활동 상태로 돌아갈 수 없습니다. "singleTask"- 시스템이 새 작업을 생성하고 새 작업의 루트에 있는 활동을 인스턴스화합니다.
그러나 활동의 인스턴스가 이미 별도의 작업에 있다면 시스템은 새 인스턴스를 생성하지 않고
onNewIntent()메서드를 호출하여 인텐트를 기존 인스턴스로 라우팅합니다. 활동의 인스턴스가 한 번에 하나만 존재할 수 있습니다.참고: 활동이 새 작업에서 시작되더라도 사용자는 여전히 뒤로 버튼을 통해 이전 활동으로 돌아갈 수 있습니다.
"singleInstance""singleTask"와 동일하지만 시스템이 인스턴스를 보유한 작업으로는 어떤 다른 활동도 실행하지 않는다는 점이 다릅니다. 활동은 항상 자체 작업의 단 하나의 유일한 멤버입니다. 이 활동으로 시작된 모든 활동은 별도의 작업으로 열립니다.
또 다른 예로 Android 브라우저 앱이 <activity> 요소의 singleTask 실행 모드를 지정함으로써 웹브라우저 활동을 항상 자체 작업으로 열어야 한다고 선언합니다.
즉, 앱이 Android 브라우저를 여는 인텐트를 발행하면 이 활동은 앱과 동일한 작업에 배치되지 않습니다. 대신 브라우저에서 새 작업이 시작되거나, 브라우저에 이미 백그라운드에서 실행 중인 작업이 있다면 그 작업이 포그라운드로 나와 새 인텐트를 처리합니다.
활동이 새 작업에서 시작되었든 또는 활동이 시작된 작업과 동일한 작업에서 시작되었든 관계없이 사용자는 뒤로 버튼을 통해 항상 이전 활동으로 돌아갈 수 있습니다. 그러나 singleTask 실행 모드를 지정한 활동을 시작했는데 그때 활동의 인스턴스가 백그라운드 작업에 존재하면 작업 전체가 포그라운드로 이동합니다. 이제 백 스택에는 앞으로 나온 작업의 모든 활동이 스택의 맨 위에 포함되어 있습니다. 그림 4는 이 유형의 시나리오를 보여줍니다.
그림 4. 실행 모드가 'singleTask'인 활동이 백 스택에 추가되는 방식을 나타냅니다. 활동이 이미 자체 백 스택이 있는 백그라운드 작업의 일부이면 백 스택 전체도 앞으로 나오며 현재 작업의 맨 위에 배치됩니다.
manifest 파일의 실행 모드 사용에 관한 자세한 내용은 <activity> 요소 문서를 참조하세요. 여기에서 launchMode 속성 및 허용되는 값에 관해 자세히 설명합니다.
참고: launchMode 속성을 통해 활동에 지정하는 동작은 다음 섹션에 설명된 것처럼 활동을 시작하는 인텐트와 함께 포함된 플래그로 재정의할 수 있습니다.
인텐트 플래그 사용
활동을 시작할 때 startActivity()에 전달하는 인텐트에 플래그를 포함함으로써 활동과 작업의 기본 연결을 수정할 수 있습니다. 기본 동작을 수정하는 데 사용할 수 있는 플래그는 다음과 같습니다.
FLAG_ACTIVITY_NEW_TASK- 활동을 새 작업에서 시작합니다. 지금 시작하고 있는 활동에 대해 이미 실행 중인 작업이 있으면 그 작업이 마지막 상태가 복원되어 포그라운드로 이동하고 활동은
onNewIntent()의 새 인텐트를 수신합니다.이 플래그를 사용하면 이전 섹션에서 설명한
"singleTask"launchMode값과 동일한 동작이 발생합니다. FLAG_ACTIVITY_SINGLE_TOP- 시작 중인 활동이 현재 활동(백 스택의 맨 위에 있는)이면 활동의 새 인스턴스가 생성되는 대신 기존 인스턴스가
onNewIntent()호출을 수신합니다.이 플래그를 사용하면 이전 섹션에서 설명한
"singleTop"launchMode값과 동일한 동작이 발생합니다. FLAG_ACTIVITY_CLEAR_TOP- 시작 중인 활동이 현재 작업에서 이미 실행 중이면 활동의 새 인스턴스가 실행되는 대신 작업의 맨 위에 있는 다른 모든 활동이 제거되고 이 인텐트가
onNewIntent()를 통해 활동(이제 맨 위에 있음)의 다시 시작된 인스턴스로 전달됩니다.이 동작을 발생시키는
launchMode속성 값은 없습니다.FLAG_ACTIVITY_CLEAR_TOP은FLAG_ACTIVITY_NEW_TASK와 함께 가장 자주 사용됩니다. 이러한 플래그를 함께 사용하면 또 다른 작업에 있는 기존 활동을 찾아 인텐트에 응답할 수 있는 위치에 활동을 넣을 수 있습니다.참고: 지정된 활동의 실행 모드가
"standard"이면 이 활동도 스택에서 삭제되고 대신 새 인스턴스가 실행되어 수신 인텐트를 처리합니다. 실행 모드가"standard"이면 새 인텐트에 대해 항상 새 인스턴스가 생성되기 때문입니다.
어피니티 처리
어피니티는 활동이 어느 작업에 소속되기를 선호하는지를 나타냅니다. 기본적으로 동일한 앱의 모든 활동은 서로에게 어피니티를 가지고 있습니다. 따라서 동일한 앱의 모든 활동은 기본적으로 동일한 작업 안에 있는 것을 선호합니다. 하지만 개발자는 활동의 기본 어피니티를 수정할 수 있습니다. 서로 다른 앱에 정의된 활동이 어피니티를 공유할 수 있습니다. 또는 동일한 앱에 정의된 활동에 다양한 작업 어피니티를 할당할 수 있습니다.
어떤 활동이든 <activity> 요소의 taskAffinity 속성을 통해 어피니티를 수정할 수 있습니다.
taskAffinity 속성은 문자열 값을 사용합니다. 이 값은 <manifest> 요소에 선언된 기본 패키지 이름과 달리 고유해야 합니다. 시스템이 이 이름을 사용하여 앱의 기본 작업 어피니티를 식별하기 때문입니다.
어피니티는 다음과 같은 두 가지 상황에서 작용합니다.
- 활동을 실행한 인텐트에
FLAG_ACTIVITY_NEW_TASK플래그가 포함되어 있을 때기본적으로 새 활동은
startActivity()를 호출한 활동의 작업으로 실행됩니다. 그리고 호출자와 동일한 백 스택에 푸시됩니다. 그러나startActivity()에 전달된 인텐트에FLAG_ACTIVITY_NEW_TASK플래그가 포함되어 있으면 시스템은 새 활동을 수용할 다른 작업을 찾습니다. 흔히 새 작업을 찾습니다. 하지만 반드시 새 작업일 필요는 없습니다. 새 활동과 동일한 어피니티를 가진 기존 작업이 이미 있으면 활동이 그 작업으로 실행됩니다. 그렇지 않으면 새 작업을 시작합니다.이 플래그로 인해 활동이 새 작업을 시작하고 사용자가 홈 버튼을 눌러 작업을 떠날 때 사용자가 작업으로 다시 이동할 수 있는 방법이 몇 가지 있어야 합니다. 일부 항목(예: 알림 관리자)은 항상 자체 작업의 일부가 아닌 외부 작업으로만 활동을 시작하므로 항상
startActivity()에 전달하는 인텐트에FLAG_ACTIVITY_NEW_TASK를 넣습니다. 이 플래그를 사용할 외부 항목에 의해 호출될 수 있는 활동이 있다면 사용자가 활동이 시작된 작업으로 돌아갈 수 있는 독자적인 방법이 있어야 합니다. 런처 아이콘을 이용하는 방법을 예로 들 수 있습니다(작업의 루트 활동에는CATEGORY_LAUNCHER인텐트 필터가 있음, 아래 작업 시작 섹션 참조). - 활동의
allowTaskReparenting속성이"true"로 설정되어 있을 때이런 상황에서 활동은 자신이 시작되는 작업에서 벗어나 어피니티를 가진 다른 작업이 포그라운드로 나오면 그 작업으로 이동할 수 있습니다.
예를 들어 선택된 도시들의 기상 상태를 예보하는 활동이 여행 앱의 일부로 정의되었다고 가정합니다. 이 활동은 동일한 앱의 다른 활동과 동일한 어피니티(기본 앱 어피니티)를 가지며 이 속성을 통한 상위 재지정을 허용합니다. 활동 중 하나가 일기 예보 활동을 시작할 때 이 활동은 처음에는 기존 활동과 동일한 작업에 속합니다. 그러나 여행 앱의 작업이 포그라운드로 나오면 일기 예보 활동은 그 작업에 다시 할당되어 작업 안에 표시됩니다.
팁: 사용자 관점에서 볼 때 APK 파일에 둘 이상의 '앱'이 포함되어 있다면 taskAffinity 속성을 사용하여 각 '앱'과 연결된 활동에 다양한 어피니티를 할당하는 것이 좋습니다.
백 스택 삭제
사용자가 오랜 시간 동안 작업을 떠나있으면 시스템은 루트 활동을 제외한 모든 활동을 작업에서 삭제합니다. 사용자가 작업으로 다시 돌아오면 루트 활동만 복원됩니다. 시스템이 이런 방식으로 동작하는 이유는 오랜 시간이 지나면 사용자가 이전에 하고 있던 일을 그만두고 작업으로 돌아왔을 때 새로운 일을 시작할 가능성이 크기 때문입니다.
이 동작을 수정하는 데 사용할 수 있는 몇 가지 활동 속성은 다음과 같습니다.
alwaysRetainTaskState- 작업의 루트 활동에서 이 속성을
"true"로 설정하면 방금 설명한 기본 동작이 일어나지 않습니다. 작업은 오랜 시간이 지난 후에도 스택의 모든 활동을 유지합니다. clearTaskOnLaunch- 작업의 루트 활동에서 이 속성을
"true"로 설정하면 사용자가 작업을 떠났다가 작업으로 다시 돌아올 때마다 스택이 루트 활동까지 삭제됩니다. 다시 말해서alwaysRetainTaskState와 정반대입니다. 사용자는 항상 작업의 초기 상태로 돌아오게 되며 이는 아주 잠깐만 작업을 떠났다가 돌아와도 마찬가지입니다. finishOnTaskLaunch- 이 속성은
clearTaskOnLaunch와 비슷하지만 작업 전체가 아니라 단일 활동에서 작동합니다. 또한 이 속성을 사용하면 루트 활동을 포함하여 어떤 활동이라도 지울 수 있습니다. 이 속성을"true"로 설정하면 활동은 현재 세션에 대해서만 작업의 일부로 유지됩니다. 사용자가 작업을 떠났다가 다시 돌아오면 이 작업은 더 이상 존재하지 않습니다.
작업 시작
"android.intent.action.MAIN"을 작업으로 지정하고 "android.intent.category.LAUNCHER"를 카테고리로 지정하여 인텐트 필터를 제공함으로써 활동을 작업의 진입점으로 설정할 수 있습니다. 예를 들면 다음과 같습니다.
<activity ... >
<intent-filter ... >
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
...
</activity>
이런 종류의 인텐트 필터를 사용하면 활동의 아이콘 및 라벨이 앱 런처에 표시됩니다. 이를 통해 사용자에게 활동을 실행할 방법과 활동이 실행된 후 언제든지 이 활동이 생성한 작업으로 돌아올 방법을 제공합니다.
이 두 번째 기능이 중요합니다. 사용자는 작업을 떠났다가 나중에 이 활동 런처를 사용하여 작업에 다시 돌아올 수 있어야 합니다. 이러한 이유로 활동이 항상 작업을 시작하는 것으로 표시하는 두 가지 실행 모드인 "singleTask" 및 "singleInstance"는 활동에 ACTION_MAIN 및 CATEGORY_LAUNCHER 필터가 있을 때만 사용해야 합니다. 필터를 누락하면 어떤 일이 일어날 수 있는지 상상해보세요. 예를 들어 다음과 같은 일이 발생합니다. 인텐트가 "singleTask" 활동을 실행하여 새 작업을 시작하고 사용자가 이 작업으로 일하며 어느 정도 시간을 보냅니다. 그런 다음 사용자가 홈 버튼을 누릅니다. 이 작업은 이제 백그라운드로 보내져 보이지 않습니다. 이제 사용자가 작업으로 돌아갈 방법이 없습니다. 작업이 앱 런처에 표시되지 않기 때문입니다.
사용자가 활동으로 돌아갈 수 없도록 하려면 <activity> 요소의 finishOnTaskLaunch를 "true"로 설정하면 됩니다(백 스택 삭제 참조).
작업 및 활동이 개요 화면에서 어떻게 표시되고 관리되는지에 관한 자세한 내용은 최근 화면에서 확인할 수 있습니다.