このページは Cloud Translation API によって翻訳されました。

アラームのスケジュールを設定する

アラーム（AlarmManager に基づく）実行する方法を提供します。時間ベースのオペレーションを実行することもできます。たとえば、長時間実行オペレーションをアラームを使用して開始できます。 1 日に 1 回サービスを開始して天気予報をダウンロードするような場合です。

アラームには以下の特徴があります。

設定した時間または周期的（あるいはその両方）にインテントを開始できます。
ブロードキャストレシーバと組み合わせて使用すると、ジョブや WorkRequest のスケジュールを設定して、他のオペレーションを実行できます。
アラームはアプリの外部で動作するため、アプリが実行されていないときや、デバイス自体がスリープ状態になっているときでも、アラームを使用してイベントやアクションをトリガーできます。
アプリのリソース要件を最小限に抑えるのに役立ちます。スケジュールを設定できますオペレーションを自動化できます。

不正確なアラームを設定する

アプリが不正確なアラームを設定した場合、ある時点でシステムからアラームが鳴る使用できます。不正確なアラームは、Doze などのバッテリー節約の制限を尊重しながら、アラームの配信タイミングに関して一定の保証を提供します。

デベロッパーは、以下の API 保証を活用して、アラートの到着が不正確になります

指定した時間の経過後にアラームを鳴らす

アプリで set() を呼び出す場合、 setInexactRepeating(), または setAndAllowWhileIdle()、アラームは指定されたトリガー時間より前には鳴りません。

Android 12（API レベル 31）以降では、システムは 1 分以内にアラームを呼び出します。指定されたトリガー時刻の時刻（バッテリー節約に関する制限がバッテリーセーバーや、 Doze。

時間枠内にアラームを配信する

アプリが setWindow() を呼び出す場合、指定されたトリガー時間より前にアラームが鳴ることはありません。バッテリー節約の制限が適用されていない限り、アラームは指定されたトリガー時間から、指定された時間枠内に配信されます。

アプリが Android 12 以降をターゲットとしている場合、時間枠付きの不正確なアラームの呼び出しが 10 分以上遅れることがあります。このため、600000 の windowLengthMillis パラメータ値は 600000 にクリップされます。

ほぼ一定間隔でアラームを繰り返す

アプリが setInexactRepeating() を呼び出すと、システムは複数のアラームを呼び出します。

最初のアラームは、指定したトリガー時刻から指定した時間枠内で鳴ります。
通常、その後のアラームは、指定した時間枠が経過した後に鳴ります。2 回連続してアラームが呼び出されるまでの時間は一定ではありません。

正確なアラームを設定する

システムは、将来の正確な時点で正確なアラームを呼び出します。

ほとんどのアプリは、不正確なアラームを使用してタスクやイベントのスケジュールを設定できます。一般的なユースケースをご覧ください。アプリのコアとなる機能が、目覚まし時計アプリなど、正確な時刻のアラームに依存している正確なアラームを使用しても問題ありません。

正確なアラームを必要としないユースケース

正確なアラームを必要としない一般的なワークフローを以下に示します。

アプリの全期間におけるタイミングオペレーションのスケジュール設定: Handler クラスには、タイミング操作を処理するためのメソッド（たとえば、 n 秒: アプリが稼働中の間: postAtTime() および postDelayed()。なお、これらの API はシステム稼働時間に依存します。リアルタイムではない
アプリの更新やログのアップロードなど、バックグラウンド処理のスケジュール設定: WorkManager を使用すると、タイミングが重要となる定期的な処理のスケジュールを設定できます。繰り返し間隔と flexInterval（15 分以上）を指定して、処理のランタイムを細かく定義できます。
特定の時間が経過した後に行う必要があるユーザー指定のアクション（システムがアイドル状態の場合でも）: 不正確なアラームを使用します。具体的には、以下の呼び出しを行います。 setAndAllowWhileIdle()。
特定の時間が経過した後に行う必要があるユーザー指定のアクション: 不正確なアラームを使用します。具体的には、set() を呼び出します。
指定された時間枠内で実行できるユーザー指定のアクション: 不正確なアラームを使用します。具体的には、以下の呼び出しを行います。 setWindow()。アプリが Android 12 以降をターゲットとしている場合、許可される最小ウィンドウ長は 10 分です。

