Как несколько AndroidManifest.xml обрабатываются в многомодульном проекте

Обработка нескольких AndroidManifest.xml в многомодульном проекте

В многомодульном Android-проекте система сборки (обычно Gradle с плагином Android Gradle Plugin — AGP) выполняет слияние (merge) манифестов из всех модулей в единый результирующий файл AndroidManifest.xml, который будет упакован в финальное APK/AAB. Этот процесс называется Manifest Merging.

Иерархия и порядок слияния

Манифесты обрабатываются в определённом порядке, от низшего приоритета к высшему:

1. Зависимости (Dependencies): Манифесты из внешних библиотек (AAR, JAR) имеют самый низкий приоритет.
2. Основной модуль (app module): Его манифест имеет более высокий приоритет, чем у библиотек.
3. Флаворы и типы сборки (Build Variants): Манифесты из папок src/flavorName/ или src/buildType/ (например, src/debug/) имеют наивысший приоритет и переопределяют настройки основного.

Таким образом, окончательный манифест формируется по принципу: зависимости → основной модуль → варианты сборки.

Правила слияния атрибутов и элементов

Процесс управляется набором правил, которые можно контролировать с помощью специальных атрибутов в тегах манифеста.

• Объединение (Merge): Некоторые элементы, например <uses-permission>, могут появляться несколько раз из разных источников. Они будут все добавлены в финальный манифест.
• Переопределение (Override): Элементы, объявленные с более высоким приоритетом (например, в основном модуле), заменяют аналогичные элементы с более низким приоритетом (например, из библиотеки). Это касается таких атрибутов, как android:icon или android:label у тега <application>.
• Слияние с конфликтами: Если элементы имеют разные значения одного атрибута, AGP попытается разрешить конфликт. Если это невозможно, сборка завершится с ошибкой.

Инструменты управления слиянием

Для тонкого контроля используются специальные атрибуты в пространстве имён tools:

• tools:replace: Указывает, какие атрибуты текущего элемента должны заменить атрибуты из манифеста с низшим приоритетом.

  <!-- В манифесте библиотеки -->
  <activity android:name=".MainActivity" android:theme="@style/LibTheme"/>
  
  <!-- В манифесте основного модуля (app) -->
  <activity
      android:name=".MainActivity"
      android:theme="@style/AppTheme"
      tools:replace="android:theme"/>
  

• tools:remove: Удаляет указанный атрибут или даже целый элемент из финального манифеста.

  <uses-permission
      android:name="android.permission.INTERNET"
      tools:remove="android:maxSdkVersion"/>
  

• tools:ignore: Игнорирует предупреждения линтера для конкретных атрибутов.

Пример практического конфликта и его решение

Допустим, библиотека mylibrary объявляет в своём манифесте:

<application android:allowBackup="false"/>

А в основном модуле app необходимо установить allowBackup="true". Простое объявление в app приведёт к конфликту. Решение — использовать tools:replace:

<!-- app/src/main/AndroidManifest.xml -->
<manifest ...>
    <application
        android:allowBackup="true"
        tools:replace="android:allowBackup">
        ...
    </application>
</manifest>

Просмотр результатов слияния

После сборки проекта слияние можно проанализировать:

• В папке сборки: app/build/intermediates/merged_manifests/{variantName}/AndroidManifest.xml.
• Через Merged Manifest View в Android Studio: открыв манифест, можно переключиться на вкладку "Merged Manifest", которая визуально показывает итоговый файл с цветовой индикацией источников каждого элемента.

Ключевые выводы

• Автоматический процесс: Слияние выполняется AGP автоматически, но разработчик должен понимать его логику.
• Приоритеты: Важно помнить иерархию приоритетов (библиотеки → app → build variants).
• Контроль через tools:: Атрибуты tools:replace, tools:remove — основной инструмент для разрешения конфликтов.
• Отладка: В случае ошибок сборки из-за манифеста первым делом следует проверить Merged Manifest View в Android Studio, чтобы понять, какой элемент и откуда вызывает проблему.

Понимание работы Manifest Merging критически важно для создания стабильных многомодульных проектов, избегания скрытых конфликтов и корректного управления конфигурацией приложения.