Как найти файл манифеста

Манифест — это набор правил, по которым работает приложение. Файл манифеста находится в корневой папке — AndroidManifest.xml — и содержит важную информацию, без которой система не сможет запустить приложение.

Основное содержимое манифеста:

• Имя пакета для приложения. Является идентификатором приложения.
• Описание возможностей компонентов приложения: Activity, Service, Broadcast Receiver.
• Процессы, в которых будут запускаться компоненты приложения.
• Разрешения, которые необходимо запросить у пользователя, чтобы у приложения был доступ к защищенным частям API, а также чтобы другие приложения могли обращаться к вашему приложению.
• Содержит список классов Instrumentation, которые при выполнении приложения предоставляют сведения о профиле и прочую информацию. Эти объявления присутствуют в файле манифеста только во время разработки и отладки приложения и удаляются перед его публикацией.
• Объявляет минимальный уровень API Android, необходимый для работы приложения.
• Перечисляет связанные библиотеки.

Основные правила манифеста:

• Обязательно надо указать в манифесте два тега: <manifest> и <application>. Оба можно указать только один раз.
• Большинство тегов можно указывать несколько раз или не указывать совсем. Это зависит от того, что будет делать приложение. 
• Тег <activity-alias> должен следовать за тегом своей <activity>. Но многие теги одного уровня могут следовать в любом порядке. 
• Все значения задаются только в виде атрибутов. Некоторые атрибуты надо прописывать обязательно, некоторые ‒ нет. Если атрибут не прописан ‒ используется значение по умолчанию. 
• Большинство атрибутов должны начинаться с префикса android. Только некоторые атрибуты тега manifest могут не иметь этого префикса.
• Многие элементы соответствуют объектам Java. Например, если вы указываете имя для activity с помощью атрибута name, то в состав имени должно входить полное обозначение пакета.
• Если элементу нужно указать несколько значений, то он всегда приводится повторно, вместо перечисления нескольких значений в одном элементе.

Структура файла

Ниже представлена структура манифеста со всеми возможными элементами. А далее рассмотрим каждый элемент отдельно. Для быстрого перехода к интересующему элементу кликайте по содержанию справа.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

<?xml version="1.0" encoding="utf-8"?>

<manifest>

    <uses-permission />
    <permission />
    <permission-tree />
    <permission-group />
    <instrumentation />
    <uses-sdk />
    <uses-configuration />  
    <uses-feature />  
    <supports-screens />  
    <compatible-screens />  
    <supports-gl-texture />  

    <application>

        <activity>
            <intent-filter>
                <action />
                <category />
                <data />
            </intent-filter>
            <meta-data />
        </activity>

        <activity-alias>
            <intent-filter> . . . </intent-filter>
            <meta-data />
        </activity-alias>

        <service>
            <intent-filter> . . . </intent-filter>
            <meta-data/>
        </service>

        <receiver>
            <intent-filter> . . . </intent-filter>
            <meta-data />
        </receiver>

        <provider>
            <grant-uri-permission />
            <meta-data />
            <path-permission />
        </provider>

        <uses-library />

    </application>

</manifest>

<?xml version="1.0" encoding="utf-8"?>

Пространство имен Android, оно всегда одно и то же.

<manifest>

Корневой элемент манифеста. Является обязательным.

<uses-permission>

Разрешения, которые должны быть запрошены при установке приложения для его нормального функционирования.

В некоторых случаях данные разрешения могут повлиять на фильтрацию вашего приложения в Google Play. Например, если вы запрашиваете разрешение на использование камеры, то Google Play логично предположит, что для работы вашего приложения необходима камера и будет фильтровать устройства, на которых ее нет. Чтобы корректно управлять данной фильтрацией, нужно использовать <uses-feature>.

Атрибуты:

• android:name — имя разрешения. Это может быть разрешение, определенное в элементе <permission> данного приложения, разрешение, определенное в другом приложении или одно из стандартных системных разрешений.
• android:maxSdkVersion — самый высокий уровень API, на котором это разрешение должно быть предоставлено вашему приложению. Полезно использовать, когда с определенного уровня API запрашивать разрешение больше не требуется.

<permission>

Разрешения, которые должны запросить другие приложения для получения доступа к вашему приложению. Можно использовать существующие, либо создать собственные.

Атрибуты:

• android:name — имя разрешения, будет использоваться в коде для ссылки на разрешение. Имена должны быть уникальными, так как если имя вашего разрешения совпадёт с именем разрешения другого приложения (которое уже установлено пользователем), то система не разрешит пользователю установить ваше приложение.
• android:label — имя разрешения, отображаемое пользователю.
• android:description — описание, которое должно объяснять пользователю для чего текущее разрешение требуется.
• android:icon — иконка разрешения.
• android:permissionGroup — определяет принадлежность к группе разрешений. Значением этого атрибута является имя группы, которое должно быть объявлено в элементе <permission-group> (в вашем или другом приложении).
• android:protectionLevel — уровень защиты, который говорит системе, как она должна себя вести, если текущее разрешение было кем-то запрошено. У данного атрибута может быть много значений, подробнее в документации.

<permission-tree>

Элемент позволяет приложению объявлять пространство имён разрешений, в которое оно может динамически во время выполнения добавлять новые разрешения.

Атрибуты:

• android:icon — иконка, которая будет отображаться для всех разрешений в дереве.
• android:label — имя группы (дерева разрешений).
• android:name — имя, которое будет добавляться как префикс всем разрешениям в древе. Должно быть уникальным, для этого рекомендуется, чтобы оно содержало более двух сегментов, разделенных точками.

<permission-group>

Объявляет имя категории, в которую можно сгруппировать все логически связанные разрешения. Добавить разрешение в группу можно с помощью атрибута permissionGroup элемента <permission>. Разрешения из одной группы в пользовательском интерфейсе отображаются вместе.

Атрибуты:

• android:description — описание группы, отображаемое пользователю. Должно быть полным и понятным.
• android:icon — иконка.
• android:label — имя группы, отображаемое пользователю.
• android:name — имя группы, которое используется в коде для назначения категории атрибуту permissionGroup элемента <permission>.

<instrumentation>

Объявляет класс Instrumentation, который дает возможность отслеживать все взаимодействия, которые система выполняет с приложением. Обычно используется при отладке и тестировании приложения и удаляется из release-версии приложения.

Атрибуты:

• android:functionalTest — если true — класс Instrumentation будет работать как функциональный тест, если false — нет.
• android:handleProfiling — будет ли класс Instrumentation включать / выключать профилирование. True — будет включать / выключать, при этом позволяет нацеливаться на определенный набор операций, false — профилирование будет выполняться все время.
• android:icon — иконка, которая будет присвоена классу Instrumentation.
• android:label — заголовок для класса Instrumentation.
• android:name — полное имя класса, который реализует Instrumentation.
• android:targetPackage — приложение, с которым будет работать объект Instrumentation. Приложение идентифицируется по имени пакета, назначенному в его файле манифеста.
• android:targetProcesses — процессы, с которыми будет работать объект Instrumentation. Можно перечислить через запятую или указать "*" для взаимодействия со всеми процессами, которые заданы атрибутом android:targetPackage.

<uses-sdk>

Совместимость приложения с указанной версией Android. Когда приложение будет устанавливаться, система сравнит указанный уровень API с API устройства. Также Google Play использует этот элемент, чтобы отфильтровывать устройства, которые не соответствуют указанному уровню API.

Атрибуты:

• android:minSdkVersion — минимальный уровень API, необходимый для работы приложения. Если значение не указать, то система будет думать, что ваше приложение поддерживает все уровни API. Поэтому этому атрибуту обязательно нужно задавать значение.
• android:targetSdkVersion — максимальный уровень API, под который приложение тестировалось. Этот атрибут помогает системе понять, можно ли использовать свежий функционал в приложении или оно может оказаться к нему не готовым. Помогает избежать ситуаций, когда после обновления версии API поменялись какие-либо ключевые значения от чего приложение может работать некорректно.
• android:maxSdkVersion — максимальный уровень API, который будет поддерживаться приложением. Если значение будет меньше, чем уровень API устройства, то система не позволит установить приложение. Если приложение было установлено, но позже устройство было обновлено до более высокого уровня API, чем указанный, то приложение перестанет отображаться, что фактически приравнивается к удалению приложения с устройства. Поэтому этот атрибут рекомендуется не указывать.

<uses-configuration>

Требуемая для приложения аппаратная и программная конфигурация устройства. Например, можно указать, что для работы приложения требуется физическая клавиатура. Таким образом можно избежать ситуаций, когда приложение будет установлено на устройство, где оно не сможет работать. Как правильно без этого элемента можно обойтись и его даже не рекомендуют использовать, потому что приложение должно стремится к универсальности и совместимости на большинстве устройствах, а некоторые ограничения можно указать с помощью других атрибутов (менее жестких в плане ограничения устройств).

Атрибуты:

