Androidアプリの対応バージョンを決めたいけれど、公式データだけでは自分のアプリの実情が見えなくて迷っていることが多いはずです。
この記事を読むと、自分のアプリで本当に使われているAndroidバージョンを正しく把握する方法と、その結果を使って現実的なサポート方針を決めるための具体的な手順が身につきます。
| 項目 | 内容 |
|---|---|
| 独自コンテンツ1 | アプリ内データとAnalyticsからバージョン別利用率を取得するための実際の手順をわかりやすく示します。 |
| 独自コンテンツ2 | CrashlyticsやPlayConsoleのデータの見方と、誤解しやすい落とし穴を実例で解説します。 |
| 独自コンテンツ3 | 取得したデータを基にしたサポート切りの判断基準と、minSdkの決め方サンプルを提示します。 |
数字を手元に置けば判断は格段に楽になりますから、まずは簡単なデータの取り方から順にやっていきましょう。
Android博士最初は誰でも不安になりますが、小さく測って少しずつ改善すれば必ず見通しが良くなります。気楽にやっていきましょう。
自分のアプリでAndroidバージョンシェアを正確に調べる方法
自分のアプリでAndroidバージョンシェアを正確に知りたいときは、手元の実データを使うのがいちばん確実です。一般的な公開統計と自分のユーザー構成は違うことが多いので、自分のアプリのデータで判断するのが安全でやさしい方法です。
現実的にはまずPlay Consoleでざっくり傾向を掴み、必要ならFirebaseとBigQueryで深掘りする流れが使いやすいです。Play Consoleは短時間で割合が把握できて、BigQueryは日付やアプリバージョンで細かく切れるのが強みです。
分析のコツは直近の期間を優先して見て、指標はアクティブユーザーやデバイス数を使うことです。まずは30日や90日で様子を見て、問題が見えたらBigQueryで詳細集計に進むと効率が良くなります。
Android博士最初はPlay Consoleで手早く全体を見るだけで十分です。気になる箇所だけBigQueryで掘れば手間が減るので、気楽に進めていきましょう。
GooglePlayConsoleで端末のバージョン構成を確認する方法
Play Consoleで端末のバージョン構成を見るには、対象アプリを選んで『統計』画面を開きます。デフォルトでは指標がたくさん出るので、ディメンションでAndroidバージョンを選ぶと見やすくなります。
期間は直近30日や90日を試して傾向を掴んでください。国やアプリバージョンで絞れるので、特定のユーザー層でどう分布しているかも確認できます。
PlayConsoleで対象アプリを開き統計を選ぶ
Play Consoleにログインし、調べたいアプリの行をクリックしてダッシュボードを開きます。
左側メニューの『統計』をクリックして統計ダッシュボードに移動します。
表示される指標を必要なものに絞って、画面を見やすく整えます。
ディメンションでAndroidバージョンを選び期間と指標を設定してCSVで保存する
統計画面のディメンション選択から『Androidバージョン』を選択してバージョンごとの行を表示します。
期間は30日や90日を選び、指標はアクティブユーザーやデバイス数を選択して偏りを見ます。
国やアプリバージョンで絞ったら画面右上のエクスポートからCSVで保存してオフラインで確認します。
FirebaseとBigQueryで細かくバージョンを集計する方法
FirebaseとBigQueryを連携すると、Analyticsの生データをSQLで自由に集計できるようになります。イベントデータには端末情報が入っており、os_versionなどの項目を集計して細かい分布を出せます。
BigQueryなら日付やアプリバージョン、地域で絞って割合を算出できます。少数派のバージョンや古いOSの挙動まで追えるので、対応範囲を決める判断材料が揃います。
FirebaseコンソールでBigQuery連携が有効か確認する
Firebaseコンソールにログインして対象のプロジェクトを開きます。
プロジェクト設定の『統合』タブを開き、BigQueryが有効になっているかとデータセットが作成されているかを確認します。
BigQueryでos_versionを集計するクエリを実行し割合を算出する
eventsテーブルやanalytics_テーブルのdevice.os_versionまたはos_version列を使い、SELECT COALESCE(NULLIF(os_version,”),’unknown’) AS os_version, COUNT(*) AS cnt FROM `project.dataset.events_*` WHERE event_date BETWEEN ‘YYYYMMDD’ AND ‘YYYYMMDD’ GROUP BY os_version ORDER BY cnt DESC のような集計を行います。
総数を別途算出して割合を計算するか、ウィンドウ関数でSUM(cnt) OVER()を使ってROUND(cnt/SUM(cnt) OVER()*100,2)で比率を出して上位を確認します。
外部統計で市場全体のAndroidバージョンシェアをつかむ方法
外部統計を使うと、自分のアプリが狙う国や端末でどのAndroidバージョンが多いかを把握できます。公開されているシェア統計サイトは実際の端末ログを持つ必要がないため手軽に使えます。実際の手順としては後でStatCounterを使ったやり方を紹介します。
おすすめはいくつかのデータソースを見ることです。サイトごとに計測方法が違って偏りが出ることがあるので、複数の傾向を見て判断すると安心できます。傾向をつかめば優先対応を決めやすくなります。
- StatCounter: 国別や期間別で幅広くシェアが見られるためまず使いやすい。
- DeviceAtlas: 実機に近い装置情報が多く端末レベルの分布を確認できる。
- AppBrain: 端末トレンドや古いバージョンの残存率を把握するのに便利。
Android博士市場の数値にはノイズがあるけれど、傾向をつかめば対応の目安には十分使えます。焦らずゆっくり数字を拾っていきましょう。
StatCounterで国別や期間別の傾向を確認する方法
StatCounterは国別や期間で端末やOSのシェアが見られて便利です。画面上部で国と期間を選び、PlatformやOSの分類からAndroidのバージョン表示を選んでください。
短い期間はばらつきが出やすいので3ヶ月や6ヶ月の範囲で傾向を見ると良いです。モバイルに限定して確認すると実際のスマホ利用者の状況に近いデータが得られます。
StatCounterで対象国と期間を選びOSバージョンのグラフをダウンロードする
画面上部の国選択で調べたい国を指定し、期間は直近3ヶ月や6ヶ月などトレンドが分かる範囲を選んでください。
表示項目でPlatformやOperating Systemを選び、さらにAndroidのバージョン表示に切り替えてモバイルに限定してください。
グラフ下のダウンロードやエクスポートメニューから画像やCSVで保存できます。必要ならローカルで整理して自分のアプリ向けにまとめてください。
取得したシェアをもとにサポート範囲と機能対応を決める方法
取得したシェアは単なる数字ではなく大事な意思決定の材料になります。ユーザーがどのAndroidバージョンを使っているかでサポート範囲や優先する機能が変わります。
まずはシェアをいくつかのカテゴリに分けて割合を把握すると見落としが減ります。たとえば最新と直近旧バージョンと古い端末の3つに分けて優先度を決めると方針が定まりやすいです。
具体的には累積カバー率とクラッシュデータを組み合わせてminSdkやサポート対象を決めます。コストとユーザーの恩恵を見比べて柔軟に対応するのが現場でうまくいくコツです。
最低APIレベルを決めてサポート対象を確定する方法
最低APIレベルはユーザーカバーと開発コストの交差点です。狙う累積カバー率を決めてそこに到達する最も低いAPIレベルを選びます。
スプレッドシートにバージョンとシェアを並べて上から累積するのがいちばん手早いです。クラッシュ率や利用される重要APIの有無も合わせて判断してください。
シェアデータをスプレッドシートに貼り累積カバー率で目標を決めminSdkを設定する
シェア表をスプレッドシートに貼りバージョン別の列を作る。パーセンテージは数値に直す。
上位から累積パーセンテージを計算して目標カバー率に到達する行を探す。たとえば90%や95%を目安にする。
到達した行のAndroidバージョンをminSdkに設定し影響範囲を洗い出す。優先度の低い機能は後回しにします。
バージョンごとに機能を分けて実装する方法
機能をバージョンごとに分けると安全に新機能を広げられます。コア機能は選んだ最低APIに合わせて実装し高度な機能は条件付きで有効化します。
実装を抽象化してインターフェースで切ると差し替えが楽になります。ユーザー層やフィーチャフラグで段階的に展開するのが現場でよく使われる方法です。
コードでBuild.VERSION.SDK_INTを使って分岐し代替実装を用意してテストする
- APIチェック例:if(Build.VERSION.SDK_INT>=Build.VERSION_CODES.S){新機能();}else{代替処理();}
- 代替実装は小さな関数に分けて差し替えやすくする。
- エミュレータや実機でOSごとに動作確認を行いログで挙動を確認する。
- フィーチャフラグやログで段階的に本番へ広げると安全です。
よくある質問
- Androidのバージョンシェアはどこで調べればいいですか
まず自分のアプリの実ユーザーデータがいちばん頼れます。Google Play ConsoleやFirebaseのBigQueryエクスポートで端末やAPIレベルごとの分布を確認してください。公開されている統計は参考値として使うと良いです。
- 自分のアプリで正確に集めるにはどうすればいいですか
Analyticsやクラッシュレポートにandroid.os.Build.VERSION.SDK_INTを載せて集計してください。Firebaseを使えばBigQueryで柔軟に集計できるので、アクティブユーザー期間や地域で絞り込むと実態に近づきます。
- minSdkVersionはどう決めればいいですか
まずユーザーのボリュームを見てサポートコストと天秤にかけてください。目安として利用率がとても低く保守コストが高いAPIレベルは切りやすいですが、主要市場の割合は重視してください。
- どの範囲でテストすれば安心ですか
ユーザーが多いAPIレベルと最新の主要バージョン、それに片手で触る代表端末を優先してください。Firebase Test Labや実機クラウドで自動テストを回すと効率よくカバーできます。
- 古いバージョンで問題が出たときはどう対応すればいいですか
まずはクラッシュの原因と影響範囲をログで確認してください。機能フラグで段階的にロールアウトしたり、代替処理で安全に動かすと被害を抑えられます。その後ユーザー割合を見てサポート継続を判断してください。
まとめ
まずは自分のアプリで実際に使われているAndroidバージョンを調べてください。FirebaseやPlay Console、あるいは自前のアクセス解析でアクティブユーザー比率とクラッシュ発生率を確認します。端末や地域ごとの傾向を見れば判断がぐっと楽になります。
判断基準はシンプルに決めると迷わず進めます。たとえば利用率が1%未満でバグ対応やテストの手間が掛かるならサポートを外すことを考えます。セキュリティパッチや使っているライブラリの対応状況も忘れずに確認してください。
実装は条件分岐や機能フラグで段階的に切り離すと安全です。テストは実機とエミュレータ両方で行い、リリース後は影響をしっかりモニタリングしましょう。迷ったらまずは限定公開で様子を見るのが現場ではやりやすいです。