正確なアラームを設定する方法

アプリでは、次のいずれかの方法で正確なアラームを設定できます。これらのメソッドは、リストの下部に近いメソッドほど、時間のかかるタスクを処理しますが、より多くのシステムリソースを必要とするように順序付けられています。

setExact()

他の予定時刻が近い限り、ほぼ正確な時刻にバッテリー節約対策が講じられていない。

アプリの動作に問題がなければ、このメソッドを使用して正確なアラームを設定します。ユーザーにとって時間的制約です

setExactAndAllowWhileIdle()

バッテリー節約対策が有効になっている場合でも、ほぼ正確な時刻にアラームを起動します。

setAlarmClock()

将来の正確な時刻にアラームを呼び出します。これらのアラームはシステムでお届け日数が調整されることはありません。システムは、これらのアラームを最も重要なアラームとして識別し、アラームを配信するために必要に応じて低電力モードを終了します。

システムリソースの使用量

アプリで設定したアラームがシステムによってトリガーされると、デバイスはバッテリーなどのリソースを大量に消費します省電力モードに切り替わりますさらに、これらのリクエストをバッチ処理するのも容易ではありません。リソースをより効率的に使用できます

可能な限り不正確なアラームを作成することを強くおすすめします。長時間の作業を行うには、アラームの BroadcastReceiver の WorkManager または JobScheduler を使用してスケジュールを設定します。デバイスが Doze モードの間に作業を行うには、setAndAllowWhileIdle() を使用して不正確なアラームを作成し、そのアラームによってジョブを開始します。

適切なアラームの権限を宣言する

アプリが Android 12 以降をターゲットとしている場合は、「アラームとリマインダー」の特別なアプリアクセス権を取得する必要があります。そのためには、次のコードスニペットに示すように、アプリのマニフェストファイルで SCHEDULE_EXACT_ALARM 権限を宣言します。

<manifest ...>
    <uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM"/>
    <application ...>
        ...
    </application>
</manifest>

アプリのターゲットが Android 13（API レベル 33）以降の場合は、SCHEDULE_EXACT_ALARM 権限または USE_EXACT_ALARM 権限を宣言できます。

<manifest ...>
    <uses-permission android:name="android.permission.USE_EXACT_ALARM"/>
    <application ...>
        ...
    </application>
</manifest>

SCHEDULE_EXACT_ALARM 権限と USE_EXACT_ALARM 権限はどちらも同じ機能を示していますが、付与方法が異なり、サポートするユースケースも異なります。ユーザー向けの機能で正確な時刻にアクションを実行する必要がある場合に限り、アプリで正確なアラームを使用して、SCHEDULE_EXACT_ALARM 権限または USE_EXACT_ALARM 権限を宣言する必要があります。

USE_EXACT_ALARM

自動的に付与
ユーザーが取り消すことはできません
今後の Google Play ポリシーの対象
限定的なユースケース

SCHEDULE_EXACT_ALARM

ユーザーによる許可
幅広いユースケース
アプリは、権限が取り消されていないことを確認する必要があります

Android 13（API レベル 33）以降をターゲットとするアプリの新規インストールでは、SCHEDULE_EXACT_ALARM 権限が事前付与されません。ユーザーがアプリを移行する場合 Android 14 を搭載したデバイスにバックアップ / 復元オペレーションを通じて新しいデバイスで SCHEDULE_EXACT_ALARM の権限が拒否されます。ただし、権限がすでに付与されている場合、その権限は Android 14 にアップグレードします

注: setExact API などで OnAlarmListener オブジェクトを使用して正確なアラームが設定されている場合、SCHEDULE_EXACT_ALARM 権限は必要ありません。

`SCHEDULE_EXACT_ALARM` 権限を使用する

USE_EXACT_ALARM とは異なり、SCHEDULE_EXACT_ALARM 権限はユーザーが付与する必要があります。ユーザーとシステムの両方が SCHEDULE_EXACT_ALARM 権限。

アプリに権限が付与されているかどうかを確認するには、正確なアラームの設定を試みる前に canScheduleExactAlarms() を呼び出します。アプリの SCHEDULE_EXACT_ALARM 権限が取り消されると、アプリは停止され、今後の正確なアラームはすべてキャンセルされます。また、canScheduleExactAlarms() から返された値は、アプリのライフサイクル全体で有効なままになります。