• android:reqFiveWayNav — если true, то приложению требуется устройство ввода, поддерживающее навигацию вверх, вниз, влево, вправо, а также нажатие выделенного элемента. К таким устройствам относятся трекболы и D-pad. В принципе устарело.
• android:reqHardKeyboard — если true, то нужна аппаратная клавиатура.
• android:reqKeyboardType — позволяет задать тип клавиатуры. Варианты:
  • undefined — требование к наличию клавиатуры не определено.
  • nokeys — приложению не требуется клавиатура.
  • qwerty — требуется стандартная QWERTY-клавиатура.
  • twelvekey — требуется клавиатура, состоящая из цифр и знаков звёздочки (*) и решетки (#).
• android:reqNavigation — позволяет указать, какое навигационное устройство требуется приложению. Варианты:
  • undefined — требование к навигации не определено.
  • nonav — навигационное устройство не требуется.
  • dpad — требуется d-pad.
  • trackball — требуется трекбол.
  • wheel — требуется навигационное колесо (интересно, что это).
• android:reqTouchScreen — позволяет задать тип сенсорного экрана. Варианты:
  • undefined — требование не задано.
  • notouch — сенсорный экран не требуется.
  • stylus — требуется сенсорный экран, который управляется стилусом.
  • finger — требуется сенсорный экран, которым можно управлять пальцами.

<uses-feature>

Объявляет одну или несколько аппаратных или программных функций, требуемых для работы приложения.

Атрибуты:

• android:name — имя аппаратной или программной функции. Имена стандартные, чувствительны к регистру.
• android:required — если true, то приложение не может функционировать без функции, заданной атрибутом name элемента <uses-feature> .
• android:glEsVersion — версия OpenGL ES, требуемая для работы приложения.

<supports-screens>

Позволяет указать размеры экрана, которые поддерживаются приложением. Если размер экрана будет больше, чем поддерживается приложением, то включится режим совместимости, что не очень хорошо, так как этот режим может вызвать размытие интерфейса из-за неправильного масштабирования. Поэтому рекомендуется создавать свои макеты под каждый размер экрана. Кроме того, с помощью отдельного макета можно оптимизировать интерфейс, например, чтобы на экране отображалось два окна (двупанельный интерфейс). Как поддерживать разные размеры экранов описано документации здесь.

По умолчанию, для каждого атрибута установлено значение true, поэтому используйте этот элемент, чтобы указать какие экраны вы не поддерживаете.

Атрибуты:

• android:smallScreens
• android:normalScreens
• android:largeScreens
• android:xlargeScreens
• android:anyDensity

Данные атрибуты были добавлены в API 13 (Android 3.2):

• android:requiresSmallestWidthDp — позволяет указать минимальную ширину экрана (наименьшая сторона устройства), чтобы Google Play отфильтровывал неподходящие устройства.
• android:compatibleWidthLimitDp — позволяет указать максимальную наименьшую ширину экрана. Если же значение превысит заданное, то пользователю будет предложено включить режим совместимости.
• android:largestWidthLimitDp — позволяет указать максимальную наименьшую ширину экрана. Если же значение превысит заданное, то будет принудительно включен режим совместимости без возможности отключения.

<compatible-screens>

Позволяет задать все возможные размеры экранов, с которыми совместимо приложение. Данный элемент может быть указан в манифесте только один раз, зато внутри него можно добавлять тег <screen> с указанием поддерживаемого размера экрана.

Этот элемент носит исключительно информационный характер. С помощью него Google Play фильтрует устройства с неподдерживаемыми экранами.

Конфигурация экрана, которая не указана в этом элементе, считается неподдерживаемой приложением.

Для тех же целей проще использовать элемент <supports-screens>, так как в нем не нужно указывать конкретные размеры экранов, а достаточно выставить логическое значение для нужного атрибута.

<supports-gl-texture>

Определяет формат сжатия текстур GL. Элемент является информационным, т.е. необходим Google Play для фильтрации устройств, которые не поддерживают заданные параметры.

<application>

Обязательный элемент манифеста, который содержит информацию о всех компонентах приложения (activity, service, receiver, provider), а также атрибуты, которые могут влиять на эти компоненты. В манифесте может быть только один элемент <application>.

Дочерние элементы:

• <activity>
• <activity-alias>
• <meta-data>
• <service>
• <receiver>
• <provider>
• <uses-library>

Атрибуты:

• android:allowTaskReparenting — позволяет activity перемещаться из task’а, который ее запустил, в task переднего плана, с которым activity имеет общее taskAffinity-значение. Если атрибут задан в теге <application>, то оно применяется ко всем activity. Но можно задавать и для конкретной activity.
• android:allowBackup — позволяет указать будет ли выполняться резервное копирование приложения. По умолчанию true, если указать false, то приложение не будет обслуживаться сервисом Backup Manager — интерфейс, через который приложение запрашивает операции резервного копирования и восстановления.
• android:allowClearUserData — применимо только для системных приложений, для обычных приложений игнорируется. Позволяет приложению сбрасывать пользовательские данные.
• android:allowNativeHeapPointerTagging — вот, что я поняла, почитав про этот тег: он добавлен временно и позволяет отключить Pointer Tagging. Оставляю ссылку на документацию, может поможет.
• android:backupAgent — следует использовать, если приложение выполняет резервное копирование. Значением данного атрибута является подкласс класса BackupAgent, где указывается, что именно будет сохранено в облачном хранилище и восстановлено после реинсталляции приложения.
• android:backupInForeground — если значение true, то резервное копирование может производиться, когда приложение активно. Вообще система закрывает приложение, если идет резервное копирование, поэтому включение этого параметра может повлиять на работу приложения.
• android:banner — картинка, которая будет отображаться на главном экране Android TV. При использовании этого атрибута в элементе <application>, картинка применится ко всем компонентам приложения. Можно задать индивидуальную картинку для каждой <activity>. Актуально только при разработке приложения для Android TV. Подробнее.
• android:debuggable — раньше этот тег использовался для того, чтобы запускать приложение в режиме отладки на реальном устройстве. На данный момент, если приложение запускает на реальном устройстве в режиме отладки, этот тег вставляется автоматически со значением true и также автоматически удаляется после завершения. В любом случае, этот тег нужно удалять из релизной версии.
• android:description — краткое описание приложения, отображаемое пользователю.
• android:directBootAware — включает режим Direct Boot, при котором приложение получает ограниченный доступ к файлам сразу после запуска системы, но до того, как пользователь разблокирует устройство. Может использоваться такими приложениями, как будильники, мессенджеры. Подробнее в статье из блога Google или в документации.
• android:enabled — если false, то система не может создавать экземпляры компонентов приложения. Не знаю какой смысл добавлять этот атрибут в элемент <application>, но его можно использовать для отключения конкретного дочернего компонента, если он не поддерживается какой-либо версией Android. Пример.
• android:extractNativeLibs — если true (по умолчанию), то нативные библиотеки приложения будут храниться в сжатом виде в APK, а при установке извлекаться PackageManager’ом и помещаться в / data / app /. При этом размер APK будет меньше, так как библиотеки сжаты. Но приложение будет дольше устанавливаться и занимать больше места в установленном виде.
  Если false (по умолчание, если версия Gradle 3.6.0 и выше), то нативные библиотеки будут хранится в APK в несжатом виде. Размер APK увеличится, но и занимаемое после установки пространство уменьшится. Подробнее.
• android:fullBackupContent— значением атрибута является ссылка на xml файл, в котором содержатся правила для автоматического резервного копирования. Подробнее о том, как оформлять файл, можно почитать здесь. Этот атрибут не является обязательным, так как большинство файлов приложения и так включено в автоматическое резервное копирование. Здесь перечислены эти файлы.
• android:fullBackupOnly — данный атрибут используется, если в приложении реализован кастомный BackupAgent. В этом случае присваивается значение true — будет использовано автоматическое резервное копирование вместо key/value.
• android:gwpAsanMode — указывает следует ли использовать GWP-ASan — анализатор памяти, который позволяет находить и исправлять проблемы, вызванные небезопасной работой с памятью.
• android:hasCode — если приложение не содержит Java-кода, а полностью реализовано на основе программного интерфейса NDK API, то данного атрибуту необходимо установить значение false.
• android:hasFragileUserData — если true, то когда пользователь будет удалять приложение, ему будет предложено сохранить данные приложения.
• android:hardwareAccelerated — включает аппаратное ускорение для всего приложения. Если minSDK или targetSDK больше или равно 14, то значение по умолчанию true. Подробнее.
• android:icon — иконка для всего приложения. Если данный атрибут использовать внутри, например, activity, то у этой activity будет персональная иконка.
• android:isGame — является ли приложение игрой. Нужен системе для сортировки и группировки всех игр вместе.
• android:killAfterRestore — используется системными приложениями, пока не ясно с какой целью.
• android:largeHeap — используется, если приложению может понадобится расширение размера кучи.
• android:label — название приложения, отображаемое пользователю.
• android:logo — логотип приложения.
• android:manageSpaceActivity — когда мы просматриваем приложения через системные настройки, можно заметить, что у некоторых приложений (как правило системных) вместо кнопки “Очистить кэш” есть кнопка “Управление памятью” (или вроде того). При нажатии на эту кнопку открывается другое окно, в котором можно выбрать, какие именно данные удалить. Такую функцию можно добавить к любому приложению с помощью этого атрибута. Значением атрибута является имя подкласса activity, которую система должна запустить при нажатии на эту кнопку.
• android:name — имя подкласса Application. Зачем этот атрибут добавлять пока непонятно.
• android:networkSecurityConfig — задается имя xml-файла, который содержит конфигурацию сетевой безопасности.
• android:permission — имя разрешения, которое должно быть предоставлено для использования приложения. Применяется ко всем компонентам приложения.
• android:persistent — в документации неявно сформулировано, что данный атрибут могут использовать только системные приложения. Если приложение не является системным, то атрибут игнорируется. А предназначение атрибута следующее — позволяет запускать фоновую службу и предотвращать ее автоматическое уничтожение. Взято отсюда.
• android:process — позволяет указать процесс, в котором будет работать приложение. По умолчанию имя процесса соответствует имени пакета, заданного в теге <manifest>. Можно использовать для запуска компонентов двух приложений в одном процессе, но при условии, что оба приложения подписаны одним сертификатом. Если данному атрибуту было присвоено имя, которое начинается с двоеточия, то создается приватный процесс конкретно для этого приложения. Если же имя начинается с маленькой буквы, то создается глобальный процесс, который можно использовать совместно с другими приложениями.
• android:restoreAnyVersion — если true, то BackupManager будет пытаться восстановить данные приложения из облачного хранилища, даже если текущая версия приложения не совпадает с версией, которая выполняла резервное копирование, что в свою очередь может указывать на несовместимость данных.
• android:requestLegacyExternalStorage — атрибут добавлен относительно недавно в связи с тем, что в Android 10 приложениям запретили неограниченное обращение к файлам в хранилище и, если я правильно поняла, этот тег позволяет обойти эту защиту. Тем не менее решение временно, просто дали время для внесения изменений.
• android:requiredAccountType — можно задать тип учетной записи, которая требуется для работы приложения (например, com.google).
• resizeableActivity — поддерживает ли приложение многооконный режим. Можно задать для конкретной activity. Если target API 24 и выше, то значение по умолчанию = true.
• android:restrictedAccountType — позволяет указать, что ограниченным профилям разрешен доступ к основной учетной записи. Ограниченные профили были введены для совместной работы с одной учетной записи, но с некоторыми ограничениями (без доступа к почте, игровому магазину, календарю итд.).
• android:supportsRtl — если true и targetSdkVersion — 17 и выше, то приложение будет поддерживать макеты “справа налево”.
• android:taskAffinity — указывается имя task’а. Позволяет изменять поведение activity, например, чтобы в одном приложении activity работали в разных task’ах или activity разных приложений работал в одном. Данный атрибут будет работать при следующих обстоятельствах:
  • Intent, который запускает activity, содержит флаг FLAG_ACTIVITY_NEW_TASK.
  • У запускаемой activity установлен атрибут allowTaskReparenting = true. Атрибут означает, что activity может перемещаться между task’ом, который ее вызвал, и task’ом, который указан в taskAfinity — в зависимости от того, какой task сейчас активен.
• android:testOnly — с помощью этого атрибута, можно указать, что текущее приложение только для целей тестирования. Такое приложение можно установить только через adb (Android Debug Bridge) и его нельзя опубликовать в Google Play.
• android:theme — устанавливает тему для всего приложения (указывается ссылка на ресурс типа style.xml). Компоненты приложения могут переопределить этот атрибут и задать свои значения.
• android:uiOptions — позволяет разделить actionBar на 2 части, если в нем слишком много элементов. Например, при горизонтальной ориентации в actionBar’е места много, все элементы умещаются и он выглядит как обычно. Но при вертикальной он может разделиться на 2 части — верхнюю и нижнюю. В верхней части останется заголовок и иконка, а в нижнюю переместятся элементы меню. Можно указывать для конкретной activity.
• android:usesCleartextTraffic — данный атрибут позволяет обойти запрет на отправку запросов без шифрования (http вместо https).
• android:vmSafeMode — если true, то отключает ART AOT-компилятор.

<activity>

Объявляет activity. Каждая activity объявляется отдельным элементом <activity>. Если activity не будет добавлена в манифест, то система ее не увидит и не сможет запустить. Данный тег обязательно должен находится внутри элемента <application>.

Дочерние элементы:

• <intent-filter>
• <meta-data>
• <layout>

Атрибуты:

• android:allowEmbedded — указывает, что activity может быть запущена как вложенный дочерний элемент другой activity. Например, это может понадобится при внедрении в приложение Bubbles и при разработки для Android Wear.
• android:allowTaskReparenting — позволяет activity перемещаться из task’а, который ее запустил, в task переднего плана, с которым activity имеет общее taskAffinity-значение.
• android:alwaysRetainTaskState — если значение этого атрибута для корневой activity = true, то стек не будет чиститься и полностью восстановится даже после длительного времени. Атрибут есть смысл указывать только для корневой activity, так как для всех остальных заданное значение будет игнорироваться.
• android:autoRemoveFromRecents — если данный атрибут задать нескольким activity и если эти activity будут запущены пользователем, то они поместятся в один task, который будет находится на экране до тех пор, пока пользователь не закроет последнюю activity в этом task’е. При этом task сам завершит свою работу, так сказать самоликвидируется. Атрибут отменяет действие флага FLAG_ACTIVITY_RETAIN_IN_RECENTS.
• android:banner — картинка, которая будет отображаться на главном экране Android TV. При использовании этого атрибута в элементе <application>, картинка применится ко всем компонентам приложения. Можно задать индивидуальную картинку для каждой <activity>. Актуально только при разработке приложения для Android TV.
• android:clearTaskOnLaunch — если значение этого атрибута для корневой activity = true, то back stack будет чиститься моментально, как только пользователь покинет task. Полная противоположность alwaysRetainTaskState.
• android:colorMode — отображение activity в режиме широкой цветовой гаммы (для отображения более ярких цветов). Если устройство не поддерживает такой режим, то атрибут игнорируется.
• android:configChanges— в данном атрибуте можно перечислить, какие изменения в конфигурации activity будут игнорироваться, т.е. данные изменения в конфигурации не будут вести к пересозданию activity. Вместо этого activity вызовет метод onConfigurationChanged(). Использование данного атрибуты считается плохим тоном, так как изменения в конфигурации никак не обрабатываются. Данный атрибут можно спокойно использовать, если в приложении все ресурсы (макеты, картинки итд.) для всех ориентаций экрана одинаковы.
• android:directBootAware — включает режим Direct Boot, при котором конкретная activity получает ограниченный доступ к файлам сразу после запуска системы,но до того, как пользователь разблокирует устройство. Может использоваться такими приложениями, как будильники, мессенджеры. Подробнее в статье из блога Google или в документации.
• android:documentLaunchMode — позволяет указать каким образом новый экземпляр activity будет добавляться в task. Например, на экране обзора task’ов могут быть отображены несколько документов из одного приложения. Подробнее.
• android:enabled — если false, то система не может создавать экземпляр activity. Можно использовать для отключения activity, которая не поддерживается какой-либо версией Android (хотя конкретный пример использования сложно представить).
• android:excludeFromRecents — если true, а также если атрибут задан для корневой activity, то task не будет отображаться на обзорном экране последних запущенный приложений. Подробнее.
• android:exported — если true, то activity может быть запущена компонентами других приложений, если false — activity может быть запущена только компонентами одного и того же приложения, либо приложениями с одинаковыми идентификаторами пользователя. В любом случае для запуска activity нужно знать ее точное имя класса.
• android:finishOnTaskLaunch — атрибут похож на clearTaskOnLaunch, но в отличии от него из task’а будет удалена та activity, для которой значение этого атрибута = true. Т.е. activity будет частью task’а только для текущего сеанса и если пользователь свернет task, то activity будет из него удалена.
• android:hardwareAccelerated — включает аппаратное ускорение для текущей activity. Подробнее.
• android:icon — иконка для текущей activity.
• android:immersive — включает режим погружения, в котором приложение отображается на весь экран, скрывая системные панели и панель навигации. Для того, чтобы увидеть эти панели пользователю нужно свайпнуть от верхнего или нижнего края экрана к центру.
• android:label — заголовок activity, отображаемый пользователю. Если не задан, то используется заголовок, установленный в элементе <application>.
• android:launchMode — данный атрибут можно указать для каждой activity в манифесте. Имеет несколько значений:
  • standard — при запуске activity создается новый экземпляр в стеке. Activity может размещаться в стеке несколько раз.
  • singleTop — activity может располагаться в стеке несколько раз. Новая запись в стеке создается только в том случаи, если данная activity не расположена в вершине стека. Если она на данный момент является вершиной, то у нее сработает onNewIntent() метод, но она не будет пересоздана.
  • singleTask — создает новый task и устанавливает activity корневой для него, но только в случае, если экземпляра данной activity нет ни в одном другом task’е. Если activity уже расположена в каком либо task’е, то откроется именно тот экземпляр и вызовется метод onNewIntent(). Она в свое время становится главной, и все верхние экземпляры удаляются, если они есть. При этом, если activity была вытащена из task’а в бэкграунде, то мы переключимся на этот task и его стек. Только один экземпляр такой activity может существовать.
  • singleInstance — тоже что и singleTask, но для данной activity всегда будет создаваться отдельный task и она будет в ней корневой. Данный флаг указывает, что activity будет одним и единственным членом своего task’а.
• android:lockTaskMode — определяет, как система будет отображать activity в режиме блокировки задач (lock task mode). Подробнее о режиме здесь. Возможные значения:
  • normal — значение по умолчанию. Task’и могут быть добавлены только с помощью метода startLockTask().
  • never — этот режим доступен только для системных приложений, для всех остальных игнорируется. В этом режиме task’и не запускаются и пользователь не может их закрепить на обзорном экране.
  • if_whitelisted — если activity прошла авторизацию у Device Policy Controller, то применяется значение always, если не прошла — normal.
  • always — режим доступен только для системных приложений.
• android:maxRecents — указывается максимальное количество task’ов, в которых может быть запущена эта activity. Если значение было превышено, то система начнет удалять task’и. По умолчанию — 16, максимальное количество — 50 (25 на устройствах с низким объемом памяти). Значение не может быть нулевым.
• android:maxAspectRatio — максимальное соотношение сторон, которое поддерживает приложение. Получается путем деления длинной стороны на короткую. Атрибут игнорируется, если задан атрибут resizeableActivity = true, так как это означает, что activity поддерживает любой размер экрана.
• android:multiprocess — если true, то activity будет запускаться в новом процессе. На stackoverflow пишут, что надо забыть о существовании этого атрибута.
• android:name — полное имя класса, который реализует activity.
• android:noHistory — если true, то к остановленной activity нельзя вернуться, так как она удаляется из стека. Удобно использовать, если при запуске приложения нужно показать лого и больше к нему не возвращаться.
• android:parentActivityName — указывается имя класса activity, которая будет открыта, если пользователь нажмет на стрелку “UP”. Например, данному атрибуту задано значение MainActivity, а пользователь находится в SettingsActivity. В этом случае, если он нажмет на стрелку “UP”, будет открыта MainActivity.
• android:persistableMode — можно указать, в каком виде будет сохранена activity в task’е при перезагрузке устройства. Если корневая activity в task’е устанавливает данному атрибуту значение persistRootOnly, то сохраняется только корневая activity. Иначе будут сохранены все activity, которым в данном атрибуте задано значение persistAcrossReboots.
• android:permission — имя разрешения, которое должно быть предоставлено для запуска activity или для получения от activity какой-либо информации.
• android:process — позволяет указать процесс, в котором будет работать activity. По умолчанию имя процесса соответствует имени пакета, заданного в теге <manifest>. Но можно переопределить этот атрибут и распределить компоненты приложения по нескольким процессам.
• android:relinquishTaskIdentity — …
• resizeableActivity — может ли пользователь запустить данную activity в многооконном режиме. Если target API 24 и выше, то значение по умолчанию = true.
• android:screenOrientation — в какой ориентации будет отображаться activity на экране. Атрибут игнорируется, если приложение запущено в многооконном режиме. Все возможные значения здесь.
• android:showForAllUsers — отображается ли activity, если текущий пользователь отличается от пользователя, который ее запустил.
• android:stateNotNeeded — позволяет перезапустить activity без сохранения ее состояния. Т.е. при перезапуске не будет вызван метод onSaveInstanceState(), а в onCreate() будет передано значение NULL. Например, можно использовать для стартового экрана, чтобы избежать удаления из-за какого-либо сбоя.
• supportsPictureInPicture — поддерживает ли activity режим “картинка в картинке”. Это такой многооконный режим, в основном предназначенный для просмотра видео. Позволяет пользователю смотреть видео в маленьком окошке в углу экрана и одновременно переключаться и работать с другими приложениями.
• android:taskAffinity — устанавливается имя task’а. Используется для группировки activity, например, чтобы в одном приложении activity работали в разных task’ах или activity разных приложений работал в одном. Данный атрибут будет работать при следующих обстоятельствах:
  • Intent, который запускает activity, содержит флаг FLAG_ACTIVITY_NEW_TASK.
  • У запускаемой activity установлен атрибут allowTaskReparenting = true. Атрибут означает, что activity может перемещаться между task’ом, который ее вызвал, и task’ом, который указан в taskAfinity — в зависимости от того, какой task сейчас активен.
• android:theme — указывается ссылка на тему activity. Если данный атрибут не задан, то наследуется от одноименного атрибута в элементе <application>. Если и он не задан, то используется системная тема.
• android:uiOptions — позволяет разделить actionBar на 2 части, если в нем слишком много элементов. Например, при горизонтальной ориентации в actionBar’е места много, все элементы умещаются и он выглядит как обычно. Но при вертикальной он может разделиться на 2 части — верхнюю и нижнюю. В верхней части останется заголовок и иконка, а в нижнюю переместятся элементы меню.
• android:windowSoftInputMode — указывается, как activity взаимодействует с экранной клавиатурой. Например, можно уменьшить окно, чтобы клавиатура поместилась или просто сдвинуть содержимое окна, тем самым освободив место для клавиатуры. Можно указывать несколько значений, разделяя их вертикальной линией |. Со всеми значениями можно ознакомиться здесь.

<activity-alias>

Данный элемент задает activity псевдоним и в манифесте должен следовать сразу после этой activity. Данный тег обязательно должен находится внутри элемента <application>.

Когда мы разрабатываем приложение, то периодически можем менять названия классов, изменять activity, которая будет запускаться первой итд. И вроде ничего в этом страшного нет, но пользователя может смутить, например, исчезновения иконки приложения с главного экрана (потому что мы ранее изменили имя стартовой activity). Чтобы этого избежать используется данный элемент. Т.е. мы можем стартовой activity присвоить псевдоним и при запуске приложения система будет осуществлять поиск этой activity именно по псевдониму, а не по имени класса, который ее реализует. И если мы назначим стартовой другую activity, то пользователь уже не потеряет иконку на главном экране, так как псевдоним остался без изменений.

На эту тему есть интересная статья.

Дочерние элементы:

• <intent-filter>
• <meta-data>

Атрибуты:

• android:enabled=["true" | "false"] — если false, то система не может создавать экземпляр activity, для которой создан данный псевдоним.
• android:exported=["true" | "false"]— если true, то activity может быть запущена под псевдонимом компонентами других приложений, если false — activity может быть запущена под псевдоним только компонентами одного и того же приложения, либо приложениями с одинаковыми идентификаторами пользователя. При этом если у элемента <activity-alias> отсутствуют intent-фильтры, то значение по умолчанию = false (так как подразумевается, что псевдоним предназначен для использования внутри приложения), если intent-фильтры заданы, то значение по умолчанию = true.
• android:icon="drawable resource" — иконка, которая будет отображаться пользователю во время работы с activity, запущенной по данному псевдониму.
• android:label="string resource" — заголовок, который будет отображаться пользователю во время работы с activity, запущенной по данному псевдониму.
• android:name="string" — имя псевдонима. Имя указывается произвольное, должно быть уникальным, но не должно ссылаться на существующий класс.
• android:permission="string" — имя разрешения, которое должно быть предоставлено для запуска activity под данным псевдонимом или для получения от activity какой-либо информации.
• android:targetActivity="string" — полное имя класса, который реализует activity и должен быть запущен через данный псевдоним. Имя, указанное в данном атрибуте, должно соответствовать имени, указанному в атрибуте android:name элемента <activity>, за которым в манифесте следует псевдоним.

<meta-data>

Данный элемент позволяет записать какие-либо данные по типу “ключ-значение”. Доступ к этим данным можно получить из всего приложения (если объявлены в внутри тега <application>), либо можно передать необходимые для работы данные конкретной activity (объявляется внутри тега <activity>).

Количество элементов <meta-data> неограничено. Все их значения в итоге будут собраны в один объект Bundle, а получить эти значения можно с помощью PackageItemInfo.metaData.

Например, в приложении используются уникальные шрифты. Чтобы избежать задержек при запуске приложения, хотелось бы загружать их предварительно. Для этого создается файл в ресурсах, в котором перечисляются эти шрифты:

1
2
3
4
5
6
7
8
9

// preloaded-fonts.xml

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <array name="preloaded_fonts" translatable="false">
        <item>@font/lato</item>
        <item>@font/lato_bold</item>
    </array>
</resources>

После чего ссылка на этот файл указывается в мета-данных манифеста:

1
2
3

<meta-data
    android:name="preloaded_fonts"
    android:resource="@array/preloaded_fonts"/>

Может быть дочерним элементом для:

• <activity>
• <activity-alias>
• <application>
• <provider>
• <receiver>
• <service>

Атрибуты:

• android:name="string" — имя мета-данных. Должно быть уникальным, поэтому рекомендуется в качестве префикса использовать полное имя пакета, например, com.example.project.preloaded_fonts.
• android:resource="resource specification" — ссылка на xml-файл в ресурсах, где хранится значение элемента.
• android:value="string" — значение элементу можно присваивать напрямую с помощью данного атрибута. Возможные типы данных — String, Int, Boolean, Color (в виде #rgb, #argb, #rrggbb, #aarrggbb), Float.

<service>

С помощью данного элемента объявляется service как один из компонентов приложения. У service’ов нет визуального интерфейса, а используются они для выполнения каких-либо фоновых задач. Также как и activity, все service’ы должны быть объявлены в манифесте, иначе система их никогда не запустит.

Данный тег обязательно должен находится внутри элемента <application>.

Дочерние элементы:

• <intent-filter>
• <meta-data>

Атрибуты:

• android:description="string resource" — небольшое описание о предназначении service’а, которое отображается пользователю.
• android:directBootAware=["true" | "false"] — включает режим Direct Boot, при котором конкретный service получает ограниченный доступ к файлам сразу после запуска системы, но до того, как пользователь разблокирует устройство. Может использоваться такими приложениями, как будильники, мессенджеры. Подробнее в статье из блога Google или в документации.
• android:enabled=["true" | "false"] — если false, то система не может создавать экземпляр service’а. Можно использовать для отключения service’ов, которые не поддерживается какой-либо версией Android (хотя конкретный пример использования сложно представить).
• android:exported=["true" | "false"] — если true, то service может быть запущен компонентами других приложений, если false — service может быть запущен только компонентами одного и того же приложения, либо приложениями с одинаковыми идентификаторами пользователя.
• android:foregroundServiceType=["connectedDevice" | "dataSync" | "location" | "mediaPlayback" | "mediaProjection" | "phoneCall" ] — позволяет указать, что данный service является service’ом переднего плана определенного типа.
• android:icon="drawable resource" — иконка для текущего service’а.
• android:isolatedProcess=["true" | "false"] — если true, то service будет запускаться в специальном процессе, который изолирован от остальной системы. Связаться с таким service’ом можно через Service API.
• android:label="string resource" — название service’а, которое отображается пользователю.
• android:name="string"— полное имя класса, который реализует service.
• android:permission="string" — имя разрешения, которое должно быть предоставлено для запуска service’а или для привязки к нему.
• android:process="string" — позволяет указать процесс, в котором будет работать service. По умолчанию имя процесса соответствует имени пакета, заданного в теге <manifest>. Но можно переопределить этот атрибут и распределить компоненты приложения по нескольким процессам.

<receiver>

С помощью данного элемента объявляется BroadcastReceiver как один из компонентов приложения. BroadcastReceiver позволяет прослушивать сообщения и события из разных точек: из других приложений, из системы, из вашего приложения. Существует два способа создания BroadcastReceiver’а: указать его в манифесте, либо создавать динамически в коде и регистрировать с помощью метода Context.registerReceiver (). Т.е. необязательно все BroadcastReceiver’ы указывать в манифесте.

Данный тег обязательно должен находится внутри элемента <application>.

Дочерние элементы:

• <intent-filter>
• <meta-data>

Атрибуты:

• android:directBootAware=["true" | "false"] — включает режим Direct Boot, при котором конкретный receiver получает ограниченный доступ к файлам сразу после запуска системы, но до того, как пользователь разблокирует устройство. Может использоваться такими приложениями, как будильники, мессенджеры. Подробнее в статье из блога Google или в документации.
• android:enabled=["true" | "false"] — если false, то система не может создавать экземпляр receiver’а. Можно использовать для отключения receiver’ов, которые не поддерживается какой-либо версией Android (хотя конкретный пример использования сложно представить).
• android:exported=["true" | "false"] — если true, то receiver может получать сообщения от других приложений, если false — receiver может получать сообщения только от компонентов одного и того же приложения, либо приложениями с одинаковыми идентификаторами пользователя.
• android:icon="drawable resource" — иконка для текущего receiver’а.
• android:label="string resource" — название receiver’а, которое отображается пользователю.
• android:name="string" — полное имя класса, который реализует receiver.
• android:permission="string" — имя разрешения, которое должно быть предоставлено для отправки сообщения receiver’у.
• android:process="string" — позволяет указать процесс, в котором будет работать receiver. По умолчанию имя процесса соответствует имени пакета, заданного в теге <manifest>. Но можно переопределить этот атрибут и распределить компоненты приложения по нескольким процессам.

<provider>

С помощью данного элемента объявляется ContentProvider как один из компонентов приложения. ContentProvider нужен только в том случае, если вам необходимо обмениваться данными между несколькими приложениями. Например, данные контактов используются многими приложениями, потому хранятся в ContentProvider’е. Подробнее.

В манифесте необходимо указывать все ContentProvider’ы, реализуемые в приложении. Если в приложении используются ContentProvider’ы других приложений, то их объявлять не требуется.

Данный тег обязательно должен находится внутри элемента <application>.

Дочерние элементы:

• <meta-data>
• <grant-uri-permission>
• <path-permission>

Атрибуты:

• android:authorities="list" — путь, по которому будут обращаться приложения для доступа к базе данных. Должен быть уникальным, поэтому рекомендуется использовать полное имя пакета.
• android:directBootAware=["true" | "false"] — включает режим Direct Boot, при котором конкретный provider получает ограниченный доступ к файлам сразу после запуска системы, но до того, как пользователь разблокирует устройство. Может использоваться такими приложениями, как будильники, мессенджеры. Подробнее в статье из блога Google или в документации.
• android:enabled=["true" | "false"] — если false, то система не может создавать экземпляр provider’а. Можно использовать для отключения provider’ов, которые не поддерживается какой-либо версией Android (хотя конкретный пример использования сложно представить).
• android:exported=["true" | "false"] — если true, то provider может использоваться другими приложениями, если false — provider доступен для компонентов одного и того же приложения, приложениям с одинаковыми идентификаторами пользователя, либо приложениям, которым временно предоставлен доступ к provider’у через элемент android: grantUriPermissions. Если targetSdkVersion 16 и ниже, то значение по умолчанию true, если от 17 и выше — false.
• android:grantUriPermissions=["true" | "false"] — если true, то стороннему приложению может быть выдано временное разрешение на доступ ко всем данным provider’а. Если необходимо предоставить доступ к определенным данным, то задается значение false и добавляются элементы <grant-uri-permission>.
• android:icon="drawable resource" — иконка для текущего provider’а.
• android:initOrder="integer" — порядок запуска provider’а (относительно других provider’ов в одном и том же процессе). Если provider’ы связаны между собой (для работы одного требуется другой), то с помощью данного атрибута можно задать в какой последовательности они они будут запускаться. Причем наиболее высокие числа запускаются первыми.
• android:label="string resource" — название provider’а, которое отображается пользователю. Если не задано, то используется название, указанное в теге <application>.
• android:multiprocess=["true" | "false"] — если компоненты приложения работают в нескольких процессах, то с помощью данного атрибута можно указать будет ли создаваться отдельный экземпляр provider’а для каждого процесса. При этом значение true (будут создаваться) может повысить производительность, так как не надо будет тратить ресурсы на передачу информации между разными процессами, но в тоже время это увеличит объем памяти каждого процесса.
• android:name="string" — полное имя класса, который реализует provider.
• android:permission="string" — имя разрешения, которое должно быть предоставлено для чтения и записи данных provider’а. Атрибут будет игнорироваться, если заданы атрибуты readPermission, writePermission, и grantUriPermissionsон и он им противоречит. Удобно использовать для добавления единого разрешения для чтения и записи данных provider’а.
• android:process="string" — позволяет указать процесс, в котором будет работать provider. По умолчанию имя процесса соответствует имени пакета, заданного в теге <manifest>. Но можно переопределить этот атрибут и распределить компоненты приложения по нескольким процессам.
• android:readPermission="string" — имя разрешения, которое должно быть предоставлено для чтения данных provider’а.
• android:syncable=["true" | "false"] — если true, то данные provider’а будут синхронизироваться с данными, хранящимися на сервере.
• android:writePermission="string" — имя разрешения, которое должно быть предоставлено для записи данных в provider.

<uses-library>

Данный элемент используется в случае, когда для работы приложения необходима библиотека, являющаяся частью прошивки устройства. Например, Goggle Карты.

Также Google Play использует этот тег для фильтра устройств, которые не соответствуют требованиям библиотеки или у которых не установлена эта библиотека.

Данный тег обязательно должен находится внутри элемента <application>.

Атрибуты:

• android:name="string" — название библиотеки, берется из документации к библиотеке.
• android:required=["true" | "false"] — если true, то приложение не может работать без указанной библиотеки и система не даст его установить на устройство, где такая библиотека отсутствует.

<intent-filter>

С помощью данного элемента можно указать типы intent’ов, на которые могут реагировать компоненты приложения (activity, service, receiver). Подробнее.

Может быть дочерним элементом для:

• <activity>
• <activity-alias>
• <service>
• <receiver>

Дочерние элементы:

• <action> — данный элемент является обязательным.
• <category>
• <data>

Атрибуты:

• android:icon="drawable resource" — данная иконка отображается, когда пользователю предоставляются на выбор все компоненты (в том числе текущий), которые могут выполнить заданное действие.
• android:label="string resource" — данный заголовок отображается, когда пользователю предоставляются на выбор все компоненты (в том числе текущий), которые могут выполнить заданное действие.
• android:priority="integer" — задается приоритет фильтра. При выборе компонентов для обработки intent‘а будет отдаваться предпочтение тем, у которых в данном атрибуте задано более высокое число.
• android:order — порядок, в котором фильтр должен обрабатываться, если он совпал с каким-то другим фильтром в рамках одного приложения. Добавлен в API 28.

<action>

С помощью данного элемента для тега <intent-filter> задается действие, которое могут обработать компоненты приложения. <intent-filter> может содержать одно или несколько действий. Если данный элемент будет отсутствовать, то фильтр не станет принимать объекты Intent.

Атрибуты:

• android:name="string" — имя действия. Стандартные действия определены в классе Intent в качестве констант. Можно создать свои действия. В этом случае для имени рекомендуется использовать полное имя пакета, чтобы обеспечить уникальность.

<category>

Используется исключительно как дочерний элемент тега <intent-filter> и позволяет задать ему категорию.

Атрибуты:

• android:name="string" — имя категории. Стандартные категории определены в классе Intent в качестве констант. Можно создать свои категории. В этом случае для имени рекомендуется использовать полное имя пакета, чтобы обеспечить уникальность.

<data>

Используется исключительно как дочерний элемент тега <intent-filter>. Объявляет тип принимаемых данных, для чего используется один или несколько атрибутов, указывающих различные составные части URI данных (scheme, host, port, path итд.) и тип MIME.

Атрибуты:

• android:scheme="string"
• android:host="string"
• android:port="string"
• android:path="string"
• android:pathPattern="string"
• android:pathPrefix="string"
• android:mimeType="string"

<grant-uri-permission>

Используется исключительно как дочерний элемент тега <provider>.

Позволяет предоставить стороннему приложению временный доступ к данным provider’а. Количество элементов не ограничено, но каждый из них должен содержать только один путь к данным.

Атрибуты:

• android:path="string" — полный путь к данным, для которых выдается разрешение.
• android:pathPattern="string" — полный путь к данным, для которых выдается разрешение. Может содержать подстановочные знаки.
• android:pathPrefix="string" — путь к определенному пакету. Для всех данных в данном пакете будет выдано разрешение.

<path-permission>

Используется исключительно как дочерний элемент тега <provider>.

Позволяет указать путь к подмножеству данных provider’а и необходимые разрешения для этих данных. Может быть указан несколько раз.

Атрибуты:

• android:path="string" — полный путь к подмножеству данных. Разрешение будет предоставлено только указанному подмножеству.
• android:pathPrefix="string" — путь к определенному пакету, в котором могут находится подмножества данных. Разрешение будет предоставлено всем подмножествам в пакете.
• android:pathPattern="string" — с помощью данного атрибута указывается полный путь к подмножеству, который может содержать подстановочные знаки.
• android:permission="string" — имя разрешения, которое должно быть предоставлено для чтения или записи данных provider’а. Удобно использовать, если для чтения и записи требуется одинаковое разрешение.
• android:readPermission="string" — имя разрешения, которое должно быть предоставлено для чтения данных provider’а.
• android:writePermission="string" — имя разрешения, которое должно быть предоставлено для записи данных provider’а.

Полезные ссылки

Официальная документация

1. Введение.
2. Соглашения об обозначениях
3. Синтаксис файлов манифеста Joomla
   1. Корневой элемент
   2. Метаданные
   3. Файлы пользовательской части сайта на CMS Joomla
   4. Медиафайлы
   5. Админка Joomla
      1. Файлы админки CMS Joomla
      2. Ссылки меню и подменю
   6. Информационные панели
   7. Конфигурация
   8. Пространство имен
   9. SQL
      1. Обновление схемы SQL
   10. Языковые файлы
   11. Файл сценария
   12. Манифесты библиотек
   13. Серверы обновлений
   14. Поддержка ключей загрузки
4. Примеры файлов манифеста Joomla

Введение

В Joomla есть файлы манифестов для всех расширений. Эти файлы содержат общую информацию об установке, а также параметры конфигурации самого расширения. Начиная с Joomla 2.5, существует очень мало различий между форматами файлов манифеста для различных типов расширений, что позволяет каждому типу получить доступ к полной мощности установщика Joomla.

Соглашения об обозначениях.

Файл манифеста должен иметь имя manifest.xml или <extension_name>.xml и находиться в корневом каталоге установочного пакета.

Корневой элемент.

Основная информация
Новый тег <extension> заменяет старый <install></install> из Joomla 1.5

Основным тегом установочного файла является:

<extension></extension>

Этот открывающий и закрывающий тег. Он одинаков для всех расширений. В теге разрешены следующие атрибуты:

Метаданные.

Для вставки метаданных можно использовать перечисленные ниже элементы. Ни один из этих элементов не является обязательным; если они присутствуют, они должны быть дочерними по отношению к корневому элементу.

Примечание: Теги <name> и <description> могут содержать языковые константы, так что имя и описание расширения могут быть показаны пользователю на его родном языке.

Файлы пользовательской части сайта на CMS Joomla.

	<files folder="from-folder">
		<filename>example.php</filename>
		<folder>examples</folder>
	</files>

Файлы для копирования во внешний каталог следует размещать в элементе <files>. Вы можете использовать дополнительный атрибут folder, чтобы указать каталог в ZIP-пакете для копирования. Каждый копируемый файл должен быть представлен элементом <filename>. Если вы хотите скопировать всю папку сразу, вы можете определить ее как <folder> без перечисления всех вложенных в неё файлов. Тогда папка будет скопирована целиком.

Важно знать, что пустые папки в установочном пакете вызывают ошибку. Для избежания этого, вкладывайте в папки файл index.html, даже без кода в нём.

Для плагинов необработанное имя плагина должно быть помещено в атрибут plugin элемента <filename>, который указывает на файл, содержащий класс плагина. Например, в случае системного плагина под названием «example» (полное имя plg_system_example) используйте <filename plugin="example">example.php</filename>.

Медиафайлы.

	<media folder="media" destination="com_example">
		<filename>com_example_logo.png</filename>
		<folder>css</folder>
		<folder>js</folder>
	</media>

В этом примере будут скопированы файлы (файлы) (/media/com_example_logo.png) и папки (/media/css/ и /media/js/), перечисленные в /media/com_example/, при необходимости создав папку com_example. Вы можете использовать необязательный атрибут folder, чтобы указать каталог в ZIP-пакете для копирования (в данном случае media).

Расширения должны хранить ресурсы, которые должны быть доступны в Интернете (JS, CSS, изображения и т.д.) в media. Среди прочего, эта фича была добавлена в качестве шага в продвижении к поддержке нескольких сайтов и возможному перемещению файлов кода (PHP) из доступных в Интернете областей сервера.

Примечание: раздел media не анализируется для расширений типа «package».

Ссылки по теме:

• Google Groups — joomla-dev-cms thread
• Google Groups — joomla-dev-cms thread

Админка Joomla.

	<administration>
		<!-- различные элементы -->
	</administration>

Раздел админки определен в элементе <administration>. Поскольку только компоненты применяются как к сайту, так и к админке, только манифесты компонентов могут включать этот элемент.

Файлы админки CMS Joomla.

Файлы для копирования во внутренний каталог админки следует размещать в элементе <files> в разделе <administration>. Вы можете использовать дополнительный атрибут folder, чтобы указать каталог в ZIP-пакете для копирования. Дополнительные правила см. в файлах сайта.

Ссылки меню и подменю.

Примечание к версии: До Joomla 3.4 отсутствие тега <menu> в XML-файле манифеста по-прежнему приводило к созданию пункта меню. Эта ошибка была исправлена в Joomla 3.4, поэтому, если в вашем файле манифеста нет тега <menu>, то для компонента не создается пункт меню администратора.

	<menu>COM_EXAMPLE</menu>
	<submenu>
		<!--
			Обратите внимание, что все & должны быть экранированы в &amp;, чтобы файл
			был действительным XML и был проанализирован установщиком
		-->
		<menu link="anoption=avalue&amp;anoption1=avalue1">COM_EXAMPLE_SUBMENU_ANOPTION</menu>
		<menu view="viewname">COM_EXAMPLE_SUBMENU_VIEWNAME</menu>
	</submenu>

Текст для пункта главного меню компонента определяется в пункте <menu>, дочернем элементе <administration>. Также может присутствовать элемент <submenu> (также дочерний элемент <administration>), который может содержать больше пунктов меню, определенных <menu>.

Кроме того, каждый пункт <menu> может определять следующие атрибуты:

Значение внутри тега — это метка меню. В отличие от Joomla 1.5, вы не можете использовать строку на естественном языке. Например, если вы введете «Example Component» вместо COM_EXAMPLE, это приведет к тому, что имя вашего компонента появится в меню как example-component, и вы не сможете предоставить перевод. Чтобы предоставить перевод, вам необходимо создать файл с именем en-GB.com_example.sys.ini в папке administrator/languages/en-GB (вы можете использовать тег манифеста <languages>, чтобы скопировать его во время установки) или в папке administrator/components/com_example/language/en-GB. В последнем случае вы не должны включать файл перевода в тег <languages>. Если вы разместили языковой каталог в теге <files>, он будет скопирован вместе с компонентом при установке.

Содержимое этого файла должно быть:

COM_EXAMPLE="Example Component"
COM_EXAMPLE_SUBMENU_ANOPTION="Another Option"
COM_EXAMPLE_SUBMENU_VIEWNAME="Another View"

Пожалуйста, обратите внимание, что значения языковых констант должны быть заключены в двойные кавычки в соответствии со стандартами перевода Joomla.

Joomla 1.6 и более поздних версий сортирует пункты меню компонентов на основе фактического перевода ключа, который вы указываете в своем XML-манифесте. Это означает, что порядок сортировки является правильным независимо от того, как вы называете свой ключ перевода и на каком языке отображается сайт. По сути, в Joomla 1.6 исправлена неправильная сортировка меню компонентов в Joomla 1.5 для большинства (не говорящих по-английски и не желающих знать этот странный язык!) пользователей Joomla.

Информационные панели (Dashboards).

Важная информация
Этот код работает только в Joomla 4.0 и более поздних версиях

Указывает сведения для отображения информационной панели для компонента в админке Joomla 4.x.

• Это приведет к появлению иконки информационной панели рядом с пунктом меню администратора для компонента.
• Иконка информационной панели при клике на ней, отобразит модули, назначенные для позиции cpanel-example  модуля админки.
• Заголовок и иконка, определенные в XML-файле, будут использоваться в качестве заголовка и иконки в верхней части страницы информационной панели компонента.

	<dashboards>
		<dashboard title="COM_EXAMPLE_DASHBOARD_TITLE" icon="icon-lock">example</dashboard>
	</dashboards>

Конфигурация.

Ахтунг!
Компоненты не поддерживают определения конфигурации в манифесте. Это был способ, реализованный в Joomla 1.5. Они могут определять параметры конфигурации для нескольких уровней с помощью файла config.xml. О том, как добавить это в свой компонент, читайте в Руководстве по разработке компонента MVC.

Элемент <config>, дочерний элемент корневого, описывает параметры конфигурации для расширения. Если применимо, параметры будут показаны соответствующим Менеджером (Менеджером плагинов, Менеджером модулей или Менеджером шаблонов). Параметры конфигурации компонентов определяются в отдельном файле с именем config.xml. Его корневым элементом должен быть <config>, плагины и модули используют раздел <config> в файле манифеста расширения.

Каждый набор полей должен содержать один или несколько элементов <field>, каждый из которых представляет одно поле формы с меткой. Список разрешенных типов полей формы и примеры определений полей XML-формы см. в разделе Стандартные типы полей формы.

Пространство имен.

Важная информация
Этот код работает только в Joomla 4.0 и более поздних версиях

Укажите пространство имен, которое будет использоваться для автоматической загрузки плагина. Данное пространство имен будет автоматически загружаться в корневой каталог вашего расширения по умолчанию, однако вы можете дополнительно добавить атрибут path к элементу пространства имен, чтобы указать подпуть в корневом каталоге ваших расширений.

SQL

    <install>
        <sql>
            <file driver="mysql" charset="utf8">sql/example.install.sql</file>
        </sql>
    </install>
    <uninstall>
        <sql>
            <file driver="mysql" charset="utf8">sql/example.uninstall.sql</file>
        </sql>
    </uninstall>

В приведенном выше примере мы помещаем файлы SQL в папку admin/sql установочного пакета. Вы должны включить папку sql в файлы администрирования (как описано в разделе Файлы админки CMS Joomla).

Вы можете выполнить SQL во время установки и/или удаления, используя элементы <install> и <uninstall> соответственно. Элемент <sql> должен отображаться как дочерний элемент этих элементов. <sql> может содержать любое количество элементов <file>, каждый из которых определяет файл SQL для выполнения. Типы драйверов их баз данных описываются атрибутом driver, их наборы символов — атрибутом charset.

Обновление схемы SQL

Начиная с версии Joomla 1.6, также существует тег <update>, который позволяет вам предоставить серию файлов SQL для обновления текущей схемы.

	<update>
		<schemas>
			<schemapath type="mysql">sql/updates/mysql</schemapath>
			<schemapath type="sqlsrv">sql/updates/sqlsrv</schemapath>
		</schemas>
	</update>

Например, чтобы перейти от версии 1.0.0 к версии 1.0.1 в базе данных MySQL, файл 1.0.1.sql должен быть создан в папке sql/updates/mysql, а тег <version> манифеста должен быть обновлен до

<version>1.0.1</version>

Окончательная структура папки sql будет выглядеть следующим образом (при условии наличия базы данных MySQL)

sql
 |-->example.install.sql
 |-->example.uninstall.sql
 |-->updates
     |-->mysql
        |-->1.0.1.sql

Аналогичные файлы должны быть созданы для последующих версий.

Языковые файлы.

Начиная с Joomla 1.5, разработчики расширений должны были помещать языковые файлы расширений в основную языковую папку Joomla, используя тег <languages>...</languages>, как показано ниже. Этот метод по-прежнему можно использовать во всех версиях Joomla.

<!-- Joomla! language tag -->
<languages folder="langfiles">
	<language tag="en-GB">en-GB.com_example.ini</language>
</languages>

Однако, начиная с Joomla 1.6, рекомендуется размещать языковые файлы вашего расширения в папке расширения. Затем Joomla автоматически загрузит языковые файлы вашего расширения.

Сохраняя языковые файлы расширения в папке расширения, вы получаете выгоду от изоляции и защиты языковых файлов вашего расширения. Например, администратор удаляет язык из своей установки Joomla. Языковые файлы вашего расширения не будут удалены. Они останутся на месте и будут доступны, если язык будет установлен снова.

Структура папки с файлами языковых констант для сайта и для анминки одинакова. Вы помещаете их в языковой тег (например, en-GB) каждого языка в своей языковой папке, т.е. language/en-GB/. Вы также должны указать эти папки как для сайта, так и для админки.

В своем манифесте просто включите папку language в раздел files. Подкаталоги для каждого языка будут автоматически скопированы. Внутри группы <files> добавьте элемент <folder> рядом с элементами в группе <files>, как показано в этом примере:

<files>
	<filename plugin="alpha">alpha.php</filename>
	<folder>sql</folder>
	<folder>language</folder>
</files>

Обратите внимание, что оба способа могут работать вместе. Вот пример из кода ядра Joomla:

<files>
	<filename plugin="languagecode">languagecode.php</filename>
	<filename>index.html</filename>
	<folder>language</folder>
</files>
<languages>
	<language tag="en-GB">language/en-GB/en-GB.plg_system_languagecode.ini</language>
	<language tag="en-GB">language/en-GB/en-GB.plg_system_languagecode.sys.ini</language>
</languages>

Преимущества этого решения заключаются в следующем:

Все файлы .ini, присутствующие в основной папке, имеют приоритет над файлами в папке language/ расширения. Например, файл .sys.ini всегда будет загружаться из основных папок в админке, если он существует, за исключением случаев установки расширения, содержащего файл .sys.ini в языковой папке. В этом случае и только в этом случае файл .sys.ini в папке расширения будет отображать переведенное содержимое во время установки. Это очень удобно. Так как разработчик может иметь два файла .sys.ini с разным содержимым.

Кроме того, пользователю, которому требуется файл .ini для расширения, которое не предоставляет его на нужном языке, намного проще добавить его в основные папки. Нет никакого риска, что он будет удален в случае удаления расширения по ошибке или по любой другой причине.

Смотрите также:

• Making non-core language packs
• Creating language packs for extensions in Joomla 2.5

Во время разработки вы можете включить отладку языка в глобальной конфигурации Joomla. Вы можете исследовать, если возникнет проблема. Начиная с версии 3.2, это необходимо для облегчения отладки, так как en-GB всегда загружается первым, когда он не находится в режиме отладки, чтобы предотвратить отображение констант.

Файл сценария.

    <scriptfile>example.script.php</scriptfile>

Дополнительный файл сценария (PHP-код, который запускается до, во время и/или после установки, удаления и обновления) может быть определен с помощью элемента <scriptfile>.

Этот файл должен содержать класс с именем <element_name>InstallerScript, где <element_name> — это имя вашего расширения (например, com_componentname, mod_modulename и т.д.). Плагины должны указывать группу (например, plgsystempluginname).

В Joomla 4.0 и более поздних версиях структура класса выглядит следующим образом:

<?php

use JoomlaCMSInstallerInstallerAdapter;

class com_componentnameInstallerScript
{
	/**
	 * Constructor
	 *
	 * @param   InstallerAdapter  $adapter  Объект, ответственный за выполнение этого сценария
	 */
	public function __construct(InstallerAdapter $adapter)
	{
	}
	
	/**
	 * Вызывается перед любым действием
	 *
	 * @param   string  $route  Какое действие происходит (install|uninstall|discover_install|update)
	 * @param   InstallerAdapter  $adapter  Объект, ответственный за выполнение этого сценария
	 *
	 * @return  boolean  True on success
	 */
	public function preflight($route, InstallerAdapter $adapter)
	{
		return true;
	}
	
	/**
	 * Вызывается после любого действия
	 *
	 * @param   string  $route  Какое действие происходит (install|uninstall|discover_install|update)
	 * @param   InstallerAdapter  $adapter  Объект, ответственный за выполнение этого сценария
	 *
	 * @return  boolean  True on success
	 */
	public function postflight($route, $adapter)
	{
		return true;
	}
	
	/**
	 * Вызывается при установке
	 *
	 * @param   InstallerAdapter  $adapter  Объект, ответственный за выполнение этого сценария
	 *
	 * @return  boolean  True on success
	 */
	public function install(InstallerAdapter $adapter)
	{
		return true;
	}
	
	/**
	 * Вызывается при обновлении
	 *
	 * @param   InstallerAdapter  $adapter  Объект, ответственный за выполнение этого сценария
	 *
	 * @return  boolean  True on success
	 */
	public function update(InstallerAdapter $adapter)
	{
		return true;
	}
	
	/**
	 * Вызывается при удалении
	 *
	 * @param   InstallerAdapter  $adapter  Объект, ответственный за выполнение этого сценария
	 */
	public function uninstall(InstallerAdapter $adapter)
	{
		return true;
	}
}

?>

Обратите внимание, что начиная с Joomla 3.6 поставлется базовый скрипт, который вы можете использовать вместо того, чтобы отправлять свой собственный с нуля JInstallerScript, который содержит различные вспомогательные методы, обычно используемые сообществом.

Манифесты библиотек.

Важная информация
Раздел относится к Joomla 4.0 и более поздних версий.

Простой манифест библиотеки может выглядеть следующим образом:

<?xml version="1.0" encoding="utf-8"?>
<extension type="library" method="upgrade" version="4.0">
    <name>My Test library.</name>
    <libraryname>mytest</libraryname>
    <files>
        <folder>Classes</folder>
        <folder>language</folder>
        <filename>mytest.php</filename>
    </files>
</extension>

Это приведет к установке библиотеки в папку JPATH_SITE/libraries/mytest.

Что делать, если в вас есть несколько библиотек, и вы хотите сгруппировать их вместе в папке JPATH_SITE/libraries/mycompany?

Просто — укажите название вашей компании в свойстве libraryname каждой библиотеки, например так:

    <libraryname>mycompany/mylibrary1</libraryname>

    <libraryname>mycompany/mylibrary2</libraryname>

Затем эти библиотеки будут установлены в папках JPATH_SITE/libraries/mycompany/mylibrary1 и JPATH_SITE/libraries/mycompany/mylibrary2.

При удалении mylibrary1, mylibrary2 все равно останется установленной на вашем сайте.

При использовании script files с такими индивидуальными библиотеками имя класса установщика должно выглядеть следующим образом:

class mycompanymylibrary1InstallerScript

class mycompanymylibrary2InstallerScript

Серверы обновлений.

    <updateservers>
        <server type="extension" priority="1" name="Extension Update Site">http://example.com/extension.xml</server>
        <server type="collection" priority="2" name="Collection Update Site">http://example.com/collection.xml</server>
    </updateservers>

Серверы обновлений могут быть определены в элементе <updateservers>, дочернем по отношению к корневому элементу. Этот элемент может содержать один или несколько элементов <server>, каждый из которых описывает расположение, из которого загружаются обновления. Каждый элемент <server> может определять следующие атрибуты:

Дополнительная информация:

• Building a Joomla! Extension — Adding an update server
• Managing Component Updates in Joomla 2.5

Поддержка ключей загрузки.

Начиная с версии Joomla 4.0.0 пользователи могут вводить свои ключи загрузки в список сайтов обновления. Это дает им единое место для управления ключами загрузки. Когда пользователь собирается обновить расширение, Joomla проверит, есть ли ключ загрузки. Если есть ключ загрузки, Joomla добавит ключ загрузки в URL-адрес обновления.

Для поддержки ключей загрузки необходимо включить тег dlid в файл манифеста. Тег dlid принимает 2 аргумента:

• prefix
• suffix

Тег dlid будет выглядеть так в вашем файле манифеста:

<dlid prefix="dlid=" suffix="&amp;dummy=my.zip"/>

Префикс prefix будет добавлен перед ключом загрузки, а суффикс suffix — после ключа загрузки. Используя приведенный выше пример, полный запрос, добавленный в ссылку для загрузки, будет:

dlid=KEY&dummy=my.zip

Ключ добавляется до запуска установщика onInstallerBeforePackageDownload, поэтому полный URL-адрес будет передан событию.

Пример из реальной жизни см. в манифесте компонента Баннера в последней версии Joomla 3.9.16.

Еще несколько примеров можно найти в репозитории автономных веб-ссылок:

• com_weblinks manifest
• mod_weblinks manifest
• plg_search_weblinks manifest
• tpl_protostar manifest (3.9.16)
• en-GB manifest (3.9.16)

Перевод с английского официальной документации Joomla:
https://docs.joomla.org/Manifest_files
от 5 ноября 2021, 12:32

Заберите ссылку на статью к себе, чтобы потом легко её найти!
Выберите, то, чем пользуетесь чаще всего:

После того как мы определились с дизайном будущего шаблона и создали необходимые для его функционирования файлы (об этом мы говорили в предыдущей статье) самое время приступить к наполнению специального установочного файла templateDetails.xml, который так же называют «манифест-файл». Данный файл просто необходим для любого устанавливаемого расширения Joomla 3, а не только нашего шаблона.

Создание любого шаблона Joomla 3 начинается помимо прочего именно с создания и наполнения данного файла. Итак, открываем наш не так давно созданный файл templateDetails.xml и приступаем к его наполнению. В самом начале файла необходимо добавить блок кода, который будет содержать информацию о нашем шаблоне – дату создания, версию, имя и электронный адрес автора, информацию о лицензии и авторских правах, а так же описание создаваемого шаблона.

Информационный блок кода установочного xml файла

Данный информационный блок может выглядеть следующим образом:

<?xml version="1.0" encoding="utf-8"?>
<extension version="3.8" type="template" client="site">
 <name>Joom4all</name>
 <creationDate>Октябрь 2017</creationDate>
 <author>Joom4all.ru</author>
 <authorEmail>Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.</authorEmail>
 <authorUrl>http://joom4all.ru</authorUrl>
 <copyright>Некая информация об авторских правах (С)</copyright>
 <license>Лицензионная информация, по которой будет распространяться данный шаблон</license>
 <version>1.0.0</version>
<description>Самостоятельно созданный шаблон для сайта Joom4all.ru</description>

Думаю, суть информационного блока вполне понятна – в первой строке мы указываем версию xml и кодировку, следующие теги давайте разберем подробнее:

• extension – в данном теге указываем версию Joomla, для которой предназначено данное расширение, в моем случае это версия 3.8. Далее указываем, что данное расширение у нас будет шаблоном (type=»template») и не просто шаблоном, а шаблоном для сайта (client=»site»). Если шаблон планируется для панели управления, то указывается это следующим образом — client=»administrator»;
• name – имя нашего шаблона;
• creationDate – дата создания, можно писать в различных форматах (например, 13.10.2017 или Октябрь 2017);
• author – название данного тега говорит само за себя, в нем мы указываем имя автора;
• authorEmail – адрес электронной почты автора шаблона;
• authorUrl – адрес сайта разработчика или разработчиков шаблона;
• copyright – информация по авторским правам;
• license – некая информация о лицензии, по которой будет распространяться шаблон;
• version – версия расширения, в нашем случае версия шаблона;
• description – краткое описание создаваемого шаблона.

Для наглядности посмотрите на скриншот кода в установочном xml файле:

С данным блоком информационного характера разобрались, как видите, ничего сложного нет. Теперь необходимо указать установщику, какие файлы и папки используются в нашем шаблоне.

Блок файлов и папок

Тут сложностей так же нет, каждый файл обозначаем тегами filename, а каждую папку тегами folder, и все это дело оборачиваем тегом files. Выглядит все это дело следующим образом:

<files>
 <filename>index.php</filename>
 <filename>templateDetails.xml</filename>
 <filename>template_preview.png</filename>
 <filename>template_thumbnail.png</filename>
 <filename>favicon.ico</filename>
 <folder>css</folder>
 <folder>html</folder>
 <folder>images</folder>
 <folder>js</folder>
 <folder>fonts</folder>
 <folder>language</folder>
</files>

И скриншот:

Таким образом, мы перечислили все файлы, которые присутствуют в шаблоне и подлежат копированию на сервер. Однако Вы можете заметить, что мы не указывали никакие вложенные файлы, которые могут присутствовать в папках css, language и так далее. Все правильно, тут нет никакой ошибки, все вложенные файлы и папки будут скопированы автоматически, а нам надо лишь указать все то, что находится в корневом каталоге.

Информация о позициях для модулей

Осталось указать только информацию о позициях модулей, которые будут присутствовать в нашем шаблоне. Количество доступных позиций можете создавать по своему усмотрению, для начала я создам 6 позиций, в дальнейшем их количество всегда можно будет увеличить или сократить. Добавляем в наш файл, следующий код:

<positions>
 <position>position-0</position>
 <position>position-1</position>
 <position>position-2</position>
 <position>position-3</position>
 <position>position-4</position>
 <position>position-5</position>
</positions>

Синтаксис таков – все доступные позиции модулей заключены в блок positions, а каждая отдельная позиция находится в теге position. Вместо имени позиции, например «position-0» можно написать что угодно. Но я рекомендую оставить, так как есть, в дальнейшем, когда мы будем говорить о локализации шаблона, мы создадим для каждого имени свой перевод.

Завершается установочный файл templateDetails.xml закрывающимся тегом </extension>. В итоге общий код нашего установочного файла будет выглядеть следующим образом:

<?xml version="1.0" encoding="utf-8"?>
<extension version="3.8" type="template" client="site">
 <name>Joom4all</name>
 <creationDate>Октябрь 2017</creationDate>
 <author>Joom4all.ru</author>
 <authorEmail>Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.</authorEmail>
 <authorUrl>http://joom4all.ru</authorUrl>
 <copyright>Некая информация об авторских правах (С)</copyright>
 <license>Лицензионная информация, по которой будет распространяться данный шаблон</license>
 <version>1.0.0</version>
 <description>Самостоятельно созданный шаблон для сайта Joom4all.ru</description>
 <files>
  <filename>index.php</filename>
  <filename>templateDetails.xml</filename>
  <filename>template_preview.png</filename>
  <filename>template_thumbnail.png</filename>
  <filename>favicon.ico</filename>
  <folder>css</folder>
  <folder>html</folder>
  <folder>images</folder>
  <folder>js</folder>
  <folder>fonts</folder>
  <folder>language</folder>
 </files>
 <positions>
  <position>position-0</position>
  <position>position-1</position>
  <position>position-2</position>
  <position>position-3</position>
  <position>position-4</position>
  <position>position-5</position>
 </positions>
</extension>

На этом редактирование данного файла можно завершить, скажу сразу, что это только основная часть того что может содержать данный файл. В дальнейшем мы его будем дополнять, и усовершенствовать, а самое интересное то, что это все можно будет делать уже после установки шаблона.

Теперь можно приступить к установке нашего шаблона. Для этого необходимо заархивировать все файлы и папки шаблона в zip архив. И установить его стандартным способом через панель управления. После установки мы получим стандартное сообщение, что шаблон успешно установлен:

Теперь давайте перейдем в раздел «Расширения»->«Шаблоны» и посмотрим, что у нас там имеется:

Можно убедиться, что шаблон действительно установлен корректно, картинки и описание отображается. Все работает!

На этом данная статья подошла к концу, в следующей статье мы несколько усложним наш установочный файл, добавим разделы, отвечающие за локализацию, разберем, что такое локализация шаблона и научимся работать с языковыми константами.