Wecker stellen

Wecker haben folgende Eigenschaften:

• Mit ihnen können Sie Intents zu festgelegten Zeiten und/oder Intervallen auslösen.

• Sie können sie zusammen mit Übertragungsempfängern verwenden, um jobs oder WorkRequests zum Ausführen anderer Geschäftsabläufe.

• Sie werden außerhalb Ihrer Anwendung ausgeführt, sodass Sie sie zum Auslösen von Aktionen ausführen, auch wenn die App nicht ausgeführt wird selbst schläft.

• Sie helfen Ihnen, den Ressourcenbedarf Ihrer Anwendung zu minimieren. Sie können Vorgänge planen, ohne auf Timer oder kontinuierlich ausgeführte Dienste angewiesen zu sein.

Wecker mit ungenauer Uhrzeit stellen

Wenn eine App einen ungenauen Alarm auslöst, löst das System den Alarm irgendwann aus zu erhalten. Ungenaue Alarme bieten einige Garantien bezüglich des Timings von unter Berücksichtigung von Energiesparmodus-Einschränkungen wie Stromsparmodus:

Entwickler können die folgenden API-Garantien nutzen, um die Auslieferung ungenauer Benachrichtigungen anzupassen.

Nach einer bestimmten Zeit einen Wecker stellen

Wenn Ihre App set(), setInexactRepeating() oder setAndAllowWhileIdle() aufruft, klingelt der Wecker nie vor der angegebenen Auslösezeit.

Unter Android 12 (API-Level 31) und höher ruft das System den Wecker innerhalb einer Stunde nach der angegebenen Auslösezeit auf, es sei denn, es gelten Einschränkungen für den Energiesparmodus, z. B. der Energiesparmodus oder Doze.

Wecker in einem bestimmten Zeitraum senden

Wenn deine App setWindow() aufruft, wird der Wecker nie ausgelöst, bevor die festgelegten die Auslösungszeit. Sofern keine Einschränkungen für den Energiesparmodus gelten, wird der Alarm innerhalb des angegebenen Zeitfensters ausgeliefert, beginnend mit dem angegebenen Trigger .

Wenn Ihre App auf Android 12 oder höher ausgerichtet ist, kann das System die Ausführung eines ungenauen Weckers mit Zeitfenster um mindestens 10 Minuten verzögern. Aus diesem Grund werden windowLengthMillis-Parameterwerte unter 600000 auf 600000 zugeschnitten.

In regelmäßigen Abständen einen sich wiederholenden Alarm auslösen

Wenn Ihre App setInexactRepeating() aufruft, löst das System mehrere Alarme aus:

1. Der erste Wecker klingelt innerhalb des angegebenen Zeitfensters, beginnend mit der angegebenen Auslösezeit.
2. Nachfolgende Alarme werden normalerweise nach dem festgelegten Zeitfenster ausgelöst an. Die Zeit zwischen zwei aufeinanderfolgenden Aufrufen des Alarms kann variieren.

Genauen Wecker stellen

Das System löst einen genauen Alarm zu einem bestimmten Zeitpunkt in der Zukunft aus.

In den meisten Apps können Aufgaben und Ereignisse mithilfe von ungenauen Weckern geplant werden, um mehrere häufige Anwendungsfälle zu erfüllen. Wenn der Kern Ihrer App funktioniert, hängt von einem genau abgestimmten Alarm ab – z. B. bei einer Wecker-App. oder eine Kalender-App haben, dann ist es in Ordnung, stattdessen einen exakten Wecker zu verwenden.

Anwendungsfälle, die möglicherweise keine genauen Alarme erfordern

In der folgenden Liste sind gängige Workflows aufgeführt, für die möglicherweise kein genauer Wecker erforderlich ist:

Timing von Vorgängen während der Lebensdauer deiner App planen

Die Klasse Handler bietet mehrere gute Methoden zum Ausführen von Zeitfunktionen, z. B. die Ausführung einer bestimmten Arbeit alle n Sekunden, während die App aktiv ist: postAtTime() und postDelayed(). Beachten Sie, dass diese APIs von der Systemverfügbarkeit abhängig sind. und nicht Echtzeit.