アプリに SCHEDULE_EXACT_ALARMS 権限が付与されると、システムはそのアプリに ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED ブロードキャストを送信します。アプリにブロードキャストを実装する受信機を使って次のとおりです。

アプリにまだ特別なアプリアクセスがあることを確認する。これを行うには、canScheduleExactAlarms() を呼び出します。このチェックにより、ユーザーが特定のサービスアカウントに対する許可をその直後にその権限を取り消します。
アプリが必要とする正確なアラームのスケジュールを、現在の状態に基づいて変更する。このロジックは、アプリが ACTION_BOOT_COMPLETED ブロードキャストを受信したときの動作と同様です。

`SCHEDULE_EXACT_ALARM` 権限を付与するようユーザーに求める

[アラームとリマインダーの設定を許可する] というオプション — **図 1.** システム設定の [アラームとリマインダー] の特別なアプリアクセスのページ。ユーザーはここで、アプリが正確なアラームを設定することを許可できます。

必要に応じて、図 1 に示すように、システム設定の [アラームとリマインダー] 画面にユーザーを誘導できます。そのための手順は次のとおりです。

アプリの UI で、アプリが正確なアラームのスケジュールを設定する必要がある理由をユーザーに説明します。
ACTION_REQUEST_SCHEDULE_EXACT_ALARM インテントアクションを含むインテントを呼び出します。

反復アラームを設定する

リピートアラームを使用すると、システムがアプリに定期的なスケジュールで通知できます。

アラームが適切に設計されていないと、電池を消耗させるだけでなく、サーバーへの負荷が大きくなる可能性があります。そのため、Android 4.4（API レベル 19）以降では、すべての反復アラームは不正確なアラームです。

反復アラームには以下の特徴があります。

アラームのタイプ。詳しくは、アラームタイプを選択するをご覧ください。
トリガー時間。指定したトリガー時間が過去の場合、アラームがすぐにトリガーされます。
アラームの間隔。たとえば、1 日 1 回、1 時間ごと、5 分ごとなどです。
アラームがトリガーされたときに開始するペンディングインテント。同じペンディングインテントを使用する 2 つ目のアラームを設定すると、そのアラームで元のアラームが置き換えられます。

PendingIntent() をキャンセルするには、次を渡します。 FLAG_NO_CREATE PendingIntent.getService() までそのインテントのインスタンスを取得（存在する場合）し、そのインテントを AlarmManager.cancel()

Kotlin

val alarmManager =
    context.getSystemService(Context.ALARM_SERVICE) as? AlarmManager
val pendingIntent =
    PendingIntent.getService(context, requestId, intent,
                                PendingIntent.FLAG_NO_CREATE)
if (pendingIntent != null && alarmManager != null) {
  alarmManager.cancel(pendingIntent)
}

Java

