Frage Android exact Alarm ist immer 3 Minuten aus


Ich habe eine App, die die verwendet AlarmManager um das Telefon regelmäßig zur vollen Stunde aufzuwecken und eine Nachricht an eine Android Wear-Uhr zu senden, die dann kurz vibriert. Ich habe zwei Nutzer mit einem Samsung Galaxy S6 mit Android 5.1.1 und die Sony SW 3 mit 5.1.1, die einen seltsamen Bug erleben. In der allerersten vollen Stunde ist die Schwingung genau zur gleichen Zeit, aber alle anderen Schwingungen sind 3 Minuten verzögert. Manchmal ist sogar die erste volle Stunde Vibration verzögert.

Hier ist ein Code:

final Calendar time = Calendar.getInstance();
time.set(Calendar.SECOND, 0);
time.set(Calendar.MILLISECOND, 0);
time.set(Calendar.MINUTE, 0);
time.set(Calendar.HOUR_OF_DAY, time.get(Calendar.HOUR_OF_DAY) + 1);

final Intent hourlyChimeIntent = new Intent(context, HourlyChimeReceiver.class);
hourlyChimeIntent.setAction(key);
final AlarmManager am = (AlarmManager)context.getSystemService(Context.ALARM_SERVICE);
final PendingIntent pi = PendingIntent.getBroadcast(context, 0, hourlyChimeIntent, PendingIntent.FLAG_CANCEL_CURRENT);
am.setExact(AlarmManager.RTC_WAKEUP, time.getTimeInMillis(), pi);

Ich erwerbe ein WakeLock im Empfänger und dann eine Nachricht an die Wear Uhr in einem Thread senden. Keine Vibration wird verpasst, sie sind nur 3 Minuten zu spät.

Ich habe keine weiteren Berichte über dieses Problem und alle meine Testgeräte funktionieren gut. Ich habe kein Samsung-Gerät.

Irgendwelche Ideen, was die 3 Minuten Verspätung verursachen könnte? Wird Samsung ignoriert? setExact und macht meinen Alarm zu ungenau? Wie man exakte Alarme auf Samsungs erzwingt?

BEARBEITEN:

Hier ist der Android Wear-spezifische Code. Im Empfänger onReceive Methode mache ich das:

final PowerManager mgr = (PowerManager)context.getSystemService(Context.POWER_SERVICE);
final PowerManager.WakeLock lock = mgr.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, BuildConfig.APPLICATION_ID);
lock.acquire(7L * 1000L);

final GoogleApiClient googleApiClient = new GoogleApiClient.Builder(context).addApi(Wearable.API).build();

new Thread(new Runnable() {
    @Override
    public void run() {
        googleApiClient.blockingConnect();

        long pattern[];
        pattern = new long[] {0L, 500L};

        final NodeApi.GetConnectedNodesResult nodes = Wearable.NodeApi.getConnectedNodes(googleApiClient).await(2000L, TimeUnit.MILLISECONDS);

        if (nodes != null) {
            for (final Node node : nodes.getNodes()) {
                // just send and forget
                Wearable.MessageApi.sendMessage(googleApiClient, node.getId(), "/hourly_chime", Utils.Vibrator.serializeVibratePattern(pattern).getBytes()).await();
            }
        }
    }
}).start();

16
2017-12-03 19:53


Ursprung


Antworten:


Das Problem scheint nur bei Samsung-Geräten (z. B. Galaxy Grand, S4, S5, S6, Note 3, Note 4) mit Lollipop (5.0, 5.1, 5.1.1) aufzutreten. Es scheint, dass die Alarme ungenau sind, wenn das Gerät bei ausgeschaltetem Bildschirm im Akkubetrieb ist. Wenn das Gerät während der Terminierung des Alarms geladen oder eingeschaltet wird, tritt das Problem nicht auf.

Sie können überprüfen, ob der nächste Alarm ungenau ist mit:

adb shell dumpsys alarm

Ich habe keine perfekte Lösung für dieses Problem gefunden - nur Workarounds, bei denen jeder einige Nachteile hat:

  1. Benutzen setAlarmClock stattdessen setExact (sehen diese Antwort). Dies funktioniert sehr gut (nicht auf allen Geräten), aber das Problem mit dieser Lösung ist, dass der Alarm das System beeinflusst, indem er das Alarmsymbol in der Statusleiste anzeigt (wenn jemand noch keinen Wecker eingestellt hat) und die nächste Alarmzeit anzeigt auf Alarm Widgets etc. Leider funktioniert das bei Galaxy Grand mit 5.1.1 aber nicht auf Galaxy S4 mit 5.0.1.
  2. Aktivieren Sie den Bildschirm, bevor Sie den Alarm planen (ich mache diese halbe Sekunde vor der Planung des nächsten Alarms, um die Wettlaufsituation zu vermeiden). Natürlich ist es keine gute Lösung für jede App, den Bildschirm zu aktivieren, um den nächsten Alarm zu planen.
  3. Ein Fehlerbericht beschreibt ähnliches Problem verbindet es mit der Länge des App-Paketnamens! Ich habe nicht überprüft, ob das Problem wirklich behoben wird, da das Ändern des Paketnamens für bereits veröffentlichte Apps keine Option ist.
  4. Es gibt ein anderer Bericht wo jemand behauptet, dass dies mit Hilfe behoben werden kann WakefulBroadcastReceiver, aber es funktioniert nicht in meinem Fall.

BTW Diese Ausgabe macht mich verrückt :)

Bearbeiten: Dieses Problem tritt nicht auf, wenn das Schlüsselwort "Alarm" oder "Warnung" im Namen des App-Pakets enthalten ist (wie von Mathieu H. in den Kommentaren unten angegeben).

Ich war auch in der Lage, das Problem manuell durch zu beheben Deaktivierung der App-Optimierung in Akkueinstellungen (oder in der Smart Manager App). Es scheint, dass es nicht programmgesteuert durchgeführt werden kann, also können Sie versuchen, Ihre Benutzer zu fragen ...


22
2017-12-04 10:02