AlarmManager triggert nicht jede Stunde

  • Themenstarter Themenstarter Gelöschtes Mitglied 17508
  • Beginndatum Beginndatum
G

Gelöschtes Mitglied 17508

Gast
Hallo Forum,
ich habe mit meiner App folgendes Problem.

Ich möchte jede Stunde zu einem bestimmten Zeitpunkt eine SMS verschicken.
Das Ganze habe ich so realisiert, dass ich einen AlarmManager mit setRepeating habe und einen BroadcastReceiver, worin dann die SMS verschickt wird.

Weiters habe ich den AlarmManager mit RTC_WAKEUP versehen und die onReceive-Methode mit einem PowerManager PARTIAL_WAKE_LOCK versehen.

Leider bekomme ich aber nicht das gewünschte Ergebnis.

Sobald ich mein Handy ausschalte ( nur einen Screen lock mache und den Screen abschalte, also schlafen lege ) wird keine SMS mehr verschickt.

Erst wenn ich das Handy wieder einschalte ( Screen einschalte und unlocke ) dann wird sofort die SMS verschickt.

Kann mir vll. jemand sagen, wie ich mein Problem lösen kann?

Ich bin für jede Hilfe dankbar!

lG
 
Hallo,
danke Dir vielmals für deinen Link.

Ich habe in der Zwischenzeit auch etwas herausgefunden oder vll. herausgefunden.

Viele User berichten Probleme mit ihrem Deep Sleep Modus und dass ihr Telefon auch nicht aus diesem aufwachen würde.

Vll. liegt es daran, dass der PowerManager nicht wirklich funktioniert.

Ich kann zwar PowerManager.FULL_WAKE_LOCK Modus verwenden, aber ich glaube der wird nur bis zum API Level 16 oder so unterstützt, vll. funktioniert es damit.

Seltsam ist halt nur, dass die ganze App bei einem Kollegen anscheinend im Deep Sleep Modus funktioniert, aber er hat auch wiederum ein gerootetes Telefon.

Eventuell muss ich es noch mit anderen Herstellern und modifizierten Androiden versuchen um vll. zu einer eindeutigen Aussage zu kommen ...

Danke Dir trotzdem für Deine Hilfe!

lG
 
Ich weiss nicht, ob es dir hilft, aber ich habe für unsere App, die auch ein WakeLock benötigt, in dem Service, der einen SpeedTest durchführt, folgendes implementiert:
Java:
	private PowerManager powerManager;
	private PowerManager.WakeLock wakeLock = null;
	
	private void initPowerManager() {
		if (powerManager == null) {
			powerManager = (PowerManager) getSystemService(Context.POWER_SERVICE);
		}
		aquireWakeLock(true);
	}
	
	@SuppressWarnings("deprecation")
	@SuppressLint("Wakelock")
	private void aquireWakeLock(boolean register) {
		if (register) {
			if ((wakeLock != null) && wakeLock.isHeld()) {
				wakeLock.release();
			}
			wakeLock = powerManager.newWakeLock(PowerManager.SCREEN_DIM_WAKE_LOCK | PowerManager.ACQUIRE_CAUSES_WAKEUP, TestService.class.getSimpleName());
			wakeLock.acquire();
		} else {
			if ((wakeLock != null) && wakeLock.isHeld()) {
				wakeLock.release();
			}
		}
	}
	
	private void testScreenOnAndWakeup() {
		if (!powerManager.isScreenOn()) {
			aquireWakeLock(true);
		}
	}
	
	private void stopPowerManager() {
		aquireWakeLock(false);
	}

mit
Code:
#aquireWakeLock(boolean)
kann ich nun das Telefon "an" und "ab" schalten. Allerdings ist das Problem ja etwas anderes gelagert... Also ob es bei dir hilft... kA.

Wir mussten es machen, weil Android das Signal des Kernels über eine Änderung des Mobilen-Verbindungstypen im Sleep-Modus nicht weitersendet. Aus Stromspargründen. GPS geht natürlich trotzdem wunderbar, da ist Stromsparen auf einmal unwichtig. (Ich verstehe schon den Sinn, dass GPS auch mit ausgeschalteten Schirm weiter funktionieren soll - vielle Apps würden nicht funktionieren, wenn es anders wäre, aber es ärgert mich dennoch.)
 
Hallo,
danke Dir vielmals für Dein Beispiel.

Interessant finde ich, dass alle Artikel, die ich bis jetzt zu meinem Problem gefunden habe mittels einem Service gelöst wurden oder teilweise gelöst werden konnten.

Ich muss zugeben, dass ich es mit einem Service bis jetzt nicht versucht habe, aber daran kann es glaube ich auch nicht liegen!

Zudem muss ich auch gewährleisten, dass der AlarmManager wirklich triggert und dann in der onReceive Methode eine SMS versendet.
Bei einem "normalen" Service kann es ja passieren, dass das Hostsystem bei Speichermangel das Service stoppt.
Wird zwar selten vorkommen, aber alles was schieflaufen kann, wird auch schief laufen 🙂

Eventuell werde ich es einmal auf ein Service umschreiben und schauen, ob sich am Verhalten etwas ändern wird!

Danke Dir vielmals!

lG
 
Verstehe Service nicht notwendigerweise als etwas, das ewig laufen muss. In deinem Fall ist der AlarmManger der Trigger. Der Service macht dann nichts weiter, als die SMS abzusetzen. Eher wird in diesem Scenarion deine AlarmManager-Instanz nicht loslegen, als das der Service hier ein Problem darstellt. Denke einfach dran, das ein IntentService wirklich erst auf einem anderen Thread läuft. Ich glaube, gelesen zu haben, dass man ansonsten Arbeitslastige Jobs auch innerhalb von Services in weitere Threads auslagern sollte.
Wie gesagt: Das ist aber nicht dein Scenario. Du brauchst nur den Auslöser (AlarmManager) und etwas, das den SMS-Versand anstösst (Service).
 
Hallo,
danke Dir für deinen Tipp.

Den Auslöser, sprich den AlarmManager habe ich, der ist auch so eingestellt, dass er sich alle 60 wiederholt ( es sind 2 laufende AlarmManager, aber zu unterschiedlichen Zeiten! ).
In der onReceive Methode des BroadcastReceivers habe ich den SMS Versand eingebaut.

Vll. werde ich den SMS Versand aus der onReceive Methode des BroadcastManagers ausbauen und in ein Service auslagern.
Das Service selber werde ich trotzdem in die onReceive Methode einbinden, damit der BroadcastReceiver auf den AlarmManager hört!

Aber ob das wirklich hilft, wenn das Telefon im "Deep Sleep" Modus ist?
Andere, die ebenso mein Programm verwenden, haben seltsamerweise kein Problem damit.

Trotzdem danke Dir vielmals, ich werde mal ein Versuch mit einem Service starten.
 
Leider sind meine Erfahrungswerte mit dem AlarmManager eher gering. Wir mussten einmal eine App bauen, bei der eine Datensynchronisation alle 30 min (glaube ich) getriggert wurde. Aber da wurde nur ein spezielles Gerät (also ein Gerätetyp, ca. 50 Geräte wohl insgesamt) verwendet und auf dem lief es. Ich kann dir also mehr als ein paar halbgare Tipps nichts weiter sagen. Sorry.
 

Zurück
Oben