Настройка AndroidManifest в разных типах сборки

Я хочу настроить AndroidManifest в разных типах сборки. Например, в режиме отладки я просто хочу, чтобы действие было экспортировано.

Предположим, что основной манифест:

/main/AndroidManifest.xml

<application>
    <activity
        android:name="com.example.MainActivity" />
</application>

Манифест отладки:

/debug/AndroidManifest.xml

<application>
    <activity
        android:name="com.example.MainActivity"
        android:exported="true" />
</application>

Пример манифеста (такой же, как отладка):

/example/AndroidManifest.xml

<application>
    <activity
        android:name="com.example.MainActivity"
        android:exported="true" />
</application>

В манифесте отладки я получаю Duplicate registration for activity com.example.MainActivity

Вот почему я создал пример типа сборки.

/build.gradle

android {
    buildTypes {
        example.initWith(buildTypes.debug)
    }
}

Но это тоже не работает.

[AndroidManifest.xml:17, AndroidManifest.xml:4] Trying to merge incompatible /manifest/application/activity[@name=com.example.MainActivity] element:
  <activity
--    @android:name="com.example.MainActivity">
--</activity>
--(end reached)
  <activity
++    @android:exported="true"
++    @android:name="com.example.MainActivity">
++</activity>

Мне интересно, это баг, отсутствующая функция (будет реализована в будущем) или я что-то не так делаю?

Я знаю, что могу предоставить другой манифест в выпуске и отладке (без /main), но я не думаю, что это хорошее решение.

РЕДАКТИРОВАТЬ: пока решение состоит в том, чтобы определить bool в ресурсах и использовать его внутри основного манифеста. В ресурсах отладки bool будет true, а в релизе false. Это решение кажется намного лучше, чем дублированные манифесты, но вопрос остается актуальным.


android android-gradle-plugin android-manifest
person tomrozb    schedule 05.12.2013    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Начиная с плагина Gradle 0.10, он наконец поддерживается. Дополнительные сведения о слиянии новых манифестов: http://tools.android.com/tech-docs/new-build-system/user-guide/manifest-merger

На данный момент (плагин gradle 0.10) требуется дополнительная конфигурация в build.gradle

android {
 useOldManifestMerger false
}
person tomrozb    schedule 05.05.2014

arrow_upward
1
arrow_downward

Я знаю, что могу предоставить другой манифест в выпуске и отладке (без манифеста в /main), но я не думаю, что это хорошее решение.

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

person Krylez    schedule 05.12.2013
comment
Ответ, на который вы ссылаетесь, - один год и говорит, что в данный момент. Я видел эту тему до того, как задал этот вопрос, и это касается ‹intent-filter›, а не аргументов действия, но действительно кажется, что это все еще не реализовано, а не ошибка. - person tomrozb; 06.12.2013
comment
Ограничение не ограничивается фильтрами намерений. Я думаю, что это ManifestMerger, который они используют в настоящее время, и он будет объединять действия с одинаковыми именами, только если они идентичны. - person Krylez; 06.12.2013