Geplante Hintergrundarbeiten wie das Aktualisieren der App und das Hochladen von Protokollen

WorkManager bietet die Möglichkeit, zeitgesteuerte regelmäßige Termine zu planen. arbeiten. Sie können ein Wiederholungsintervall und flexInterval (mindestens 15 Minuten) angeben, um detaillierte Laufzeit für die Arbeit definieren.

Vom Nutzer angegebene Aktion, die nach einer bestimmten Zeit ausgeführt werden soll (auch wenn das System inaktiv ist)

Verwenden Sie einen ungefähren Wecker. Rufen Sie insbesondere setAndAllowWhileIdle()

Vom Nutzer angegebene Aktion, die nach einer bestimmten Zeit ausgeführt werden soll

Einen ungenauen Alarm verwenden. Rufen Sie dazu set() an.

Vom Nutzer angegebene Aktion, die innerhalb eines bestimmten Zeitraums erfolgen kann

Einen ungenauen Alarm verwenden. Rufen Sie dazu setWindow() an. Wenn Ihre App auf Android 12 oder höher ausgerichtet ist, beträgt die kürzeste zulässige Zeitspanne 10 Minuten.

Möglichkeiten zum Stellen eines exakten Alarms

Ihre App kann mit einer der folgenden Methoden genaue Wecker stellen. Diese Methoden so angeordnet, dass diejenigen, die näher am Ende der Liste stehen, zeitkritische Aufgaben zu erledigen, die aber mehr Systemressourcen erfordern.

setExact()

Sie können einen Wecker zu einer nahezu genauen Zeit in der Zukunft stellen, sofern keine anderen Maßnahmen zur Akkuschonung aktiv sind.

Verwenden Sie diese Methode, um genaue Wecker einzustellen, es sei denn, die Arbeit Ihrer App ist für den Nutzer zeitkritisch.

setExactAndAllowWhileIdle()

Sie können einen Wecker zu einer nahezu genauen Zeit in der Zukunft stellen, auch wenn Akkusparmaßnahmen aktiviert sind.

setAlarmClock()

Sie können einen Wecker für eine bestimmte Uhrzeit in der Zukunft stellen. Diese Alarme sind für Nutzer gut sichtbar ist, passt das System die Lieferdauer nie an. Das System identifiziert diese Benachrichtigungen als die wichtigsten und beendet bei Bedarf den Energiesparmodus, um sie zu senden.

Verbrauch von Systemressourcen

Wenn das System genau die Wecker auslöst, die Ihre App stellt, verbraucht das Gerät viele Ressourcen, z. B. Akkulaufzeit, insbesondere wenn es sich im Energiesparmodus befindet. Außerdem kann das System diese Anfragen nicht einfach in Batches zusammenfassen. um Ressourcen effizienter zu nutzen.

Wir empfehlen dringend, einen ungenauen Alarm zu erstellen, möglich. Wenn Sie eine längere Aufgabe ausführen möchten, planen Sie sie mit WorkManager oder JobScheduler über die BroadcastReceiver Ihres Weckers. Wenn Sie Aufgaben ausführen möchten, während das Gerät im Ruhemodus ist, erstellen Sie mit setAndAllowWhileIdle() einen ungefähren Wecker und starten Sie einen Job über den Wecker.

Entsprechende Berechtigung für exakte Alarme erklären

Wenn deine App auf Android 12 oder höher ausgerichtet ist, musst du die "Wecker und Erinnerungen“ App-Zugriff haben. Deklarieren Sie dazu die Berechtigung SCHEDULE_EXACT_ALARM in der Manifestdatei Ihrer App, wie im folgenden Code-Snippet gezeigt:

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

Wenn Ihre App auf Android 13 (API-Level 33) oder höher ausgerichtet ist, können Sie Deklarieren Sie entweder die SCHEDULE_EXACT_ALARM oder die USE_EXACT_ALARM Berechtigung.

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