AlarmManager alarmManager =
    (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
PendingIntent pendingIntent =
    PendingIntent.getService(context, requestId, intent,
                                PendingIntent.FLAG_NO_CREATE);
if (pendingIntent != null && alarmManager != null) {
  alarmManager.cancel(pendingIntent);
}

アラームタイプを選択する

反復アラームを使用する場合、最初にどのタイプにするかを検討する必要があります。

アラームの一般的な時計の種類は「経過時間（リアルタイム）」の 2 つです。および "リアルタイムクロック"（RTC）を使用します。実経過時間ではリファレンスとして「システムが起動してからの経過時間」を使用し、リアルタイムクロックでは UTC（ウォールクロック）時間を使用します。つまり、実経過時間はタイムゾーンやロケールの影響を受けないため、時間の経過に基づくアラームの設定に適しています（30 秒ごとにトリガーされるアラームなど）。リアルタイムクロックのタイプは、現在の言語 / 地域に依存します。

どちらのタイプにも、画面がオフの場合にデバイスの CPU のスリープを解除するように指示する「wakeup」バージョンが用意されています。これにより、スケジュール設定された時間にアラームを確実にトリガーできます。これは、アプリに時間に依存している場合に便利です。たとえば限られた時間枠内で特定の操作を実行できます。「アラームの種類の wakeup バージョンの場合、すべての繰り返しアラームが作動します。スリープ解除します。

特定の間隔（ 30 分ごとなど）、経過時間タイプの 1 つを使用します。通常はこのタイプを選択することをおすすめします。

特定の時間帯にアラームをトリガーする必要がある場合は、時間ベースのリアルタイムクロックタイプのいずれかを選択します。ただし、このアプローチにはいくつかのデメリットがあります。他の言語 / 地域には適切に翻訳されないことがあります。また、ユーザーがデバイスの時刻設定を変更すると、予期しない動作が発生する可能性があります。説明しますまた、リアルタイムクロックのアラームも適切に調整されません。使用します。「リアルタイムの経過時間」アラーム。

以下に、アラームタイプの一覧を示します。

ELAPSED_REALTIME: デバイスが起動してからの経過時間に基づいてペンディングインテントを開始しますが、デバイスのスリープは解除しません。経過時間には、デバイスがスリープしていた時間が含まれます。
ELAPSED_REALTIME_WAKEUP: デバイスが起動してから指定された時間が経過した後にデバイスのスリープを解除し、ペンディングインテントを開始します。
RTC: 指定した時刻にペンディングインテントを起動しますが、デバイスは復帰しません。
RTC_WAKEUP: 復帰デバイスを起動して、指定した時刻にペンディングインテントを開始します。

実経過時間タイプのアラームの例

ELAPSED_REALTIME_WAKEUP の使用例を次に示します。

30 分後と 30 分ごとにデバイスをスリープ解除して、アラームを作動させます変更すると、次のようになります。

Kotlin

// Hopefully your alarm will have a lower frequency than this!
alarmMgr?.setInexactRepeating(
        AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() + AlarmManager.INTERVAL_HALF_HOUR,
        AlarmManager.INTERVAL_HALF_HOUR,
        alarmIntent
)

Java

// Hopefully your alarm will have a lower frequency than this!
alarmMgr.setInexactRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() + AlarmManager.INTERVAL_HALF_HOUR,
        AlarmManager.INTERVAL_HALF_HOUR, alarmIntent);

1 分後にデバイスのスリープを解除し、アラームを 1 回だけ（反復なし）トリガーします。

Kotlin

private var alarmMgr: AlarmManager? = null
private lateinit var alarmIntent: PendingIntent
...
alarmMgr = context.getSystemService(Context.ALARM_SERVICE) as AlarmManager
alarmIntent = Intent(context, AlarmReceiver::class.java).let { intent ->
    PendingIntent.getBroadcast(context, 0, intent, 0)
}

alarmMgr?.set(
        AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() + 60 * 1000,
        alarmIntent
)

Java

private AlarmManager alarmMgr;
private PendingIntent alarmIntent;
...
alarmMgr = (AlarmManager)context.getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(context, AlarmReceiver.class);
alarmIntent = PendingIntent.getBroadcast(context, 0, intent, 0);

alarmMgr.set(AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() +
        60 * 1000, alarmIntent);

リアルタイムクロックタイプのアラームの例

この例は、 RTC_WAKEUP。

午後 2 時ごろにデバイスのスリープを解除してアラームをトリガーします。毎日 1 回、同じ時間にこの処理を行います。

Kotlin

// Set the alarm to start at approximately 2:00 p.m.
val calendar: Calendar = Calendar.getInstance().apply {
    timeInMillis = System.currentTimeMillis()
    set(Calendar.HOUR_OF_DAY, 14)
}

// With setInexactRepeating(), you have to use one of the AlarmManager interval
// constants--in this case, AlarmManager.INTERVAL_DAY.
alarmMgr?.setInexactRepeating(
        AlarmManager.RTC_WAKEUP,
        calendar.timeInMillis,
        AlarmManager.INTERVAL_DAY,
        alarmIntent
)

Java

// Set the alarm to start at approximately 2:00 p.m.
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(System.currentTimeMillis());
calendar.set(Calendar.HOUR_OF_DAY, 14);

// With setInexactRepeating(), you have to use one of the AlarmManager interval
// constants--in this case, AlarmManager.INTERVAL_DAY.
alarmMgr.setInexactRepeating(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(),
        AlarmManager.INTERVAL_DAY, alarmIntent);

