Почему я должен держать BuildConfig в ProGuard?

Я встречал несколько примеров Proguard с этими строками:

# Keep the BuildConfig
-keep class com.example.BuildConfig { *; }

Я запустил приложение с и без этой строки (конечно, с моим пакетом) и не нашел никаких отличий. Я также посмотрел в сгенерированном /.../BuildConfig.java и никаких изменений тоже нет.

Для чего мне нужно хранить BuildConfig в ProGuard?

Спасибо!

Источник

2 ответа

Решение

Как и в любом другом классе, вам нужно -keep класс, если вы обращаетесь к нему косвенно с помощью рефлексии, поэтому ProGuard не будет запутывать его или оптимизировать как неиспользованный.

Чаще всего шаблоны доступа с BuildConfig являются прямыми без отражения, так что в этих случаях хорошо, чтобы ProGuard обработал ваш BuildConfig, тоже.

Источник

BuildConfig содержит ряд полезных значений, которые устанавливаются во время компиляции. В частности, это:

boolean DEBUG – if the build is debuggable.
int VERSION_CODE
String VERSION_NAME
String APPLICATION_ID
String BUILD_TYPE – name of the build type, e.g. "release"
String FLAVOR – name of the flavor, e.g. "paidapp"

Вы также можете установить свои собственные значения конфигурации, например, разные URL-адреса для тестирования и производства, и извлечь их из файла BuildConfig вместо того, чтобы поддерживать свой собственный файл Config.java. Это может быть сделано путем добавления buildConfigFields в ваш gradle buildTypes следующим образом:

buildTypes {
    debug {
        buildConfigField "boolean", "SOME_VAR", "true"
    }
    release {
        buildConfigField "boolean", "SOME_VAR", "false"
    }
}

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

Источник

Некоторые библиотеки отчетов о сбоях, такие как ACRA, имеют доступBuildConfig через отражение, поэтому, если вы используете его и хотите, чтобы информация о нем отображалась в отчетах о сбоях, вам следует -keep Это.

Источник
Другие вопросы по тегам