アプリの権限をリクエストする

すべての Android アプリは、アクセスが制限されたサンドボックス内で実行されます。アプリ自体のサンドボックスの外部にあるリソースや情報を使用する必要がある場合は、権限を宣言し、このアクセスを提供する権限リクエストを設定できます。この手順は、権限を使用するためのワークフローの一部です。

危険な権限を宣言し、Android 6.0（API レベル 23）以降を搭載しているデバイスにアプリがインストールされている場合は、このガイドの手順に従って実行時に危険な権限をリクエストする必要があります。

危険な権限を宣言していない場合、または Android 5.1（API レベル 22）以前を搭載しているデバイスにアプリがインストールされている場合は、権限が自動的に付与されるため、このページの残りの手順を完了する必要はありません。

基本方針

実行時に権限をリクエストする際に適用される基本方針は次のとおりです。

  • 権限を必要とする機能をユーザーが操作し始めたら、その状況に応じた権限をリクエストすること。
  • ユーザーをブロックしないこと。権限に関連した説明を表示する UI フローは、常にキャンセルできるようにしてください。
  • 機能に必要な権限をユーザーが拒否または取り消した場合は、グレースフル デグラデーションを行いアプリの使用を続けられるようにすること。その際、権限を必要とする機能が無効になる場合もあります。
  • システム動作を前提としないこと。たとえば、すべての権限が同じ権限グループにあるとは限りません。権限グループが役立つのは、アプリが密接に関連する権限をリクエストしたときに、ユーザーに表示されるシステム ダイアログの数を最小限に抑えられることだけです。

権限をリクエストする場合のワークフロー

アプリで実行時の権限を宣言してリクエストする前に、アプリでその権限が必要かどうかを検討してください。権限の宣言を必要とすることなく、写真の撮影、メディア再生の一時停止、関連性の高い広告の掲載など、アプリのさまざまなユースケースに対応できます。

アプリで実行時の権限を宣言してリクエストする必要があると判断した場合は、次の手順を行ってください。

  1. アプリのマニフェスト ファイル内で、アプリがリクエストする必要がある権限を宣言します。
  2. アプリの特定のアクションが特定の実行時の権限に関連付けられるようアプリの UX を設計します。アプリが非公開のユーザーデータにアクセスするための権限の付与がどのアクションで必要となるかをユーザーが認識できるようにします。
  3. 特定の非公開のユーザーデータへのアクセスを必要とするアプリ内のタスクやアクションをユーザーが起動するまで待ちます。ユーザーが起動した時点で、アプリはそのデータへのアクセスに必要となる実行時の権限をリクエストできます。

  4. アプリが必要とする実行時の権限をユーザーがすでに付与しているかどうかを確認します。すでに付与している場合、アプリは非公開のユーザーデータにアクセスできます。付与されていない場合は、次のステップに進みます。

    権限を必要とする操作を実行するたびに、その権限の有無を確認する必要があります。

  5. アプリがユーザーに根拠を示す必要があるかどうかを確認します。この根拠によって、特定の実行時の権限を付与してもらう必要がある理由を説明します。アプリが根拠を示す必要がないとシステムで判断された場合は、UI 要素を表示せずに、直接次のステップに進みます。

    ただし、アプリが根拠を示す必要があるとシステムで判断された場合は、UI 要素でその根拠をユーザーに提示します。この根拠によって、アプリがアクセスしようとしているデータと、実行時の権限を付与した場合にアプリからユーザーにもたらされるメリットを明確に説明する必要があります。ユーザーが根拠を確認したら、次のステップに進みます。

  6. アプリが非公開のユーザーデータにアクセスするために必要な実行時の権限をリクエストします。システムによって、実行時の権限を求めるメッセージが表示されます（権限の概要ページに表示されるメッセージなど）。

  7. ユーザーの応答で、ユーザーが実行時の権限を付与するか、拒否するかを確認します。

  8. ユーザーがアプリに権限を付与した場合は、非公開のユーザーデータにアクセスできます。ユーザーが権限を拒否した場合は、アプリ エクスペリエンスのグレースフル デグラデーションを行って、その権限で保護される情報がなくてもユーザーに機能が提供されるようにします。

図 1 は、このプロセスに関連するワークフローと一連の判断を示します。

図 1. Android で実行時の権限を宣言してリクエストする場合のワークフローを示す図

アプリに権限が付与されているかどうかを確認する

