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

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

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

  • 設定した時間または周期的(あるいはその両方)にインテントを開始できます。

  • ブロードキャスト レシーバと組み合わせて使用することで、 jobs WorkRequest を使用して、他のタスクや 必要があります。

  • アプリケーションの外部で動作するため、これを使用してトリガー アプリが実行されていないときや、アプリが実行中でも、 睡眠状態になるのです。

  • アプリのリソース要件を最小限に抑えるのに役立ちます。スケジュールを設定できます オペレーションを自動化できます。

で確認できます。

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

アプリが不正確なアラームを設定した場合、ある時点でシステムからアラームが鳴る 使用できます。不正確なアラームは、 次のようなバッテリー節約の制限を考慮しつつ、アラームを配信 Doze

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

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

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

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

特定の時間帯にアラームを配信する

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

Android 12 以降をターゲットとするアプリの場合、システムによって遅延が発生する可能性があります。 少なくとも 10 分間、時間枠が設定された不正確なアラームの呼び出し対象 そのため、600000windowLengthMillis パラメータ値はクリップされて、 600000

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

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

  1. 最初のアラームは、指定した時間( トリガー時間。
  2. 以降のアラームは通常、指定された時間枠の後に鳴ります。 削除されます。2 回連続してアラームが呼び出されるまでの時間は一定ではありません。

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

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

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

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

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

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

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

次のいずれかの方法で正確なアラームを設定できます。これらのメソッドは、 リストの下の方にある商品の方が 多く表示されるようにします 時間の制約が厳しいタスクですが、より多くのシステム リソースが必要になります。

setExact()

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

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

setExactAndAllowWhileIdle()

バッテリー節約の場合でも、ほぼ正確な時刻にアラームを鳴らす 防ぐことができます。

setAlarmClock()

将来の正確な時刻にアラームを鳴らす。これらのアラームは システムでお届け日数が調整されることはありません。「 システムがこれらのアラームを最も重要なアラームとして識別し、 必要に応じてモードをチューニングできます。

システム リソースの消費

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

常に不正確なアラームを作成することを強くおすすめします。 考えています長時間の作業を実行するには、 WorkManager または アラームの JobScheduler BroadcastReceiver。作業を実行しながら デバイスが 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

SCHEDULE_EXACT_ALARM

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

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

: OnAlarmListener オブジェクトの setExact API の場合、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 あります。アプリにブロードキャストを実装する 受信する: 次のとおりです。

  1. アプリが特別なアプリにアクセスできることを確認します。これを行うには、 canScheduleExactAlarms()。 このチェックは、ユーザーが特定の権限の付与を許可した場合からアプリを保護します。 その直後にその権限を取り消します。
  2. アプリが必要とする正確なアラームを、現在の状態に基づいて再スケジュールします。 このロジックは、アプリが ACTION_BOOT_COMPLETED ブロードキャストを受信したときの動作と同様です。

SCHEDULE_EXACT_ALARM 権限を付与するようユーザーに依頼する

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

必要に応じて、ユーザーを [アラームとシステムのリマインダー画面 設定を行う必要があります(図 1 を参照)。そのための手順は次のとおりです。

  1. アプリの UI で、アプリが正確なアラームのスケジュールを設定する必要がある理由をユーザーに説明します。
  2. 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);
}

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

繰り返しアラームを使用する際に最初に考慮すべきことの 1 つは、その種類です。 必要があります。

アラームの一般的な時計の種類は「経過時間(リアルタイム)」の 2 つです。および "リアルタイム クロック"(RTC)。 経過時間は「システム起動からの経過時間」を使用として リアルタイム クロックでは UTC(実時間)が使用されます。つまり 経過時間に基づいてアラームを設定するのに適しています( (例: 30 秒ごとに起動するアラームなど)は、 タイムゾーンまたは言語 / 地域によって異なります。リアルタイム クロックのタイプは、 現在の言語 / 地域に依存します。

どちらのタイプにも「ウェイクアップ」があります。デバイスの CPU が復帰した場合に 画面がオフになっています。これにより、設定した時刻にアラームが起動します。 これは、アプリに時間に依存している場合に便利です。たとえば 限られた時間枠内で特定の操作を実行できます。「 アラームのタイプのウェイクアップ バージョンを設定している場合、すべての繰り返しアラームが作動します。 スリープ解除します。

特定の間隔(例: 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 日 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 が ユーザーが手動でアラームを再起動しなくても、タスクを続行できます。

手順は次のとおりです。

  1. RECEIVE_BOOT_COMPLETED を設定します。 権限を宣言する必要があります。これにより、アプリは ACTION_BOOT_COMPLETED ブロードキャストされます(これは、 ユーザーがすでに 1 回以上起動している場合)。

    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>
  2. 実装 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.
            }
        }
    }
    
  3. アプリのマニフェスト ファイルに、以下のインテント フィルタを使用してレシーバを追加する。 フィルタ条件として 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 モードを終了するまで延期されます。必要に応じて デバイスがアイドル状態の場合でも作業を完了できる 使用可能:

おすすめの方法

繰り返しアラームを設定する際の選択肢がどれも、影響を及ぼす可能性があります。 リソースの使用状況を表します。たとえば、 サーバーと同期できる人気のアプリです。同期処理がクロックに基づく場合 アプリのすべてのインスタンスが午後 11 時に同期され、 レイテンシの上昇や 「サービス拒否攻撃」と呼んでいます。アラームを使用する場合は、以下のおすすめの方法に従ってください。

  • ネットワーク リクエストにランダム性(ジッター)を アラームが繰り返された場合のトリガー:

    • アラームがトリガーされたときにローカル処理を実行します。「ローカル作業」つまり、 サーバーにヒットしないか、サーバーからのデータを必要としません。

    • 同時に、ネットワーク リクエストを含むアラームのスケジュールを設定します。 呼び出されるようにトリガーできます。

  • アラームの頻度は最小限に維持します。

  • デバイスを不必要に復帰させないでください(この動作は、 (アラームタイプを選択するをご覧ください)。

  • アラームのトリガー時刻を必要以上に正確に設定しないでください。

    使用 setInexactRepeating()setRepeating()setInexactRepeating() を使用する場合: Android は、複数のアプリの繰り返しアラームを同期して発動します。 同時に使用できます。これにより、システムが復帰する合計回数が バッテリーの消耗を抑えることができます。Android 4.4 以降 (API レベル 19)の場合、繰り返しアラームはすべて不正確なアラームとなります。備考 その一方で setInexactRepeating() Google Cloud の setRepeating(), それでもアプリのすべてのインスタンスがサーバーにヒットすると、サーバーに過負荷をかける可能性がある 行います。そのため、ネットワーク リクエストの場合は、なんらかのランダム性を アラームを設定します。

  • 可能であれば、時計で目覚ましを設定することは避けてください。

    正確なトリガー時間に基づく繰り返しのアラームは、うまく調整できません。使用 次の場合は ELAPSED_REALTIME できます。別のアラーム 各タイプの詳細については、次のセクションで説明します。