ぼっちプログラマのメモ

UE4とかVRとかについて書いたり書かなかったり。

【UE4 & Android】実機デバッグ実行中のログ確認方法について

はじめに

突然ですが、Android開発時のデバッグ・プロファイリング方法についてまとめようと思います。検証したUE4のバージョンは4.21.2です。

今回は実機実行のログ確認方法についてです。
UE4エディタ上で確認する方法と、Android Debug Monitorというツールを使う方法の2つを紹介します。

ちなみに、iOS開発版はこちらです。
pafuhana1213.hatenablog.com

続きを読む

【UE4.21】「The specified Android SDK Build Tools version (26.0.1) is ignored, as it is below the minimum supported version (26.0.2) for Android Gradle Plugin 3.0.1.」 というWarningが出てAndroidパッケージ作成に失敗する問題への対応方法

本題

記事タイトルの通りですが、UE4.21にてGradleを有効にした状態でAndroidパッケージを作成すると、以下のメッセージがログに出力されてパッケージ作成に失敗する場合があります。

 Creating rungradle.bat to work around commandline length limit (using unused drive letter Z:)
 Making .apk with Gradle...
 To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: https://docs.gradle.org/4.1/userguide/gradle_daemon.html.
 Daemon will be stopped at the end of the build stopping after processing
 WARNING: The specified Android SDK Build Tools version (26.0.1) is ignored, as it is below the minimum supported version (26.0.2) for Android Gradle Plugin 3.0.1.
 Android SDK Build Tools 26.0.2 will be used.
 To suppress this warning, remove "buildToolsVersion '26.0.1'" from your build.gradle file, as each version of the Android Gradle Plugin now has a default version of the build tools.
 File C:\Users\awfor\.android\repositories.cfg could not be loaded.
 Checking the license for package Android SDK Build-Tools 26.0.2 in C:\NVPACK\android-sdk-windows\licenses
 Warning: License for package Android SDK Build-Tools 26.0.2 not accepted.
 
 FAILURE: Build failed with an exception.

原因は最近Googleがライセンス契約を変更したのですが、UE4.21時点ではその変更に対応できていないからです。 (ライセンス更新は2019/1/16 頃、たぶん)

この問題を解決するには、UE4.22から入る新しいライセンス契約への対応をUE4.21に移植する必要があります。といっても対応は簡単で、UE4.22以降が持つ Engine/Source/ThirdParty/Android/package.xmlUE4.21のpackage.xmlに上書きした後に、再度Project設定のAndroidカテゴリにある "Accept SDK License"ボタンを押すだけです。
f:id:pafuhana1213:20190206005342p:plain

なお、この記事を書いた2019/2/6時点では以下のurlからUE4.22版のpackage.xmlをDL可能です。
https://github.com/EpicGames/UnrealEngine/blob/4.22/Engine/Source/ThirdParty/Android/package.xml

おまけ 1

UE4.21からAndroidのNDKのバージョンが 12b から 14b に上がっています。そのため、UE4.20以前にAndroid開発をしていた場合は、\Engine\Extras\AndroidWorks\Win64\CodeWorksforAndroid-1R7u1-windows.exe を使って開発環境をアップデートする必要があります。アップデート後は、UE4エディタのプロジェクト設定におけるAndroid SDKカテゴリにある各項目を新しいバージョンのものに合わせることをお忘れなく。あと、インストールする前に以前のバージョンをアンインストールした方が安全かと思います。

Android
Android NDK r14b (新しい CodeWorks for Android 1r7u1 インストーラは、Windows および Mac 上の、以前の CodeWorks を置き換えます。Linux は 1r6u1 と修正版を使用します)
https://www.unrealengine.com/ja/blog/unreal-engine-4-21-released?sessionInvalidated=true

おまけ 2

上述の対応後にAndroidパッケージの作成を行うと、以下のエラーが発生する場合があります。

LogPlayLevel: Error: C:\Users\●●●\.gradle\caches\transforms-1\files-1.1\support-compat-27.1.0.aar\36ca67ef4f432d33200b3e8a5af4a755\res\values\values.xml:20:5-70: AAPT: error: resource android:attr/fontStyle not found.
 LogPlayLevel: Error: C:\Users\●●●\.gradle\caches\transforms-1\files-1.1\support-compat-27.1.0.aar\36ca67ef4f432d33200b3e8a5af4a755\res\values\values.xml:20:5-70: AAPT: error: resource android:attr/font not found.
 LogPlayLevel: Error: C:\Users\●●●\.gradle\caches\transforms-1\files-1.1\support-compat-27.1.0.aar\36ca67ef4f432d33200b3e8a5af4a755\res\values\values.xml:20:5-70: AAPT: error: resource android:attr/fontWeight not found.
 LogPlayLevel: Error: Z:\app\build\intermediates\incremental\mergeDebugResources\merged.dir\values\values.xml:95: error: resource android:attr/fontStyle not found.
 LogPlayLevel: Error: Z:\app\build\intermediates\incremental\mergeDebugResources\merged.dir\values\values.xml:95: error: resource android:attr/font not found.
 LogPlayLevel: Error: Z:\app\build\intermediates\incremental\mergeDebugResources\merged.dir\values\values.xml:95: error: resource android:attr/fontWeight not found.
 LogPlayLevel: Error: error: failed linking references.
 LogPlayLevel: Failed to execute aapt

