キオスク端末の消灯がstartActivity1本頼りで、失敗すると朝まで点灯したままになる

結論

常時起動のAndroidキオスク端末で、夜間の消灯を「黒いオーバーレイActivityのstartActivity1回」だけに頼っていると、その1回がBAL（Background Activity Launch）制限やSYSTEM_ALERT_WINDOW未許可で失敗した瞬間、画面は消えないまま朝を迎えます。 呼び出しはrunCatchingで囲み、しかも経路そのものを2本用意しないと直りません。

症状

Device Ownerキオスクの夜間消灯は、lockNow()でバックライトごと落とすのではなく、明るさ0＋FLAG_KEEP_SCREEN_ONの黒いActivityを前面に出す「擬似消灯」で実装していました。パネルを起こしたままにしておけば、朝は黒オーバーレイを解除するだけで必ず復帰できるからです（lockNow()は機種によっては復帰不能スリープを誘発するため、既定では使いません）。

この黒オーバーレイの起動は、スケジュールを管理するScheduleManager.applyCurrentState()が担っていました。

if (cfg.isCurrentlyInOffPeriod(Calendar.getInstance())) {
    context.startActivity(
        Intent(context, BlackScreenActivity::class.java)
            .addFlags(Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TOP)
    )
    Log.i(TAG, "applyCurrentState: OFF period -> black screen")
}

一方、PowerController.screenOff()のoverlayモード側は、これに委ねる前提で早期returnするだけでした。つまり黒画面を出す経路は実質1本だけです。このstartActivityが端末側の制約で失敗すると、例外はScheduleAlarmReceiver.onReceive()全体を包むtry/catchまで届き、そこで警告ログを1行残して次のアラームを再武装するだけで処理が終わります。画面には何も出ず、キオスクなので操作者もいません。次にこのアラームが発火するのは翌日の同時刻なので、その日の夜はずっと画面が点いたままになります。

原因

startActivityが失敗し得る理由は2つあります。

• BAL（Background Activity Launch）制限: Android 10以降、バックグラウンドのアプリからのActivity起動は既定でブロックされます。AlarmManager経由のBroadcastReceiverはフォアグラウンドではないため、この制限に引っかかる余地があります。
• SYSTEM_ALERT_WINDOW未許可: 黒オーバーレイを他アプリの上に重ねて出すための権限で、端末の初期セットアップや工場出荷後の権限リセットで外れていることがあります。

どちらの場合もstartActivityは例外を投げますが、呼び出し元は**「消灯の唯一の経路」であると同時に「例外を握りつぶすtry/catchの内側」**でした。失敗が起きても画面上には何の兆候も出ず、ログを見に行かない限り気づけません。

直し方

2箇所を直しました。

(1) screenOff()自身にも黒オーバーレイの起動を追加し、経路を2本にする。

fun screenOff(context: Context) {
    if (Config.isNightOffOverlay(context)) {
        Log.i(TAG, "screenOff: overlay mode -> show black overlay (keep-screen-on), lockNow skipped")
        runCatching {
            context.startActivity(
                Intent(context, BlackScreenActivity::class.java)
                    .addFlags(Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TOP)
            )
        }.onFailure { Log.w(TAG, "screenOff: black overlay launch failed (SYSTEM_ALERT_WINDOW 未付与?): ${it.message}") }
        return
    }
    // ...
}

ScheduleAlarmReceiverはOFFアラームの発火時にPowerController.screenOff(context)を直接呼んだあと、同じ処理内でScheduleManager.applyCurrentState(context)も呼びます。片方がBAL制限や権限未許可で落ちても、もう一方が黒画面を出せます。BlackScreenActivityの起動フラグはFLAG_ACTIVITY_CLEAR_TOP込みなので、両方成功して多重起動しても実害はありません。

(2) startActivityの呼び出しを全てrunCatchingでガードする。

ScheduleManager.applyCurrentState()側の黒オーバーレイ起動と、ON期間に戻すサイネージActivityの起動、両方をrunCatchingで包み、失敗をログだけに留めるようにしました。

if (Config.autoLaunchSignage(context) && Config.signageUrl(context).isNotBlank()) {
    runCatching {
        context.startActivity(
            Intent(context, SignageActivity::class.java)
                .addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)
        )
    }.onFailure { Log.w(TAG, "applyCurrentState: signage launch failed (SYSTEM_ALERT_WINDOW 未付与?): ${it.message}") }
}

あわせて、KeepAwakeManager.reassertForegroundIfNeeded()がOFF期間中にサイネージが前面に出ていた場合の再消灯処理も、独自に黒オーバーレイをstartActivityしていたのをやめ、PowerController.screenOff(context)を呼ぶ形に一本化しました。消灯のロジック（overlayかlockNowか、失敗時にどう振る舞うか）を1箇所にまとめることで、再消灯の経路が増えるたびに同じガード漏れを繰り返さないようにしています。

再発防止

この修正は自社レビューのHIGH指摘で見つかり、対応まで完了しています。「消灯の経路を2本にする」「startActivityを全てガードする」の2点に加えて、消灯ロジックの呼び出し元をPowerController.screenOff()1箇所に統一したのが3点目の対策です。以前はKeepAwakeManagerが独自に黒オーバーレイを起動するコードを持っていて、消灯の実装が2箇所に分散していました。呼び出し元が増えるほど「新しい経路にはガードを入れ忘れる」リスクが増えるため、消灯そのものの実装は1箇所に閉じ込め、呼び出し側はscreenOff()を呼ぶだけにしています。