AndroidManifest란?

AndroidManifest란? (https://developer.android.com/guide/topics/manifest/manifest-intro.html?hl=ko)

• 모든 애플리케이션에는 루트 디렉토리에 AndroidManifest.xml 파일(정확히 이 이름이어야 함)이 있어야 한다. 매니페스트 파일에서는 Android 시스템이 앱의 코드를 실행하기 전에 확보해야 하는 앱에 대한 필수 정보를 시스템에 제공한다. 이외에도 매니페스트 파일은 다음 작업을 수행한다.

  • 애플리케이션에 대한 Java 패키지의 이름을 지정한다. 이 패키지 이름은 애플리케이션에 대한 고유한 식별자 역할을 한다.

  • 액티비티, 서비스, 브로드캐스트 수신기 및 콘텐츠 제공자 등 애플리케잉션을 이루는 구성 요소를 설명한다. 또한, 각 구성 요소를 구현하는 클래스의 이름을 지정하고 클래스가 처리할 수 있는 해당 기능을 게시한다. (예: Intent 메시지)

  • 애플리케이션 구성 요소를 호스팅하는 프로세스를 결정한다.

  • 애플리케이션 API의 보호된 부분에 액세스하여 다른 애플리케이션과 상호 작용하는 데 보유해야 하는 권한을 선언한다. 또한, 다른 애플리케이션이 이 애플리케이션의 구성 요소와 상호작용하기 위해 보유해야 하는 권한도 선언한다.

  • 애플리케이션이 실행 중일 때 프로파일링과 기타 정보를 제공하는 Instrumentation 클래스를 나열한다. 이러한 선언은 애플리케이션이 개발 중인 동안에만 매니페스트에 존재하고, 애플리케이션이 게시되기 전에 삭제된다.

  • 애플리케이션이 필요로 하는 Android API의 최소 레벨을 선언한다.

  • 애플리케이션이 연결되어야 하는 라이브러리를 나열한다.

• 매니페스트 파일 구조

  • 아래에 나와 있는 코드 스니펫은 매니페스트 파일의 일반적인 구조와 매니페스트 파일에 들어 있을 수 있는 모든 요소를 보여준다. 각 요소와 각각의 특성을 모두 문서화한 전문은 별도의 팡리에서 확인할 수 있다.

  다음 목록에는 매니페스트 파일에 나타날 수 있는 모든 요소가 사전순으로 나열되어 있습니다.

  • <action>

  • <activity>

  • <activity-alias>

  • <application>

  • <category>

  • <data>

  • <grant-uri-permission>

  • <instrumentation>

  • <intent-filter>

  • <manifest>

  • <meta-data>

  • <permission>

  • <permission-group>

  • <permission-tree>

  • <provider>

  • <receiver>

  • <service>

  • <supports-screens>

  • <uses-configuration>

  • <uses-feature>

  • <uses-library>

  • <uses-permission>

  • <uses-sdk>

   

  ** 참고: 이 요소들만 허용된다. 개발자 자체적인 요소나 특성은 추가할 수 없다

   

• 파일 규칙

  • 이 섹션에서는 매니페스트 파일에 포함되는 모든 요소 및 특성에 일반적으로 적용되는 규칙에 대해 설명한다.

    1) 요소

    • <manifest> 및 <application> 요소만 필수이다. 이 요소는 모두 제공되어야 하며 한 번만 나올 수 있다. 다른 요소 대부분은 여러 번 나오거나 전혀 나오지 않아도 된다. 하지만, 매니페스트 파일이 유용하려면 이러한 요소 중 적어도 일부가 제공되어야 한다.

    • 요소에 무엇이든 들어있기만 하면, 그 요소는 다른 요소를 포함하고 있는 것이다. 모든 값은 요소 내의 문자 데이터로서가 아니라 특성을 통해 설정된다.

    • 같은 레벨에 있는 여러 요소는 보통 순서가 지정되지 않는다. 예를 들어 <activity>, <provider> 및 <service> 요소는 어떤 순서로든 서로 섞여도 된다. 이 규칙에는 두 가지 중요한 예외 사항이 있다.

      1. <activity-alias>요소는 이 요소를 별칭으로 사용하는 <activity> 다음에 와야 한다.

      2. <application>요소는 <manifest> 요소 내부에 있는 마지막 요소여야 한다. 다시 말해, </application> 닫는 태그가 </manifest> 닫는 태그 바로 앞에 와야 한다.

    2) 특성

    • 공식적인 의미에서 모든 특성은 선택 항목이다. 하지만, 요소가 특성이 가진 용도를 실현할 수 있도록 지정되어야 하는 일부 특성이 있다. 관련 문서를 지침으로 사용해라. 정말로 선택 항목인 특성에 대해서는 기본값이 언급되어 있거나 지정하지 않을 경우 어떠한 동작이 수행되는지에 대한 설명이 나와 있다.

    • 루트 <manifest> 요소의 몇 가지 특성을 제외하고 모든 특성 이름은 접두사 android:로 시작된다. 예를 들어 android:alwaysRetainTaskState와 같다. 이 접두사는 범용이기 때문에 특성을 이름으로 참조하는 경우 관련 문서에서 이를 생략하는 경우가 일반적이다.

    3) 클래스 이름 선언

    • 대다수의 요소가 Java 객체에 해당한다. 여기에는 애플리케이션 자체에 대한 요소(<application> 요소)와 해당 주 구성 요소, 즉 액티비티(<activity>), 서비스(<service>), 브로드캐스트 수신기(<receiver>) 및 컨텐츠 제공자(<provider>)에 대한 요소가 포함된다.

    • 구성 요소 클래스(Activity, Service, BroadcastReceiver, ContentProvider)에 대해 거의 항상 그렇듯이 서브클래스를 정의하는 경우 서브클래스는 name 특성을 통해 선언한다. 이름에는 완전한 패키지 지정이 포함되어야 한다. 예를 들어, Service 서브클래스를 선언하려면 다음과 같이 할 수 있다.

     

     

     

     

    • 그러나 문자열의 첫 번째 문자가 마침표이면 애플리케이션 패키지 이름이(<manifest> 요소의 package 특성에서 지정한 대로) 이 문자열에 추가된다. 다음 할당은 위에 표시된 것과 동일하다.

     

     

     

     

    • Android 시스템은 구성 요소를 시작할 때 명명된 서브클래스의 인스턴스를 생성한다. 서브클래스가 지정되지 않은 경우, 기본 클래스의 인스턴스를 생성한다.

    4) 여러 개의 값

    • 둘 이상의 값을 지정할 수 있는 경우, 한 요소 안에 여러 값이 나열되지 않고 해당 요소가 거의 반복된다. 예를 들어 한 인텐트 필터가 여러 개의 작업을 나열할 수 있다.

     

     

     

     

    5) 리소스 값

    • 몇몇 특성에는 액티비티에 대한 레이블 및 아이콘과 같이 사용자에게 표시될 수 있는 값이 있다. 이러한 특성의 값은 리소스나 테마에서 현지화되고 설정되어야 한다. 리소스 값은 다음과 같은 형식으로 표현된다. @[package:]type/name

    • 리소스가 애플리케이션과 동일한 패키지에 있을 경우 package 이름을 생략할 수 있다. type은 리소스 유형(예: string 또는 drawable)이고, name은 특정 리소스를 식별하는 이름이다. 다음은 이에 대한 예이다.

     

     

     

     

    • 테마에서 설정하는 값은 이와 유사하게 표현되지만 @ 대신 ?를 시작 문자로 사용한다. ?[package:]type/name

    6) 문자열 값

    • 특성 값이 문자열인 경우, 문자를 이스케이프 처리하려면 이중 백슬래시(\\) 를 사용해야 한다.

      (예: 줄바꿈의 경우 \\n 또는 유니코드 문자의 경우 \\uxxx).

