Warum Android-Erinnerungen oft nicht feuern – und wie wir das lösen

Die häufigste Support-Anfrage für Medikamenten-Apps auf Android lautet in einer Variation: „Die Erinnerung kommt manchmal, manchmal aber auch nicht." Das ist kein Fehler der App und meistens auch kein Fehler der Entwickler:innen – es ist eine Folge der Art, wie Android mit Hintergrund-Prozessen umgeht. Hier ist, was technisch passiert und wie RemMedy das angeht.

Drei Mechanismen, die Android verwendet, um Strom zu sparen

Seit Android 6 („Doze") hat Google schrittweise Mechanismen eingeführt, die Apps im Hintergrund ausschalten, wenn das Gerät nicht aktiv benutzt wird. Die drei wichtigsten:

• Doze Mode – wenn das Gerät eine Weile unbenutzt auf dem Tisch liegt, werden Wake-Ups drastisch reduziert. Netzwerkzugriffe werden gebündelt, WorkManager-Jobs verzögert, Alarme werden auf „Maintenance Windows" verschoben. Kritisch: das kann Stunden dauern.
• App Standby Buckets – jede App landet je nach Nutzungsintensität in einem Bucket (active → frequent → rare → restricted). Wer RemMedy nur einmal am Tag öffnet, landet schnell in „frequent" oder „rare", was die Intervalle für Hintergrund-Arbeit verlängert.
• Vendor-Customizations – und jetzt wird es wild. Xiaomi, Samsung, OnePlus, Huawei, Honor und andere Hersteller haben eigene, aggressivere Schichten darüber gelegt. Xiaomis MIUI kann Apps ohne Nachfrage komplett beenden, sobald sie im Hintergrund sind. Samsungs „Optimierung" verhindert selbst explizit eingetragene Alarme. Die dontkillmyapp.com-Liste dokumentiert das seit Jahren.

Die API-Primitive, die wirklich funktionieren

Android bietet zwei APIs, die unter dem Radar all dieser Optimierungen am zuverlässigsten sind:

• AlarmManager mit setExactAndAllowWhileIdle() – diese Variante darf auch im Doze-Mode feuern, allerdings muss die App dafür die Berechtigung „SCHEDULE_EXACT_ALARM" haben (seit Android 12 explizit über die Systemeinstellung „Wecker & Erinnerungen" zu erteilen).
• WorkManager für wiederkehrende Hintergrund-Arbeit (bei uns: Pläne aktualisieren, neue Alarme setzen, Stock-Checks). Unterliegt den Bucket-Regeln, ist aber robust gegen Reboots und App-Updates.

RemMedy nutzt beide in Kombination: Jede einzelne Einnahme bekommt einen exakten Alarm. Ein WorkManager-Job im Hintergrund hält die nächsten 48 Stunden vor und plant nach Neustart/Update neu ein. Beides passiert offline – wir brauchen keine Push-Server, keine Google-Services, keinen Internetzugang.

Die drei Schritte, die der Nutzer beisteuern muss

Auch mit perfekt gebautem Alarm-Stack gibt es Dinge, die nur der Nutzer selbst freischalten kann. RemMedy fragt sie beim ersten Start in genau dieser Reihenfolge ab:

1. Benachrichtigungen zulassen – klingt trivial, aber seit Android 13 ist das ein expliziter Laufzeit-Dialog. Ohne diese Zustimmung sieht niemand eine Erinnerung.
2. Exakte Alarme zulassen – ein Deep-Link in die Systemeinstellung „Wecker & Erinnerungen". Seit Android 12 ist das eine App-spezifische Einstellung, Google hat sie absichtlich reibungsvoll gemacht, damit nur Apps, die sie wirklich brauchen, sie auch bekommen.
3. Akku-Optimierung deaktivieren – der wichtigste Schritt auf vielen Geräten. Ohne diese Ausnahme kann MIUI (Xiaomi) oder OneUI (Samsung) RemMedy einfach beenden.

Wir führen das im Onboarding durch – für Notifications und exakte Alarme mit echten Systemdialogen. Die Akku-Optimierung ist der Sonderfall: Android verbietet Apps, den Systemdialog dafür aufzurufen (außer in eng definierten Ausnahmen). Unsere Lösung: Wir prüfen den Status laufend im Hintergrund. Ist die Optimierung noch aktiv, erscheint im Heute-Tab eine Warnung mit Support-Links zu den Anleitungen der gängigsten Hersteller (Pixel, Samsung, Xiaomi, OnePlus) – weil jedes Gerät den Schalter an einer anderen Stelle versteckt.

Eine automatische Vendor-Erkennung per Build.MANUFACTURER haben wir bewusst nicht eingebaut: zu viele Custom-ROMs, zu viele Sub-Marken, und die Support-Seiten der Hersteller ändern sich ohnehin regelmäßig. Stattdessen sieht der Nutzer eine Liste der vier gängigen Ziele und wählt selbst. Das ist weniger „magisch", aber zuverlässiger.

Trotzdem bleibt es ein kultureller Bruch: Nutzer erwarten, dass eine App „einfach funktioniert", nicht, dass sie drei Systemeinstellungen anfassen müssen. Wir halten es für ehrlicher, das offen zu kommunizieren, als so zu tun, als ob es nicht nötig wäre.

Die Test-Erinnerung als Debug-Tool

In den Einstellungen gibt es einen Button „Test-Erinnerung". Er plant einen Alarm für 10 Sekunden später. Wenn er nicht feuert, ist mindestens einer der drei obigen Schritte offen – und der Nutzer kann das herausfinden, ohne auf die nächste echte Erinnerung warten zu müssen. Für Support-Anfragen ist das ein Lebensretter: Wir können anleiten, den Test laufen zu lassen, und haben sofort ein klares Signal.

Was wir nicht tun

Ein paar Dinge, die im Android-Ökosystem verbreitet sind und die wir bewusst weglassen:

• Kein Firebase Cloud Messaging für Erinnerungen. FCM wäre der „einfache" Weg, aber er setzt Google-Services voraus und schickt jeden Reminder-Trigger durch Google-Server. Das ist für eine Offline-first-App die falsche Antwort.
• Kein dauerhafter Foreground-Service. Einige Apps lösen das Akku-Optimierungsproblem, indem sie eine permanente Benachrichtigung zeigen und damit als „läuft sichtbar" gelten. Das funktioniert – aber es ist laut, nimmt Energie und fühlt sich für Nutzer wie Spam an.
• Keine Eskalations-Push-Nachrichten. Wir erinnern einmal zur geplanten Zeit, optional mit Premium-Option zur Wiederholung bis zur Bestätigung. Keine künstlichen „Vergiss nicht…"-Pushes nach 10 Minuten.

Fazit

Zuverlässige Erinnerungen auf Android sind machbar – aber überraschend viel ist davon nicht der Code, sondern die Systemeinstellungen. Wir könnten einfach so tun, als sei die App „Plug & Play", und die Kritik der Nutzer hinnehmen, wenn sie feststellen, dass doch nichts kommt. Der ehrlichere Weg ist, den Setup-Prozess offen zu kommunizieren, durchzuführen und testbar zu machen. Genau das haben wir bei RemMedy versucht.