Одноразовые разрешения, вызывающие отмену фоновых запланированных заданий и предупреждений

Aug 21 2020

Мы разрабатываем Android SDK и при тестировании бета-версии Android 11 обнаружили проблему, о которой, похоже, еще не сообщалось.

В Android 11 были введены новые одноразовые разрешения для разрешений местоположения, микрофона и камеры. При использовании этой опции, как только пользователь покидает приложение, разрешение аннулируется (более подробную информацию можно найти здесь ).

Проблема в том, что по прошествии короткого промежутка времени, когда приложение больше не находится на переднем плане (нет необходимости убивать приложение, достаточно просто минимизировать), все будущие запланированные будильники или задания удаляются, как если бы приложение было принудительно убит. Это происходит только с этим уровнем разрешения. Отказ или обеспечение других уровней сохраняют ранее запланированные будильники или задания, как и ожидалось. Мы воспроизвели это в сборке Beta 3 в эмуляторе Pixel 2 с номером сборки RPB3.200720.005. В этом репо вы можете найти образец приложения для воспроизведения ошибки.

Это приложение для одного занятия планирует срабатывание будильника в течение следующих пяти минут, а также задание, которое будет срабатывать в течение 5-6 минут. На экране есть три кнопки, каждая из которых запускает соответствующий запрос разрешения. Классы JobService и BroadcastReceiver регистрируют только то, что они были запущены. Ситуацию можно воспроизвести, выполнив следующие действия:

  1. Всякий раз, когда приложение запускается, можно запустить оба adb shell dumpsys alarm | grep com.example.permissions.appи adb shell dumpsys jobscheduler | grep com.example.permissions.appувидеть, что и будильник, и задание запланированы;
  2. Щелкните любую из кнопок и предоставьте одноразовый уровень разрешения;
  3. Сверните приложение (вы можете перейти на главный экран или открыть другое приложение);
  4. Примерно через минуту запустите оба adb shell dumpsys alarm | grep com.example.permissions.appи adb shell dumpsys jobscheduler | grep com.example.permissions.app. Тревога и задание больше не появятся;
  5. Ожидание исходного запланированного времени и для задания, и для сигнала тревоги (с учетом системных задержек) покажет, что они не сработают.

Кто-нибудь из вас сталкивался с подобной ситуацией? Мы догадываемся, что для отмены одноразовых разрешений процесс приложения каким-то образом прекращается, что вызывает эти побочные эффекты. Мы также отправили сообщение о проблеме в системе отслеживания проблем Android и будем обновлять этот пост, если Google ответит на него.

Ответы

GabrielFalcone Sep 14 2020 at 12:38

Проблема была «решена». На самом деле проблема заключалась в том, что Android Studio вызывала принудительное закрытие, когда разрешение было отозвано после закрытия приложения.

Фактический ответ Google:

Большое спасибо за то, что подняли эту проблему и предоставили образец кода для ее воспроизведения. После дальнейшего исследования мы обнаружили, что это связано с взаимодействием между Android Studio и приложениями, запускаемыми с помощью команды «Выполнить».

В частности, когда Android отменяет разрешение приложения, он убивает процесс этого приложения. Мы обнаружили, что Android Studio отправляет команду принудительного останова через adb, когда видит, что запущенное приложение больше не работает.

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

Таким образом, это не вызовет дополнительных проблем, кроме как на этапе разработки. Для получения дополнительной информации ознакомьтесь с системой отслеживания проблем Android, указанной в вопросе.