• 파일 기능

  • 다음 섹션에서는 몇 가지 Android 기능이 매니페스트 파일에 반영되는 방법을 설명한다.

    1) 인텐트 필터

    • 애플리케이션의 핵심 구성 요소(액티비티, 서비스, 브로드캐스트 수신기)는 인텐트에 의해 활성화된다. 인텐트는 원하는 작업을 설명하는 정보 묶음이다. (Intent 객체) 여기에는 작업을 수행할 데이터, 작업을 수행해야 하는 구성 요소의 범주 및 기타 관련 지침 등이 포함된다. Android 시스템은 인텐트에 응답할 수 있는 적절한 구성 요소를 찾아 필요한 경우 구성 요소의 새 인스턴스를 시작하고, 이것을 Intent 객체에 전달한다.

    • 구성 요소는 인텐트 피터를 통해 응답할 수 있는 인텐트 유형을 알린다. Android 시스템은 구성 요소를 시작하기 전에 해당 구성 요소가 처리할 수 있는 인텐트에 대해 알아야 하기 때문에 인텐트 필터를 매니페스트 파일에서 <intent-filter> 요소로 지정한다. 하나의 구성 요소에 있을 수 있는 필터의 수에는 어떠한 제한도 없으며, 각각 다른 기능을 설명한다.

    • 대상 구성 요소를 명시적으로 지명하는 인텐트가 해당 구성 요소를 활성화한다. 따라서 필터는 아무런 역할도 하지 않는다. 하지만 이름으로 대상을 지정하지 않는 인텐트는 구성 요소의 필터 중 하나를 통과할 수 있는 경우에만 해당 구성 요소를 활성화 할 수 있다.

    • Intent 객체가 인텐트 필터에 대해 테스트되는 방식에 대한 자세한 내용은 인텐트 및 인텐트 필터 문서를 참조해라.

    2) 아이콘 및 레이블

    • 대다수의 요소에는 사용자에게 표시될 수 있는 작은 아이콘 및 텍스트 레이블을 나타내는 icon 및 label 특성이 있다. 몇몇 요소에는 화면에 표시될 수 있는 좀 더 긴 설명 텍스트를 나타내는 description 특성도 있다. 예를 들어 <permission> 요소는 이와 같은 특성을 세 개 모두 가지고 있으므로 사용자에게 이를 요청한 애플리케이션에 권한을 부여할지 여부를 물을 때 권한을 나타내는 아이콘, 권한 이름 및 이에 수반되는 내용에 대한 설명이 모두 사용자에게 표시된다.

    • 어떤 경우에든, 포함하는 요소에 설정된 아이콘과 레이블이 해당 컨테이너의 모든 하위 요소에 대한 기본 icon 및 label 설정이 된다. 이와 강티 <application> 요소에 설정된 아이콘과 레이블이 애플리케이션의 각 구성 요소에 대한 기본 아이콘과 레이블이 된다. 이와 유사하게, 구성 요소(예: <activity> 요소)에 대해 설정된 아이콘과 레이블이 각 구성 요소의 <intnet-filter> 요소에 대한 기본 설정이다. <application> 요소가 레이블을 설정하지만 액티비티와 그 인텐트 필터는 이를 설정하지 않는 경우, 애플리케이션 레이블이 액티비티와 인텐트 필터 양쪽 모두의 레이블인 것으로 취급된다.

    • 인텐트 필터에 대해 설정된 아이콘과 레이블은 구성 요소가 사용자에게 표시되어 필터가 알리는 기능을 이행할 때마다 구성 요소를 나타낸다. 예를 들어 android.intent.action.MAIN 및 android.intent.category.LAUNCHER가 설정된 필터는 애플리케이션을 초기화하는 항목으로 액티비티를 알린다. 즉, 애플리케이션 런처에 표시되어야 하는 항목으로 알린다. 필터에 설정된 아이콘과 레이블은 런처에 표시된다.

    3) 권한

    • 권한은 기기에서 코드의 일부분이나 데이터로 액세스를 한정하는 제한이다. 이러한 제한을 부과하는 것은 중요한 데이터와 코드를 보호해 이들이 남용되어서 사용자 환경을 왜곡하거나 손상시키지 않도록 하기 위해서이다.

    • 각 권한은 고유한 레이블로 식별된다. 레이블은 대개 제한되는 작업을 나타낸다. 다음은 Android에서 정의한 몇가지 권한이다.

       

       

       

       

    • 하나의 기능은 하나의 권한으로만 보호될 수 있다.

    • 애플리케이션이 권한으로 보호되는 기능에 액세스해야 하는 경우, 매니페스트에 <uses-permission> 요소를 사용해 해당 권한이 필요하다는 것을 선언해야 한다. 그러면 애플리케이션이 기기에 설치될 때 설치 프로그램이 애플리케이션의 인증서에 서명한 인증 기관을 확인하고, 경우에 따라 사용자에게 묻는 방식으로 요청된 권한을 부여할지 여부를 결정한다. 권한이 부여되면 애플리케이션이 보호된 기능을 사용할 수 있다. 부여되지 않으면, 그러한 기능에 액세스하려는 시도가 실패하고 사용자에게는 아무런 알림도 표시되지 않는다.

    • 애플리케이션이 권한을 사용해 자체적인 구성 요소를 보호할 수도 있다. Android에서 정의했거나(android.Manifest.permission에 나열됨) 다른 애플리케이션에서 선언한 권한은 무엇이든 사용할 수 있다. 또한, 자체적으로 정의할 수도 있다. 새 권한을 선언할 때에는 <permission> 요소를 사용한다. 예를 들어 액티비티를 보호하려면 다음과 같이 하면 된다.

       

       

       

       

    • 참고로, 이 예시에서는 DEBIT_ACCT 권한이 <permission> 요소를 사용해 선언되었을 뿐만 아니라, 이에 대한 사용도 <uses-permission> 요소를 사용해 요청되었다. 이렇게 사용을 요청해야만 애플리케이션의 다른 구성 요소가 보호된 액티비티를 시작할 수 있다. 이는 애플리케이션이 자체적으로 보호를 적용한 경우에도 해당된다.

    • 위에 표시된 예시를 계속 참고해, permission 특성이 다른 곳에서 선언된 권한으로 설정된 경우(예: android.permission.CALL_EMERGENCY_NUMBERS), <permission> 요소를 사용해 이를 다시 선언할 필요가 없다. 하지만 해당 권한의 사용은 여전히 <uses-permission>을 사용해 요청해야 한다.

    • <permission-tree> 요소는 코드에 정의된 권한 그룹에 대한 네임스페이스를 선언하고 <permission-group> 요소는 그룹에 속하는 권한을 지정하지는 않지만, 그룹에 이름을 제공한다. 그룹에 권한을 배치하려면 그룹 이름을 <permission> 요소의 permissionGroup 특성에 할당하면 된다.

    4) 라이브러리

    • 모든 애플리케이션은 기본 Android 라이브러리에 연결되어 있다. 여기에는 애플리케이션 빌드를 위한 기본적인 패키지(액티비티, 서비스, 인텐트, 뷰, 버튼, 애플리케이션, ContentProvider 등 보편적인 클래스 포함)가 포함되어 있다.

    • 그러나 패키지 가운데에는 자신만의 라이브러리에 속한 것도 있다. 애플리케이션이 사용하는 코드의 출처가 이러한 패키지 가운데 어느 한 가지에 해당하는 경우, 해당 패키지에 연결되도록 명시적으로 요청해야만 한다. 매니페스트에는 각 라이브러리의 이름을 지정하는 개별 <uses-library> 요소가 들어 있어야 한다. 패키지 관련 문서에서 라이브러리 이름을 확인할 수 있다.