ユーザーがすでに特定の権限をアプリに付与しているかどうかを確認するには、その権限を ContextCompat.checkSelfPermission() メソッドに渡します。このメソッドは、アプリに権限があるかどうかに応じて、PERMISSION_GRANTED または PERMISSION_DENIED のいずれかを返します。

アプリが権限を必要とする理由を説明する

requestPermissions() を呼び出したときにシステムが表示する権限ダイアログでは、アプリが必要とする権限は示されますが、その理由は示されません。そのため、ユーザーが困惑する可能性があります。requestPermissions() を呼び出す前に、アプリが権限を必要とする理由をユーザーに説明することをおすすめします。

調査によると、ユーザーはアプリに権限が必要な理由を知っていると、権限リクエストを快く受け入れるようになることがわかっています。あるユーザー調査では、次の点が指摘されています。

...ユーザーが特定の権限を特定のモバイルアプリに付与するかどうかは、その権限に関連付けられている目的に大きく左右されます。たとえば、ユーザーが位置情報へのアクセスを快く許可するかどうかは、アプリの中核的機能を実現するためにその権限が必要なのか、それとも広告掲載ネットワークや分析会社に位置情報を提供することが目的なのかによって変わります。1

カーネギー メロン大学の Jason Hong 教授は、共同研究の結果に基づいて次のように結論づけています。

...ターゲット広告の場合など、位置情報のような機密性の高い情報をアプリが使用する場合、その理由を知っていると、アプリが位置情報を使用することを知らされただけのときよりも、ユーザーの信頼感は高まります。1

そのため、権限グループに属する API 呼び出しの一部のみを使用している場合は、使用する権限とその権限を使用する理由の明示的なリストを作成することをおすすめします。次に例を示します。

  • おおまかな位置情報のみを使用している場合は、これについて、アプリの説明またはアプリに関するヘルプ記事でユーザーに知らせます。

  • 不正行為からユーザーを保護する認証コードを取得するうえで、SMS メッセージにアクセスする必要がある場合は、その点について、アプリの説明か、アプリがデータに最初にアクセスする必要があるタイミングでユーザーに知らせます。

    注: アプリが Android 8.0（API レベル 26）以降をターゲットとしている場合は、ユーザーの認証情報を確認する一環として READ_SMS 権限をリクエストしないでください。代わりに、createAppSpecificSmsToken() を使用してアプリ固有のトークンを生成し、確認済み SMS メッセージを送信できる別のアプリまたはサービスにそのトークンを渡してください。

特定の状況では、機密性の高いデータへのアクセスをリアルタイムでユーザーに知らせることもおすすめします。たとえば、カメラやマイクにアクセスする場合は、通常、アプリ内の任意の場所に表示される通知アイコンまたは通知トレイ（アプリがバックグラウンドで実行されている場合）を使ってユーザーに知らせることにより、データをひそかに収集しているわけではないことを示すことをおすすめします。

最後に、アプリの機能を動作させるために権限をリクエストする必要があるが、その理由がユーザーに明確ではない場合は、最も機密性の高い権限を必要とする理由をユーザーに知らせる方法を探してください。

ContextCompat.checkSelfPermission() メソッドが PERMISSION_DENIED を返した場合は、shouldShowRequestPermissionRationale() を呼び出します。このメソッドが true を返した場合は、ユーザーに説明 UI を表示します。この UI で、ユーザーが有効にしようとしている機能が特定の権限を必要とする理由を説明します。

さらに、アプリが位置情報、マイク、またはカメラに関連する権限をリクエストする場合は、対象の情報にアプリがアクセスする必要性を説明することを検討してください。

権限をリクエストする

ユーザーに説明 UI を表示した後、または shouldShowRequestPermissionRationale() の戻り値で今回は説明 UI を表示する必要がないことが判明したときは、権限をリクエストします。システム権限ダイアログがユーザーに表示され、アプリに特定の権限を付与するかどうかの選択をユーザーに促します。

従来からある方法では、権限リクエストの一部として開発者自身がリクエスト コードを管理し、このリクエスト コードを権限コールバックのロジックに含めます。別の方法として、AndroidX ライブラリに含まれる RequestPermission コントラクトを使用して、システムに権限リクエスト コードの管理を許可することもできます。RequestPermission コントラクトを使用するとロジックが簡素化されるため、可能な場合は使用することをおすすめします。

