ticktakclockの日記

技術ポエムを綴ったりします。GitHub idも同じです (@ticktakclock)

minSdkVersionを19->23にする時に考慮したこと

Android

こんにちは、tkyです。

私が業務で担当しているAndroidのアプリサポートバージョンをAPI19->23に引き上げました。

すでにリリースから数ヶ月経過しましたが、その時にやったことなどをまとめたいと思います。

OSの分布を知る

  • 世界的なOS分布 developer.android.com

  • プロダクトのOS分布

    アナリティクスツールなどで確認

切りたいバージョンのユーザーが何％行っていたら切るか、というのは社内でもそこまで定まっておらず、他の会社で採用している5%や3%などといった数値を参考に踏み切りました。

ちなみに5系以下は全体の6%でした。そこそこいました。

社内に持ちかけ

POと話す機会は何回かあり、以前より

  • 古いOSVerでWebViewの表示不正やクラッシュがある
  • 特定の動画フォーマットが再生できない

などの問題が起こっていたことと、たまたまOSサポートバージョンの話になった時に「やりましょう」という流れになりました。

開発しやすくなるなら、という目線で快く進める方向になったのは一番大きいです。

（正直意思決定権を持つ人が納得してくれるかがサポートバージョンを上げる最難関ポイントだと思っています）

クリティカルな不具合は直しておく

目に見えてわかっている不具合は予め対応しておきましょう。後に修正できても古いOSを持つユーザーにはそれは届きません。

minsdkversionを23に引き上げる

単純にapp.gradleの記述を返るだけです。

- minSdkVersion 19
+ minSdkVersion 23

MultiDexサポートライブリは不要に

minSdkVersion が 21未満の場合、64k制限のためにMultidexオプションを付けることがありますが、

minSdkVersion が 21 以上の場合は multidex がデフォルトで有効のため、multidex サポートライブラリは必要ありません。

ApplicationクラスやGradleにmultidex関連の処理を書いている場合削除しておきましょう。

VERSION分岐コードの精査

例えば以下のようなコードがプロジェクト内に存在するとします。

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
    // lollipop以上でしか使えないAPIを使用するコード
    doSomething()
} else {
   // lollipop未満の場合はこちらを使う
    doSomethingLegacy()
}

minSdkVersionが23になる場合、lollipop未満の条件に当てはまることが無いので

doSomething()

だけで問題ないことになります。条件が if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) であっても同様ですね。

このように VERSION_CODES でGrepをかけて削除できそうな箇所を探してリファクタリングしていきました。 Marshmallowでランタイムパーミッションなどが入っているでこういった条件分岐を書いたりしている箇所があるかもしれません。自身のプロジェクト内を探してみてください。

動作確認で何をしたか

特に何もしていませんが、検証端末に5系端末を使っていたので念の為インストール出来ないよね、という確認はしました。

次回からはこの端末もお役御免という形になりました。ありがとう。

ユーザーに事前に通知すること

運用面で考慮したことですが、事前にOSのサポートが終了となる旨をユーザーにお伝えしなければびっくりしてしまいますよね。

そのため直前のバージョンを以てサポートを終了とする旨をお知らせページなどで通知するようにしました。

ユーザーはアプデできないということを意識する

当たり前ですが、5系を切ると5系を使っているユーザーは最新Verにアプデができなくなります。

サーバーレベルでサポートを切るかどうかは別の話で、今回はアプリをアプデできないもののサービスは引き続き利用できる状態としました。

アプリ起動時「新しいバージョンのアプリがあります。アップデートしてください」というようなアプデを促すダイアログを出しているアプリは多いでしょう。

ただし5系ユーザーにこのダイアログを出すとPlay Storeに行っても勿論最新アプリはないので混乱を招いてしまいます。

実際にアプデが入ったときのユーザーの行動を事前に予測しておくことが大事だと思いました。

リリース後に起こった問題について

  • 間違ったAPIを消していた

WebViewのとあるメソッドで、TARGETがLOLLIPOPのメソッドがあったのでそもそも使われることが無いだろうというので消したコードが実はMASHMALLOW以下のメソッドだった。。

WebViewに手を入れるときは全OSバージョンチェックしたほうが良いな・・・と改めて反省・・・

まとめ

  • OSサポートバージョンを23に引き上げた
  • これでWebView関連の不具合に当たることも少なくなるといいな
  • 他にもこんなことを考慮した、みたいなのがあればぜひ教えていただきたい