Die Berechtigungen SCHEDULE_EXACT_ALARM und USE_EXACT_ALARM Sie signalisieren die gleichen Fähigkeiten, werden unterschiedlich gewährt und unterstützen unterschiedliche Anwendungsfälle. Ihre App sollte exakte Alarme verwenden und entweder Berechtigung SCHEDULE_EXACT_ALARM oder USE_EXACT_ALARM, nur wenn ein für den Nutzer sichtbarer Funktionen in Ihrer App erfordern zeitgenaue Aktionen.

USE_EXACT_ALARM

• Automatisch gewährt
• Kann vom Nutzer nicht widerrufen werden
• unterliegt einer anstehenden Google Play-Richtlinie
• Begrenzte Anwendungsfälle

SCHEDULE_EXACT_ALARM

• Vom Nutzer gewährt
• Breitere Auswahl an Anwendungsfällen
• Apps müssen bestätigen, dass die Berechtigung nicht widerrufen wurde

Die Berechtigung SCHEDULE_EXACT_ALARM wird für Neuinstallationen von Apps, die auf Android 13 (API-Level 33) und höher ausgerichtet sind Wenn ein Nutzer App-Daten über einen Sicherungs- und Wiederherstellungsvorgang auf ein Gerät mit Android 14 überträgt, wird die Berechtigung SCHEDULE_EXACT_ALARM auf dem neuen Gerät abgelehnt. Wenn eine vorhandene App diese Berechtigung bereits hat, wird sie vorab gewährt, wenn das Gerät auf Android 14 aktualisiert wird.

Hinweis: Wenn der exakte Wecker mit einem OnAlarmListener -Objekt enthält, zum Beispiel mit dem setExact API verwenden, ist die Berechtigung SCHEDULE_EXACT_ALARM nicht erforderlich.

Verwendung der Berechtigung SCHEDULE_EXACT_ALARM

Im Gegensatz zu USE_EXACT_ALARM muss die Berechtigung SCHEDULE_EXACT_ALARM vom Nutzer erteilt werden. Sowohl der Nutzer als auch das System können die Berechtigung „SCHEDULE_EXACT_ALARM“.

Um zu prüfen, ob Ihrer App die Berechtigung gewährt wurde, rufen Sie canScheduleExactAlarms() bevor du versuchst, einen exakten Alarm einzustellen. Wenn die Berechtigung SCHEDULE_EXACT_ALARM wird für Ihre App widerrufen, Ihre App wird beendet und alle zukünftigen exakten Wecker werden abgebrochen. Das bedeutet auch, dass der von canScheduleExactAlarms() bleibt für den gesamten Lebenszyklus deiner App gültig.

Wenn Ihrer App die Berechtigung SCHEDULE_EXACT_ALARMS gewährt wird, sendet das System ihr die Übertragung ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED. Ihre App sollte eine Übertragung implementieren. Empfänger, der die Folgendes:

1. Bestätigt, dass Ihre App weiterhin den speziellen App-Zugriff hat. Rufen Sie dazu canScheduleExactAlarms() auf. Diese Prüfung schützt Ihre App vor dem Fall, dass der Nutzer Ihrer App die und widerruft sie fast unmittelbar danach.
2. Richtet alle exakten Alarme, die Ihre App benötigt, basierend auf ihrem aktuellen Status neu ein. Diese Logik sollte der Vorgehensweise Ihrer App entsprechen, wenn sie die ACTION_BOOT_COMPLETED Nachricht an alle.

Nutzer um die Berechtigung SCHEDULE_EXACT_ALARM bitten

Bei Bedarf können Sie Nutzer auf die Seite Alarme & Erinnerungen im System wie in Abbildung 1 dargestellt. Gehen Sie dazu so vor:

1. Erklären Sie dem Nutzer auf der Benutzeroberfläche Ihrer App, warum Ihre App exakte Zeitplanung Alarme.
2. Rufen Sie einen Intent auf, der den ACTION_REQUEST_SCHEDULE_EXACT_ALARM Intent-Aktion.

Sich wiederholenden Wecker stellen

Durch wiederkehrende Alarme kann das System deine App bei einer wiederkehrenden ein.

Ein schlecht konzipierter Alarm kann den Akku stark beanspruchen und die Server. Daher werden ab Android 4.4 (API-Level 19) alle sich wiederholende Weckrufe sind ungenaue Alarme.

