Android studio gradleバージョン 下げる

凡ミスした結果Gradleについて少し勉強できた．

内容はしょうもないミス．ただ，初心者は意外とこういうミスでハマったりするので，Gradleについての基礎とあわせ，自分の恥ずかしいミスについて紹介させてください．

「アプリのbuild.gradleファイルに~」と書かれていたら．
build.gradle(:app)のことですよ！！！
ただGradleについてのいい勉強になったのでメモ．

やろうとしたこと

NavigationEditorを使いたくて，公式ガイドを参考に作業しようとした．
Navigation コンポーネント スタートガイド  |  Android デベロッパー  |  Android Developers

プロジェクトにナビゲーション サポートを組み込むには、アプリの build.gradle ファイルに以下の依存関係を追加します。

ここで僕はミスり，build.gradle(プロジェクト名)のdependenciesにコードを追加してしまった．

起きたこと

Gradleエラーが出，わけが分からずバージョンをいじってさらに深刻化してしまった．

解決策

• コードの修正（正しい場所へ追加し直した）
• ぐちゃぐちゃになってしまったGradle とGradle pluginのバージョンを直した．

Gradle Gradle pluginのバージョンについて

ビルドシステムであるGradleを利用できるようにするのがGradle pluginなのだが，それぞれの対応しているバージョンが異なる．

例えばGradle pluginのバージョンが4.0.0の際に必要なGradleのバージョンは6.1.1以降となる．ややこしい…

• 参考 |対応表が確認できる．
  Android Gradle プラグインのリリースノート  |  Android デベロッパー  |  Android Developers

GradleとGradle pluginのバージョン確認と変更

Android Studio上で
⌘ ; またはFile>Project Structureを開きバージョンを揃える．

以下，凡ミスに気づかなかったときの迷走ぶりを紹介

混乱している当時のメモです．

エラーの内容

Gradle DSL method not found: 'implementation()'
Possible causes:
The project 'projectname' may be using a version of the Android Gradle plug-in that does not contain the method (e.g. 'testCompile' was added in 1.1.0).
Upgrade plugin to version 4.0.1 and sync project

The project 'omikuji' may be using a version of Gradle that does not contain the method.
Open Gradle wrapper file

The build file may be missing a Gradle plugin.
Apply Gradle plugin

Gradleのバージョンがあってないらしい．
そもそもGradleとは？
Gradle入門 - Qiita
ビルドシステムの一種らしい．

一度追加したコードをコメントアウトし，

GradleとGradle pluginのバージョンを対応させる．

エラーが消えた．
コードを戻すとまたエラー．
このコードの中に何があるんだ？

// Navigation-editor
def nav_version = "2.3.1"

implementation "androidx.navigation:navigation-fragment-ktx:$nav_version"
implementation "androidx.navigation:navigation-ui-ktx:$nav_version"

アホですね−．
植えた木にうまく果実がならないときは，まずはそもそも植えたものが正しいかどうかを確認しましょう！！！

参考

• Gradle と Gradle Plugin のバージョンについて - Qiita
• Gradle入門 - Qiita

[Android]ライブラリーとGradleのバージョンを指定する技術

古いバージョンを使っていると気づいたら、バージョンの更新をします。バージョンの指定の仕方は複数あります。皆様はどうやってバージョンを指定していますか？

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

このシリーズを初めての方はこちらです。

「最近Androidを始めた同僚のソースをモダン化計画 」シリーズ開始 ｜ Developers.IO

リリースを目指して作っているので、公開してまずいところは、一部改変しています。

前回復習

[Android]ライブラリーとGradleが古いバージョンを使っていると気づく技術 ｜ Developers.IO

古いバージョンを使っていると気づいたら、次は新しいバージョンに設定します。設定するだけと思いがちなんですが、ここよく考えたほうが良いです。長いプロジェクトや個人や趣味で放置しがちのプロジェクトほど、1周回って悩みどころなんです！

バージョン指定の方法

まずはどんな指定の仕方があるか洗い出します。無駄に選択肢がたくさんあります。皆さんはどれを使っていますか？

直接バージョンを指定する

愚直にバージョンを直接書きます。

implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:0.22.5"

+ で指定する

マイナーバージョンをいちいちアップデートしたりめんどいので+を使うと楽ですね。+ですると、その中でも一番新しいバージョンという指定ができます。

implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:0.22.+"
implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:0.+"
implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:+"

build.gradleで変数を使って指定する

メリットとしては、Android Supportライブラリーなどは全部同じバージョンを指定しないといけないですが、変数をつかってるので統一しやすいです。

設定例:

ext.firebase_version = '16.0.1'

implementation "com.google.firebase:firebase-core:$firebase_version"
implementation "com.google.firebase:firebase-invites:$firebase_version"

