基本的にJDK8の時とさほど変わりはないのですが、JDK17になってから、デプロイファイルをパッケージングする際に多少の違いがありました。
環境構築としてはnode.js(LTS)最新版でも利用可ですが、
筆者の環境で確認ができているのはnode.js20系(LTS)です。
あとは、このブログを読んでくれている方で、熱心な方は、CordovaをインストールしてCLIコマンドにてコンパイルする手順は大きく変わりません。
JDK17では、スタンドアロン環境構築のためのAndroidSDKを利用していましたが、
アプリケーション生成時に動作を安定させ、生成したネイティブアプリをエミュレートする時点で、結局はAndroidStudioのインストールが必要になるため、
JDK17でのスタンドアロン環境を構築しても、動作確認時のADVがAndroidStudioにプリインストールされているものを使って動作確認しています(筆者のPCの環境の変化もあり旧来のADVでは確認できませんでした。)
また、どちらにせよAndroidStudioをインストールしたほうが、AndroidSDKも一緒にインストールすることができるため、AndroidStudioをインストールし、AndroidSDKをオプションで最新版の前々当たりのバージョンをインストールすることが必要になってきます。
JDK17とJDK8ではCLIこそ大きな違いはありませんが、コマンドが少し違っていたり、
JDK8で出ていた警告がスルーされるようになったりSignの時に微妙に違っていたりと、
JDK17では少しずつ変更があるようです(変更点を把握していないとJDK8~JDK17にジャンプアップした時に、違いに気づくのが遅くなり連日徹夜となったこともあります。)
JDK17とgradle8.9を使い、ktolinは用いていません。
あくまでもJavaにコンパイルしたネイティブアプリとして、パッケージングします。
JDK8の環境の方がJDK11に変更されるときは、JDKとはいえ、ほぼ別のJDKという認識でいたほうが良いので、
JDK8とほぼ似たような互換性のあるJDK17を用いました。
基本的にモバイルアプリケーションのパッケージングが出来ている方向けについての補足記事のようなものなので、モバイルアプリケーションのパッケージングとは?についての詳細は、階層が深くなりますが、
上記のリンクのページで解説しています。
また、当方の有料記事にお金を払いたくない、または、お金をかけたくないかたは、Google検索をなさってください。
モバイルアプリケーションのパッケージングについてはツクールMVのヘルプを参照していただくか(ios関連のパッケージング方法をandroidアプリのパッケージングに応用する)ほかの方がトピックとして扱われているものを参照してください。
Cordovaでアプリのパッケージングなどで検索するとヒットすると思います。
一番気を付けなければならないのがSignの時で、以前から利用していたPCでのアプリのパッケージングでSignをするときは、以前利用していた証明書鍵がJDK17でも利用できるので、大丈夫なのですが、環境移行なのでPCが変わったなど、秘密鍵そのものを最初から作成しなければならない時が注意深くSignの手順を進めなければならないことになります。
とはいえ、GooglePlayではデベロッパーの本人確認ができていれば、証明書鍵も秘密鍵もアップデートのタイミングで変更することが可能なので、あまり深く悩まなくても大丈夫です。
Javaのsignerの時に最初は何度か弾かれるかもしれません(新環境PCだと)
それでも何度か挑戦していると、java signerが通じてくれるようになるので、何度も試してみてください。
そもそも証明書鍵のパスワードもエイリアスも忘れて、証明書鍵をインストールできないという事象に陥ったら、GooglePlayのデベロッパーコンソールで連絡して、秘密鍵と証明書鍵をリセットしてもらうことになります。
リセットする際に証明書鍵はPEMにて、GooglePlayデベロッパーコンソールに再申請することになりますが…。
では、簡単にではありますが、JDK17での環境構築やモバイルアプリのパッケージングについての補足記事でした。
最後までお読みくださり、誠にありがとうございます。