正確な午前 8 時 30 分と 20 分ごとにデバイスをスリープ解除して、アラームを作動させますそれ以降は、次のようになります。

Kotlin

private var alarmMgr: AlarmManager? = null
private lateinit var alarmIntent: PendingIntent
...
alarmMgr = context.getSystemService(Context.ALARM_SERVICE) as AlarmManager
alarmIntent = Intent(context, AlarmReceiver::class.java).let { intent ->
    PendingIntent.getBroadcast(context, 0, intent, 0)
}

// Set the alarm to start at 8:30 a.m.
val calendar: Calendar = Calendar.getInstance().apply {
    timeInMillis = System.currentTimeMillis()
    set(Calendar.HOUR_OF_DAY, 8)
    set(Calendar.MINUTE, 30)
}

// setRepeating() lets you specify a precise custom interval--in this case,
// 20 minutes.
alarmMgr?.setRepeating(
        AlarmManager.RTC_WAKEUP,
        calendar.timeInMillis,
        1000 * 60 * 20,
        alarmIntent
)

Java

private AlarmManager alarmMgr;
private PendingIntent alarmIntent;
...
alarmMgr = (AlarmManager)context.getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(context, AlarmReceiver.class);
alarmIntent = PendingIntent.getBroadcast(context, 0, intent, 0);

// Set the alarm to start at 8:30 a.m.
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(System.currentTimeMillis());
calendar.set(Calendar.HOUR_OF_DAY, 8);
calendar.set(Calendar.MINUTE, 30);

// setRepeating() lets you specify a precise custom interval--in this case,
// 20 minutes.
alarmMgr.setRepeating(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(),
        1000 * 60 * 20, alarmIntent);

アラームに必要な精度を決定する

前述のとおり、アラームの作成では通常、最初にアラームタイプを選択します。さらに、アラームに必要な精度も区別されます。あります。ほとんどのアプリでは setInexactRepeating() おすすめしますこの方法を使用すると、Android は不正確な複数の繰り返しアラームを同期し、起動させます。同時に使用できます。これにより、電池の消耗を抑えることができます。

正確なアラームの使用はできるだけ避けてください。ただし、柔軟性が高く、正確なアラームを設定するには、 setRepeating()。

setInexactRepeating() では、setRepeating() で指定できるカスタムの間隔を指定できません。次のような間隔定数のいずれかを使用する必要があります。 INTERVAL_FIFTEEN_MINUTES INTERVAL_DAY, といった具合です一覧については、AlarmManager をご覧ください。

アラームのキャンセル

アプリによっては、アラームをキャンセルする機能を追加することをおすすめします。アラームをキャンセルするには、cancel() を呼び出します「アラームマネージャー」で指定し、不要になった PendingIntent 件発生します。例:

Kotlin

// If the alarm has been set, cancel it.
alarmMgr?.cancel(alarmIntent)

Java

// If the alarm has been set, cancel it.
if (alarmMgr!= null) {
    alarmMgr.cancel(alarmIntent);
}

デバイスの再起動時にアラームを開始する

デフォルトでは、デバイスのシャットダウン時にすべてのアラームがキャンセルされます。これを防ぐには、アプリケーションを設計する際に、ユーザーがデバイスを再起動したときに、繰り返しアラームを自動的に再開するように設定できます。こうすることで、ユーザーが手動でアラームを再起動しなくても AlarmManager によってタスクの実行が継続されます。

手順は次のとおりです。

RECEIVE_BOOT_COMPLETED を設定します。権限を宣言する必要があります。これにより、システムが起動を終了した後にブロードキャストされる ACTION_BOOT_COMPLETED をアプリで受信できます（この処理は、アプリがユーザーによって 1 回以上起動されたことがある場合にのみ行われます）。
```
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>
```

実装 BroadcastReceiver ブロードキャストを受信します。

Kotlin

class SampleBootReceiver : BroadcastReceiver() {

    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == "android.intent.action.BOOT_COMPLETED") {
            // Set the alarm here.
        }
    }
}

Java

public class SampleBootReceiver extends BroadcastReceiver {

