【Android】初めて個人アプリをリリースした話 トラブル編
はじめに
前回の記事ではバスの時刻表アプリに使った技術の話をしました。
今回はリリース時に遭遇したトラブルの話を書こうと思います。
アプリをストアにアップロード！そして…
実は私は、業務でもまだアプリのリリース対応をやったことがありませんでした。
次々にあらわれる入力項目に四苦八苦しながら、いったんアルファ版でリリースしてみようとapk（アプリのバイナリ）をアップロードしました。
そして現れる「審査中です」の文字。
あ、アルファ版でも審査入るんだ…と思いながらいったん待ちの状態に入りました。
数時間後、こんなメールが届いているのに気がつきました。
（バスアプリには、クラッシュなどが発生したときに自動的に報告されるように Firebase Crashlytics を入れていました）
…えっ？
いや、今日アプリ触ってないですけど…
とりあえず詳細見てみるか
ヒエッ！
クラッシュしとる…
しかも自分ひとりしか触ってないのに2名のユーザー…？
なにこれこわい！
そう思いながらも、その日は触る時間がなく、不安に思いながらもそのまま就寝しました。
そして翌日、またFirebaseからメールが…
😇
もはやパニックです。
身に覚えのない大量のクラッシュ、しかも誰も触ってないはずなのに6名のユーザーからの報告…
そのうえ、手元の端末では全然クラッシュが再現しません。
もしやどこからか情報が漏れた？ハックされた？いやいやこんな何のユーザー登録もないアプリハックする意味ないしリリースしてないんだから誰も知らんだろ…などと考えを巡らせたあと、1つの可能性に気づきました。
そういえば、ストアにapkアップロードしたな…
Play Consoleのリリース前レポート
慌てて Play Console を見に行ったところ、「リリース前レポート」という項目がメニューに存在することに気づきました。
これは Play Console にアプリの apk をアップロードすることにより、Google がデータセンターに所持している端末を用いて自動的にテストを行ってくれるという非常に便利なサービスです。
ここを開くと、ありました。クラッシュレポートが。
Crash java.lang.RuntimeException: Unable to start activity ComponentInfo(...)
android.view.InflateException: Binary XML file line #9: Binary XML file line #9:
Error inflating class androidx.fragment.app.FragmentContainerViewというエラーがずらりと並んでいました。
どうやら起動直後にクラッシュしているようです。
つまり、リリース前レポートで自動的にテストが行われたことによりアプリがクラッシュ、そのレポートが Crashlytics に送られていたのでした。
クラッシュの原因と対応
結論から言えば、原因はStackOverflowの以下の記事と同じでした。
Navigation ライブラリの2.2.2からリリースビルドでのみクラッシュが起きるようになったようで、回避策としては、proguard-rules.pro に
-keep class androidx.navigation.fragment.NavHostFragmentという文言を追加してあげることでクラッシュしなくなるようです。
※私は上記記事を見つける前に、とりあえず Fragment のコンテナに FragmentContainerView を使うのをやめて fragment に差し替えることで対処してしまいました。
こうして私はクラッシュを解消し、再度ストアにアプリをアップロードして今度は何事もなく審査を通過、念願の初リリース作業を完遂させたのでした。
余談：リリース前レポート便利だよという話
さて、初っ端から大量のクラッシュレポートを送りつけて筆者を恐怖のどん底に陥れたリリース前レポートくんですが、落ち着いて触ってみるとなかなか便利なサービスです。
上記のような感じで自動的にさまざまな端末での解析レポートを送ってくれて、クラッシュ以外でも例えば以下のような警告を出してくれます。
- サポート対象外のAPIを利用している件数
（導入しているライブラリが利用している場合も警告される）
- パフォーマンスの問題が発生している端末の名称とその動作ログ
（動画やCPU、メモリ使用量のグラフなど）
- 既知の脆弱性が含まれている件数
- アクセシビリティに問題が発生している箇所（タップ領域が狭いなど）
例えばパフォーマンスのログは以下のような感じで表示され、追加料金などかからない割に、かなり情報量が豊富です。
検証端末をあまり数多く用意できない場合でも、簡易的な検査なら上記でもやってくれるので、少し安心できます。
おわりに
今回は個人アプリ初リリース時に遭遇したトラブルについて書きました。
実務上でも一度あったんですが、デバッグビルドでは正常に動くのにリリースビルドにするとクラッシュするという事例はたまにあります。
これが本当に曲者で、開発者はたいていデバッグビルドで確認するため、下手をするとアプリを公開してからクラッシュすることに気づく😇という最悪のパターンもあり得ます…
今回は「リリース前レポート」が事前にカバーしてくれた形ですね。
ちなみにリリースビルドだけでクラッシュが発生する場合、アプリの難読化（今回の場合はProGuard）が悪さしている場合が多いっぽいので、そのあたりを疑う癖を付けておくのがいいかもしれません。
最後まで読んでくださり、ありがとうございました。
この記事が気に入ったらサポートをしてみませんか？