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

[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).

[Kartik1607]

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.

[eligt]

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?

[eligt]

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?

[stuartmorgan]

Closing as android_alarm_manager is deprecated in favor of android_alarm_manager_plus.

[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.