Ein sich wiederholender Alarm hat die folgenden Eigenschaften:

• Ein Alarmtyp. Weitere Informationen finden Sie unter Alarmtyp auswählen.

• Einen Triggerzeitpunkt. Wenn der von Ihnen angegebene Triggerzeitpunkt in der Vergangenheit liegt, wird der Wecker sofort ausgelöst.

• Intervall des Weckers. Zum Beispiel einmal täglich, stündlich oder alle 5 Minuten.

• Ein ausstehender Intent, der ausgelöst wird, wenn der Wecker klingelt. Wenn Sie einen zweiten Wecker stellen, der dieselbe ausstehende Absicht verwendet, wird der ursprüngliche Wecker ersetzt.

Wenn Sie eine PendingIntent() abbrechen möchten, übergeben Sie FLAG_NO_CREATE an PendingIntent.getService(), um eine Instanz des Intents abzurufen (falls vorhanden), und übergeben Sie diesen Intent dann an AlarmManager.cancel().

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)
}

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);
}

Weckertyp auswählen

Einer der ersten Überlegungen bei der Verwendung eines sich wiederholenden Weckers ist der Wecktyp das sein sollte.

Es gibt zwei allgemeine Uhrentypen für Wecker: „Abgelaufene Echtzeit“ und „Echtzeituhr“ (Real Time Clock, RTC). Für die vergangene Echtzeit wird die „Zeit seit Systemstart“ als Referenz verwendet. Die Echtzeituhr verwendet die UTC-Zeit (Uhrzeit auf der Weltzeituhr). Das bedeutet, dass die vergangene Echtzeit zum Einstellen eines Weckers geeignet ist, der auf der Zeit basiert (z. B. ein Wecker, der alle 30 Sekunden klingelt), da er sich nicht von Zeitzone oder Gebietsschema beeinflusst lässt. Die Echtzeituhr eignet sich besser für Alarme, die sind vom aktuellen Gebietsschema abhängig.

Beide Typen haben ein „Wakeup“- und besagt, dass die CPU des Geräts aktiviert werden soll, wenn der Bildschirm ist aus. Dadurch wird sichergestellt, dass der Alarm zum geplanten Zeitpunkt ausgelöst wird. Das ist nützlich, wenn Ihre App eine zeitliche Abhängigkeit hat. Wenn beispielsweise bestimmte Operation auszuführen. Wenn Sie die Weckversion des Weckertyps nicht verwenden, werden alle wiederkehrenden Wecker ausgelöst, wenn Ihr Gerät das nächste Mal aktiv ist.

Wenn der Wecker einfach in einem bestimmten Intervall ausgelöst werden soll (z. B. alle halbe Stunde), verwenden Sie einen der Typen für die vergangene Echtzeit. Im Allgemeinen ist die bessere Wahl.

Wenn der Wecker zu einer bestimmten Tageszeit klingeln soll, wählen Sie einen der uhrbasierten Echtzeit-Uhrtypen aus. Dieser Ansatz kann jedoch einige Nachteile haben. Die App lässt sich möglicherweise nicht gut in andere Sprachen übersetzen. Wenn der Nutzer die Zeiteinstellung des Geräts ändert, kann dies zu unerwartetem Verhalten führen. in Ihrer App. Auch der Weckertyp Echtzeituhr funktioniert nicht gut, wie oben beschrieben. Wir empfehlen, wenn möglich, einen Wecker mit Echtzeitfunktion zu verwenden.

Hier ist eine Liste der Typen:

• ELAPSED_REALTIME: Löst den ausstehenden Intent basierend auf der Zeit aus, die seit dem Start des Geräts vergangen ist gestartet, aber das Gerät nicht aktiviert. Die Verstrichene Zeit umfasst die Zeit, in der sich das Gerät im Ruhemodus befand.

• ELAPSED_REALTIME_WAKEUP: Das Gerät wird geweckt und die ausstehende Intent wird ausgelöst, nachdem seit dem Start des Geräts die angegebene Zeit verstrichen ist.

