Почему режим ожидания не влияет на функцию AlarmManager setExact ()? - PullRequest
0 голосов
/ 04 октября 2019

Я пытаюсь проверить поведение моего приложения для Android, когда ОС переходит в режим ожидания. Я использую эмулятор gennymotion под управлением Android API 25. Приложение запускает IntentService через AlarmManager, используя метод setExact с типом RTC_WAKEUP. Я включил будильник через 1 минуту (только для целей тестирования).

Это служебный код намерения (MyService.java): -

public class MyService extends IntentService {

public static final String TAG = "noor";

@Override
public void onHandleIntent(Intent intent) {
    for (int i = 1; i <= 10; i++) {
        Log.d(TAG, "i: " + i);

        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

}

Это код менеджера аварийных сигналов: -

AlarmManager alarm = (AlarmManager) getSystemService(Context.ALARM_SERVICE);
        Intent intent = new Intent(this, MyService.class);
        PendingIntent pendingIntent = PendingIntent.getService(this, 101, intent, 0);
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
            alarm.setExact(AlarmManager.RTC_WAKEUP,System.currentTimeMillis() + (60 * 1000),pendingIntent);
        }

}

только для того, чтобы убедиться, что успешно впереводим эмулятор в состояние IDLE, выполняя предложенные команды dumpsys следующим образом: -

adb shell dumpsys deviceidle enable
adb shell dumpsys battery unplug
adb shell dumpsys deviceidle force-idle

Я даже дважды проверил, используя

adb shell dumpsys deviceidle get deep

Теперь вот проблема: -

Даже когда устройство находится в режиме ожидания, я все еще могу видеть, что IntentService (MyService) запускается сигналом тревоги. Вот результаты LogCat: -

    2019-10-04 01:42:20.842 1818-1922/com.example.android.sunshineweatherapp D/noor: i: 1
2019-10-04 01:42:21.843 1818-1922/com.example.android.sunshineweatherapp D/noor: i: 2
2019-10-04 01:42:22.845 1818-1922/com.example.android.sunshineweatherapp D/noor: i: 3
2019-10-04 01:42:23.856 1818-1922/com.example.android.sunshineweatherapp D/noor: i: 4
2019-10-04 01:42:24.857 1818-1922/com.example.android.sunshineweatherapp D/noor: i: 5
2019-10-04 01:42:25.859 1818-1922/com.example.android.sunshineweatherapp D/noor: i: 6
2019-10-04 01:42:26.860 1818-1922/com.example.android.sunshineweatherapp D/noor: i: 7
2019-10-04 01:42:27.861 1818-1922/com.example.android.sunshineweatherapp D/noor: i: 8
2019-10-04 01:42:28.862 1818-1922/com.example.android.sunshineweatherapp D/noor: i: 9
2019-10-04 01:42:29.863 1818-1922/com.example.android.sunshineweatherapp D/noor: i: 10

Это не должно быть ожидаемое поведение в соответствии с документами: -

Стандартные тревоги AlarmManager (включая setExact() и setWindow ()) откладываются до следующего окна обслуживания.

Так что я ожидал и обратного (поскольку setExact () не должен запускаться, если устройство находится в режиме ожидания). Я даже протестировал это на реальном устройстве (под управлением Android Marshmallow) и получил те же результаты.

Это ошибка? Или я что-то упустил?

Следующий вопрос может быть повторен, но ответ не дается должным образом: - Android M (предварительный просмотр) Режим ожидания и AlarmManager

PS: -

Это третий раз, когда я публикую этот вопрос на этой платформе, так как я не получил никаких ответов. Я не смог найти никакой помощи по всему Интернету (reddit, androidcentral, quora, coderanch).
Мне нужно создать приложение с будильником, и я не смогу правильно проверить поведение, еслиэта проблема сохраняется.

1 Ответ

1 голос
/ 05 октября 2019

Я НАШЕЛ ПРОБЛЕМУ:

Во-первых, режим Doze не влиял не влиял функция setExact () alarmmanager * , когда я тестировал свое приложениев эмуляторе (в моем случае я использовал genymotion).

Затем я решил использовать физический телефон, то есть HTC Desire 530, но результаты остались прежними. Это то место, где я был разочарован, пока не обнаружил что-то очень интересное на официальной странице поддержки документации HTC , а именно:

Телефон выходит из режима ожидания, когда:

Вы подключаете адаптер питания и заряжаете телефон.

Есть движение, например, когда вы поднимаете трубку.

В установленное время сработает будильник.

Я подумал, может ли 3-я точка быть причиной того, что режим сна не влияет на метод setExact аларм-менеджера. Поэтому я проверил свое приложение в другом телефоне, например, OPPO A3s. Здесь все работает как ожидалось!

Метод setExact не работал в режиме ожидания, пока он работал, когда я выходил из режима ожидания! , пока setExactAndAllowWhileIdle ()побежал так же, как написано в документации.

Итак, я пришел к выводу, что: -

  • HTC, возможно, изменил поведение режима сна? (Поскольку Android официально ограничивает выполнение AlarmManager SetExact в режиме ожидания, в то время как HTC этого не делает). Причина этого (возможно, наивного) предположения заключается в том, что в некоторых телефонах с ОС Android я столкнулся с нестандартным поведением, например, сработал будильник, даже если устройство было ВЫКЛЮЧЕНО!
  • и, что не менее важно, никогдадоверяйте своему эмулятору: p

PS:

, если вам интересно, почему я так обеспокоен этим, это потому, что я работаю над приложением тревоги и используюAlarmManager для выполнения задач на основе времени. Я бы не смог протестировать свое приложение должным образом, если бы эта проблема сохранялась (надеюсь, вы поняли мою точку зрения).

Фоновые ограничения Android и оптимизация батареи сделали простые вещи сложными.

ОБНОВЛЕНИЕ: -

Режим ожидания не влиял на набор сигналов тревоги setExact (), даже когда я включил оптимизацию заряда аккумулятора в HTC Desire 530.

...