Skip to content

[Plugins android_alarm_manager] Invoking oneShot() from within a oneShot callback creates infinite threads #26813

Closed

Description

@eligt

The following code will end up creating an ever-increasing amount of threads:

void alarmServiceHandler() {
  final DateTime now = DateTime.now();
  final int isolateId = Isolate.current.hashCode;

  print("[$now] alarmServiceHandler isolate=${isolateId} function='$alarmServiceHandler'");

  AndroidAlarmManager.initialize().then((bool ready) {
    print("AndroidAlarmManager");
    if (ready) {
      print("AndroidAlarmManager.oneShot");
      final int alarmID = 1;
      AndroidAlarmManager.oneShot(const Duration(seconds: 1), alarmID, alarmServiceHandler, exact: true);
    }
  });

  print("[$now] alarmServiceHandler FINISH");
}

void main() {
  AndroidAlarmManager.initialize().then((bool ready) {
    print("AndroidAlarmManager");
    if (ready) {
      print("AndroidAlarmManager.oneShot");
      final int alarmID = 1;
      AndroidAlarmManager.oneShot(const Duration(seconds: 1), alarmID, alarmServiceHandler, exact: true);
    }
  });

  runApp(MyApp());
}

After execution of the function and new oneShot alarm is registered, I'd expect the thread to finish and get freed but that doesn't seem to happen. Note that the Isolate hash stays the same, but a new thread is created each time oneShot is called (and never released).

Activity

  1. Kartik1607 commented on Jan 20, 2019

    @Kartik1607
    Contributor
    void alarmServiceHandler() {
    ...
        AndroidAlarmManager.initialize().then((bool ready) {
            ...
            AndroidAlarmManager.oneShot(const Duration(seconds: 1), alarmID, alarmServiceHandler, exact: true);
        }
    ....
    }

    The handler is re-initializing AlarmManager, which in turn again calls up the handler after duration of 1 second. This seems to be a case of recursion.

  2. added this to the milestone on Jan 20, 2019
  3. eligt commented on Jan 21, 2019

    @eligt
    Author

    It's not recursion in that the alarm is re-enqueued once the old alarm handler has finished, so my expectation would be for the old thread to be released and a new one to be created for the new alarm - I'm not saying this should occur instantly but at some point the old threads should be released. Instead what I'm noticing is that new threads keep being created and the old ones are never released.

    Unless you're saying that the initialize() call holds the thread in some kind of loop? In that case, what's the best way to invoke an alarm handler from inside another alarm handler?

  4. eligt commented on Jan 21, 2019

    @eligt
    Author

    It looks like just calling AndroidAlarmManager.oneShot from within the alarm handler, without calling initialize first, seems to correct the issue. I'm wondering however, if this is the expected way of re-enqueuing an alarm from within the handler or just a fluke that it happens to work?

  5. added
    P2Important issues not at the top of the work list
    on May 29, 2020
  6. removed this from the milestone on Aug 17, 2020
  7. added and removed
    P2Important issues not at the top of the work list
    on Feb 4, 2021
  8. stuartmorgan-g commented on May 27, 2021

    @stuartmorgan-g
    Contributor

    Closing as android_alarm_manager is deprecated in favor of android_alarm_manager_plus.

  9. added 5 commits that reference this issue on Jun 21, 2021
  10. github-actions commented on Aug 1, 2021

    @github-actions

    This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

  11. locked as resolved and limited conversation to collaborators on Aug 1, 2021
  12. added
    P3Issues that are less important to the Flutter project
    and removed on Jun 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Issues that are less important to the Flutter projectp: android_alarm_managerThe Android background execution pluginpackageflutter/packages repository. See also p: labels.platform-androidAndroid applications specifically

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions