12

We develop an Android SDK and, while testing the Android 11 Beta, we found a problem that does not seem to be reported yet.

In Android 11, new one-time permissions have been introduced for Location, Microphone and Camera permissions. With this option, as soon as the user leaves the application, the permission is revoked (more details can be found here).

The problem is that after a short amount of time when the app is no longer in the foreground (it is not necessary to kill the app, just minimizing is enough), all future scheduled alarms or jobs are removed, as if the app was force killed. This only happens with this level of permission. Denying or providing other levels keep the previously scheduled alarms or jobs, as expected. We have reproduced this in the Beta 3 build, in a Pixel 2 emulator with the RPB3.200720.005 build number. In this repo you can find a sample app for reproducing the bug.

This single activity app schedules an alarm to ring in the next five minutes, as well as a job to trigger in between 5-6 minutes. The screen has three buttons, each triggering the corresponding permission request. The JobService and BroadcastReceiver classes only log that they have been triggered. The situation can be reproduced after the following steps:

  1. Whenever the app is started, it is possible to run both adb shell dumpsys alarm | grep com.example.permissions.app and adb shell dumpsys jobscheduler | grep com.example.permissions.app to see that both the alarm and the job are scheduled;
  2. Click in any of the buttons and grant the one-time permission level;
  3. Minimize the app (you can go to the home screen or open other app);
  4. After around a minute, run both adb shell dumpsys alarm | grep com.example.permissions.app and adb shell dumpsys jobscheduler | grep com.example.permissions.app. The alarm and job will no longer appear;
  5. Waiting the original scheduled times for both job and alarm (with lenience for system delays) will show that they won't be triggered.

Have any of you encountered a similar situation? Our hunch is that to revoke the one-time permissions, the app process is being killed in some way that is causing these side effects. We also submitted an issue on Android Issue Tracker, and we will keep this post updated if Google answers it.

Gabriel Falcone
  • 648
  • 4
  • 16
  • 2
    Not sure if will be fixed by final version of Android 11, but you can read about this here: https://commonsware.com/blog/2020/08/28/android-r-one-time-permission-expiration-sometimes-kills-alarms-jobs.html – android developer Aug 29 '20 at 10:37

1 Answers1

0

The issue was 'solved'. The problem was actually with Android Studio calling a force close when the permission was revoked after closing the app.

The actual Google's response:

Thank you very much for raising this issue, and providing sample code to reproduce it. After investigating further, we discovered that this is due to an interaction between Android Studio and apps launched via the "Run" command.

Specifically, when Android revokes an app's permission, it kills that app's process. We found that Android Studio sends a force-stop command via adb when it observes the app it launched is no longer running.

If the app is started via the launcher (including in an emulator that's connected to Android Studio), the app is not force-stopped, and the alarm and job both run as expected.

So it won't cause additional issues except during development phase. For further information, please check out the Android issue tracker linked in the question.

Gabriel Falcone
  • 648
  • 4
  • 16