発生した場合は、Android SDK API Levelをandroid-21に戻してみてください。これで解決することが多いです。

おまけ 3

プロジェクト設定のAndroidカテゴリにある "Enable Gradle Instead of Ant"を無効にすれば、gradleではなく昔のantを使ってパッケージを作成するようになるため、gradle絡みの問題を回避することが可能です。しかし、antは古いシステムなので推奨されていない上に今後削除される予定なのでご注意ください。

また、ARCoreを使う場合は必ずgradleを使用する必要があります。 antを使ってパッケージを作った場合、起動後に即クラッシュします。クラッシュした際のlogcatは以下の通り。

02-05 23:37:22.006: E/AndroidRuntime(17685): java.lang.UnsatisfiedLinkError: dlopen failed: library "libarcore_sdk_c.so" not found
02-05 23:37:22.006: E/AndroidRuntime(17685): 	at java.lang.Runtime.loadLibrary0(Runtime.java:977)
02-05 23:37:22.006: E/AndroidRuntime(17685): 	at java.lang.System.loadLibrary(System.java:1530)
02-05 23:37:22.006: E/AndroidRuntime(17685): 	at com.epicgames.ue4.GameActivity.<clinit>(GameActivity.java:5504)
02-05 23:37:22.006: E/AndroidRuntime(17685): 	at java.lang.Class.newInstance(Native Method)
02-05 23:37:22.006: E/AndroidRuntime(17685): 	at android.app.Instrumentation.newActivity(Instrumentation.java:1079)
02-05 23:37:22.006: E/AndroidRuntime(17685): 	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2538)
02-05 23:37:22.006: E/AndroidRuntime(17685): 	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2707)
02-05 23:37:22.006: E/AndroidRuntime(17685): 	at android.app.ActivityThread.-wrap12(ActivityThread.java)
02-05 23:37:22.006: E/AndroidRuntime(17685): 	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1460)
02-05 23:37:22.006: E/AndroidRuntime(17685): 	at android.os.Handler.dispatchMessage(Handler.java:102)
02-05 23:37:22.006: E/AndroidRuntime(17685): 	at android.os.Looper.loop(Looper.java:159)
02-05 23:37:22.006: E/AndroidRuntime(17685): 	at android.app.ActivityThread.main(ActivityThread.java:6097)
02-05 23:37:22.006: E/AndroidRuntime(17685): 	at java.lang.reflect.Method.invoke(Native Method)
02-05 23:37:22.006: E/AndroidRuntime(17685): 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
02-05 23:37:22.006: E/AndroidRuntime(17685): 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)
02-05 23:37:22.008: W/ActivityManager(2739):   Force finishing activity com.YourCompany.ARTemplateBuild/com.epicgames.ue4.GameActivity

どうやらgradleが持っている libarcore_sdk_c.so が必要なので、antだとクラッシュするようです。こちらもご注意くださいまし。

おわり

UE4の物理アセット・クロスの荒ぶりを何とかする方法について (UE4.21版)

はじめに

この記事はUnreal Engine 4 その2 Advent Calendar 2018の20日目の記事です。
qiita.com

何を書こうか色々悩んだのですが、今年も物理と仲良くする(意味深)方法について書こうと思います。なお、去年の記事は以下の通り。(え、もうアレから一年経ったの!?)

UE4.18で生まれ変わった物理アセットエディタ(Physics Asset Editor)について」 と 「物理と少し仲良くなる方法について」
その1:http://pafuhana1213.hatenablog.com/entry/2017/12/13/000000
その2:http://pafuhana1213.hatenablog.com/entry/2017/12/13/000100
その3:http://pafuhana1213.hatenablog.com/entry/2017/12/13/003018

f:id:pafuhana1213:20181220151928g:plain

実験に付き合ってもらうのはいつものこの方々。左のOwenくんはクロス担当、右のグレイマンは物理アセット担当です。

