Android get list of active alarms

Question

Is there any way to get a list of all the active alarms in the android device programmatically in our application programmatically.Just point me out to some links that can b

Answer 1

For getting active alarms, there is no work-around yet, but to get the list of alarms - use the RingtoneManager, which has access to alarm tones, ringtones & notification sounds.

1. To launch the default intent of user selecting an alarm, you can launch an implicit intent like so:

private void selectAlarmTone(){
    Intent intent = new Intent(RingtoneManager.ACTION_RINGTONE_PICKER);
    intent.putExtra(RingtoneManager.EXTRA_RINGTONE_TYPE, RingtoneManager.TYPE_ALARM); //Incase you want the user to set a notification use => RingtoneManager.TYPE_NOTIFICATION, ringtone use => RingtoneManager.TYPE_RINGTONE
    intent.putExtra(RingtoneManager.EXTRA_RINGTONE_TITLE, "Select an alarm tone");
    intent.putExtra(RingtoneManager.EXTRA_RINGTONE_EXISTING_URI, (Uri) null);
    startActivityForResult(intent, 1);
}

and to get the alarm that the user has selected use from onActivityResult:

@Override
protected void onActivityResult(final int requestCode, final int resultCode, final
Intent data) {
    super.onActivityResult(requestCode, resultCode, data);
    if (resultCode == Activity.RESULT_OK && requestCode == 1) {
        Uri selectedUri = data.getParcelableExtra(RingtoneManager.EXTRA_RINGTONE_PICKED_URI);

        Ringtone ringtone = RingtoneManager.getRingtone(this, selectedUri);
        String title = ringtone.getTitle(this);
        Log.i("ALARM_SELECTED: ", title);
    }
}

2. Incase you want to get the list of the tones programmatically, use:

public void listAlarmtones() {
    RingtoneManager ringtoneManager = new RingtoneManager(this);
    ringtoneManager.setType(RingtoneManager.TYPE_ALARM);
    Cursor cursor = ringtoneManager.getCursor();

      while (cursor.moveToNext()) {
        String title = cursor.getString(RingtoneManager.TITLE_COLUMN_INDEX);
        String uri = String.valueOf(ringtoneManager.getRingtoneUri(cursor.getPosition()));

        String alarmTone = cursor.getString(cursor.getColumnIndex("title"));

        Log.e("ALARM_TONE: ", title + "=>" + uri + "=>" + alarmTone);
      }
}

Answer 2

You can get the next alarm that is scheduled (docs)

getSystemService(AlarmManager::class.java).nextAlarmClock.triggerTime

Returns the time at which the alarm is going to trigger. This value is UTC wall clock time in milliseconds

Answer 3

Short answer: you can't.

The alarm manager gives no visibility to the alarms currently scheduled in the system. Every app that uses alarm manager must persist the state of each alarm that they set.

However you can get a list via adb as described in this question Get list of active PendingIntents in AlarmManager. And an app could get a system dump and get the alarms that way but that would require root.

Answer 4

No, AFAIK you can't do that programmatically so showing that info to a user in UI is not feasible.

However for your own reference you can dump the alarm data via

adb shell dumpsys alarm

You don't need root permission for that.

But what you get from above could be very confusing to understand. In order to understand that dump completely you should check out morphatic's answer here.

Answer 5

If you mean by active alarms, the ones in the device's Alarm Clock Application, I think you can. Try checking out the methods from Here.

However, if you mean that you want to see all alarms created by AlarmManager on your device, then unfortunately you can not do it programatically.

But, you can view the dump data in a text file like this:

adb shell dumpsys alarm > dump.txt

Answer 6

I just ran into this issue with my new phone. I migrated data from an older phone and in hindsight what I think happened was that an inactive alarm app suddenly activated, or a disabled alarm in that app enabled after migration. At any rate, what happened was that suddenly an alarm that I couldn't identify went off every day at 8:30.

The following outlines how I solved it. If you don't care about that, scroll to the TL;DR at the end.

Troubleshooting Process

The process I used was to use adb as described in other answers. However, if you do this, you'll quickly get overwhelmed. The output for me was a 2,000+ line output with this laconic message somewhere around line 260:

Pending alarm batches: 130

This is because these aren't what you and I would call alarms. Instead, they are various apps asking to be woken up at a particular time (e.g. a mail app asking to be awoken in a minute to check for new mail). So I guess alarms, but for apps. What I did was to first identify how a "proper" alarm looked. I already had two alarms in the official alarm app enabled and they had rung in the last 24 hours. So I first ran:

adb shell dumpsys alarm > two-alarms.txt

I then disabled one of the two alarms and ran:

adb shell dumpsys alarm > one-alarm.txt

I then compared the two outputs and noticed that most of the differences were to do with timestamps (which makes sense -- they are run at different times and the output is heavily focused on "what should I do X milliseconds from now"). For example, I'd see diff outputs like this:

287c293
<       type=3 expectedWhenElapsed=+1m51s619ms expectedMaxWhenElapsed=+1m51s619ms whenElapsed=+1m51s619ms maxWhenElapsed=+1m51s619ms when=+1m51s619ms
---
>       type=3 expectedWhenElapsed=+1m48s727ms expectedMaxWhenElapsed=+1m48s727ms whenElapsed=+1m48s727ms maxWhenElapsed=+1m48s727ms when=+1m48s727ms

I re-ran the diff, filtering out lines containing type=:

$ diff -I 'type=' two-alarms.txt one-alarm.txt|less

