端末やエミュレータのAndroidバージョン名がすぐに分からず戸惑っていませんか。
この記事を読むと実機とエミュレータ双方で確実にバージョン名を確認できるようになり、APIレベルとの対応やデバッグ時の判断が素早くできるようになります。
| 項目 | 内容 |
|---|---|
| 見つけ方 | 設定画面とadbコマンドの両方で確実に確認する手順を図とともに示します。 |
| 活用ポイント | バージョン名とAPIレベルの対応の見方や条件分岐の書き方を実例でわかりやすく紹介します。 |
| トラブル対処 | エミュレータが古い場合の更新方法や端末表示が期待通りでないときの現場で使える対処法を共有します。 |
順を追って手順と実践的なコツを解説しますので、実際の作業中にすぐ使える知識が手に入ります。
Android博士安心して読み進めてくださいね、ちょっとしたコツを知るだけでバージョン確認がぐっと楽になりますよ。
Androidで端末やエミュレータのAndroidバージョン名を確認する方法
端末やエミュレータのAndroidバージョン名を確認する方法は複数あります。コマンドで素早く確認したいときはadbが便利で、GUIで見たいときはAndroid Studioのエミュレータや端末の設定画面が助けになります。
どの方法を選ぶかは目的次第です。開発中にスクリプトで使うならadbでの取得がおすすめで、ちょっとした確認だけならエミュレータ画面や設定を見るだけで十分です。
- Macのターミナル＋adbで実機のバージョンを取得する方法。
- Android Studioのエミュレータでイメージや端末情報を確認する方法。
- 実機の設定画面で手軽にバージョン名を見る方法。
Android博士最初はどれを使えばいいか迷いやすいですが、すぐ確認したければGUI、繰り返しや自動化が必要ならadbをまず覚えると作業がぐっと楽になりますよ。
Macのターミナルとadbで実機のバージョン名を確認するパターン
Macのターミナルでadbを使う方法は、開発者にとって一番手早く正確にバージョンを取れる手段です。事前にAndroid Platform Toolsがインストールされていて、実機でUSBデバッグが有効になっている必要があります。
接続確認としてadb devicesを実行し、認識されていればadb shellで端末に入れます。複数端末があるときはデバイスIDを指定すると確実に目的の端末から情報を取れます。
adb devicesで接続を確認してadb shell getprop ro.build.version.releaseを実行する手順
Macのターミナルでadb devicesを実行して端末が一覧にあるか確認します。unauthorizedなら端末側で許可をタップしてください。
adb -s <デバイスID> shell getprop ro.build.version.releaseを実行してリリースバージョンを確認します。APIレベルが必要ならro.build.version.sdkも確認します。
複数端末対応はadb -sでIDを指定するか、最初にadb devicesでIDを取り自動で処理するシェルスクリプトにまとめると便利です。
Android Studioのエミュレータでバージョン名を確認するパターン
Android Studioのエミュレータでは、AVD ManagerでイメージのAndroidバージョンが一覧表示されています。エミュレータを起動せずにどのAPIレベルのイメージかをすばやく確認できます。
実際に起動して詳しく見たいときはエミュレータの画面右上の三点メニューからExtended controlsを開き、端末情報を確認するとOSのリリース名がわかります。
AVD ManagerでイメージのAndroidバージョンを確認してエミュレータ設定の端末情報を見る手順
Android StudioのAVD Managerを開き、TargetやAndroid Versionの列でイメージ名とAPIレベルを確認します。エディットで詳細が見られます。
対象のエミュレータを起動し、画面右上の三点メニューからExtended controls→SettingsまたはAbout emulated deviceでリリース情報を確認します。
起動中のエミュレータに対してadb -s emulator-5554 shell getprop ro.build.version.releaseを実行すると確実にバージョンが取れます。
Androidアプリのコードでバージョン名とAPIレベルを対応付けする方法
アプリのコード内でバージョン名とAPIレベルをきちんと対応付けると、古い端末向けの回避処理や新機能の安全な呼び出しが安心して行えます。ここでは現場でよく使う実践的な方法をやさしく紹介します。
大まかな選択肢は複数ありますが、実行時にAPIを判定して振り分ける方法と、ビルド時にflavorなどで別ビルドを作る方法が中心です。それぞれ場面に合わせて使い分けると効率よく対応できます。
- 実行時チェック：Build.VERSION.SDK_INTとBuild.VERSION_CODESで条件分岐し互換処理を行う手法。
- ビルド時分岐：appレベルのGradleでminSdkVersionやtargetSdkVersionをflavorで分けて別APKを作る手法。
- 混合運用：ランタイムチェックを基本に、パフォーマンスや依存関係が厳しい部分だけflavorで切り分ける手法。
アプリ実行時にAPIレベルで処理を分けるパターン
実行時にAPIレベルで処理を切るときはBuild.VERSION.SDK_INTを使います。具体的にはBuild.VERSION.SDK_INT>=Build.VERSION_CODES.XXXのように比較して、新APIを安全に呼び出すようにします。
チェックはUIやActivityの中に直書きせず、ユーティリティ関数にまとめると見通しが良くなります。テスト時には古いエミュレータで必ず動作を確認すると安心です。
Build.VERSION.SDK_INTで条件分岐して互換処理を行うコードの書き方と配置場所
if(Build.VERSION.SDK_INT>=Build.VERSION_CODES.S){ //新APIの処理 }else{ //互換処理 }の形で分岐します。
互換処理はHelperクラスやCompatクラスにまとめて、ActivityやFragmentから呼び出す形にすると保守しやすくなります。
条件を散らかさないことと、APIレベルだけでなく権限やライブラリの挙動差も意識してチェックすることが大切です。
Gradle設定でバージョンに合わせたビルドを作るパターン
Gradleでバージョン毎のビルドを作るときはproductFlavorsやbuildTypesを活用します。minSdkVersionやtargetSdkVersionをflavorごとに設定すると、端末向けに最適化されたAPKを用意できます。
ソースセットをflavor別に分けて差分だけを置くと重複が減ります。compileSdkVersionは統一しておき、テストやCIで各フレーバーのビルドを確認すると安心です。
appレベルのbuild.gradleでminSdkVersionとtargetSdkVersionを設定しflavorで分ける手順
androidブロック内にあるdefaultConfigのminSdkVersionとtargetSdkVersionを確認します。ここで基準となる値を決めます。
flavorごとにminSdkVersionとtargetSdkVersionを上書き設定します。例：productFlavors{legacy{minSdkVersion 21}modern{minSdkVersion 26}}。
src/legacyやsrc/modernのようにソースセットを作り、API依存の実装だけを分けて置きます。共通はmainに残します。
AndroidStudioやCIで各flavorのビルドとテストを必ず回し、リリース前に実機やエミュレータで動作を確認します。
Androidのバージョン名を使って互換性問題を見つけて修正する方法
Androidのバージョン名を手がかりにバグを追うと、原因のあたりがぐっと速くなります。端末やエミュレータで同じバージョンを再現して挙動を比べると、どのAPIや実装差が絡んでいるかが見えてきます。
ここでは現場でよく使う実践的なアプローチを並べます。状況に応じて組み合わせると、再現と修正がとても楽になります。
- 特定バージョンのエミュレータで再現してLogcatとスクリーンショットを比べる。
- バージョン別の機能フラグや条件分岐で挙動を切り分ける。
- 外部ライブラリのバージョン差をチェックしてライブラリ更新で検証する。
- ユーザー報告の端末情報から優先度を決めてCIで重点的に走らせる。
特定バージョンでの挙動差を再現して原因を特定するパターン
まずは再現性を固めることが肝心です。どのバージョンで必ず起きるかをログやスクショで確定すると、原因の範囲がぐっと狭まります。
- 差分を最小化して再現する。不要な設定やプラグインは外して試す。
- 機能フラグでオンオフを切り分けて挙動の起点を探る。
- プロガード設定やマルチDexの影響をチェックする。
- ログを詳細に取って例外箇所と前後の状態を突き合わせる。
特定のAPIレベルを持つエミュレータで操作を再現しLogcatで例外とスタックを絞る手順
AVDManagerで対象のAPIレベルのエミュレータを作成する。GooglePlayの有無は実端末と揃えると良い。
adbやuiautomatorで同じ操作をスクリプト化し、実行ごとにLogcatをクリアしてから走らせる。
タグとプロセスIDでフィルタしてスタックトレースを追い、該当クラスや行番号を特定する。
バージョン名を基準にテスト優先度を決めてCIで回すパターン
全パターンを毎回回すと時間がかかるので、バージョン名と利用率を元に優先度を付けます。利用者が多いAPIレベルや過去に問題が出ているバージョンを上位に置くと効率が良いです。
優先度を決めたらCIで上位だけ並列に回す運用が実務向けです。GitHubActionsやFirebaseTestLabを組み合わせると失敗ログの収集が楽になります。
- 高優先: 使用率が高い主要APIレベルを対象にする。
- 中優先: バグ報告が集中するAPIレベルを入れる。
- 低優先: シェアが低い古いバージョンは回数を減らす。
重要なAPIレベルを抽出してテストマトリクスを作りGitHub Actionsなどでマトリクス実行する手順
端末分布とバグ報告を照らし合わせて、テスト対象のAPIレベルを3〜5個に絞る。
workflowでapi_levelのマトリクスを定義し、エミュレータ起動とadb操作をワークフローに組み込む。
マトリクスで並列ジョブを回し、失敗ログをアーティファクトとして保存してチームで共有する。
よくある質問
- 端末でAndroidのバージョン名を簡単に確認するにはどうすればよいですか。
端末の設定アプリを開き「端末情報」や「システム」を確認するとAndroidバージョンの表示が見つかります。機種によっては「Androidバージョン」の項目に表記があり、わかりやすく表示されます。もっと詳しく知りたいときはadbで端末にアクセスしてシステムプロパティを見ると数字や内部情報が確認できます。
- エミュレータでバージョン名を確認する方法はありますか。
Android StudioのAVD Managerで使っている仮想デバイスのイメージ名にバージョン情報が書かれています。エミュレータを起動してから実機と同じく設定アプリの「端末情報」で確認することもできます。開発中はadbでプロパティを確認すると手早く状況を把握できます。
- バージョン名（例:Pie）とバージョン番号やSDK_INTの違いは何ですか。
バージョン名は消費者向けの名称で、バージョン番号やSDK_INTは開発者が条件判断に使う数値です。コードで動作を切り替えるときはBuild.VERSION.SDK_INTの数値比較で行うのが確実です。見た目の名前に頼らず数値で判断する癖をつけるとトラブルが減ります。
- アプリで特定バージョン向けの処理を書くときの注意点は何ですか。
OSのバージョンで分岐するより機能の有無で判定するほうが堅牢です。どうしてもバージョン判定が必要ならSDK_INTを使い、境界の条件（以上/未満）を慎重に設定してください。端末メーカーのカスタマイズで動作が変わることもあるため、実機での確認を忘れないでください。
- バージョン表示がおかしい、または表示されないときはどうすればよいです。
カスタムROMや開発用ビルドだと表示が省略されたり独自表記になることがあります。その場合はadbでro.build.version.releaseやro.build.version.sdkを確認すると確実に数値が取れます。端末がルート化されていると出力が変わることがあるので、状況に応じて複数の方法で確認してください。
まとめ
まとめとして、端末やエミュレータのAndroidバージョン名は設定画面でさっと確認できますし、開発作業ではadbやアプリ側のAPIで手早く取得できます。ここで紹介した手順を使えば、ユーザー向けの見た目情報と開発で必要な内部番号の両方を迷わず取得できます。
実務では状況に応じた使い分けがポイントです。一般的な確認は設定画面、開発や自動化はadbやgetpropによる確認、アプリのランタイム判定はBuild.VERSION.RELEASEとBuild.VERSION.SDK_INTを組み合わせると安定して扱えます。
注意点としてエミュレータと実機で表示や動作が異なること、マーケット表示名と内部のSDK番号は別物であることを覚えておいてください。複数のAPIレベルで実機テストを行い、compileSdkやtargetSdkを最新に保つ習慣がトラブルを減らす近道です。