Почему Gradle игнорирует выпуск {} и реализует правило для сборки отладки?

Question

Я не уверен, что это произошло раньше, но я думаю, что это произошло после недавних обновлений Android Studio и Gradle.

А именно, я пытаюсь установить выходной путь для выпуска APK. Так что я сделал такой код

buildTypes { 
    release { 
     minifyEnabled false 
     proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' 

     signingConfig signingConfigs.config 

     def outputPathName = "./apk-release.apk" 
     applicationVariants.all { variant -> 
      variant.outputs.each { output -> 
       output.outputFile = file(outputPathName) 
      } 
     } 
    } 
} 

Это переместит APK из расположения по умолчанию (/build/outputs/apk) и поместить его рядом с файлом build.gradle.

Однако игнорируется release{}, и Android Studio перемещает сборку отладки в это место, а также переименовывает его. Поэтому либо я создаю подписанный APK, либо нажимаем значок отладки, чтобы протестировать отладочную версию, APK перемещается и переименовывается. И он должен оставаться в своем месте по умолчанию, не так ли?

Почему это происходит? Ошибка в Android Studio Gradle или ошибка в моем коде?

ПРИМЕЧАНИЕ. Я заметил, что то же самое происходит и в моем другом проекте, в котором я создаю собственное имя для APK. Он также переименует debug APK и таким же образом игнорирует release{}.

Версия для Android для Android: 1.3. Просмотр 5

Answer 1

выпуск {} в настоящее время игнорируется

Не совсем. Каждая строка кода в build.gradle выполняется при обработке сценария.

Скриншоты Gradle не могут выполнять код во время сборки. Они предназначены для определения объектной модели процесса сборки. В Android Studio скрипты Gradle не читаются и не интерпретируются во время сборки; они считываются, когда проект открывается или когда вы «Синхронизируете проект с файлами Gradle». Именно эта объектная модель заполняет такие вещи, как представление «Варианты сборки».

Закрытие не означает «это только то, что должно быть сделано в сборке релизов». Он просто говорит «эй, все, что вы не можете распознать, например, minifyEnabled, посмотрите, есть ли это свойство или метод или что-то в этом здесь release объект». Вы можете написать начальную часть вашего release закрытия, как это:

buildTypes { 
    release.minifyEnabled false 
    release.proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' 
    release.signingConfig signingConfigs.config 
} 

или даже:

buildTypes.release.minifyEnabled false 
    buildTypes.release.proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' 
    buildTypes.release.signingConfig signingConfigs.config 

, если вы хотите.

Вот почему вы обычно видите, что вроде applicationVariants петли в конце android {}, так как (я думаю) applicationVariants является частью Gradle для Android плагин DSL, и он будет перебирать все возможные варианты применения.

Итак, если вы хотите только повлиять на release сборки, в цикле, проверьте variant для своего типа сборки:

def outputPathName = "./apk-release.apk" 
    applicationVariants.all { variant -> 
     def name = variant.buildType.name 

     if (name.equals(com.android.builder.core.BuilderConstants.DEBUG)) { 
      return; // Skip debug builds. 
     } 

     variant.outputs.each { output -> 
      output.outputFile = file(outputPathName) 
     } 
    } 

(там, наверное, дождевик способ фильтрации, но это то, что я я использовал ...)