This still contains a lot of noise, but the relevant sections are easier to locate. For example, the first material difference I found was this:

561c567,573
< Batch{b03e994 num=1 start=1851593838 end=1851593838 flgs=0x1}:
---
> Batch{849c837 num=1 start=1851593838 end=1851593838 flgs=0x5}:
>     RTC_WAKEUP #0: Alarm{e855db5 statsTag *walarm*:com.google.android.gms.reminders.notification.ACTION_REFRESH_TIME_REMINDERS type 0 when 1606626000000 com.google.android.gms}
>       tag=*walarm*:com.google.android.gms.reminders.notification.ACTION_REFRESH_TIME_REMINDERS
>       type=0 expectedWhenElapsed=+4h30m42s565ms expectedMaxWhenElapsed=+4h30m42s565ms whenElapsed=+4h30m42s565ms maxWhenElapsed=+4h30m42s565ms when=2020-11-29 00:00:00.000
>       window=0 repeatInterval=0 count=0 flags=0x5
>       operation=PendingIntent{543c4a: PendingIntentRecord{97867bb com.google.android.gms startService}}
> Batch{3f531a4 num=1 start=1851593838 end=1851593838 flgs=0x1}:

This is clearly a reminder I have set up (or perhaps a generic "wake me up to check for reminders" alarm that Google Reminders has set up to check for reminders).

Some more digging in the output gives us:

1027c1033,1039
<       type=0 expectedWhenElapsed=+1d13h20m45s459ms expectedMaxWhenElapsed=+1d13h20m45s459ms whenElapsed=+1d13h20m45s459ms maxWhenElapsed=+1d13h20m45s459ms when=2020-11-30 08:50:00.002
---
>       type=0 expectedWhenElapsed=+1d13h20m42s566ms expectedMaxWhenElapsed=+1d13h20m42s566ms whenElapsed=+1d13h20m42s566ms maxWhenElapsed=+1d13h20m42s566ms when=2020-11-30 08:50:00.002
>       window=0 repeatInterval=0 count=0 flags=0x9
>       operation=PendingIntent{89757d2: PendingIntentRecord{127f2fd com.lge.clock broadcastIntent}}
> Batch{39e90a3 num=1 start=2045693838 end=2045693838 flgs=0x9}:
>     RTC_WAKEUP #0: Alarm{ba76fa0 statsTag *walarm*:com.lge.clock.show_quick_dismiss_noti type 0 when 1606820100000 com.lge.clock}
>       tag=*walarm*:com.lge.clock.show_quick_dismiss_noti
>       type=0 expectedWhenElapsed=+2d10h25m42s565ms expectedMaxWhenElapsed=+2d10h25m42s565ms whenElapsed=+2d10h25m42s565ms maxWhenElapsed=+2d10h25m42s565ms when=2020-12-01 05:55:00.000

So the official alarm app appears to be com.lge.clock, which makes perfect sense -- it's an LG phone. Let's look for that in the original output:

  u0a194:com.lge.clock +21s656ms running, 61 wakeups:
    +12s50ms 11 wakes 11 alarms, last -1d10h37m18s647ms:
      *walarm*:com.lge.clock.alarmclock.internal.for.lmk
    +8s338ms 17 wakes 17 alarms, last -1d12h42m26s219ms:
      *walarm*:com.lge.clock.show_quick_dismiss_noti
    +4s272ms 11 wakes 11 alarms, last -1d10h37m18s647ms:
      *walarm*:com.lge.clock.alarmclock.internal
    +1s2ms 11 wakes 11 alarms, last -1d10h38m15s71ms:
      *walarm*:com.lge.sizechangable.weather.action.force.update.currentonly
    +996ms 11 wakes 11 alarms, last -1d10h37m18s647ms:
      *walarm*:indicator

Here we can see that this app has had a number of alarms going off one day, 10 hours and 37 minutes and some seconds and milliseconds ago (-1d10h37m18s647ms). This makes sense. This output was ran at 18:32 (6:32pm) and one of my real alarms was set at 7:55. Recognizing how we can identify times of "last trigger", we can now search for that illusive 8:30 alarm. 8:30 is about one day, 10 hours, and two minutes from the time of the report, so we search for -1d10h2m and get:

  u0a235:net.fredericosilva.mornify +14s944ms running, 20 wakeups:
    +14s944ms 20 wakes 20 alarms, last -1d10h2m26s3ms:
      *walarm*:net.fredericosilva.mornify/.alarm.AlarmBroadcastReceiver

Hmm... what is net.fredericosilva.mornify? A quick search results in the Mornify Play Page. And lo and behold! I had Mornify installed with that alarm. I had totally forgotten that I had tested out this app in the past and forgot to delete it after I decided it didn't work for me. Problem solved!

TL;DR

Step 1:

Run the alarm output:

adb shell dumpsys alarm > my-alarms.txt

Step 2:

Figure out the relative time from now to the last time the illusive alarm ran. For example, if the time of running the output is 6:32:18pm and the alarm went off at 7am last morning, the difference is 6:32pm-7am+24 hours, or 1 day, 11 hours, 32 minutes, and 18 seconds (a spreadsheet can be handy here to do the time math for you).

Step 3:

Reformat the time difference as -DdHhMm, where D is the number of days, H is the number of hours and M is the number of minutes. We'll forget about seconds here to avoid problems with clock drift. In our example from before, this will be -1d11h32m.

Step 4:

Search for this string in the output from Step 1. If you don't find it, two to subtract or add a minute in the string to correct for clock differences.