Każdy projekt aplikacji musi mieć plik AndroidManifest.xml
, który dokładnie
imię i nazwisko,
w katalogu głównym zbioru źródłowego projektu.
Plik manifestu zawiera podstawowe informacje
narzędzia do kompilacji, system operacyjny Android oraz narzędzia
Google Play.
Plik manifestu musi zawierać między innymi te elementy:
- Komponenty aplikacji, w tym wszystkie aktywności, usługi, odbiornikami i dostawcami treści. Każdy komponent musi definiować podstawowe takie jak nazwa jego klasy Kotlin lub Java. Może również zadeklarować jego możliwości, np. możliwych konfiguracji urządzeń, filtry intencji, które opisują sposób uruchamiania komponentu. Więcej informacji o komponentach aplikacji znajdziesz w następnej sekcji.
- Uprawnienia wymagane przez aplikację dostęp do chronionych części systemu lub innych aplikacji. Deklaruje też wszystkie uprawnienia, które inne aplikacje muszą mieć, jeśli chcą uzyskać dostęp do treści z tej aplikacji. Więcej informacji o uprawnieniach znajdziesz w następnej sekcji.
- sprzęt i oprogramowanie wymagane przez aplikację, co ma wpływ na na urządzeniach, na których można zainstalować aplikację z Google Play. Więcej informacji o zgodności urządzeń znajdziesz w następnej sekcji.
Jeśli tworzysz aplikację za pomocą Android Studio, plik manifestu jest tworzone automatycznie, a większość podstawowych elementów manifestu jest dodawana jako zwłaszcza wtedy, gdy używasz szablonów kodu.
Funkcje pliku
W sekcjach poniżej opisano niektóre z najważniejszych cech aplikacji pojawi się w pliku manifestu.
Komponenty aplikacji
Dla każdej aplikacji komponent utworzony w aplikacji, zadeklaruj w pliku manifestu odpowiedni element XML:
<activity>
dla każdej podklasy klasyActivity
<service>
dla każdej podklasy klasyService
<receiver>
dla każdej podklasy klasyBroadcastReceiver
<provider>
dla każdej podklasy klasyContentProvider
Jeśli zmienisz klasę dowolnego z tych komponentów na podklasę bez zadeklarowania go w pliku manifestu system nie może go uruchomić.
Podaj nazwę podklasy za pomocą atrybutu name
używając pełnego oznaczenia pakietu. Na przykład
Podklasa Activity
jest deklarowana w ten sposób:
<manifest ... > <application ... > <activity android:name="com.example.myapp.MainActivity" ... > </activity> </application> </manifest>
Jeśli jednak pierwszy znak w wartości name
jest kropką,
do przestrzeni nazw aplikacji, z narzędzia build.gradle
na poziomie modułu
namespace
jest poprzedzona nazwą. Jeśli na przykład przestrzeń nazw to
"com.example.myapp"
, ta nazwa aktywności odpowiada
com.example.myapp.MainActivity
:
<manifest ... > <application ... > <activity android:name=".MainActivity" ... > ... </activity> </application> </manifest>
Więcej informacji o ustawianiu nazwy lub przestrzeni nazw pakietu znajdziesz w artykule Ustawianie przestrzeni nazw.
Jeśli masz komponenty aplikacji, które znajdują się w podpakietach, np.
com.example.myapp.purchases
, wartość name
musi dodać brakującą wartość
nazw podpakietów, takich jak ".purchases.PayActivity"
, lub użyj
w pełni kwalifikowana nazwa pakietu.
Filtry intencji
Aktywność w aplikacjach, usługi i komunikaty
odbiorcy są aktywowani przez zamiary. Intencja to komunikat zdefiniowany przez
obiekt Intent
opisujący
działania do wykonania, w tym dane, na podstawie których należy podjąć działanie, kategorię
który ma wykonać działanie, oraz inne instrukcje.
Gdy aplikacja wysyła intencję do systemu, system znajduje ją
komponent, który może obsłużyć intencję na podstawie filtra intencji.
deklaracje w pliku manifestu każdej aplikacji. System zostaje uruchomiony
wystąpienie pasującego komponentu i przekazuje do niego obiekt Intent
. Jeśli więcej niż jedna aplikacja może
obsługuje intencję, użytkownik może wybrać aplikację, której chce użyć.
Komponent aplikacji może mieć dowolną liczbę filtrów intencji (zdefiniowanych za pomocą funkcji
<intent-filter>
), z których każdy opisuje inne możliwości danego komponentu.
Więcej informacji znajdziesz w dokumencie Intencje i filtry intencji.
Ikony i etykiety
Niektóre elementy manifestu mają atrybuty icon
i label
.
atrybutów wyświetlania odpowiednio małej ikony i etykiety tekstowej.
dla odpowiedniego komponentu aplikacji.
W każdym przypadku ikona i etykieta ustawiona w elemencie nadrzędnym stają się domyślnymi
icon
i label
dla wszystkich elementów podrzędnych.
Na przykład ikona i etykieta ustawione w sekcji
<application>
są domyślną ikoną i etykietą poszczególnych komponentów aplikacji, np. wszystkich aktywności.
Ikona i etykieta ustawione w komponencie
<intent-filter>
są wyświetlane, gdy komponent jest przedstawiony jako opcja
realizowanych celów. Domyślnie ta ikona jest dziedziczona z dowolnego
dla komponentu nadrzędnego jest deklarowana,
<activity>
lub
<application>
.
Możesz zmienić ikonę dla filtra intencji, jeśli oferuje on unikalne działanie, które chcesz lepiej wskazać w okno wyboru. Więcej informacji znajdziesz w artykule Zezwalanie innym aplikacjom na rozpoczynanie Twojej aktywności.
Uprawnienia
Aplikacje na Androida muszą prosić o dostęp do poufnych danych użytkownika, takich jak kontakty i SMS-y, lub pewnych funkcji systemowych, takich jak za pomocą aparatu i dostępu do internetu. Każde uprawnienie jest oznaczone unikalną etykietą. Na przykład aplikacja, która musi wysyłać SMS-y, musi mieć: w pliku manifestu:
<manifest ... > <uses-permission android:name="android.permission.SEND_SMS"/> ... </manifest>
Rozpoczyna się od
Android 6.0 (poziom interfejsu API 23) użytkownik może zatwierdzać lub odrzucać niektóre uprawnienia aplikacji w czasie działania. Ale
Bez względu na to, którą wersję Androida obsługuje Twoja aplikacja, wszystkie żądania uprawnień musisz zadeklarować za pomocą tagu
<uses-permission>
w pliku manifestu. Jeśli to uprawnienie zostanie przyznane, aplikacja będzie mogła korzystać z chronionego
funkcje zabezpieczeń. W przeciwnym razie próby uzyskania dostępu do tych funkcji się nie uda.
Aplikacja może też chronić własne komponenty za pomocą uprawnień. Może użyć funkcji
wszystkie uprawnienia zdefiniowane przez Androida, wymienione w
android.Manifest.permission
lub uprawnienie
zadeklarowany w innej aplikacji. Aplikacja może też określać własne uprawnienia.
Nowe uprawnienie zostało zadeklarowane razem z
<permission>
.
Więcej informacji znajdziesz w sekcji Uprawnienia na urządzeniu z Androidem.
Zgodność urządzeń
W pliku manifestu możesz też zadeklarować, jakiego typu sprzęt lub funkcji oprogramowania wymaganych przez aplikację, a także typów urządzeń, na których aplikacja który jest zgodny z technologią. Sklep Google Play nie zezwala użytkownikom na instalowanie Twojej aplikacji na urządzeniach, które nie mają funkcji lub wersji systemu tej aplikacji wymaga.
Istnieje kilka tagów manifestu, które określają, na jakich urządzeniach działa aplikacja . Oto najpopularniejsze z nich.
<uses-feature>
<uses-feature>
pozwala zadeklarować sprzęt oraz
funkcje oprogramowania, których potrzebuje Twoja aplikacja. Jeśli na przykład aplikacja nie może osiągnąć podstawowych
W przypadku urządzenia bez czujnika kompasu możesz zadeklarować,
czujnika zgodnie z wymaganiami z następującym tagiem manifestu:
<manifest ... > <uses-feature android:name="android.hardware.sensor.compass" android:required="true" /> ... </manifest>
Uwaga: Jeśli chcesz udostępnić swoją aplikację na Chromebookach, ważne ograniczenia funkcji sprzętu i oprogramowania i ujawniamy to, co naprawdę ważne. Więcej informacji: Zgodność pliku manifestu aplikacji Chromebooki.
<uses-sdk>
Każda kolejna wersja platformy często dodaje nowe interfejsy API,
dostępne w poprzedniej wersji. Aby wskazać minimalną wersję aplikacji,
zgodne, plik manifestu musi zawierać tag <uses-sdk>
i minSdkVersion
.
Pamiętaj jednak, że atrybuty w elemencie <uses-sdk>
są zastąpione przez odpowiednie właściwości
w pliku build.gradle
.
Jeśli więc korzystasz z Android Studio, określ minSdkVersion
i
Zamiast tego targetSdkVersion
wartości:
Odlotowe
android { defaultConfig { applicationId 'com.example.myapp' // Defines the minimum API level required to run the app. minSdkVersion 21 // Specifies the API level used to test the app. targetSdkVersion 33 ... } }
Kotlin
android { defaultConfig { applicationId = "com.example.myapp" // Defines the minimum API level required to run the app. minSdkVersion(21) // Specifies the API level used to test the app. targetSdkVersion(33) ... } }
Więcej informacji o pliku build.gradle
znajdziesz w artykule o konfigurowaniu kompilacji.
Aby dowiedzieć się, jak zadeklarować obsługę różnych urządzeń, znajdziesz w sekcji Zgodność urządzeń .
Konwencje plików
W tej sekcji opisano konwencje i reguły, które dotyczą wszystkich elementów i atrybutów w pliku manifestu.
- Elementy
- Tylko
<manifest>
i<application>
elementów są wymagane. Każda z nich musi wystąpić tylko raz. Większość pozostałych elementów może wystąpić zero lub więcej razy. Jednak niektóre muszą być obecne, aby plik manifestu był przydatny.Wszystkie wartości są ustawiane przez atrybuty, a nie jako dane znaków w obrębie i inne elementy.
Elementy na tym samym poziomie zwykle nie są uporządkowane. Na przykład parametr
<activity>
,<provider>
i<service>
elementy można umieścić w dowolnej kolejności. Istnieją 2 główne wyjątki od tej reguły reguła:-
<activity-alias>
element musi być po<activity>
dla których jest to alias. -
Element
<application>
musi być ostatnim elementem wewnątrz<manifest>
.
-
- Atrybuty
- Z technicznego punktu widzenia wszystkie atrybuty są opcjonalne. Jednak w przypadku wielu atrybutów
musi być określony, aby element mógł zrealizować swoje przeznaczenie.
W przypadku atrybutów naprawdę opcjonalnych zapoznaj się z dokumentacją
wskazuje wartości domyślne.
Z wyjątkiem niektórych atrybutów katalogu głównego
<manifest>
, wszystkie nazwy atrybutów zaczynają się od prefiksuandroid:
, na przykładandroid:alwaysRetainTaskState
. Ponieważ prefiks to uniwersalne, w dokumentacji pomijane jest przy odwoływaniu się do atrybutów. według imienia i nazwiska. - Wiele wartości
- Jeśli można określić więcej niż jedną wartość, element jest prawie zawsze
wartość może się powtarzać, a nie w jednym elemencie.
Na przykład filtr intencji może wyświetlić listę kilku działań:
<intent-filter ... > <action android:name="android.intent.action.EDIT" /> <action android:name="android.intent.action.INSERT" /> <action android:name="android.intent.action.DELETE" /> ... </intent-filter>
- Wartości zasobów
- Niektóre atrybuty mają wartości, które są wyświetlane użytkownikom, takie jak
tytuł aktywności lub ikonę aplikacji. Wartości tych atrybutów mogą
różnią się w zależności od języka użytkownika lub innych konfiguracji urządzenia (np.
ikona ikony powinna mieć inny rozmiar w zależności od gęstości pikseli na ekranie).
wartości powinny być ustawiane na podstawie zasobu lub motywu, a nie na stałe
manifestu. Rzeczywista wartość może się następnie zmienić w zależności od parametru alternatywnego
zasobów dostępnych na potrzeby różnych konfiguracji urządzeń.
Zasoby są wyrażone jako wartości w tym formacie:
"@[package:]type/name"
Możesz pominąć nazwę package, jeśli zasób został dostarczony przez aplikacji (także jeśli jest ona udostępniana przez zależność biblioteki, ponieważ zasoby biblioteki są możesz połączyć z Twoją). Jedyna inna prawidłowa nazwa pakietu to
android
, gdy chcesz skorzystać z zasobu z Androida platformy.type jest typem zasobu, np.
string
lubdrawable
, a name to nazwa identyfikująca konkretny zasób. Oto przykład:<activity android:icon="@drawable/smallPic" ... >
Więcej informacji o dodawaniu zasobów do projektu znajdziesz w artykule Omówienie zasobów dotyczących aplikacji.
Aby zamiast tego zastosować wartość określoną w motywie, pierwszy znak musi wynosić
?
zamiast@
:"?[package:]type/name"
- Wartości ciągu znaków
- Gdy wartość atrybutu jest ciągiem znaków, użyj podwójnych ukośników lewych
(
\\
), aby zmienić znaczenie znaków, np.\\n
dla nowego wiersza lub\\uxxxx
w przypadku znaku Unicode.
Odniesienie do elementów pliku manifestu
W tabeli poniżej znajdziesz linki do dokumentów referencyjnych dotyczących wszystkich prawidłowych
elementów w pliku AndroidManifest.xml
.
<action> |
Dodaje działanie do filtra intencji. |
<activity> |
Deklaruje komponent aktywności. |
<activity-alias> |
Deklaruje alias aktywności. |
<application> |
Deklaruje aplikację. |
<category> |
Dodaje nazwę kategorii do filtra intencji. |
<compatible-screens> |
Określa każdą konfigurację ekranu, z którą aplikacja jest zgodna. |
<data> |
Dodaje specyfikację danych do filtra intencji. |
<grant-uri-permission> |
Określa podzbiory danych aplikacji, do których ma dostęp nadrzędny dostawca treści. |
<instrumentation> |
Deklaruje klasę Instrumentation , która umożliwia monitorowanie interakcji aplikacji z systemem. |
<intent-filter> |
Określa typy intencji, na które może reagować działanie, usługa lub odbiornik. |
<manifest> |
Element główny pliku AndroidManifest.xml . |
<meta-data> |
Para nazwa-wartość określająca element dodatkowych, dowolnych danych, które można przekazać do komponentu nadrzędnego. |
<path-permission> |
Definiuje ścieżkę i wymagane uprawnienia do określonego podzbioru danych w ramach dostawcy treści. |
<permission> |
Deklaruje uprawnienia dotyczące zabezpieczeń, które mogą być używane do ograniczenia dostępu do określonych komponentów lub funkcji tej lub innych aplikacji. |
<permission-group> |
Deklaruje nazwę logicznej grupy powiązanych uprawnień. |
<permission-tree> |
Deklaruje podstawową nazwę drzewa uprawnień. |
<provider> |
Deklaruje komponent dostawcy treści. |
<queries> |
Deklaruje zestaw innych aplikacji, do których aplikacja ma mieć dostęp. Więcej informacji w przewodniku po widoczności pakietów |
<receiver> |
Deklaruje komponent odbiornika. |
<service> |
Deklaruje komponent usługi. |
<supports-gl-texture>
| Deklaruje format kompresji tekstur pojedynczego GL, który jest obsługiwany przez aplikację. |
<supports-screens> |
Deklaruje rozmiary ekranów, które obsługuje Twoja aplikacja, i włącza tryb zgodności ekranu w przypadku ekranów większych niż obsługiwane przez Twoją aplikację. |
<uses-configuration> |
Wskazuje funkcje wejściowe wymagane przez aplikację. |
<uses-feature> |
Deklaruje pojedynczą funkcję sprzętu lub oprogramowania, które są używane przez aplikację. |
<uses-library> |
Określa bibliotekę współdzieloną, z którą musi być połączona aplikacja. |
<uses-native-library> |
Określa dostarczoną przez dostawcę natywną bibliotekę współdzieloną, z którą aplikacja musi być połączona. |
<uses-permission> |
Określa uprawnienie systemowe, które użytkownik musi przyznać, aby aplikacja mogła działać prawidłowo. |
<uses-permission-sdk-23> |
Określa, że aplikacja potrzebuje określonych uprawnień, ale tylko wtedy, gdy jest zainstalowana na urządzeniu z Androidem 6.0 (poziom interfejsu API 23) lub nowszym. |
<uses-sdk> |
Umożliwia określenie zgodności aplikacji z jedną lub wieloma wersjami platformy Android za pomocą liczby całkowitej poziomu interfejsu API. |
Limity
Następujące tagi mają ograniczoną liczbę wystąpień w pliku manifestu:
Nazwa tagu | Limit |
---|---|
<package> |
1000 |
<meta-data> |
1000 |
<uses-library> |
1000 |
Następujące atrybuty mają ograniczenia dotyczące maksymalnej długości:
Atrybut | Limit |
---|---|
name |
1024 |
versionName |
1024 |
host |
255 |
mimeType |
255 |
Przykładowy plik manifestu
Poniższy kod XML to prosty przykład atrybutu AndroidManifest.xml
, który deklaruje
dwie aktywności w aplikacji.
<?xml version="1.0" encoding="utf-8"?>
<manifest
xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="1"
android:versionName="1.0">
<!-- Beware that these values are overridden by the build.gradle file -->
<uses-sdk android:minSdkVersion="15" android:targetSdkVersion="26" />
<application
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:roundIcon="@mipmap/ic_launcher_round"
android:label="@string/app_name"
android:supportsRtl="true"
android:theme="@style/AppTheme">
<!-- This name is resolved to com.example.myapp.MainActivity
based on the namespace property in the build.gradle file -->
<activity android:name=".MainActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
<activity
android:name=".DisplayMessageActivity"
android:parentActivityName=".MainActivity" />
</application>
</manifest>