パーミッションシステムの仕様変更がAPI≧30で行われています。
(1)1回だけアクセス許可
(2)“今後表示しない”の非表示
(3)アプリの休止
ここでは、「(1)1回だけアクセス許可」について説明します。
パーミッションシステムの仕様変更がAPI≧30で行われています。
(1)1回だけアクセス許可
(2)“今後表示しない”の非表示
(3)アプリの休止
ここでは、「(1)1回だけアクセス許可」について説明します。
Android Emulator(AVD:Android Vertual Device)は、Play Storeアプリを実装したデバイスの構築が可能です。
このデバイスを用いれば、Google Playストアへ公開されているアプリをインストールしたり、アップデートしたり、エミュレータ上で出来るようになります。一般に販売されているAndroid端末と変わりません。
変わらないが故に、セキュリティに対して同等なリスクを持つことになります。
ですので、「デバイスの構築とエミュレータの起動は必要最小限にする」、「完全に信頼できるアプリのみインストールする」など、取り扱いに注意が必要です。
今回はAndroid EmulatorでPlay Storeアプリを使う方法をまとめます。
デバイスの構築を行う前に、Play Storeアプリを実装したシステムイメージが必要です。
SDK Managerでインストールを行います。
図に示したイメージがPaly Storeアプリを実装しています。チェックを付ければ、インストール対象に登録されます。※図はAPI24の場合、インストール済みの状態
イメージ名の接頭語 | Google Play Servicesの実装 | Play Storeの実装 | コメント |
---|---|---|---|
なし | × | × | |
Google APIs | ○ | × | |
Google Play | ○ | ○ | Intel x86 Atomのみ |
ただし、すべてのプロセッサアーキテクチャに対応していません。対応は「Intel x86 Atom」のみです。
Device Managerを開いてデバイスを構築する際に、Play Store欄にマークの付いたプロファイルを選択してください。
Play Storeアプリを実装したシステムイメージがデバイスへ組み込まれます。
このデバイスでエミュレータを起動すれば、Play Storeアプリが実装されたデバイスがエミュレートされます。
ユーザが作成したプロファイル(または、Play Store欄にマークの付かないプロファイル)を選択して構築したデバイスは、Play Storeアプリが使えません。
Play Storeアプリを実装したシステムイメージが、デバイスへ組み込まれないためです。
しかし、端末の構成ファイルを変更することで、Play Storeアプリを実装したシステムイメージへ置き換えることが出来ます。
端末の構成ファイルconfig.iniを次のように変更します(API24の場合)。
旧:image.sysdir.1=system-images\android-24\google_apis\x86\ 新:image.sysdir.1=system-images\android-24\google_apis_playstore\x86\ ※google_apis,google_apis_playstoreはシステムイメージのインストール先 (Android SDKがインストールされたフォルダの階下に存在)
上記の変更後にエミュレータを再起動すれば、Play Storeアプリが実装されたデバイスがエミュレートされます。
エミュレータ上でPlay Storeアプリを使用するためには、Googleへログインが必要です。
Play Storeの初回の起動で、正式なアカウントを使ったログインが求められます。
アプリのインストールやアップデートは、このログイン後に可能です。
エミュレータ上でPlay Storeアプリが使用できる利点は、Google Play Servicesのアップデートが行える点です。
Google Play Servicesとは、Googleが提供するサービスとアプリ間の仲介役を担うシステムアプリ(プログラム)です。
Googleのサービスを利用する時に必須なプログラムのため、端末へプリインストールされています。
一般のアプリと同様に、Google Playストアからアップデート(インストール)できるようになっており、古いAndroid端末であっても最新のバージョンがストアから提供されます。
つまり、端末の新旧を問わずに最新の機能(または、バグ修正済みの機能)が使えるということです。同様なことがエミュレータ上でもいえます。
関連記事:
Runtime(Dangerous)Permissionの取得方法についてまとめます。
現在、Runtime Permissoinの取得方法は2つあります。
ここで紹介するのは、ActivityResultContracts(※)を使う方法です。
この方法は、リクエスト(Permissionの申請)と結果を受け取る専用のコールバックが1対1に対応しています。ですので、複数のリクエストを行っても、RequestCodeによる分岐処理は必要ありません。システムが結果を各コールバックへ割り振ってくれます。
つまり、「システムがリクエストを管理」してくれます。
ドキュメントで推奨されている方法です。
Permissionの詳細は「Permissionとその一覧」を参照してください。
※ライブラリandroidx.activity:activity≧1.20が必要
Runtime(Dangerous)Permissionの取得方法についてまとめます。
現在、Runtime Permissoinの取得方法は2つあります。
ここで紹介するのはRuntime Permission(API≧23)が登場した当初から存在している方法です。
この方法は、リクエスト(Permissionの申請)の結果を共用のコールバックAppCompatActivity#onRequestPermissionsResult( )で受け取ります。複数のリクエスト行うと、複数の結果を一つのコールバックで受けることになり、コールバック内でRequestCodeによる分岐が必要になります。
つまり、「開発者がリクエストを管理」しなければなりません。
Permissionの詳細は「Permissionとその一覧」を参照してください。