Omówienie pliku manifestu aplikacji

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 klasy Activity
• <service> dla każdej podklasy klasy Service
• <receiver> dla każdej podklasy klasy BroadcastReceiver
• <provider> dla każdej podklasy klasy ContentProvider

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:

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
        ...
    }
}

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.

Elements

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 prefiksu android:, na przykład android: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 lub drawable, 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.

Limity

Następujące tagi mają ograniczoną liczbę wystąpień w pliku manifestu:

Następujące atrybuty mają ograniczenia dotyczące maksymalnej długości:

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>