• RTC: Mit dieser Option wird der ausstehende Intent zum angegebenen Zeitpunkt ausgelöst, das Gerät wird jedoch nicht geweckt.

• RTC_WAKEUP: Das Gerät wird aktiviert, um den ausstehenden Intent zur angegebenen Zeit auszuführen.

Beispiele für abgelaufene Wecker in Echtzeit

Hier sind einige Beispiele für die Verwendung von ELAPSED_REALTIME_WAKEUP:

So wecken Sie das Gerät, damit der Wecker in 30 Minuten und danach alle 30 Minuten klingelt:

// 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
)

// 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);

So aktivieren Sie das Gerät, damit in einer Minute ein einmaliger (nicht wiederkehrender) Wecker ausgelöst wird:

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
)

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);

Beispiele für Echtzeit-Wecker

Hier sind einige Beispiele für die Verwendung RTC_WAKEUP

Wecke das Gerät auf, um gegen 14:00 Uhr den Alarm auszulösen. einmal täglich zur gleichen Zeit wiederholen:

// 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
)

// 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);

Aktiviere das Gerät, damit der Alarm genau um 8:30 Uhr und alle 20 Minuten ausgelöst wird. Danach:

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
)

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);

Präzision des Weckers festlegen

Wie bereits beschrieben, ist die Auswahl des Weckertyps oft der erste Schritt beim Erstellen eines Weckers. Ein weiterer Unterschied besteht darin, wie genau Ihr Wecker sein muss. Für die meisten Apps ist setInexactRepeating() die richtige Wahl. Wenn Sie diese Methode verwenden, synchronisiert Android mehrere ungenau wiederkehrende Wecker und löst sie gleichzeitig aus. Dadurch wird der Akku weniger beansprucht.

Verwende möglichst keine exakten Alarme. Für die seltene App mit starren können Sie einen genauen Alarm einstellen, indem Sie setRepeating()

Mit setInexactRepeating() Sie können kein benutzerdefiniertes Intervall festlegen, setRepeating() Sie müssen eine der Intervallkonstanten verwenden, z. B. INTERVAL_FIFTEEN_MINUTES, INTERVAL_DAY, und so weiter. Eine vollständige Liste finden Sie unter AlarmManager.

Einen Wecker ausschalten

Je nach App sollten Sie die Möglichkeit zum Abbrechen des Weckers einbinden. Wenn du einen Wecker ausschalten möchtest, ruf cancel() an im Alarm Manager an und übergeben die PendingIntent, die Sie nicht mehr benötigen zu feuern. Beispiel:

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

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

Wecker beim Neustart des Geräts starten

Standardmäßig werden alle Alarme abgebrochen, wenn ein Gerät ausgeschaltet wird. Um dies zu verhindern, können Sie Ihre App , um einen sich wiederholenden Wecker automatisch neu zu starten, wenn der Nutzer das Gerät neu startet. Dieses sorgt dafür, dass der AlarmManager ohne dass der Benutzer den Alarm manuell neu starten muss.

Gehe dazu so vor:

1. Legen Sie die RECEIVE_BOOT_COMPLETED fest. im Manifest Ihrer App angegeben. Dadurch kann deine App die ACTION_BOOT_COMPLETED die nach dem Systemstart gesendet wird. Dies funktioniert nur, App wurde bereits mindestens einmal vom Nutzer gestartet):

   <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>

2. Implementiere eine BroadcastReceiver, um die Übertragung zu empfangen:

   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. Fügen Sie den Empfänger mit einem Intent-Filter zur Manifestdatei Ihrer App hinzu, Filter auf der ACTION_BOOT_COMPLETED Aktion:

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

   Beachten Sie, dass im Manifest der Boot-Empfänger auf android:enabled="false" festgelegt ist. Das bedeutet, dass der Empfänger nur dann aufgerufen wird, wenn die Anwendung dies ausdrücklich zulässt. So wird verhindert, dass der Boot-Empfänger unnötig aufgerufen wird. Du kannst einen Empfänger aktivieren (z. B. wenn der Benutzer einen Alarm einstellt) wie folgt:

   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);
   

   Wenn Sie den Empfänger so aktivieren, bleibt er aktiviert, auch wenn der Nutzer das Gerät neu startet. Mit anderen Worten: Wenn der Empfänger programmgesteuert aktiviert wird, wird die Manifesteinstellung überschrieben, auch nach einem Neustart. Der Empfänger bleibt aktiviert, bis er von Ihrer App deaktiviert wird. So deaktivieren Sie einen Empfänger (z. B. wenn der Nutzer einen Wecker abbricht):

   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);
   