システムに権限リクエスト コードの管理を許可する

権限リクエストに関連付けられたリクエスト コードの管理をシステムに許可するには、モジュールの build.gradle ファイルに次のライブラリへの依存関係を追加します。

次のクラスのいずれかを使用できます。

RequestPermission コントラクトを使用する手順を以下に示します。RequestMultiplePermissions コントラクトを使用する手順もこれとほぼ同じです。

  1. アクティビティまたはフラグメントの初期化ロジックで、registerForActivityResult() の呼び出しに ActivityResultCallback の実装を渡します。ActivityResultCallback は、権限リクエストに対するユーザーの応答の処理方法を定義します。

    ActivityResultLauncher 型の戻り値 registerForActivityResult() への参照を保持します。

  2. 必要に応じてシステム権限ダイアログを表示するには、前の手順で保存した ActivityResultLauncher のインスタンスで launch() メソッドを呼び出します。

    launch() が呼び出されると、システム権限ダイアログが表示されます。ユーザーが選択すると、前のステップで定義した ActivityResultCallback の実装が非同期で呼び出されます。

    注: launch() を呼び出したときに表示されるダイアログをアプリでカスタマイズすることはできません。ユーザーに詳細な情報やコンテキストを提供するには、アプリの UI を変更して、アプリの機能に特定の権限が必要な理由をユーザーにわかりやすく説明します。たとえば、機能を有効にするボタンのテキストを変更します。

    また、権限をリクエストするシステム ダイアログのテキストでは、リクエストする権限に関連付けられた権限グループを参照します。この権限グループはシステムを使いやすくするために設計されたものです。アプリでは、権限が特定の権限グループに属しているかどうかに依存するロジックを使用するべきではありません。

次のコード スニペットは、権限に関する応答の処理方法を示しています。

Kotlin

// Register the permissions callback, which handles the user's response to the
// system permissions dialog. Save the return value, an instance of
// ActivityResultLauncher. You can use either a val, as shown in this snippet,
// or a lateinit var in your onAttach() or onCreate() method.
val requestPermissionLauncher =
    registerForActivityResult(RequestPermission()
    ) { isGranted: Boolean ->
        if (isGranted) {
            // Permission is granted. Continue the action or workflow in your
            // app.
        } else {
            // Explain to the user that the feature is unavailable because the
            // features requires a permission that the user has denied. At the
            // same time, respect the user's decision. Don't link to system
            // settings in an effort to convince the user to change their
            // decision.
        }
    }

Java

// Register the permissions callback, which handles the user's response to the
// system permissions dialog. Save the return value, an instance of
// ActivityResultLauncher, as an instance variable.
private ActivityResultLauncher<String> requestPermissionLauncher =
    registerForActivityResult(new RequestPermission(), isGranted -> {
        if (isGranted) {
            // Permission is granted. Continue the action or workflow in your
            // app.
        } else {
            // Explain to the user that the feature is unavailable because the
            // features requires a permission that the user has denied. At the
            // same time, respect the user's decision. Don't link to system
            // settings in an effort to convince the user to change their
            // decision.
        }
    });

このコード スニペットは、権限を確認し、必要に応じてユーザーに権限をリクエストする場合の推奨されるプロセスを示しています。

Kotlin

when {
    ContextCompat.checkSelfPermission(
            CONTEXT,
            Manifest.permission.REQUESTED_PERMISSION
            ) == PackageManager.PERMISSION_GRANTED -> {
        // You can use the API that requires the permission.
    }
    shouldShowRequestPermissionRationale(...) -> {
        // In an educational UI, explain to the user why your app requires this
        // permission for a specific feature to behave as expected. In this UI,
        // include a "cancel" or "no thanks" button that allows the user to
        // continue using your app without granting the permission.
        showInContextUI(...)
    }
    else -> {
        // You can directly ask for the permission.
        // The registered ActivityResultCallback gets the result of this request.
        requestPermissionLauncher.launch(
                Manifest.permission.REQUESTED_PERMISSION)
    }
}

Java

