2015-02-26 1 views
3

Скажем, у меня есть константа, определенная на обоих уровнях: в типе сборки я устанавливаю ее в «mybuild», и в аромате я устанавливаю ее на «myflavor».Что имеет преимущество, типы сборки или ароматы Gradle?

Такие, как здесь:

buildTypes { 
    debug { 
     resValue "string", "analytics_key", "XXX_SANDBOX_KEY_XXX" 
    } 
} 

productFlavors { 
    appA { 
     resValue "string", "analytics_key", "XXX_KEY_FOR_A_XXX" 
    } 
    appB { 
     resValue "string", "analytics_key", "XXX_KEY_FOR_A_XXX" 
    } 
} 

Я хочу, чтобы отправить событие различных приложений (thta есть, ароматизаторы) на различные счета в моей аналитической платформе. Но, если я отлаживаю, я хочу отправить их всем в мою учетную запись sandbox.

Оригинальный вопрос: что имеет преимущество? Из моего теста я уже могу ответить на это: тот, что есть в типе сборки.

Тем не менее, тем интереснее: это гарантировано?

(Или есть лучший способ сделать это?)

ответ

7

в это гарантировано?

Тип сборки обычно считается более высоким приоритетом, чем вкусы продукта для вещей на одном уровне (например, тот же модуль). Цитирование the documentation:

Обычно конфигурация типа сборки является наложением поверх другой конфигурации. Например, пакет PackageNameSuffix типа сборки добавляется к имени пакета Product Flavor.

Манифест, однако, довольно сложный, требующий its own set of docs.

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

Всех ресурсах (Android Реза и активы) используются с помощью наложения приоритета, когда тип сборки перекрывает продукт Вкус, который переопределяет основной источник.

Если resValue начал вести себя иначе, чем эквивалент, используя исходники, я бы счел это ошибкой.

+0

@espinchi: «если я не использую ресурсы XML, или если я их смешиваю (как я и предполагал) »- я определенно не буду использовать ресурсы« resValue »и« real »для одного и того же типа и имени ресурса, поскольку я скорее сомневаюсь, что это ожидаемый шаблон использования. Однако, если что-либо, использование только файлов ресурсов должно быть более безопасным, поскольку это поведение явно документировано.Каков ваш сценарий, когда это не работает? – CommonsWare

+0

(Извините, я удалил свой предыдущий комментарий по ошибке.) Да, использование только ресурсов работает по назначению, и конечный результат на самом деле более читабельен. Первоначально я хотел сделать переопределение более явным в файле build.gradle, но я вижу, что это не нужно. – espinchi

1

В качестве альтернативы вы можете разместить свои ресурсы в string.xml файл в исходном-папке buildType-папки, productFlavour-папки или в папке buildVariant.

Если вы поместите его в папку buildVariant, если будете уверены, что это значение будет использовано.

src-Root 
    |->main 
    |->debugAppA <- resources in this combination will be given precedence. 
    | |->res 
    |  |->values 
    |   |-> strings.xml 
    |-> debug 
    | |->res 
    |  |->values 
    |   |-> strings.xml 
    |-> appA 
    | |->res 
    |  |->values 
    |   |-> strings.xml 
+0

+1. Да, это подтверждается (по ссылкам CommonsWare), что ваше предложение действительно сработает. В конце концов, я сделаю гибрид: string.xml для флейворов и build.gradle для типа сборки, который их переопределяет. – espinchi

+0

@espinchi, как можно? вы можете проверить мой вопрос здесь http://stackoverflow.com/questions/33014820/gradle-exclude-file-creating-jar-in-a-subproject – smilyface

Смежные вопросы