(2023年追記あり)【Unity】AndroidのテストにはもうAndroid Studioのエミュレータは使えない……かも
以前はAndroid向けのビルドを行って出力したapkをAndroid Studioのエミュレータでテストできたりもしましたが、Unity2019.3以降はこれも難しくなりました。というのもx86のアーキテクチャのサポートがUnity2019.2で終了したためです。Android Studioのエミュレータのシステムイメージはx86かx86_64がメインなので、ビルドしたアプリがx86をターゲットに含められないとなると、もはや動かないんですよね。
この記事を書いているのは2020年の12月、実はこの話が出てきたのは2019年の半ばごろだったので今更感はあるのですが、LTS版のUnity2018.4のサポートが2021年の春ごろに終了するため、ここで一度状況を整理しておきたいと考えこの記事にまとめました。
結論から言えば「実機でテストしよう」です。身もふたもありませんね。
念のため補足しておくと、これはあくまでUnityでゲームを作成するときの話であって、Android Studioでアプリを作っている場合には普通にエミュレータ使えますからね。念のため。
(追記)2023年には再び使えるようになっています
2023年8月ではAndroid Studioで提供しているシステムイメージが「arm64-v8a」になっているので、Unityでarm64にチェックを入れてapkのパッケージをビルドしている場合はインストールできました。Windows側はまだ確認できていませんが、2023年8月現在の私の環境だとM2 macにAndroid Studioを入れていて、こちらでは使えました。当時はIntel版macを使っていたのでそのせいもあったり……?(疑心暗鬼)
この記事を書いた記憶があったので、「シミュレータだとアプリをインストールできないんだよなぁ……」なんて思いながらダメ元でやってみたら普通に使えたので泣きそうになりました。長らく更新していなかった点は本当に申し訳ありません。気づいていなかったのは本当に不覚です。もしかして当時も「arm64-v8a」はAndroid Studio経由ではなくGoogle社のサイトからダウンロードできていたのでしょうか……?(震え声)
このページの内容は古くなったので、「過去はそんなことあったのね」と歴史を振り返るためだけにご利用いただければと思います。
AndroidのテストにはもうAndroid Studioのエミュレータは使えない……かも
Android向けのアプリを開発するためのIDE「Android Studio」にはAndroid端末の動作をシミュレーションしてくれる端末エミュレータがあります。Androidの各バージョンに合わせたシステムイメージを使った仮想端末を作成することができ、バージョンごとに実機を揃えるのが難しい個人開発者にとってはありがたい機能です。
以前のUnityでは、Android向けにビルドする際にAndroid Studioのエミュレータでも使えるx86のアーキテクチャが選択できました。しかしUnity2019.3になってからは選択できなくなっちゃったんですよね。
この決定についてはUnity Blogでも触れられていて、Androidの64bit対応をする一方で、x86へのサポートの終了が告知されています。
Unity2019.3のリリースノートでも「Androidでx86をターゲットとするオプションが削除された」との記載があります。
この経緯としては、x86のアーキテクチャの端末(スマホやタブレット)が少なくなってきたことが背景にあるようで、スマホ向けのアーキテクチャはほとんどArm社のもの(ARMv7やARM64など)で、IntelまたはAMDのもの(x86など)は一部に限られているようです。Unityとしても既に少なく、そして減りつつある端末のサポートを残しておくのはコスト面で負担が大きくなることが想像されます。
市場の動向によってサポートを終了するのは、大きく開発者というくくりであれば理解できる点です。しかし、Unityエディタを使用しているアプリ開発者の立場からするとちょっと残念な気持ちもあります。
アーキテクチャについて
ここでアーキテクチャについてちょっとおさらい。既にご存知の方は次の章まで飛ばしてもらってOKです。
アーキテクチャとは基本設計や設計思想のことで、今回のテーマであるAndroidの端末に関していうと主にCPUのアーキテクチャを指しています。すごくざっくり言うと、CPUをどう作るかの設計が異なれば、実際に出来上がるCPU内部の構造(マイクロアーキテクチャ)や、CPUなどに命令を伝える仕組み(命令セットアーキテクチャ)も異なります。(ここでは概要の説明を目的にしているので、正確な情報が必要な場合は適宜他のサイトや書籍などで補っていただけると助かります。)
例えば32bitのCPUを作るのか、それとも64bitのCPUを作るのかでも大きく変わるというのを想像してもらえるかもしれません。32bit、64bitといったビット数は一度に扱える情報量で、一度に扱える情報量が違うならCPUに伝える命令も変わってきます。
CPUと言えば「インテル、入ってる」でおなじみのインテルが有名ですが、主にPCやサーバー向けのCPUを作っています。PCやサーバー向けだけあって、高性能であることが売りで、マルチコアにするとか、トランジスタの数を増やすといったCPU内部の設計を改善するなどして性能を上げています。一方で、その分消費電力も大きく、発熱しやすいといったデメリットもあります。例えばチップの周りに冷却用のパーツを入れるなどの対策が必要になります。
スマートフォンやタブレットなどではファンを同梱するのは難しいため、別の設計思想をもとにCPUを作る必要があります。性能は多少犠牲になるかもしれませんが、スマホをホッカイロに変えるような発熱の問題や、バッテリーを使うことから電力の問題に強いARMのアーキテクチャを使ってCPUを作ることが多いんです。
Androidビルドとの関係
ここでCPUのアーキテクチャとAndroidビルドとの関係に戻ると、ソフトウェア(Unity)からみた場合、アーキテクチャごとにCPUにどうやって命令を伝えるかが異なってきます。ARMv7であればARMの第7世代の32bitCPUに対応した形でアプリをビルドする必要がありますし、ARM64であればARMの第8世代の64bitCPUに対応した形でアプリをビルドする必要があります。
冒頭で紹介したUnity Blogの記事によれば、x86(Intelまたは互換のAMD)のCPUはAndroidを搭載している端末(スマホ、タブレットなど)は数が少なくなってきていることから、x86のアーキテクチャをサポートするのはUnity さんとしても大変であると想像できます。また、GooglePlayでも64ビット対応が求められている状況もあり、2020年の夏頃にかけてx86端末のサポートを終了するアプリもいくつかみられました。
このような背景からUnity2019.3以降ではx86を選択するオプションが削除されたようです。
Android Studioのエミュレータ
Android StudioのエミュレータはPC上で動かします。PCではx86またはx86_64のアーキテクチャになっていることから、これに対応したシステムイメージが必要です。
仮想デバイスをx86のシステムイメージで作成したとしたら、x86のアプリは動くけれどARMv7のアプリは動かないんです。これはアプリとしてコンパイルされたときに命令セットが別のものになっているためです。すごく簡単にいうと「違うアーキテクチャのものは動かない」と……あ、こっちの方がシンプルで分かりやすかったですね。
「じゃあARMv7のシステムイメージを使えば?」と思ったあなた。鋭いです。
実はAndroid7.1あたりのバージョンではシステムイメージとしてARMv7を選択することもできます。
しかし、それをx86またはx86_64の環境(PC上)で動かすとなると、互いに異なる命令セットを持っているため変換する必要があるんです。そしてこの変換が曲者で、ARMv7の動作をエミュレートするのには超クッソ激烈に時間がかかります。とてもじゃないけどゲームを動かして確認するなんてのはできません。
アプリをx86で作成できれば良かったのですが、Unity2019.3以降では作成できなくなってしまっているので、Unity製AndroidアプリをAndroid Studioのエミュレータで確認するのは難しくなりました。残念。
代替案はあるかな?
本当のところを言えば「実機で確認しよう」というのがベストな方法です。実機確認に勝る方法はありません。
ですが、その実機を揃えるのは個人開発者にとって結構厳しいものがあります。毎年アップデートされるOSバージョンに対応する端末を手に入れていくのも結構な負担になりますし、Androidの場合は端末を作成する会社ごとに違いもありますからここをチェックするとなると大変です。
個人的には実機は1つ持っているべきだと思いますが、異なるOSバージョンのテストは正直きついです。いや、きつくてもやらないといけないんですけど。
なのでちょっと代替となる方法も考えてみたいと思います。
別のエミュレータを使う
Android端末のエミュレータはAndroid Studioのものだけではありません。例えばGenymotionというAndroidエミュレータがあります。
Genymotion側で仮想デバイスをホスティングしてネットワークを介して操作したり、あるいはデスクトップで使うこともできるエミュレータです。
クラウド(SaaS)で使える方は端末1台につき1分あたり0.05ドルの料金がかかります。短時間ならこちらもアリかも?
デスクトップ版は機能制限ありの個人利用なら無料、フル機能が使えるバージョンは個人開発者なら年136ドル、企業なら年412ドルかかります。Oracle VM VirtualBox上で動くみたい。
ドキュメントを眺めてみましたがどのバージョンまで対応しているかは掴めず、8月頃に書かれたブログを見るにGenymotionのバージョン2.9だとAndroid7.xまで使えるようでした。
また、マニュアルには「arm64は対応していない」との記述もあり、64ビットのARMをテストするのは難しいかも。また、ARMv7でも別途ARM翻訳ツールが必要だったりと多少の操作は必要なようです。(ARM翻訳ツールは権利関係の問題でGenymotionが直接配布できない) ただし、PaaSの環境では翻訳なしでそのままARMのデバイスが使える機能もベータ版として出てきたようなので、翻訳の問題は今後気にしなくても良くなるかもしれません。
クラウドで実機テスト
ネットワークを介してAndroidの実機を操作してテストする方法です。上で紹介したのはエミュレータですが、こちらは実際のデバイスである点が異なります。
リモートで実機を操作した結果を私たちのPCに表示するサービスがいくつかあります。
例えばAmazonがやっている「AWS Device Farm」が代表的です。AWSクラウドでホストされている実機デバイスに対してブラウザでアクセスして操作することができます。また、複数のデバイスで自動テストすることもできるので、端末依存のバグなども拾いやすくなると思います。AndroidとiOSの端末双方が用意されているのがグッド。
自動テストといえばFirebaseのTestLabもそうですね。Google社のサービスですが、AndroidとiOSの両方でテストできます。
複数の端末で自動テストができるのはかなりありがたい点です。例えばアプリをアップデートした際、既存の機能に影響を与えていないかのリグレッションテストを手動でやるのは本当にきついので、自動で一気に確認できるのはかなり負担が減ります。ただ自動テストは自分でテストを作る必要があるので、その部分は工数かかるかもしれません。もちろんそれに見合うリターンはあります。
使った分だけ課金される方式なので、デバイスを複数買うよりは安く済むと思います。無料枠もついているので料金表を要チェック。
実機をレンタルする
スマホをレンタルして実機で確認するパターン。例えば「ケータイラボ」などでしょうか。会社が運営している検証センターに行ったり、端末を家まで送ってもらったりして実機をつないで確認する方法です。
検証センターにいく場合は東京にいるならアリかもしれません。うちのような地方デベロッパーだと端末を送ってもらう形になりますが送料がいい感じの値段になります。検証センター、社外貸し出し共に、1回あたり9000円というのもなかなか辛いところが。おそらく企業向けのサービスなので個人で使うものではなさそうです。(個人向けにはやってませんと書いてあるところも)
クラウドが現実的かな……?
実機がベストではありますが、クラウドでテストするのが現実的な路線でしょうか。自分で操作するなら「AWS Device Farm」を使って、自動テストを作る場合はFirebaseのTest Labも便利ですね。
お金がかかる点はやむなしで、そこは端末課金よりはマシかなーと思います。
まとめ
自分の考えをまとめるつもりが長文になってしまいました。
Unity2019.3以降はAndroidビルドにおいてx86のアーキテクチャをターゲットとすることはできなくなったので、Android Studioのエミュレータで確認することはできなくなりました。残念。
代替の手段としては実機がベストであるものの個人開発者にとって複数の端末を揃えるのは負荷が大きいので、「AWS Device Farm」や「Firebase TestLab」といったクラウドで実機を操作、あるいは自動テストをするサービスもあるのでこちらを織り交ぜるのが良さそうですね。
ゲーム開発の攻略チャートを作りました!
-
前の記事
【第29回Ex】作成したゲームをAndroid向けにビルドするUnityチュートリアル 2020.12.16
-
次の記事
メンタルの状態に応じて取り入れる言葉を変えることも必要【ゲーム開発】 2020.12.18
I’m sorry to hear that. I still use Android Studio on my PC.