if (ContextCompat.checkSelfPermission(
        CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
        PackageManager.PERMISSION_GRANTED) {
    // You can use the API that requires the permission.
    performAction(...);
} else if (shouldShowRequestPermissionRationale(...)) {
    // In an educational UI, explain to the user why your app requires this
    // permission for a specific feature to behave as expected. In this UI,
    // include a "cancel" or "no thanks" button that allows the user to
    // continue using your app without granting the permission.
    showInContextUI(...);
} else {
    // You can directly ask for the permission.
    // The registered ActivityResultCallback gets the result of this request.
    requestPermissionLauncher.launch(
            Manifest.permission.REQUESTED_PERMISSION);
}

開発者自身がリクエスト コードを管理する

システムに権限リクエスト コードの管理を許可する代わりに、開発者自身がリクエスト コードを管理することもできます。そのためには、requestPermissions() の呼び出しにリクエスト コードを含めます。

次のコード スニペットは、リクエスト コードを使用して権限をリクエストする方法を示しています。

Kotlin

when {
    ContextCompat.checkSelfPermission(
            CONTEXT,
            Manifest.permission.REQUESTED_PERMISSION
            ) == PackageManager.PERMISSION_GRANTED -> {
        // You can use the API that requires the permission.
        performAction(...)
    }
    shouldShowRequestPermissionRationale(...) -> {
        // In an educational UI, explain to the user why your app requires this
        // permission for a specific feature to behave as expected. In this UI,
        // include a "cancel" or "no thanks" button that allows the user to
        // continue using your app without granting the permission.
        showInContextUI(...)
    }
    else -> {
        // You can directly ask for the permission.
        requestPermissions(CONTEXT,
                arrayOf(Manifest.permission.REQUESTED_PERMISSION),
                REQUEST_CODE)
    }
}

Java

if (ContextCompat.checkSelfPermission(
        CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
        PackageManager.PERMISSION_GRANTED) {
    // You can use the API that requires the permission.
    performAction(...);
} else if (shouldShowRequestPermissionRationale(...)) {
    // In an educational UI, explain to the user why your app requires this
    // permission for a specific feature to behave as expected. In this UI,
    // include a "cancel" or "no thanks" button that allows the user to
    // continue using your app without granting the permission.
    showInContextUI(...);
} else {
    // You can directly ask for the permission.
    requestPermissions(CONTEXT,
            new String[] { Manifest.permission.REQUESTED_PERMISSION },
            REQUEST_CODE);
}

ユーザーがシステム権限ダイアログに応答すると、システムはアプリの onRequestPermissionsResult() の実装を呼び出します。システムは、ユーザーの応答と、開発者が定義したリクエスト コードを権限ダイアログに渡します。次のコード スニペットをご覧ください。

Kotlin

override fun onRequestPermissionsResult(requestCode: Int,
        permissions: Array<String>, grantResults: IntArray) {
    when (requestCode) {
        PERMISSION_REQUEST_CODE -> {
            // If request is cancelled, the result arrays are empty.
            if ((grantResults.isNotEmpty() &&
                    grantResults[0] == PackageManager.PERMISSION_GRANTED)) {
                // Permission is granted. Continue the action or workflow
                // in your app.
            } else {
                // Explain to the user that the feature is unavailable because
                // the features requires a permission that the user has denied.
                // At the same time, respect the user's decision. Don't link to
                // system settings in an effort to convince the user to change
                // their decision.
            }
            return
        }

        // Add other 'when' lines to check for other
        // permissions this app might request.
        else -> {
            // Ignore all other requests.
        }
    }
}

Java

@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions,
        int[] grantResults) {
    switch (requestCode) {
        case PERMISSION_REQUEST_CODE:
            // If request is cancelled, the result arrays are empty.
            if (grantResults.length > 0 &&
                    grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                // Permission is granted. Continue the action or workflow
                // in your app.
            }  else {
                // Explain to the user that the feature is unavailable because
                // the features requires a permission that the user has denied.
                // At the same time, respect the user's decision. Don't link to
                // system settings in an effort to convince the user to change
                // their decision.
            }
            return;
        }
        // Other 'case' lines to check for other
        // permissions this app might request.
    }
}

複数の権限をリクエストする

位置情報へのアクセスをリクエストする場合は、他の実行時の権限と同じおすすめの方法に従ってください。ただし、位置情報へのアクセスには、関連する権限がシステムに複数あるという重要な違いがあります。リクエストする権限とリクエストの方法は、アプリのユースケースにおける位置情報の要件によって異なります。

フォアグラウンドでの位置情報