def firebase_version = '16.0.1'

implementation "com.google.firebase:firebase-core:$firebase_version"
implementation "com.google.firebase:firebase-invites:$firebase_version"

使用例

timber/build.gradle at master · JakeWharton/timber

gradle.propertiesを使って指定する

個人の感想ですが、メリットとしては、「build.gradleで変数を使って指定する」と同じですが、app/build.gradleは長くなりがちで、ファイルの途中にバージョン定義があったり探しにくいです gradle.propertiesに書くことで、指定箇所がわかりやすくなります。

設定例:

/gradle.properties

support_lib_version=25.1.1

/app/build.gradle

implementation "com.android.support:support-v4:${support_lib_version}"

例：Droid Kaigi 2017

conference-app-2017/gradle.properties at master · DroidKaigi/conference-app-2017

conference-app-2017/build.gradle at master · DroidKaigi/conference-app-2017

1周回っての結論: 何も工夫せず直接バージョンを指定する

ええーっという方が多いと思うんですが、昔は僕も「+で指定するのめっちゃ楽ー。サポートライブラリーのバージョンを揃えるために変数つかって一気に指定するとか便利ー」とか思っていた時期がありました。直接バージョン指定するなど情弱っと。

今は、逆で1周回って「直接書いたほうが変な罠踏まないしメンテが楽で、変更も楽だな」と思うようになりました。

とはいえ、こればっかりは趣味の世界だと思います。チーム内でよく話し合って決めていただけばと思います。僕なりの結論を書きます。

古いバージョンに気づける

前回で説明した通り、古いバージョンのときは背景の色がつくので気づけます。

+ で指定した場合は、ずっとあの色の背景なので、気づけないんですよね。

ビルドがはやくなる

+ で指定している場合は、Android Studioでビルドや起動するたび最新版のチェックしてDLが走るので少し遅いです。バージョンが指定ある場合すでにDLしてたらチェックが走らないので早い。

オフラインモードでビルドできる

「ビルドがはやくなる」でチェックがはしるということはオンラインじゃないとビルドができないです。一度DLし終わった状態だとオフラインモードでのビルドは、めちゃめちゃ早いのでオススメです。

突然動かなくなったときの無駄な調査が発生しない

+ 指定の場合は、突然ビルドができなくなるっということが半年に一回ぐらい起きます。「そのときなんで？昨日までできたじゃん。。」パニック状態。+だとライブラリーのバージョンを気にしないで運用/開発してると思います。なので疑うのが一番最後なんですよね。ソースコードをもうめちゃめちゃ疑った後に途方にくれてbuild.gradleみて、「あっ」てなるやつです。

だめだったときに、もとに戻しやすい

これまた + のときです。 「突然動かなくなったときの無駄な調査が発生しない」で話した、突然動くなったときの対処が難しい。どのバージョンで動いてたっけ？っという不毛な調査することになります。だって一度もバージョンを確認していないのだから、コミット履歴みても成功していたバージョンがわからない。一つずつバージョンあげてみてテストしたりなどをします。つらい。

意外と変更が簡単

変数だとあまりに触らないから、影響範囲が忘れがち 変数系にいえることなんですが、バージョン変更が意外と面倒で、ここ書き換えるとどこ変わるんだっけ？結局最新バージョンいくつに変更するんだっけ？って何往復かしてしまいます。月に1回、3ヶ月1回しか触らないので、影響範囲を忘れています。

100歩譲って、そこはまぁ我慢しよう。バージョンの更新ちょっとストレスがあるんです。

変数だとAndroid Studioがいい感じに変えてくれない

変数系でもAndroid Studioで気づくことはできるんですが、Android Studioが変えてくれないんです。

前回Android Stuidioがいい感じにバージョンを編集してくれるので、メッセージ読んで「Alt Enter or Option Enter」 して、動作確認してだめだったら前に戻すっていうことも簡単にできます。Support Libraryとかの揃えるのめんどくさい？っと思うと思うのですが、更新のタイミングをそろえるとAlt Enter or Option Enterで最新に変えていくと全部バージョンが揃うのであんまり困っていません。

以上の点で趣味でもプロダクトでも、僕は1周回って直接バージョンを指定しています。

これはすべてAndroid Studioさんが優秀すぎるからです。

まとめ

「Droid Kaigiとかイケイケのプロジェクトは変数とか使って指定してるよ！今どき直接バージョンしてるとか、ふっるい〜。この情弱めが！」っと言われても、僕は理由を説明します。

好みの問題もあるので、チームでメリット・デメリットをよく話し合い決めていただければ思います。

Android Gradle Plugin Versionの確認方法は？

Androidアプリのバージョン番号は？

Android Studioのバージョン表示は？

Gradle 何ができる？