CODEWITHSUNDEEP
androidalarmmanagerandroid-permissionsandroid-11
Gabriel Falcone
Gabriel Falcone

Reputation: 698

One-time permissions causing background scheduled jobs and alarms to be cancelled

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.

Upvotes: 12

Views: 771

Answers (2)

NonoyBrown
NonoyBrown

Reputation: 1

I know that my problem is not exact with this one but I also encountered this issue in android 11 in google map when I click this one time permission. I noticed that if you left your app for 1 minute in background and go back, the app process was killed.

I have 2 SupportMapFragment inside the viewpager and connected in TabLayout and every time this happen, view will be recreated, however the fragment that was in the current position of the viewpager is not recreated properly.

For those people who encountered this as well, you have to change your flow and use only 1 SupportMapFragment instead of two. In that way, your map fragment will recreated properly. I just handle the map state and marker depending on the tab current position

Upvotes: 0

Gabriel Falcone
Gabriel Falcone

Reputation: 698

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.

Upvotes: 0

Related Questions