1 回のみ、あるいは指定した期間にわたって位置情報を共有または受信する機能がアプリに含まれている場合には、フォアグラウンドでの位置情報へのアクセスが必要です。以下はその一例です。

  • ナビゲーション アプリで、ターンバイターン方式の経路案内をする機能。
  • メッセージ アプリで、現在地を別のユーザーと共有する機能。

アプリの機能が次のいずれかの状況でデバイスの現在地にアクセスする場合、システムはアプリがフォアグラウンドで位置情報を使用しているとみなします。

  • アプリに属するアクティビティが可視状態にある。

  • アプリがフォアグラウンド サービスを実行している。フォアグラウンド サービスが実行されているとき、システムはユーザーに対して常に通知を表示します。ユーザーがデバイスのホームボタンを押したりディスプレイをオフにしたりしてアプリがバックグラウンドに移動しても、アクセスは継続します。

    また、次のコード スニペットに示すように、フォアグラウンド サービス タイプを location と宣言することをおすすめします。Android 10（API レベル 29）以降では、このフォアグラウンド サービス タイプを宣言する必要があります。

    <!-- Recommended for Android 9 (API level 28) and lower. -->
<!-- Required for Android 10 (API level 29) and higher. -->
<service
    android:name="MyNavigationService"
    android:foregroundServiceType="location" ... >
    <!-- Any inner elements would go here. -->
</service>

次のスニペットに示すように、アプリが ACCESS_COARSE_LOCATION または ACCESS_FINE_LOCATION のいずれかの権限をリクエストするときに、フォアグラウンドでの位置情報が必要であることを宣言します。

<manifest ... >
  <!-- Always include this permission -->
  <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />

  <!-- Include only if your app benefits from precise location access. -->
  <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
</manifest>

バックグラウンドでの位置情報

アプリ内の機能が常に他のユーザーと位置情報を共有する場合や、Geofencing API を使用する場合、アプリはバックグラウンドでの位置情報へのアクセスを必要とします。以下はその一例です。

  • 家族間位置情報共有アプリで、家族と位置情報を継続的に共有する機能。
  • IoT アプリで、ユーザーが自宅を離れるとオフになり、帰宅すると再びオンになるようにホームデバイスを設定する機能。

フォアグラウンドでの位置情報のセクションで説明した以外の状況で、アプリがデバイスの現在地にアクセスする場合、システムはアプリがバックグラウンドで位置情報を使用しているとみなします。バックグラウンドでの位置情報の精度は、フォアグラウンドでの位置情報の精度と同じであり、アプリが宣言する位置情報へのアクセスによって異なります。

Android 10（API レベル 29）以降では、実行時にバックグラウンドでの位置情報へのアクセスをリクエストするために、アプリのマニフェストで ACCESS_BACKGROUND_LOCATION 権限を宣言する必要があります。以前のバージョンの Android では、アプリがフォアグラウンドでの位置情報へのアクセスを取得すると、バックグラウンドでの位置情報へのアクセスも自動的に取得します。

<manifest ... >
  <!-- Required only when requesting background location access on
       Android 10 (API level 29) and higher. -->
  <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
</manifest>

権限の拒否を処理する

ユーザーが権限のリクエストを拒否した場合は、その影響をユーザーが理解できるようにする必要があります。特に、権限がないために動作しない機能をユーザーに知らせる必要があります。その際は、次のベスト プラクティスを念頭に置いてください。

  • ユーザーの注意を引く。アプリに必要な権限がないために機能が制限されている UI を強調します。次のような方法が考えられます。

    • 機能の結果やデータが表示される場所にメッセージを表示する。
    • エラーアイコンとエラーを示す色を含んだ別のボタンを表示する。

  • 具体的に記述する。一般的なメッセージは表示しないでください。代わりに、アプリに必要な権限がないためにどの機能が利用できないかを記載します。

  • ユーザー インターフェースをブロックしない。具体的には、アプリの使用を妨げるような全画面の警告メッセージは表示しないでください。

ヒント: 権限が拒否された場合でも、考えられる最高のユーザー エクスペリエンスをアプリで提供するよう努める必要があります。たとえば、マイクへのアクセスが拒否された場合でも、テキスト機能を最大限活用するよう推奨してください。