Alarme auslösen, während sich das Gerät im Stromsparmodus befindet

Geräte mit Android 6.0 (API-Level 23) werden unterstützt Stromsparmodus den Modus verlängert die Akkulaufzeit des Geräts. Wecker werden nicht ausgelöst, wenn sich das Gerät im Ruhemodus befindet. Geplante Wecker werden verschoben, bis das Gerät den Ruhemodus beendet. Wenn Sie Aufgaben auch dann erledigen müssen, wenn das Gerät inaktiv ist, haben Sie mehrere Möglichkeiten:

• Stellen Sie einen exakten Alarm ein.

• Nutzen Sie die WorkManager API, die für eine im Hintergrund. Sie können angeben, dass das System Ihre Arbeit beschleunigen soll, dass die Arbeit so schnell wie möglich abgeschlossen wird. Weitere Informationen finden Sie unter Aufgaben mit WorkManager planen

Best Practices

Jede Entscheidung, die Sie beim Entwerfen des wiederkehrenden Weckers treffen, kann Auswirkungen darauf haben, wie Ihre App Systemressourcen nutzt (oder missbraucht). Stellen Sie sich beispielsweise eine beliebte App vor, die mit einem Server synchronisiert wird. Wenn die Synchronisierung auf der Uhr basiert und jede Instanz der App um 23:00 Uhr synchronisiert wird, wird die Last auf der zu hoher Latenz oder sogar zu hoher „Denial of Service“. Beachten Sie bei der Verwendung von Weckern die folgenden Best Practices:

• Zufälligkeit (Jitter) zu allen Netzwerkanfragen hinzufügen, wird als Folge eines sich wiederholenden Weckers ausgelöst:

  • Erledige vor Ort Arbeit, wenn der Alarm ausgelöst wird. „Lokale Arbeit“ bedeutet alles, was keinen Server erreicht und keine Daten vom Server benötigt.

  • Planen Sie gleichzeitig den Wecker, der die Netzwerkanfragen enthält, so, dass er zu einem zufälligen Zeitpunkt ausgelöst wird.

• Beschränke die Alarmhäufigkeit auf ein Minimum.

• Das Gerät wird nicht unnötig geweckt. Dieses Verhalten wird durch den Weckertyp bestimmt, wie unter Weckertyp auswählen beschrieben.

• Legen Sie die Auslösezeit des Weckers nicht genauer fest, als es nötig ist.

  Verwenden Sie setInexactRepeating() anstelle von setRepeating() Wenn Sie setInexactRepeating() verwenden, synchronisiert Android wiederholte Wecker aus mehreren Apps und löst sie gleichzeitig aus. Dadurch wird die Gesamtzahl der Systemaufweckungen reduziert, was die Akkulaufzeit verlängert. Ab Android 4.4 (API-Level 19) sind alle wiederkehrenden Wecker ungenaue Wecker. Beachten Sie, dass setInexactRepeating() zwar eine Verbesserung gegenüber setRepeating() darstellt, aber dennoch einen Server überlasten kann, wenn alle Instanzen einer App den Server ungefähr zur selben Zeit aufrufen. Fügen Sie daher Ihren Benachrichtigungen für Netzwerkanfragen etwas Zufälligkeit hinzu, wie bereits erwähnt.

• Richte deinen Wecker nach Möglichkeit nicht auf die Uhrzeit zurück.

  Wiederholte Alarme, die auf einer genauen Auslösungszeit basieren, lassen sich nicht gut skalieren. Verwenden Sie nach Möglichkeit ELAPSED_REALTIME. Die verschiedenen Arten von Benachrichtigungen werden im folgenden Abschnitt ausführlicher beschrieben.