Androidの権限リクエストで「3回目にダイアログが出ない」→「設定画面へ遷移させましょう」
CyberAgent Developers Blogは、Androidアプリ開発においてユーザーが権限を2回拒否した後にOSダイアログが表示されなくなる「永久的な拒否」状態の仕様を解説し、アプリ詳細設定画面への誘導を実現するための状態管理と実装フローを具体的なコード例と共に紹介している。
キーポイント
Androidの権限リクエストにおける「永久的な拒否」仕様
ユーザーが権限リクエストを2回連続で拒否すると、システムは「永久的な拒否（Permanent Denial）」状態とみなし、以降のリクエストではOS標準の許可ダイアログが表示されなくなる。
状態判別の課題と解決策
Android標準のshouldShowRequestPermissionRationale()メソッドだけでは「初期状態」と「永久的な拒否状態」を区別できないため、アプリ側で権限リクエスト履歴を永続化（DataStore等）して状態を管理し、適切なアクションに分岐させる必要がある。
実装フローと設定画面への誘導方法
永久的な拒否状態を検知した場合、アプリはOSダイアログの表示を諦め、Intentを使用してアプリの詳細設定画面（Settings.ACTION_APPLICATION_DETAILS_SETTINGS）へユーザーを直接遷移させるUIを提供すべきである。
状態遷移と内部フラグの解説
記事では権限状態の遷移（初期、1回拒否、永久的拒否、許可後拒否）と、それに対応するOS内部フラグ（USER_SET, USER_FIXED）の役割を表と図で詳細に説明している。
永久的な拒否（Permanent Denial）の判定方法
shouldShowRationaleがfalseかつhasRequestedがtrueの場合が永久的な拒否状態であり、このタイミングで設定画面への誘導が必要です。
権限状態の管理方法
sealed interfaceを使用して権限状態（初期状態、拒否状態、許可済み）を管理し、拒否状態ではshouldShowRationaleフラグで説明が必要か設定誘導が必要かを判断します。
設定画面遷移の実装と配慮
永久的な拒否状態ではSettings.ACTION_APPLICATION_DETAILS_SETTINGS Intentを使用して設定画面に遷移しますが、突然遷移させずに理由を説明する自作ダイアログを挟むことが推奨されています。
影響分析・編集コメントを表示
影響分析
この記事は、Androidアプリ開発における一般的かつ実践的な課題に対する具体的な解決策を提供しており、開発現場でのバグ回避とユーザー体験向上に直接寄与する。仕様の深い理解と適切な実装パターンの普及を通じて、アプリの品質と信頼性の底上げに影響を与える可能性がある。
編集コメント
Android開発の現場で実際に遭遇する頻出トラブルに対する、仕様に基づいた実践的で完成度の高い解決ガイド。コード例と状態遷移図が理解を大いに助ける。
権限を3回目にリクエストした際にダイアログが表示されないのは仕様です。権限ダイアログの表示は諦めてください。
解決策：アプリの詳細設定画面へ遷移させましょう
val intent = Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS).apply { data = Uri.fromParts("package", packageName, null) } startActivity(intent)
権限に関する状態遷移は以下の表を参照してください。
(shouldShowRationale)
アプリが取るべき次のアクション
OS標準の権限ダイアログを表示する
ダイアログ等で理由を説明した後（Rationale）、再度リクエスト
「〇〇のために必要です」と説明
アプリ詳細設定画面へ誘導するUIを表示
「設定から許可してください」ボタン
理由説明後、再度リクエスト（②と同じ）
「〇〇」のために必要ですと説明
はじめまして！九州大学3年の後藤尋と申します。2026年2月の1ヶ月間、CyberAgentのインターン「Tech Job」に参加させていただき、Androidアプリ開発を行いました。この期間中、「権限ダイアログを2回拒否したあとに、ダイアログが表示されない」というバグに遭遇し、本記事の方法で解決いたしました。今回はその方法をご紹介します。
Androidアプリ開発において、避けては通れない権限リクエスト（Permission Request）。一見シンプルに見えるこの機能ですが、実装を進めると、「権限を2回拒否すると、3回目以降はタップしても何も起きなくなる」という不可解な挙動に直面することがあります。
Androidの権限許可ダイアログの仕組み
権限を2回拒否したあとの正しい実装フロー
設定画面への遷移が必要な理由と判定方法
検証環境：Android 16.0（API 36.0）
対象権限: ACCESS_FINE_LOCATION（正確な位置情報）
機能: 画面に現在の緯度・経度を表示する。権限がない場合は「権限リクエスト」ボタンを表示してユーザーに許可を求める。
※ACCESS_COARSE_LOCATIONやバックグラウンド位置情報については、本記事の対象外とします。
位置情報を取得し、画面に緯度経度を表示する機能を実装しているときに、以下のバグに遭遇しました。
ユーザーが権限リクエストを「許可しない」と選択する。
もう一度ボタンを押し、再度「許可しない」を選択する。
3回目、ボタンを押してもOSのダイアログが表示されない。
これはAndroidの仕様で、ユーザーが2回拒否すると永久的な拒否（Permanent Denial）とみなされ、以降のリクエストが自動的に無視されるためです。この状態になった場合、アプリはOSダイアログではなくアプリの詳細設定画面へ誘導するUIを出す必要があります。コードを確認したところ、この処理は実装されていました。
原因は、「過去に権限リクエストを行ったか」というフラグを永続的に保存していなかったためです（一時的に保存されていたため）。当初、このフラグは ViewModel 内で保持していたため、画面遷移やタスクキルによって ViewModel が破棄されるとフラグもリセットされてしまいます。その結果、アプリが初めての権限リクエストと誤認して requestPermissions を呼びますが、OS 側は永久的な拒否（Permanent Denial）状態であるため、ダイアログを出せない状態でした。
開発者は、この状態に陥った場合、OS のダイアログではなく、アプリの詳細設定画面へ誘導する UI を出す必要があります。しかし、単に requestPermissions を呼ぶだけでは、この「永久的な拒否（Permanent Denial）」状態を判別できません。
以下にフローを提示します。単にリクエストを投げるのではなく、アプリ側で状態を判断し、適切なアクション（ダイアログ表示 or アプリ詳細設定画面への遷移）に振り分ける必要があります。
適切なアクションへの分岐を実現するために重要なのが、OS の状態とアプリ独自のフラグの組み合わせです。
Android 標準の shouldShowRequestPermissionRationale() だけでは、①初期状態と③2 回拒否後（永久的な拒否（Permanent Denial））の区別がつきません。どちらも false を返すからです。区別するために、永続化領域（DataStore など）に権限リクエストを行ったかどうかを保存する必要があります。
(shouldShowRationale)
アプリが取るべき次のアクション
OS 標準の権限ダイアログを表示する
ダイアログ等で理由を説明した後（Rationale）、再度リクエスト
「〇〇のために必要です」と説明
アプリ詳細設定画面へ誘導する UI を表示
「設定から許可してください」ボタン
理由説明後、再度リクエスト（②と同じ）
「〇〇」のために必要ですと説明
※②で USER_SET というフラグが立ちます。ユーザーが選択（許可または拒否）したことを示します。権限が永久に拒否された場合、権限は USER_FIXED としてマークされます。
※③で USER_FIXED というフラグが立ちます。この Flag はユーザーが権限を 2 回拒否した際に設定されます。一度このフラグが立つと、システムは自動的に以降の権限リクエストを拒否し、アプリ側からの権限リクエストが無効化されます。（永久的な拒否（Permanent Denial）状態）
※⑤権限リセットは、権限を一度許可したあとに、設定画面で「拒否」に設定した場合の挙動。shouldShowRationale が常に true になるため、②1 回拒否と同じ状態になります。（参考：AOSP の該当箇所）
※アプリをアンインストールして、再度インストールしたあとは①初期状態になります。
※OS 内部フラグについては adb shell dumpsys package my.package.name 等で確認可能です。
※shouldShowRationale は OS 内部フラグによって判定されます。
// shouldShowRequestPermissionRationaleの内部ロジック
val fixedFlags = FLAG_PERMISSION_SYSTEM_FIXED | FLAG_PERMISSION_POLICY_FIXED | FLAG_PERMISSION_USER_FIXED
if ((flags & fixedFlags) != 0) {
return false // USER_FIXEDが立っていると強制的にfalse
}
return (flags & FLAG_PERMISSION_USER_SET) != 0
上記の表のとおり、shouldShowRationaleがfalseかつhasRequestedがtrueの場合こそが、設定画面への誘導すべきタイミング（永久的な拒否（Permanent Denial）状態）となります。
このロジックをシーケンス図で可視化すると、以下のようになります。
権限に関する状態をsealed interfaceで管理します。
sealed interface PermissionState {
/** 許可されているか */
val isGranted: Boolean get() = this is Granted
/** 初期状態 */
object Initial : PermissionState
/**
- 拒否された状態
- @property shouldShowRationale trueならアプリ内で説明が必要、falseなら設定画面へ誘導
*/
data class Denied(val shouldShowRationale: Boolean) : PermissionState
/** 許可済み */
object Granted : PermissionState
}
永久的な拒否（Permanent Denial）の判定
ここでは、DataStoreに保存したhasRequestedLocationPermissionが重要になります。
private suspend fun isPermanentDenial(shouldShowRationaleAfter: Boolean): Boolean {
val hasRequestedBefore = locationRepository.getHasRequestedLocationPermission() // DataStoreに保存した値をRepository経由で取得
return !shouldShowRationaleAfter && hasRequestedBefore
}
権限リクエストボタンを押したときに、ダイアログの出しわけを行う
2回目の権限リクエストの際は、OS標準のダイアログを表示する前に、自作ダイアログ等でワンクッション挟んで理由を説明するのがGoogleによって推奨されています。
fun onClickRequestLocationPermissionButton(shouldShowRationaleAfter: Boolean) { when(viewModelState.value.locationPermissionState) { PermissionState.Initial -> { // 初回リクエスト // TODO:権限許可ダイアログの表示（1回目） return } is PermissionState.Denied -> { // 永久的な拒否（Permanent Denial）の可能性があるので、 // ダイアログ表示フラグを更新してから、永久的な拒否かどうかを判定する viewModelScope.launch { val isPermanent = isPermanentDenial(shouldShowRationaleAfter) viewModelState.update { it.copy( event = if (isPermanent) { // 拒否後の設定誘導ダイアログを表示 // TODO: 設定画面への遷移 } else { // 通常の権限リクエストダイアログを再表示 // TODO:権限許可ダイアログの表示（2回目） } ) } } return } PermissionState.Granted -> { // 既に許可されている場合は、特に何もしない return } } }
権限リクエストの結果を受け取ったあとの処理です。ここでhasRequestedLocalePermissionを保存します。
fun onPermissionResult( isGranted: Boolean, context: Context, shouldShowRationale: Boolean = false ) { viewModelScope.launch { // 権限リクエストを行ったことを保存 locationRepository.saveHasRequestedLocationPermission() // permissionStateの更新 val newPermissionState = when { isGranted -> PermissionState.Granted shouldShowRationale -> PermissionState.Denied(shouldShowRationale = true) else -> PermissionState.Denied(shouldShowRationale = false) } viewModelState.update { it.copy( locationPermissionState = newPermissionState ) } // 許可された場合は、位置情報を取得 if (isGranted) { getLocation() } } }
永久的な拒否（Permanent Denial）状態になった場合は、アプリ側で権限を許可することはできません。 設定画面へ遷移するために、以下のIntentを使用します。
突然、設定画面に飛ばすとユーザーが驚くので、なぜ権限設定が必要かを説明する自作のダイアログを挟んでから遷移させると親切です。
val intent = Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS).apply { data = Uri.fromParts("package", packageName, null) } startActivity(intent)
注意事項：権限変更とプロセスキル
ユーザーが設定画面で「許可」または「拒否」を選択し、権限を変更した場合、Android OS はセキュリティと整合性を保つため、アプリのプロセスをキルして再起動することがあります。
拒否から許可へ切り替えた場合：権限を変更してもプロセスキルは発生しませんでした。
許可から拒否へ切り替えた場合：権限を変更すると、即座にプロセスキルが発生します。アプリに戻ると Activity が再生成されます。
拒否から許可へ切り替えてアプリに戻っても onCreate が呼び出されないため、権限の状態が更新されていない可能性があります。許可から拒否へ切り替えた際は、onStart や onResume、あるいは LifecycleObserver を使用して、画面が表示されるたびに最新の権限状態を確認する実装にしておくのが安全です。
Android の権限リクエストで「ダイアログが表示されない」問題に遭遇した場合は、以下の 3 点を確認してください。
Android OS の shouldShowRequestPermissionRationale は、2 回拒否した場合、またはアプリの権限をリセットして再度 1 回拒否した場合は false を返します。
初期状態と永久拒否を区別するために、アプリ側で hasRequestedPermission（永続フラグ）を管理します。
設定画面から戻った際の挙動を考慮し、onResume 等で権限チェックを行うようにします。
1 か月のインターンシップでしたが、2 月は期間が短く祝日も多かったため、あっという間に終了しました。
トレーナーの小野さん、メンターの手塚さん、そしてチームの皆様に大変お世話になりました。
今後の開発に活かせる非常に貴重な経験となりました。ありがとうございました！
Android での権限 | Privacy | Android Developers
Android の権限 | Android Open Source Project
AOSP Permission README
Android の permission 要求を整理する
原文を表示
3回目に権限をリクエストしたときにダイアログが出ないのは仕様です。権限ダイアログを出すのは諦めてください。
解決策: アプリ詳細設定画面へ遷移させましょう
val intent = Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS).apply { data = Uri.fromParts("package", packageName, null) } startActivity(intent)
権限に関する状態遷移は以下の表を参照。
(shouldShowRationale)
アプリが取るべき次のアクション
OS標準の権限ダイアログを表示する
ダイアログ等で理由を説明した後（Rationale）、再度リクエスト
「〇〇のために必要です」と説明
アプリ詳細設定画面へ誘導するUIを表示
「設定から許可してください」ボタン
理由説明後、再度リクエスト（②と同じ）
「〇〇」のために必要ですと説明
はじめまして！九州大学3年の後藤尋と申します。2026年2月の1ヶ月間、CyberAgentのインターン「Tech Job」に参加させていただき、Androidアプリ開発を行いました。この期間中、「権限ダイアログを2回拒否したあとに、ダイアログが表示されない」というバグに遭遇し、本記事の方法で解決いたしました。今回はその方法をご紹介します。
Androidアプリ開発において、避けては通れない権限リクエスト。一見シンプルに見えるこの機能ですが、実装を進めると、「権限を2回拒否すると、3回目以降はタップしても何も起きなくなる」不可解な挙動に直面することがあります。
Androidの権限許可ダイアログの仕組み
権限を2回拒否したあとの正しい実装フロー
設定画面への遷移が必要な理由と判定方法
検証環境：Android 16.0（API 36.0）
対象権限: ACCESS_FINE_LOCATION（正確な位置情報）
機能: 画面に現在の緯度・経度を表示する。権限がない場合は「権限リクエスト」ボタンを表示してユーザーに許可を求める。
※ACCESS_COARSE_LOCATIONやバックグラウンド位置情報については、本記事の対象外とします。
位置情報を取得し、画面に緯度経度を表示する機能を実装しているときに、以下のバグに遭遇しました。
ユーザーが権限リクエストを「許可しない」と選択する。
もう一度ボタンを押し、再度「許可しない」を選択する。
3回目、ボタンを押してもOSのダイアログが表示されない。
これはAndroidの仕様で、ユーザーが2回拒否すると永久的な拒否（Permanent Denial）とみなされ、以降のリクエストが自動的に無視されるためです。この状態になった場合、アプリはOSダイアログではなくアプリの詳細設定画面へ誘導するUIを出す必要があります。コードを確認したところ、この処理は実装されていました。
原因は、「過去に権限リクエストを行ったか」というフラグを永続的に保存していなかったためです（一時的に保存されていたため）。当初、このフラグはViewModel内で保持していたため、画面遷移やタスクキルによってViewModelが破棄されるとフラグもリセットされてしまいます。その結果、アプリが初めての権限リクエストと誤認してrequestPermissionsを呼びますが、OS側は永久的な拒否（Permanent Denial）状態であるため、ダイアログを出せない状態でした。
開発者は、この状態に陥った場合、OSのダイアログではなく、アプリの詳細設定画面へ誘導するUIを出す必要があります。しかし、単にrequestPermissionsを呼ぶだけでは、この「永久的な拒否（Permanent Denial）」状態を判別できません。
以下にフローを提示します。単にリクエストを投げるのではなく、アプリ側で状態を判断し、適切なアクション（ダイアログ表示 or アプリ詳細設定画面への遷移）に振り分ける必要があります。
適切なアクションへの分岐を実現するために重要なのが、OSの状態とアプリ独自のフラグの組み合わせです。
Android標準のshouldShowRequestPermissionRationale()だけでは、①初期状態と③2回拒否後（永久的な拒否（Permanent Denial））の区別がつきません。どちらもfalseを返すからです。区別するために、永続化領域（DataStoreなど）に権限リクエストを行ったかどうかを保存する必要があります。
(shouldShowRationale)
アプリが取るべき次のアクション
OS標準の権限ダイアログを表示する
ダイアログ等で理由を説明した後（Rationale）、再度リクエスト
「〇〇のために必要です」と説明
アプリ詳細設定画面へ誘導するUIを表示
「設定から許可してください」ボタン
理由説明後、再度リクエスト（②と同じ）
「〇〇」のために必要ですと説明
※②でUSER_SETというフラグが立ちます。ユーザーが選択（許可または拒否）したことを示します。権限が永久に拒否された場合、権限は USER_FIXED としてマークされます。 ※③でUSER_FIXEDというフラグが立ちます。このFlagはユーザーが権限を2回拒否した際に設定されます。一度このフラグが立つと、システムは自動的に以降の権限リクエストを拒否し、アプリ側からの権限リクエストが無効化されます。（永久的な拒否（Permanent Denial）状態） ※⑤権限リセットは、権限を一度許可したあとに、設定画面で「拒否」に設定した場合の挙動。shouldShowRationaleが常にtrueになるため、②1回拒否と同じ状態になります。（参考：AOSPの該当箇所） ※アプリをアンインストールして、再度インストールしたあとは①初期状態になります。 ※OS内部フラグについてはadb shell dumpsys package my.package.name等で確認可能です。
※shouldShowRationaleはOS内部フラグによって判定されます。
// shouldShowRequestPermissionRationaleの内部ロジック val fixedFlags = FLAG_PERMISSION_SYSTEM_FIXED | FLAG_PERMISSION_POLICY_FIXED | FLAG_PERMISSION_USER_FIXED if ((flags & fixedFlags) != 0) { return false // USER_FIXEDが立っていると強制的にfalse } return (flags & FLAG_PERMISSION_USER_SET) != 0
上記の表のとおり、shouldShowRationaleがfalseかつhasRequestedがtrueの場合こそが、設定画面への誘導すべきタイミング（永久的な拒否（Permanent Denial）状態）となります。
このロジックをシーケンス図で可視化すると、以下のようになります。
権限に関する状態をsealed interfaceで管理します。
sealed interface PermissionState { / 許可されているか */ val isGranted: Boolean get() = this is Granted / 初期状態 */ object Initial : PermissionState / * 拒否された状態 * @property shouldShowRationale trueならアプリ内で説明が必要、falseなら設定画面へ誘導 */ data class Denied(val shouldShowRationale: Boolean) : PermissionState / 許可済み */ object Granted : PermissionState }
永久的な拒否（Permanent Denial）の判定 ここでは、DataStoreに保存したhasRequestedLocationPermissionが重要になります。
private suspend fun isPermanentDenial(shouldShowRationaleAfter: Boolean): Boolean { val hasRequestedBefore = locationRepository.getHasRequestedLocationPermission() // DataStoreに保存した値をRepository経由で取得 return !shouldShowRationaleAfter && hasRequestedBefore }
権限リクエストボタンを押したときに、ダイアログの出しわけを行う
2回目の権限リクエストの際は、OS標準のダイアログを表示する前に、自作ダイアログ等でワンクッション挟んで理由を説明するのがGoogleによって推奨されています。
fun onClickRequestLocationPermissionButton(shouldShowRationaleAfter: Boolean) { when(viewModelState.value.locationPermissionState) { PermissionState.Initial -> { // 初回リクエスト // TODO:権限許可ダイアログの表示（1回目） return } is PermissionState.Denied -> { // 永久的な拒否（Permanent Denial）の可能性があるため、 // ダイアログ表示フラグを更新してから、永久的な拒否かどうかを判定する viewModelScope.launch { val isPermanent = isPermanentDenial(shouldShowRationaleAfter) viewModelState.update { it.copy( event = if (isPermanent) { // 拒否後の設定誘導ダイアログを表示 // TODO: 設定画面への遷移 } else { // 通常の権限リクエストダイアログを再表示 // TODO:権限許可ダイアログの表示（2回目） } ) } } return } PermissionState.Granted -> { // 既に許可されている場合は、特に何もしない return } } }
権限リクエストの結果を受け取ったあとの処理です。ここでhasRequestedLocalePermissionを保存します。
fun onPermissionResult( isGranted: Boolean, context: Context, shouldShowRationale: Boolean = false ) { viewModelScope.launch { // 権限リクエストを行ったことを保存 locationRepository.saveHasRequestedLocationPermission() // permissionStateの更新 val newPermissionState = when { isGranted -> PermissionState.Granted shouldShowRationale -> PermissionState.Denied(shouldShowRationale = true) else -> PermissionState.Denied(shouldShowRationale = false) } viewModelState.update { it.copy( locationPermissionState = newPermissionState ) } // 許可された場合は、位置情報を取得 if (isGranted) { getLocation() } } }
永久的な拒否（Permanent Denial）状態になった場合は、アプリ側で権限を許可することはできません。 設定画面へ遷移するために、以下のIntentを使用します。
突然、設定画面に飛ばすとユーザーが驚くので、なぜ権限設定が必要かを説明する自作のダイアログを挟んでから遷移させると親切です。
val intent = Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS).apply { data = Uri.fromParts("package", packageName, null) } startActivity(intent)
注意事項：権限変更とプロセスキル
ユーザーが設定画面で「許可」や「拒否」を押下し、権限を変更すると、Android OSはセキュリティと整合性を保つため、アプリのプロセスをキルして再起動する場合があります。
拒否→許可に切り替えたとき 権限を変更してもプロセスキルは発生しませんでした。
許可→拒否に切り替えたとき 権限を変更すると、即座にプロセスキルが発生します。アプリに戻るとActivityが再生成されます。
拒否 → 許可に切り替えてアプリに戻ってきてもonCreateが走らないため、権限の状態更新ができていない可能性があります。 許可 → 拒否に切り替えたとき、onStartやonResume、あるいはLifecycleObserverを使用して、画面が表示されるたびに最新の権限状態を確認する実装にしておくのが安全です。
Androidの権限リクエストで「ダイアログが出ない」問題に遭遇したら、以下の3点を確認してください。
Android OSのshouldShowRequestPermissionRationaleは、2回拒否したり、アプリの権限をリセットし1回拒否したらfalseに戻る。
初期状態と永久拒否を見分けるために、アプリ側でhasRequestedPermission（永続）フラグを管理する。
設定画面から戻った際の挙動を考慮し、onResume等で権限チェックを行う。
1ヶ月のインターンシップでしたが、2月は短くて祝日が多いということもあり、あっという間に終了しました。
トレーナーの小野さんとメンターの手塚さん、そしてチームの方々には特にお世話になりました。
今後の開発に活かせるとても貴重な経験となりました。ありがとうございました！
Android での権限 | Privacy | Android Developers
Android の権限 | Android Open Source Project
AOSP Permission README
Android の permission 要求を整理する
関連記事
Gemma 4：バイト単位で最も能力の高いオープンモデル
GoogleがGemma 4を発表した。高度な推論とエージェントワークフロー向けに設計された、これまでで最も知的なオープンモデルである。
GoogleのGemma 4が初めてApache 2.0ライセンスで利用可能に
Googleが最も高性能なオープンモデルファミリー「Gemma 4」をリリースした。4つの新モデルはスマートフォンからワークステーションまで幅広く動作し、初めて完全にオープンなApache 2.0ライセンスで提供される。
Google、オープンモデルファミリーGemma 4を発表
Googleは、高度な推論とマルチモーダル機能を備えたオープンモデルファミリー「Gemma 4」を発表した。