1
/
5

おいしい健康AndroidアプリのminSDKを21から23へ上げた時にやったこと

こんにちは。おいしい健康Androidエンジニアの小林です。

おいしい健康Androidアプリは、2019年の初回リリース以降〜先月までminSDK21でした。
先月初旬にminSDK23へ上げたのですが、その時にやったことを振り返りたいと思います。

minSDKを上げる理由

2つの大きい理由があります。

1 Android OSバージョンのシェアへの追従

おいしい健康はリリース以降、minSDK 21だったので、Android L(5)の端末まで後方互換性がある状態でした。

Android OS は年々新しいバージョンをリリースしており、ユーザーもどんどん新しいバージョンへ移行していきます。
古いOSバージョンのままのユーザーも一部いますが、日が経つほどの古いバージョンのユーザーは必然的に減少していきます。

2 開発環境の新陳代謝

開発環境はどんどん新しくなっていき、一般的にはモダンな環境の方が開発効率は上がります。
新しいライブラリを導入する時にもminSDKの要件を意識する必要があります。現状は導入したいライブラリがminSDK >= 21であることが多かったので、ブロッカーになることはありませんでしたが、今後要件が上がっていく可能性はあります。
そのときにブロッカーにならないように今のうちからあげていこうという判断をしました。

運用ルールの決定

「minSDKを上げたいよね」というチーム内での感覚の共有はできていましたが、どんなルールに基づいて運用していくかまでは定めていませんでした。
現状のおいしい健康Androidアプリのアクティブユーザー数と他社さまの事例などを参考に、チーム内で話した結果下記の方針に決まりました。

全体のアクティブユーザーの内、シェアが2%以下になったバージョンはサポートを終了する

シェアの調査

シャアの調査はGooglePlayConsole上で行いました。各OSバージョンごとのアクティブユーザー数が確認できます。
調査した日時点で、Android5とAndroid5.1のシェアが2%以下だったのでminSDKを23にすることが決まりました。

(余談ですが、このときおいしい健康Androidアプリでは、Android7よりもAndroid6のシェアの方が高かったです。)

影響範囲の調査

おいしい健康Androidアプリは有償プランがあります。minSDKを上げることにより、有料ユーザーのどれほどが影響を受けるのか事前調査が必要でした。
ログからAndroid5, Android5.1 を利用している有料ユーザーを特定しましたが、対象ユーザーはごく少数でリテンションもあまりないようでした。

サポートとの連携

サポート終了対象のバージョンは事前にユーザーに告知する必要があります。
サポートチームに今回の旨を伝えてAndroid5系のサポート終了告知を掲載してもらようにお願いしました。

告知の掲載から実際のサポート終了日までの期間ですが、今回はおいしい健康Androidアプリで初めての特定バージョンのサポート終了になるため、余裕をもって2ヶ月と定めました。

(2ヶ月先になると忘れそうなので、カレンダーに予定を入れます。)

実際の作業

やることとしては、build.gradleのminSdkVersionの指定値を変更するだけです。

- minSdkVersion 21
+ minSdkVersion 23

大体のアプリUIテストは、GooglePlayConsoleのリリース前レポートにお任せします。
アプリ内課金の購入テストは、手動で確認しました。

リリース後

Crashlyticsの監視やユーザー問い合わせの様子見をしていましたが、minSDKを上げたことによる不具合や問い合わせはありませんでした。
元々の影響範囲が小さいこともありましが、事前調査、事前準備を行なったことで安心感がありました。

最後に

おいしい健康ではAndroidエンジニアの募集をしています。 サービス開発好きな方、ヘルスケア領域に興味のある方、ぜひお気軽にご連絡ください。Androidエンジニアへのスイッチも歓迎しています!

[https://www.wantedly.com/projects/835348:embed:cite]

おいしい健康's job postings
3 Likes
3 Likes

Weekly ranking

Show other rankings
Invitation from おいしい健康
If this story triggered your interest, have a chat with the team?