Включить / отключить ProGuard в вкусе продукта

#android #gradle #proguard

#Android #gradle #proguard

Вопрос:

Итак, я знаю, что в типе сборки runProguard 'bool' директива может использоваться для указания, следует ли запускать ProGuard или нет. К сожалению, эта директива не работает с вкусами продукта. Есть ли какой-либо способ указать, должен ли ProGuard запускаться во вкусах или нет? Я подумал об использовании файла конфигурации, в котором в основном написано «ничего не делать», но (1) Я не знаю, что я должен написать в нем, чтобы запретить ProGuard делать абсолютно все, и (2) Я не думаю, что это хорошее решение.

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

2. @CommonsWare Я использую «два уровня» конфигурации отладки. Первый основан на типе сборки: если buildconfig является debug, печатаются вызовы журнала в приложении. Затем второй «уровень» позволяет мне отлаживать и отслеживать проблемы (ProGuard выключен), тогда как, если ProGuard включен, эта процедура, очевидно, невозможна. Дело в том, что я хотел бы иметь возможность использовать два apk-файла с конфигурацией «ProGuard off» для работы с версией buildconfig — так что у меня отключен buildconfig release PG, включен buildconfig release PG (тот, который нужно опубликовать) и отключен buildconfig debug PG.

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

4. Ага, я этого не знал, я думал, что ароматы были единственными, которые можно было создать. Это решает все, да, спасибо.

Ответ №1:

Для вашего сценария создается впечатление, что вы пытаетесь смоделировать разные этапы жизненного цикла вашей разработки. Это действительно то, для чего нужны типы сборки. Хотя Gradle (и, следовательно, Gradle для Android) поставляется с debug release типами сборки и, вы можете определить свои собственные:

 buildTypes {
    debug {
      applicationIdSuffix ".d"
      versionNameSuffix "-debug"
    }

    release {
        signingConfig signingConfigs.release
    }

    mezzanine.initWith(buildTypes.release)

    mezzanine {
        applicationIdSuffix ".mezz"
        debuggable true
    }
}

Здесь я:

Настройте debug release типы сборки и
Клонировать mezzanine тип сборки из release
Переопределите некоторые настройки mezzanine , заменив то, что они были определены как изначально release

1. Привет, нет ли способа указать разные настройки для разных вкусов продукта внутри release variant?

2. @BharathMg: В общем, вкусы продуктов ортогональны типам сборки. IOW, любые изменения, которые вы хотите внести в версию для варианта выпуска, также должны быть изменены для варианта отладки. Тем не менее, могут быть некоторые способы работы с конкретными настройками таким образом, который может вам подойти. Я предлагаю вам задать новый вопрос о переполнении стека, в котором вы объясняете свой сценарий и спрашиваете, как его выполнить.