なお、今回は物理アセット・クロスの設定を極力変えずに既存の機能で何とかすることを目標とします。何故なら去年の内容と被りますし、作業コスト高いですし、職人芸になりがちですし、、説明が大変だからです!(ドン!

物理の荒ぶりに対して、我々はどう立ち向かえばいいのか?

基本方針は以下の3つです!

  • 荒ぶりの原因になる挙動を無視させる
  • 物理をリセットして荒ぶりを消す
  • 荒ぶり前に物理を停止し、その後再開する

これらの対応を入れることで、(色々と許容しないといけない場合あったりしますが)、だいたいの物理の荒ぶりを回避できます。

具体的にどうすればいいのか、これから順に説明します。

続きを読む

UE4 & iOS開発時の実機デバッグ・プロファイリング方法 まとめ 2018 < CPU・GPUプロファイリング編 >

本内容は複数の記事で構成されています。検索などでこの記事に直接飛んできた方はまず以下の記事をご確認ください。
pafuhana1213.hatenablog.com

はじめに

みんな大好きプロファイリングについての話です。
iOS開発では、Instrumentsというプロファイリング用のツールが用意されています。ここではをUE4で開発をする際にどのようにしてInstrumentsを使うかについて説明します。

…実機上で各statコマンドを活用することもお忘れなく。

www.slideshare.net

続きを読む

UE4 & iOS開発時の実機デバッグ・プロファイリング方法 まとめ 2018 < CPU・GPUデバッグ編 >

本内容は複数の記事で構成されています。検索などでこの記事に直接飛んできた方はまず以下の記事をご確認ください。
pafuhana1213.hatenablog.com

はじめに

ゲームの動作や不具合を調査・デバッグする上でBreakPointは必要不可欠です。ということで、UE4 & iOS開発時にどのようにしてBreakPointを使うのかについて紹介します。なお、Xcodeを使用する関係でMacが必須なのでご注意ください ( MacMiniはいいぞ )。
f:id:pafuhana1213:20181213024154g:plain

続きを読む

UE4 & iOS開発時の実機デバッグ・プロファイリング方法 まとめ 2018 < ログ確認・抽出編 >

本内容は複数の記事で構成されています。検索などでこの記事に直接飛んできた方はまず以下の記事をご確認ください。
pafuhana1213.hatenablog.com

はじめに

ゲーム中にPrintStringなどで出力したデバッグ情報の確認やクラッシュ時の原因調査など、ログファイルはすごく便利で得られるものも多いです!
ということで、まずはログの確認、ファイル取得から。

続きを読む

UE4 & iOS開発時の実機デバッグ・プロファイリング方法 まとめ 2018 < はじめに編 >

はじめに

この記事はUnreal Engine 4 Advent Calender 2018の13日目の記事です。
qiita.com

f:id:pafuhana1213:20181213023820j:plain
おかげさまでUE4モバイル案件が増えてきたということもあり、ネット上にあまり情報がないiOS開発時の実機デバッグ・プロファイリング方法についてまとめてみました。
…社内外含めて情報全然ない!がんばた!

各記事のご案内

…予想以上に内容が膨らんだので記事を分割しました。

  • ログの確認
    • 実行中のログ確認
    • 実行後のログ確認

pafuhana1213.hatenablog.com

pafuhana1213.hatenablog.com

  • CPU, GPUプロファイリング
    • Instrumentsを使って、CPU・GPU処理の負荷を確認

pafuhana1213.hatenablog.com

注意

なお、全て実機上でのデバッグ・プロファイリングについてです。UE4エディタ上で行う際はモバイルプレビュア機能をご活用ください。ただしあくまで疑似再現なので、ちゃんとデバッグ・プロファイリングするときは実機でしましょう!
api.unrealengine.com

また、stat関連とログ取得以外に関しては必ずMacが必要になります


Mac Mini(2018)、少なくとも個人開発レベルでは、リモートビルド・プロファイリングする上で不便に思ったことはないです。オススメです。はい。

Macと仲良くできるかはまた別問題だけどな!

検証環境

開発環境構築について

皆さん大好きな証明書、プロビジョニングファイル、リモートビルドを含む開発環境の構築に関しては、わんちゃん( @WanchanJP )さんの神記事に全てが載っているのでご確認くださいまし…(本当に…本当にありがとうございます!)
soramame-games.com

最後に (各記事をご確認頂いた後にどうぞ)

手探り感が凄いですが、UE4iOS開発をする際のデバッグ・プロファイリング方法について簡単にまとめてみました。
ただ、Macを使った開発をまだ勉強中ということもあり、「もっといい方法があるよ!」と思う方がいるかもしれません…

そういう方は…ぜひ教えてください!
なんでもしますから!

はい

以上です。あとは各記事をご確認ください。
明日は @dgtanaka さんの「なんか書きます」です!
いつも非常に有益な記事を公開して頂いているので今回も楽しみです!