同時に、アプリは権限のリクエストを拒否するというユーザーの決定を尊重する必要があります。Android 11（API レベル 30）以降では、デバイスにインストールされたアプリの全期間に、同じ権限に対してユーザーが何度も [許可しない] をタップした場合、アプリがその権限を再度リクエストしても、ユーザーにシステム権限ダイアログが表示されることはありません。このユーザーのアクションにより、[次回から表示しない] が選択されたことになります。以前のバージョンでは、ユーザーが以前に [次回から表示しない] チェックボックスまたはオプションをオンにしていない限り、アプリが権限をリクエストするたびに、システム権限ダイアログが表示されていました。

ユーザーが権限リクエストを複数回拒否した場合、これは完全な拒否と見なされます。特定の機能へのアクセスを必要とする場合のみ権限の許可をユーザーに求めることが非常に重要です。そうしないと、権限を再リクエストできなくなる可能性があります。

状況によっては、権限が自動的に拒否され、ユーザーによるアクションを必要としない場合があります（権限が自動的に付与される場合もあります）。自動的な動作を想定しないことが重要です。権限を必要とする機能にアプリがアクセスするたびに、その権限がアプリに付与されていることを確認する必要があります。

アプリの権限を求めるときのユーザー エクスペリエンスを向上させるには、アプリの権限に関するおすすめの設定もご覧ください。

1 回だけのアクセス許可

[今回のみ] というオプションは、ダイアログにある 3 つのボタンのうち 2 つ目のオプションです。
図 2. アプリが 1 回だけのアクセス許可をリクエストしたときに表示されるシステム ダイアログ

Android 11（API レベル 30）以降では、アプリが位置情報、マイク、またはカメラに関連する権限をリクエストするたびに、図 2 に示すように、ユーザー向けの権限ダイアログに [今回のみ] というオプションが表示されます。ユーザーがダイアログでこのオプションを選択した場合、アプリには一時的な「1 回だけのアクセス許可」が付与されます。

アプリの動作とユーザーの操作に応じて、アプリは該当するデータに一定時間アクセスできます。

  • アプリのアクティビティが表示されている間、アプリはデータにアクセスできます。
  • ユーザーがアプリをバックグラウンドに移行した場合、アプリは短時間だけ引き続きデータにアクセスできます。
  • アクティビティが表示されている間にフォアグラウンド サービスを起動した場合、ユーザーがアプリをバックグラウンドに移動しても、そのフォアグラウンド サービスが停止するまで、アプリは引き続きそのデータにアクセスできます。
  • ユーザーがシステム設定などで 1 回だけのアクセス許可を取り消した場合、アプリはフォアグラウンドサービスを開始したかどうかにかかわらず、データにアクセスできなくなります。他の権限と同様に、ユーザーがアプリの 1 回だけのアクセス許可を取り消すと、アプリのプロセスは終了します。

ユーザーが次にアプリを開いて、アプリ内の機能が位置情報、マイク、またはカメラへのアクセスをリクエストすると、ユーザーに再度権限の付与が求められます。

Android で使用されていないアプリの権限を自動リセットする

Android 11（API レベル 30）以降をターゲットとするアプリを数か月間使用しないと、ユーザーデータを保護するため、システムはユーザーがアプリに付与した機密情報に関する実行時の権限を自動的にリセットします。詳細については、アプリの休止状態に関するガイドをご覧ください。

必要に応じてデフォルト ハンドラになるようリクエストする

アプリによっては、通話履歴や SMS メッセージに関するユーザーの機密情報にアクセスする必要があります。通話履歴や SMS メッセージにのみ使用される権限をリクエストするアプリを Play ストアに公開する場合は、実行時の権限をリクエストする前に、アプリを中核的システム機能のデフォルト ハンドラとして設定することをユーザーに求める必要があります。

デフォルト ハンドラの詳細（デフォルト ハンドラのプロンプトをユーザーに表示する方法など）については、デフォルト ハンドラでのみ使用される権限のガイドをご覧ください。

テスト用にすべての実行時の権限を付与する

エミュレータまたはテストデバイスにアプリをインストールする際にすべての実行時の権限を自動的に付与するには、次のコード スニペットに示すように、adb shell install コマンドで -g オプションを使用します。

adb shell install -g PATH_TO_APK_FILE

参考情報

権限について詳しくは、以下の記事をご覧ください。

権限のリクエストについて詳しくは、以下のサンプルアプリをダウンロードしてください。

  • Android RuntimePermissionsBasic サンプル Java | Kotlin

前へ
アプリの権限を宣言する
次へ
アプリの権限に関するおすすめの設定