- [Manifest 주요 속성]
모든 앱 프로젝트는 프로젝트 source 세트의 루트에 AndroidManifest.xml 파일이 있어야한다. 이 파일은 Android 빌드 도구, Android 운영체제 및 Google play에 앱에 관한 필수 정보를 설명한다.
앱의 패키지 이름, 앱의 구성요소(모든 액티비티, 서비스, Brodcast Receiver, 콘텐츠 제공자), 앱이 시스템 또는 다른 앱의 보호된 부분에 액세스하기 위해 필요한 권한, 앱에 필요한 하드웨어 및 소프트웨어 기능(이에 따라 Google Play에서 설치할 수 있는 기기의 종류가 달라짐)은 특히 선언해야 한다.
- <manifest> (패키지 이름과 애플리케이션 ID)
AndroidManifest.xml 파일의 루트 요소이다. <application> 요소를 포함해야 하며, xml:android 및 package 속성을 지정한다.
포함 해야하는 요소: <application>
포함 가능한 요소: <compatiable-screens> <instrumentation> <permission> <permission-group> <permission-tree> <queries> <supports-gl-texture> <supports-screens> <uses-configuration> <uses-configuration> <uses-feature> <uses-permission> <uses-permission-sdk-23> <uses-sdk>
- xmlns:android
Android 네임스페이스를 정의한다. 이 속성은 항상 'http://schemas.android.com/apk/res/android'로 설정해야한다.
- package
패키지 이름에는 대문자, 소문자, 숫자, _ 이 포함될 수 있다. 그러나 개별 패키지 이름 부분은 문자로만 시작할 수 있다.
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.myapp"
android:versionCode="1"
android:versionName="1.0" >
...
</manifest>패키지 이름이 "com.example.myapp"인 루트 <manifest> 요소를 나타낸다.
Android 빌드 도구가 package 특성을 사용한다.
1. 빌드 도구는 앱에서 생성된 R.java 클래스의 네임스페이스로 이 이름을 적용한다. (manifest와 함께 R클래스가 com.example.myapp.R에서 생성된다.)
2. 빌드 도구는 이 이름을 사용하여 매니페스트 파일에 선언되어 있는 상대 클래스 이름을 확인한다. (<activity android:name=".MainActivity>로 선언된 액티비티가 com.example.myapp.MainActivity인 것으로 확인된다.
manifest의 package 특성에 있는 이름은 프로젝트의 기본 패키지 이름과 항상 일치해야 한다. 프로젝트에 다른 하위 패키지가 있을 경우, package 특성의 네임스페이스를 사용하여 R.java 클래스를 가져오면 된다.
참고: https://developer.android.com/guide/topics/manifest/manifest-element?hl=ko
https://developer.android.com/guide/topics/manifest/manifest-intro?hl=ko
- <application>
포함된 위치: <manifest>
포함 가능한 요소: <activity> <activity-alias> <meta-data> <service> <receiver> <profileable> <provider> <uses-library>
<uses-native-library>
애플리케이션을 선언한다. 애플리케이션의 각 구성요소(아이콘, 앱이름 등) 를 선언하는 하위 요소를 포함하며 모든 구성요소에 영향을 줄 수 있는 속성을 가진다. 속성 중 다수는 (icon, label, permission, process, taskAffinity, allowTaskReparentin)은 구성요소의 상응하는 속성에 기본값을 설정한다. 그 외 속성( debuggable, enabled, description, allowClearUserData)는 애플리케이션의 값을 전체적으로 설정하며 구성요소별로 재정의할 수 없다.
참고: https://developer.android.com/guide/topics/manifest/application-element?hl=ko
- <action>
포함된 요소: <intent-filter>
인텐트 필터에 작업을 추가한다. <intent-filter> 요소에 <action> 요소가 하나 이상 포함되어야 한다. <intent-filter> 요소에 <action> 요소가 없으면 필터가 Intent 객체를 허용하지 않는다.
<action android:name="string" />- android:name
작업의 이름이다. 일부 표준 작업은 Intent 클래스에서 ACTION_string 상수로 정의된다. 이러한 작업 중 하나를 이 속성에 할당하려면 ACTION_ 다음에 나오는 sting 앞에 'android.intent.action.'을 추가한다. 예를 들어 ACTION_MAIN이면 'android.intent.action.MAIN'을 사용하고, ACTION_WEB_SEARCH이면 'android.intent.action.WEB_SEARCH'를 사용한다. 개발자가 직접 정의하는 작업의 경우 고유성을 위해 앱의 패키지 이름을 접두사로 사용하는 것이 가장 좋다. 에를 들어 TRANSMORGIFY 작업을 위해 다음과 같이 지정할 수 있다.
<action android:name="com.example.project.TRANSMOGRIFY" />참고: https://developer.android.com/guide/topics/manifest/action-element?hl=ko
- <intent-filter>
포함된 위치: <activity> <activity-alias> <service> <receiver> <provider>
포함해야 하는 요소: <action>
포함 가능한 요소: <category> <data>
activity, 서비스, broadcast receiver가 응답할 수 있는 인텐트의 유형을 지정한다. 인텐트 필터는 활동이나 서비스가 할 수 있는 작업과 수신기가 처리할 수 있는 브로드캐스트의 유형을 선언한다. 전달된 유형의 수신 인텐트로 구성요소를 열고 구성요소에 의미가 없는 인텐트를 필터링한다.
앱이 인텐트를 시스템에 발행하면 시스템은 각 앱의 manifest 파일에 선언된 인텐트 필터에 기초하여 인텐트를 처리할 수 있는 앱의 구성 요소를 찾는다.
참고: https://developer.android.com/guide/topics/manifest/intent-filter-element?hl=ko
https://developer.android.com/guide/topics/manifest/manifest-intro?hl=ko#perms
- <category>
포함된 요소: <intent-filter>
인텐트 필터에 카테고리 이름을 추가한다. (인텐트 필터 및 필터 내에서 카테고리 사양 역할에 관해 자세히 알아보려면 인텐트와 인텐트 필터를 알아야 한다.)
- <activity>
포함된 위치: <application>
포함 가능한 요소: <intent-filters> <meta-data> <layout>
액티비티 구성요소를 선언한다. 애플리케이션의 시각적 사용자 인터페이스 요소를 구현하는 활동(Activity 서브클래스)를 선언한다. 모든 activity는 manifest 파일의 <activity> 요소로 나타내야 한다. 여기에 선언되지 않는 activity는 시스템에 표시되지 않으며 실행되지 않는다.
참고: https://developer.android.com/guide/topics/manifest/activity-element?hl=ko
- <activity-alias>
포함된 요소: <application>
포함 가능한 요소: <intent-filter> <meta-data>
activity의 별명을 설명한다. activity의 별칭으로, targetActivity 속성에서 이름이 지정된다. target은 별칭과 동일한 애플리케이션에 있어야 하며 manifest에서 별칭보다 먼저 선어해야 합니다. targetActivity를 제외하고 <activity-alias> 속성은 <activity> 속성의 하위 집합이다. 하위 집합에 있는 속성의 경우 타켓에 설정된 어떤 값도 별칭에 적용되지 않습니다. 그러나 하위 집합에 없는 속성의 경우 targetActivity에 설정된 값이 별칭에도 적용된다.
참고: https://developer.android.com/guide/topics/manifest/activity-alias-element?hl=ko
- <compatible-screens>
포함된 요소: <manifest>
애플리케이션이 호환되는 각 화면 구성을 지정한다. manifest에는 <compatible-screens> 요소의 인스턴스 1개만 허용되지만 <screen> 요소는 여러 개 포함할 수 있다. 각 <screen> 요소는 애플리케이션이 호환되는 특정 화면 크기-밀도 조합을 지정한다.
하위 요소: <screen>
애플리케이션이 호환되는 단일 화면 구성을 지정한다. 이 요소의 인스턴스 중 하나 이상이 <compatible-screens> 요소 내에 있어야 한다. 이 요소는 android:screenSize 및 android:screenDensity 속성을 둘 다 포함해야 한다. 두 속성을 선언하지 않으면 요소가 무시된다.
android:screenSize(이 화면 구성의 화면 크기를 지정), android:screenDensity(이 화면 구성의 화면 밀도 지정)
참고: https://developer.android.com/guide/topics/manifest/compatible-screens-element?hl=ko
- <data>
포함된 요소: <intent-filter>
데이터 사양을 인텐트 필터에 추가한다. 사양은 데이터 유형만 사용하거나 URI만 사용하거나 데이터 유형과 URI를 모두 사용할 수 있다. URI는 사양의 부분별로 개별 속성으로 지정된다.
URL 형식을 지정하는 이러한 속성은 선택사항이지만 상호 의존적이다. (인텐트 필터의 scheme을 지정하지 않으면 다른 모든 URI 속성이 무시된다, 필터의 host를 지정하지 않으면 port 속성과 모든 경로 속성이 무시된다.)
동일한 <intent-filter> 요소에 포함된 모든 <data> 요소는 동일한 필터에 기여한다.
<intent-filter> 내부에 <data> 요소를 원하는 수만큼 배치하여 여러 데이터 옵션을 제공할 수 있다. 속성에 기본값은 없다.
인텐트 객체와 필터의 일치 방식에 적용되는 규칙을 포함하여 인텐트 필터가 작동하는 방식과 관련된 정보는 다른 문서인 인텐트 및 인텐트 필터에서 확인할 수 있다.
참고: https://developer.android.com/guide/topics/manifest/data-element?hl=ko
- <grant-uri-permission>
포함된 요소: <provider>
상위 콘텐츠 제공자에 액세스 권한이 있는 앱 데이터의 하위 집합을 지정한다. 데이터 하위 집합은 content: URI의 경로 부분으로 나타낸다. uRI의 권한 부분은 콘텐츠 제공자는 식별한다. 권한 부여는 일반적으로 데이터 액세스 권한이 없는 제공자의 클라이언트가 일회성으로 제한을 극복할 수 있도록 하는 방법이다.
content provider의 grantUriPermissions 속성이 'true'이면 제공자의 범위 내에 있는 모든 데이터에 관한 권한을 부여할 수 있다. 하지만 이 속성이 'false'면 이 요소에서 지정하는 데이터 하위 집합에만 권한을 부여할 수 있다. provider는 <grant-uri-permission> 요소를 원하는 만큼 포함할 수 있다. 각 속성은 하나의 경로만(가능한 속성 중 하나만) 지정할 수 있다.
참고: https://developer.android.com/guide/topics/manifest/grant-uri-permission-element?hl=ko
- <instrumentation>
포함된 요소: <manifest>
애플리케이션과 시스템의 상호작용을 모니터링 할 수 있는 Instrumentation 클래스를 선언한다. Instrumentation object(객체)는 애플리케이션의 구성요소 이전에 인스턴스화된다.
참고: https://developer.android.com/guide/topics/manifest/instrumentation-element?hl=ko
- <meta-data>
포함된 요소: <activity> <activity-alias> <application> <provider> <receiver> <service>
상위 구성요소에 제공할 수 있는 추가적인 임의의 데이터 항목에 대한 이름-값 쌍이다. 구성요소 요소에는 여러 <meta-data> 하위 요소가 포함 될 수 있다. 모든 하위 요소의 값은 Bundle 객체에 수집되며 구성요소에 PackageItemInfo.metaData 필드로 제공된다. 일반 값은 value 속성을 통해 지정된다. 그러나 리소스 ID를 값으로 할당하려면 대신 resource 속성을 사용한다.
예를 들어 다음 코드는 @string/kangaroo 리소스에 저장된 값이 무엇이든 'zoo' 이름에 할당한다.
<meta-data android:name="zoo" android:value="@string/kangaroo" />하지만 resource 속성을 사용하면 리소스에 값이 아니라 리소스의 숫자 ID를 'zoo'에 할당한다.
<meta-data android:name="zoo" android:resource="@string/kangaroo" />
관련 데이터를 별도의 여러 <meta-data> 항목으로 제공하지 않는 것이 좋다. 대신 구성요소와 연결한 데이터가 복잡한 경우 데이터를 리소스로 저장한 다음 resource 속성을 사용해 구성요소에 리소스 ID로 알립니다.
참고: https://developer.android.com/guide/topics/manifest/meta-data-element?hl=ko
- <path-permission>
포함된 요소: <provider>
content provider 내의 특정 데이터 하위 집합에 관해 경로와 필수 권한을 정의한다. 이 요소를 여러번 지정하여 여러 경로를 제공할 수 있다.
참고: https://developer.android.com/guide/topics/manifest/path-permission-element?hl=ko
- <permission>
포함된 요소: <manifest>
이 애플리케이션이나 또는 다른 애플리케이션의 각 특성 구성요소 또는 기능에 대한 액세스를 제한하는 데 사용될 수 있는 보안 권한을 선언한다.
앱에서 권한을 정의할 수도 있는데, 새 권한을 선언할 때는 <permission> 요소를 사용한다. 권한 요청 외에도 애플리케이션은 <permission> 요소를 사용하여 보안에 민감하고 Content Provider와 같은 다른 애플리케이션에 노출되는 IPC(프로세서 간 통신)를 보호할 수 있다.
참고: https://developer.android.com/guide/topics/manifest/permission-element?hl=ko
https://developer.android.com/training/articles/security-tips?hl=ko
https://developer.android.com/guide/topics/manifest/permission-element?hl=ko
- <permission-group>
포함된 요소: <manifest>
관련 권한의 논리적 집합에 대한 그룹 이름을 선언한다. 개별 권한은 <permission> 요소의 permissionGroup 속성을 통해 그룹에 참여한다. 그룹의 구성은 사용자 인터페이스에 함께 표시된다.
이 요소는 권한 자체를 선언하지 않고, 권한을 배치할 수 있는 카테고리만 선언한다.
참고: https://developer.android.com/guide/topics/manifest/permission-group-element?hl=ko
- <permission- tree>
포함된 위치: <manifest>
permission tree의 기본 이름을 선언한다. 애플리케이션은 트리 내의 모든 이름의 소유권을 가진다. PackageManager.addPermission()을 호출하여 동적으로 새 권한을 트리에 추가할 수 있다. 트리 내에서 이름은 마침표로 구분한다.
이 요소는 권한 자체를 선언하지 않으며 추가 권한을 배치할 수 있는 네임스페이스만 선언한다.
참고: https://developer.android.com/guide/topics/manifest/permission-tree-element?hl=ko
- <uses-permission>
포함된 요소: <manifest>
앱이 올바르게 작동하기 위해 사용자가 반드시 부여해야 하는 시스템 권한이다. 애플리케이션이 설치 될 때(Android 5.1 이하 버전을 실행하는 기기) 또는 앱이 실행 중일 때(Android 6.0 이상 버전을 실행하는 기기) 사용자에게 권한이 부여도니다.
android: maxSdkVersion (앱에 이 권한을 부여해야 하는 최상위 API 수준이다. maxSdkVersion이 18이면 19부터는 이 권한을 부여하지 않는다.)
Android 앱은 민감한 사용자 데이터(연락처, SMS) 또는 특정 시스템 기능(카메라, 인터넷 액세스)에 액세스하기 위한 권한을 요청해야 한다. 각 권한은 고유한 레이블로 식별한다. 예를 들어 SMS 메시지를 보내야 하는 앱을 manifest에 다음과 같은 줄이 있어야 한다.
<manifest ... >
<uses-permission android:name="android.permission.SEND_SMS"/>
...
</manifest>
Android 6.0(API 레벨 23)부터는 사용자가 런타임에서 일부 앱 권한을 승인하거나 거절할 수 있게 된다. 그러나 앱이 어떤 Android 버전을 지원하든 manifest에서 <uses-permission> 요소로 모든 권한을 선언해야 한다. 권한이 부여되면 앱이 보호된 기능을 사용할 수 있다. 권한이 부여되지 않으면 그러한 기능에 액세스하려는 시도가 실패한다.
참고: https://developer.android.com/guide/topics/manifest/permission-tree-element?hl=ko
https://developer.android.com/guide/topics/manifest/manifest-intro?hl=ko#perms
- <uses-permission-sdk-23>
포함된 위치: <manifest>
앱이 특정 권한을 원하는 것을 지정한다. 단, Android 6.0(API 수준 23) 이상을 실행하는 기기에 앱이 설치된 경우에만 해당된다. 기기가 API 수준 22 이하를 실행 중인 경우에는 앱에 지정된 권한이 없다.
이 요소는 추가 권한이 필요한 새 기능을 포함하기 위해 앱을 업데이트하는 경우 유용하다. 사용자가 API 수준 22 이하를 실행하는 기기에서 앱을 업데이트하는 경우 시스템은 사용자에게 설치 시 업데이트에 선언된 새 권한을 부여하도록 요청하는 메시지를 표시한다.
참고: https://developer.android.com/guide/topics/manifest/uses-permission-sdk-23-element?hl=ko
- <uses-sdk>
포함된 요소: <manifest>
하나 이상의 Android 플랫폼 버전과의 애플리케이션 호환성을 API 수준 정수로 표시할 수 있다. 애플리케이션이 표시한 API 수준은 해당 Android 시스템의 API 수준가 비교가 되고, 이는 여러 Android 기기들마다 다를 수 있다.
android:minSdkVersion (애플리케이션이 실행하는데 필요한 최소 API 수준을 지정하는 정수이다.)
android:targetSdkVersion(애플리케이션의 대상 API 수준을 지정하는 정수이다.)
android:maxSdkVersion(애플리케이션이 실행하도록 설계된 최대 API 수준을 지정하는 정수이다.)
참고: https://developer.android.com/guide/topics/manifest/uses-sdk-element?hl=ko
- <profileable>
profiler가 이 애플리케이션에 액세스할 수 있는 방법을 지정한다.
참고: https://developer.android.com/guide/topics/manifest/profileable-element?hl=ko
- <provider>
포함된 위치: <application>
포함 가능한 요소: <meta-data> <grant-uri-permission> <intent-filter> <path-permission>
content provider(애플리케이션에서 관리되는 데이터에 관해 구조화된 액세스를 제공하는 ContentProvider 서브클래스) 구성요소를 선언한다. 애플리케이션의 모든 content provider는 manifest 파일의 <provider> 요소에 정의해야한다.
content proivder는 애플리케이션이 자체적으로 저장된 데이터, 다른 앱이 저장한 데이터에 대한 액세스 권한을 관리하도록 돕고 다른 앱과 데이터를 공유할 방법을 제공한다.
참고:https://developer.android.com/guide/topics/manifest/provider-element?hl=ko
https://developer.android.com/guide/topics/providers/content-providers?hl=ko
- <queries>
포함된 위치: <manifest>
앱이 상호작용할 다른 앱 집합을 지정한다. 패키지 이름, 인텐트 서명 또는 provider 권한을 기준으로 다른 앱을 지정할 수 있다.
참고: https://developer.android.com/guide/topics/manifest/queries-element?hl=ko
- <receiver>
포함된 위치: <application>
포함한 가능한 요소: <intent-filter> <meta-data>
board receiver(BroadcastReceiver 서브클래스)를 애플리케이션의 구성요소 중 하나로 선언합니다. boardcast receiver를 사용하면 애플리케이션의 다른 구성요소가 실행되고 있지 않을 때도 시스템이나 다른 애플리케이션에서 브로드캐스트하는 인텐트를 애플리케이션에서 수신할 수 있다.
boardcast receiver를 시스템에 알리는 방법에는 두 가지가 있다. 한 가지 방법은 이 요소를 사용해 manifest 파일에 broadcast receiver를 선언하는 것이다. 또 다른 방법은 코드에서 동적으로 boardcast receiver를 만든 다음 Context.registerReceiver() 메서드를 사용해 등록하는 것이다.
참고: https://developer.android.com/guide/topics/manifest/receiver-element?hl=ko
- <service>
포함된 위치: <application>
포함 가능한 요소: <intent-filter> <meta-data>
서비스(Service 서비스클래스)를 애플리케이션의 구성요소 하나로 선언한다. activity와 달리 service는 시각적 사용자 인터페이스가 없다. 서비스는 오래 실행되는 백그라운드 작업이나 다른 애플리케이션에서 호출할 수 있는 리치 커뮤니케이션 API를 구현하는데 사용한다.
참고: https://developer.android.com/guide/topics/manifest/service-element?hl=ko
- <supports-gl-texture>
포함된 요소: <manifest>
앱에서 지원하는 단일 GL 텍스처 압축을 선언한다.
참고: https://developer.android.com/guide/topics/manifest/supports-gl-texture-element?hl=ko
- <supports-screens>
포함된 위치: <manifest>
애플리케이션에서 지원하는 화면 크기를 지정하고 사용하는 화면이 애플리케이션에서 지원하는 화면보다 큰 경우 화면 호환 모드를 사용 설정할 수 있게 한다. 애플리케이션에서 항상 이 요소를 사용하여 애플리케이션에서 지원하는 화면 크기를 지정하는 것이 중요하다.
참고: https://developer.android.com/guide/topics/manifest/supports-screens-element?hl=ko
- <uses-configuration>
애플리케이션이 요구하는 특정 입력 기능을 나타낸다. 애플리케이션에 필요한 하드웨어 및 소프트웨어 기능을 나타낸다. 예를 들어 애플리케이션에서 물리적 키보드 또는 특정 탐색 기기가 필요하다고 지정할 수 있다. 이 지정은 애플리케이션이 작동하지 않는 기기에 애플리케이션이 설치되지 않도록 하는데 사용된다.
참고: https://developer.android.com/guide/topics/manifest/uses-configuration-element?hl=ko
- <uses-feature>
포함된 위치: <manifest>
애플리케이션이 사용하는 단일 하드웨어 또는 소프트웨어 기능을 선언한다. <uses-feature> 선언의 목적은 애플리케이션이 의존하는 하드웨어 및 소프트웨어 기능 집합을 알려주는 것이다. 이 요소는 required 속성을 제공한다. 개발자는 이 속성을 통해 선언된 기능을 애플리케이션이 작동하기 위한 필수 요건으로 지정하거나, 기능이 있는 것을 권장하지만 없어도 작동하도록 지정할 수 있다.
각 기능을 개별 <uses-feature> 요소에 지정해야 하므로 애플리케이션에 여러 가지 기능이 필요한 경우 <uses-feature> 요소를 여러개 선언한다. 예를 들어 기기의 블루투스 기능과 카메라 기능이 모두 필요한 애플리케이션은 다음과 같은 두 요소를 선언한다.
<uses-feature android:name="android.hardware.bluetooth" android:required="true" />
<uses-feature android:name="android.hardware.camera.any" android:required="true" />
참고: https://developer.android.com/guide/topics/manifest/uses-feature-element?hl=ko
- <uses-library>
애플리케이션이 연결되어야 하는 공유 라이브러리를 지정한다. 이 요소는 패키지의 클래스 로더에 라이브러리 코드를 포함하도록 시스템에 알린다.
참고: https://developer.android.com/guide/topics/manifest/uses-library-element?hl=ko
- <uses-native-library>
애플리케이션을 연결해야 하는 native library를 지정한다. 이 요소는 패키지에서 native library에 액세스 할 수 있도록 시스템에 지시한다.
참고: https://developer.android.com/guide/topics/manifest/uses-native-library-element?hl=ko
'Studying > Android' 카테고리의 다른 글
| [GDSC 안드로이드 스터디] 1주차 solution 안드로이드 파일의 기본구조 알기- layout 정리 (0) | 2022.11.07 |
|---|---|
| [GDSC 안드로이드 스터디] 1주차 solution 안드로이드 파일의 기본구조 알기- Palatte 정리 (0) | 2022.11.06 |
| [GDSC 안드로이드 스터디] 1주차 solution 안드로이드 파일의 기본구조 알기- 4대 컴포넌트, intent (0) | 2022.11.06 |
| [GDSC 안드로이드 스터디] 1주차 강의 Layout 클래스 (0) | 2022.11.04 |
| [GDSC 안드로이드 스터디] 1주차 강의 UI 프로그래밍의 기본 (0) | 2022.11.04 |