    @Override
    public void onReceive(Context context, Intent intent) {
        if (intent.getAction().equals("android.intent.action.BOOT_COMPLETED")) {
            // Set the alarm here.
        }
    }
}

アプリのマニフェストファイルにレシーバを追加し、ACTION_BOOT_COMPLETED アクションに基づいてフィルタするインテントフィルタを指定します。

<receiver android:name=".SampleBootReceiver"
        android:enabled="false">
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED"></action>
    </intent-filter>
</receiver>

マニフェストで起動レシーバが android:enabled="false" に設定されていることに注目してください。つまり、受信側はアプリケーションが明示的に有効にしない限り、呼び出されません。このため、起動レシーバが不必要に呼び出されるのを防ぐことができます。レシーバを有効にするには次のように記述します（ユーザーがアラームを設定する場合など）。

Kotlin

val receiver = ComponentName(context, SampleBootReceiver::class.java)

context.packageManager.setComponentEnabledSetting(
        receiver,
        PackageManager.COMPONENT_ENABLED_STATE_ENABLED,
        PackageManager.DONT_KILL_APP
)

Java

ComponentName receiver = new ComponentName(context, SampleBootReceiver.class);
PackageManager pm = context.getPackageManager();

pm.setComponentEnabledSetting(receiver,
        PackageManager.COMPONENT_ENABLED_STATE_ENABLED,
        PackageManager.DONT_KILL_APP);

この方法でレシーバを有効にすると、ユーザーがデバイスを再起動しても有効なままになります。言い換えれば、レシーバをプログラムで有効にすると、マニフェストの設定がオーバーライドされます。レシーバは、アプリによって無効にされるまで有効なままになります。レシーバを無効にするには次のように記述します（ユーザーがアラームをキャンセルする場合など）。

Kotlin

val receiver = ComponentName(context, SampleBootReceiver::class.java)

context.packageManager.setComponentEnabledSetting(
        receiver,
        PackageManager.COMPONENT_ENABLED_STATE_DISABLED,
        PackageManager.DONT_KILL_APP
)

Java

ComponentName receiver = new ComponentName(context, SampleBootReceiver.class);
PackageManager pm = context.getPackageManager();

pm.setComponentEnabledSetting(receiver,
        PackageManager.COMPONENT_ENABLED_STATE_DISABLED,
        PackageManager.DONT_KILL_APP);

デバイスが Doze モードのときにアラームを起動する

Android 6.0（API レベル 23）を搭載したデバイスがサポートします。 Doze 使用すると、デバイスのバッテリー寿命を延ばします。デバイスが Doze モードの場合、アラームは起動しません。スケジュール設定されたアラームは、デバイスが Doze モードを終了するまで延期されます。デバイスがアイドル状態でも処理を完了させる必要がある場合は、次の方法があります。

正確なアラームを設定する。
WorkManager API を使用する。この API はバックグラウンド処理を行います処理の迅速化を指示して、可能な限り早く終了するようにします詳細については、次をご覧ください: WorkManager でタスクのスケジュールを設定する

アラームのスケジュールを設定する

不正確なアラームを設定する

指定した時間の経過後にアラームを鳴らす

時間枠内にアラームを配信する

ほぼ一定間隔でアラームを繰り返す

正確なアラームを設定する

正確なアラームを必要としないユースケース

正確なアラームを設定する方法

システム リソースの使用量

適切なアラームの権限を宣言する

SCHEDULE_EXACT_ALARM 権限を使用する

SCHEDULE_EXACT_ALARM 権限を付与するようユーザーに求める

反復アラームを設定する

Kotlin

Java

アラームタイプを選択する

実経過時間タイプのアラームの例

Kotlin

Java

Kotlin

Java

リアルタイム クロックタイプのアラームの例

Kotlin

Java

Kotlin

Java

アラームに必要な精度を決定する

アラームのキャンセル

Kotlin

Java

デバイスの再起動時にアラームを開始する

Kotlin

Java

Kotlin

Java

Kotlin

Java

デバイスが Doze モードのときにアラームを起動する

おすすめの方法

システムリソースの使用量

`SCHEDULE_EXACT_ALARM` 権限を使用する

`SCHEDULE_EXACT_ALARM` 権限を付与するようユーザーに求める

リアルタイムクロックタイプのアラームの例